20110213 GitWorkflowAgenda
Agenda for the February 13 KDE Core Git Workflow meeting
Agenda
- 3rd party examples we can learn from:
- 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)
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)