Jump to content

20110213 GitWorkflowAgenda

From KDE Community Wiki

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" commands:
  * 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

* more details added later by jlayt:
  * Git has 3 config levels in descending order: repo, user, system, that get merged just like KConfig
  * repo config lives in .git/config, update with "git config", overrides all
  * user config lives in ~/.gitconfig, update with "git config --global", applies to all repos for user unless overridden by a repo
  * system in /etc/gitconfig is irrelevant for our purposes
* need to determine if we can ship defaults in .git/config
  * commit template
  * kde: shortcuts
* other settings probably belong at user level unless user needs different email for other non-KDE repos.


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

Outstanding issues

  1. dealing with an unmergable 4.6
  2. Other common tasks that we should offer nice little recipes for?
  3. Adapting http://techbase.kde.org/Policies/SVN_Commit_Policy
  4. Using content from http://community.kde.org/Sysadmin/GitKdeOrgManual
  5. Identifying other pages on techbase that need work
  6. First draft of workflow documentation
  7. branch names, auto-completion and other bash/zsh magic, e.g. http://blogs.oracle.com/linuxnstuff/2010/05/recommended_git-completionbash.html
  8. recommend strategy for those working in both stable and master: two clones, or magic scripts to change build/install paths?

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=9875"