20110213 GitWorkflowAgenda: Difference between revisions
| Line 24: | Line 24: | ||
* branch names, auto-completion and other bash/zsh magic, e.g. http://blogs.oracle.com/linuxnstuff/2010/05/recommended_git-completionbash.html | * branch names, auto-completion and other bash/zsh magic, e.g. http://blogs.oracle.com/linuxnstuff/2010/05/recommended_git-completionbash.html | ||
== | == Minutes == | ||
Meeting Minutes | |||
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 == | == Attendees == | ||
Revision as of 01:19, 14 February 2011
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
Meeting Minutes 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)