20110213 GitWorkflowAgenda: Difference between revisions

From KDE Community Wiki
Line 25: Line 25:


== Minutes ==
== Minutes ==
Meeting 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
Topic 1: Examples We Can Learn From
'''cmake - http://public.kitware.com/Wiki/Git/Workflow/Topic
* 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
Topic 2: How To Handle Topic Branches
'''"emerge with at least a skeleton of a workable, kdelibs-relevant workflow for feature devel" - aseigo
"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'''
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
Topic 3: Merging
'''forward-porting vs. backporting
* 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

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)