Revision as of 01:19, 14 February 2011 by Eean (talk | contribs) (→‎Results)

20110213 GitWorkflowAgenda

Agenda for the February 13 KDE Core Git Workflow meeting



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 - assumes little collaboration in feature Qt - VideoLan - 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 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)


  • 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)

This page was last edited on 23 February 2011, at 00:32. Content is available under Creative Commons License SA 4.0 unless otherwise noted.