20110213 GitWorkflowAgenda: Difference between revisions

← Older edit Newer edit →

Revision as of 22:42, 14 February 2011

Agenda for the February 13 KDE Core Git Workflow meeting

Agenda

3rd party examples we can learn from:
- CMake http://public.kitware.com/Wiki/Git/Workflow/Topic
- Qt: http://qt.gitorious.org/qt/pages/CommitPolicy
- Videolan: http://wiki.videolan.org/Git
- Others?
Topic branches
- strategy overview
- git recipes for the common cases
Bug fix strategy
- dealing with an unmergable 4.6
- 4.7 and beyond
Handling trivial changes
- require branches, allow direct to an integration branch or even master?
Other common tasks that we should offer nice little recipes for?
Adapting http://techbase.kde.org/Policies/SVN_Commit_Policy
Using content from http://community.kde.org/Sysadmin/GitKdeOrgManual
Identifying other pages on techbase that need work
First draft of workflow documentation
Commit template
Recommended Git config settings
branch names, auto-completion and other bash/zsh magic, e.g. http://blogs.oracle.com/linuxnstuff/2010/05/recommended_git-completionbash.html

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)

jlayt adding minutes from here, working backwards, others please work forwards from previous point :-)

Topic X: Large Binaries

* Some discussion on what to do with large binaries such as wallpapers, icons, etc
* GIT very inefficient, but work underway to resolve this
* Understanding was to stay in SVN, but some discussion if SVN will always be around
  * i18n teams
  * incomplete histories in GIT
  * extra admin burden on sysadmins
  * annoying for packagers
* Conclusion:
  * Have to stay in SVN until GIT is fixed, will wait until then, ok for others to stay there in interim
  * Would be ideal to move i18n over when dust settles, but would need to work with them to provide tools to keep their workflow simple.
  * Wallpapers to be restroed back to SVN by toma in a location of his and Uninstall's choosing

Topic X: Commit Template

* .commit-template file is default text used in all commit messages
  * remind devs of tags like BUG and FIXED-IN
  * remind of max width, empty line, better descriptions
  * considered a good thing
* can add to each repo as easy way to distribute but still allow each project to customise as required
* need to use "git config" command to activate (?) so add to techbase recipe
* use templete as previously proposed on k-c-d

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

dealing with an unmergable 4.6
Other common tasks that we should offer nice little recipes for?
Adapting http://techbase.kde.org/Policies/SVN_Commit_Policy
Using content from http://community.kde.org/Sysadmin/GitKdeOrgManual
Identifying other pages on techbase that need work
First draft of workflow documentation
branch names, auto-completion and other bash/zsh magic, e.g. http://blogs.oracle.com/linuxnstuff/2010/05/recommended_git-completionbash.html
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)