20110213 GitWorkflowAgenda

From KDE Community Wiki
Revision as of 01:29, 14 February 2011 by Eean (talk | contribs) (→‎Minutes)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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)