Jump to content

20110213 GitWorkflowAgenda

From KDE Community Wiki
Revision as of 19:15, 14 February 2011 by Jlayt (talk | contribs) (→Minutes)

Agenda for the February 13 KDE Core Git Workflow meeting

Agenda

Minutes

See log at 20110213_GitWorkflowLog.

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)


Topic X - Recommended Git Config Settings 

* Recommend settings to devs are part of set-up KDE git recipe on techbase using "git config --global":
  * kde: remote name different for push and pull
  * name
  * email
  * commit template
  * color.ui: true
  * push.default: none
    * set to tracking to ensure always push to correct remote tracking branch, not whatever local branch is named
    * set to none to ensure git always require name of remote branch to be entered
      * viewed as safer for newbies, forces to be explicit about what they want to do
      * may prevent accidentally pushing all local branches to origin
      * advanced users will know to use tracking option instead

* other possibilities
  * mpyne has a bash alias for shifting sourcedir/builddir
  * Useful aliases like on http://wiki.videolan.org/Git?  Best stick to native git, advanced users can add later

Topic X: Release Branch Naming 

* Currently 2 different conventions KDE/4.6 in kdelibs/kdebase, and 4.6 in all others.
* Need to be consistent for packagers and to prevent stuff-ups when devs switch between repo's
* Healthy debate on relative merits

  * 4.6
    * was there first
    * is closer to old convention
    * is shorter to type
    * easier for kdesrc-build
    * is what most people call local branches leading to bad pushes if really KDE/4.6 ( but mitigated by push None option above?)

  * KDE/4.6
    * is clearer and easier to grep as being release branches especially with feature branches being in main repo which may lead to long results with git branch -r

* Either way need pre-commit hook to ensure no more wrong braches created:
  * block new branches for 4.x and KDE/4.x, only release team can create these
  * Message displayed will be something like:
    "Creation of release branches is restricted to the KDE Release Team"
    "Push declined - attempted repository integrity violation"

* Will need to fix existing repos anyway

* While most participants preferred KDE/4.x, a coin toss decided in favour of 4.x, but this is open to further debate once feature branch naming scheme is decided.

* Action points:
  * Final decision to be made of KDE/4.x vs 4.x
  * sys-admins to block both KDE/4.x and 4.x except for release team
  * All repos to have release branches renamed to match final decision

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)
Retrieved from "https://community.kde.org/index.php?title=20110213_GitWorkflowAgenda&oldid=9849"