20110213 GitWorkflowAgenda: Difference between revisions
| Line 25: | Line 25: | ||
== Minutes == | == Minutes == | ||
Aaron introduces purpose of meeting: determine workflow for kdelibs & kde-runtime and thus a default "KDE" workflow. | 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 | * assumes little collaboration in feature | ||
Qt - http://qt.gitorious.org/qt/pages/CommitPolicy | * Qt - http://qt.gitorious.org/qt/pages/CommitPolicy | ||
VideoLan - http://wiki.videolan.org/Git | * VideoLan - http://wiki.videolan.org/Git | ||
mostly just straightforward use of git, rather similar to us probably | * mostly just straightforward use of git, rather similar to us probably | ||
Linux? (mpyne) | * Linux? (mpyne) | ||
quite different development, but it shows feature branches can be used for complicated projects (eean) | * 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? | * too many feature branches -> impossible to test? | ||
feature branches always happen. in cmake they stay private, as they do no collaborate on feature branches | * 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 | * general consensus that feature branches should be public | ||
feature branches in the main repo, they are easier to find BUT: | * feature branches in the main repo, they are easier to find BUT: | ||
we need a naming convention | * we need a naming convention | ||
they should be deleted after merge | * they should be deleted after merge | ||
Branch Naming | * 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" | * 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 | * Dead branches | ||
should we develop some sort of 'garbage collection' scheme | * should we develop some sort of 'garbage collection' scheme | ||
every year | * every year | ||
every release? | * every release? | ||
deleted branches are automatically saved on git.kde.org under backups/ | * deleted branches are automatically saved on git.kde.org under backups/ | ||
is it even a problem? | * is it even a problem? | ||
graveyard repo - push old branches there, delete from main | * 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 | 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... | * backporting has the advantage of... | ||
is what we do currently | * is what we do currently | ||
people run and test master | * people run and test master | ||
forward-porting | * forward-porting | ||
ensures that all bug fixes in the stable release branch end up in the master branch | * 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 | * 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 | * cleans up the git history a bit; each commit is only there once instead of the cloned commits created by cherry-pick | ||
conclusions | * 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. | * 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 | * I'm not clear if there was a consensus on which should be the suggested method for people | ||
Documenting best practices considerations | Documenting best practices considerations | ||
Always use 'git merge --log' when merging something into one of the official branches (master, KDE/4.6 etc) | * 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:29, 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
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)