20110213 GitWorkflowAgenda

Agenda for the February 13 KDE Core Git Workflow meeting

Agenda

• 3rd party examples we can learn from:
  • CMake http://public.kitware.com/Wiki/Git/Workflow/Topic
  • Qt: http://qt.gitorious.org/qt/pages/CommitPolicy
  • Videolan: http://wiki.videolan.org/Git
  • Others?
• Topic branches
  • strategy overview
  • git recipes for the common cases
• Bug fix strategy
  • dealing with an unmergable 4.6
  • 4.7 and beyond
• Handling trivial changes
  • require branches, allow direct to an integration branch or even master?
• Other common tasks that we should offer nice little recipes for?
• Adapting http://techbase.kde.org/Policies/SVN_Commit_Policy
• Using content from http://community.kde.org/Sysadmin/GitKdeOrgManual
• Identifying other pages on techbase that need work
• First draft of workflow documentation
• Commit template
• Recommended Git config settings
• branch names, auto-completion and other bash/zsh magic, e.g. http://blogs.oracle.com/linuxnstuff/2010/05/recommended_git-completionbash.html

Minutes

See log at 20110213_GitWorkflowLog.

Aaron introduces purpose of meeting: determine workflow for kdelibs & kde-runtime and thus a default "KDE" workflow.

Topic 1: Examples We Can Learn From

* cmake - http://public.kitware.com/Wiki/Git/Workflow/Topic
  * assumes little collaboration in feature
* Qt - http://qt.gitorious.org/qt/pages/CommitPolicy
* VideoLan - http://wiki.videolan.org/Git
  * mostly just straightforward use of git, rather similar to us probably
* Linux? (mpyne)
  * quite different development, but it shows feature branches can be used for complicated projects (eean)

Topic 2: How To Handle Topic Branches "emerge with at least a skeleton of a workable, kdelibs-relevant workflow for feature devel" - aseigo

* too many feature branches -> impossible to test?
  * feature branches always happen. in cmake they stay private, as they do no collaborate on feature branches
  * general consensus that feature branches should be public
* feature branches in the main repo, they are easier to find BUT:
  * we need a naming convention
  * they should be deleted after merge
* Branch Naming
  * if a branch is specific to a subproject, e.g. solid, specify it in the branch name such as "solid/udevbackend". otherwise, give it a good descriptive name such as "pluggable-kconfig"
* Dead branches
  * should we develop some sort of 'garbage collection' scheme
    * every year
    * every release?
    * deleted branches are automatically saved on git.kde.org under backups/
  * is it even a problem?
  * graveyard repo - push old branches there, delete from main

Topic 2b: Emails it was decided that the issue of clones running into the "100 commit" max issue when pushing into the main repo should be tabled, as its a topic that affects others

Topic 3: Merging

* forward-porting vs. backporting
* backporting has the advantage of...
  * is what we do currently
  * people run and test master
* forward-porting
  * ensures that all bug fixes in the stable release branch end up in the master branch
    * This is a real problem: PovAddict noted two bug fixes in 4.6 that weren't in master
  * cleans up the git history a bit; each commit is only there once instead of the cloned commits created by cherry-pick
* conclusions
  * the two methods are not mutually exclusive: on the contrary, backporting commits makes it easier for the next person who wants to merge the stable branch into master.
  * I'm not clear if there was a consensus on which should be the suggested method for people

Documenting best practices considerations

* Always use 'git merge --log' when merging something into one of the official branches (master, KDE/4.6 etc)

Topic X: Release Branch Naming

* Currently 2 different conventions KDE/4.6 in kdelibs/kdebase, and 4.6 in all others.
* Need to be consistent for packagers and to prevent stuff-ups when devs switch between repo's
* Healthy debate on relative merits

  * 4.6
    * was there first
    * is closer to old convention
    * is shorter to type
    * easier for kdesrc-build
    * is what most people call local branches leading to bad pushes if really KDE/4.6 ( but mitigated by push None option above?)

  * KDE/4.6
    * is clearer and easier to grep as being release branches especially with feature branches being in main repo which may lead to long results with git branch -r

* Either way need pre-commit hook to ensure no more wrong braches created:
  * block new branches for 4.x and KDE/4.x, only release team can create these
  * Message displayed will be something like:
    "Creation of release branches is restricted to the KDE Release Team"
    "Push declined - attempted repository integrity violation"

* Will need to fix existing repos anyway

* While most participants preferred KDE/4.x, a coin toss decided in favour of 4.x, but this is open to further debate once feature branch naming scheme is decided.

* Action points:
  * Final decision to be made of KDE/4.x vs 4.x
  * sys-admins to block both KDE/4.x and 4.x except for release team
  * All repos to have release branches renamed to match final decision

Attendees

• Aaron Seigo (aseigo)
• Anne-Marie Mahfouf (annma)
• Albert Astals Cid (tsdgeos)
• Alex Fiestas (afiestas)
• Arjen Hiemstra (ahiemstra)
• Casian Andrei (skelet)
• Davide Bettio (Uninstall)
• Ekie Hein (Sho)
• Eli MacKenzie (argonel)
• Giulio Camuffo (giucam)
• Ian Monroe (eean)
• Ivan Čukić (ivan|home)
• John Layt (jlayt)
• Jonathan Callen (ABCD)
• Kurt Hindenburg (khindenburg)
• Laszlo Papp (djszapi)
• Marco Martin (notmart)
• Martin Grässlin (mgraesslin)
• Michael Pyne (mpyne)
• Nicolás Alvarez (PovAddict)
• Raphael Kubo da Costa (rakuco)
• Richard Moore (richmoore)
• Sune Vuorela (svuorela)
• Theo Chatzimichos (tampakrap)
• Thomas Baumgart (ipwizard)
• Tom Albers (toma)
• Wolfgang Rohdewald (wrohdewald)
• Stephen Kelly (steveire)