20110213 GitWorkflowAgenda: Difference between revisions
Appearance
Line 79: | Line 79: | ||
Topic X - Recommended Git Config Settings | Topic X - Recommended Git Config Settings | ||
* Recommend settings to devs are part of set-up KDE git recipe on techbase using "git config | * 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 | * kde: remote name different for push and pull | ||
* name | * name | ||
Line 95: | Line 95: | ||
* mpyne has a bash alias for shifting sourcedir/builddir | * 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 | * 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 | Topic X: Release Branch Naming |
Revision as of 22:04, 14 February 2011
Agenda for the February 13 KDE Core Git Workflow meeting
Agenda
- 3rd party examples we can learn from:
- 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)
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
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)