20110213 GitWorkflowAgenda: Difference between revisions

From KDE Community Wiki
(→‎Agenda: added git.git here, didn't get copied from the etherpad)
 
(21 intermediate revisions by 3 users not shown)
Line 6: Line 6:
** Qt: http://qt.gitorious.org/qt/pages/CommitPolicy
** Qt: http://qt.gitorious.org/qt/pages/CommitPolicy
** Videolan: http://wiki.videolan.org/Git
** Videolan: http://wiki.videolan.org/Git
** Git: http://repo.or.cz/w/git.git/blob/todo:/MaintNotes#l87
** Others?
** Others?
* Topic branches
* Topic branches
Line 30: Line 31:


===Examples We Can Learn From===
===Examples We Can Learn From===
* cmake - http://public.kitware.com/Wiki/Git/Workflow/Topic
* cmake - http://public.kitware.com/Wiki/Git/Workflow/Topic
  * assumes little collaboration in feature
** assumes little collaboration in feature
* Qt - http://qt.gitorious.org/qt/pages/CommitPolicy
* Qt - http://qt.gitorious.org/qt/pages/CommitPolicy
* VideoLan - http://wiki.videolan.org/Git
* VideoLan - http://wiki.videolan.org/Git
  * mostly just straightforward use of git, rather similar to us probably
** mostly just straightforward use of git, rather similar to us probably
* Linux? (mpyne)
* Linux? (mpyne)
  * quite different development, but it shows feature branches can be used for complicated projects (eean)
** quite different development, but it shows feature branches can be used for complicated projects (eean)
 
=== Proposed workflows ===
 
* [[/StevesIdea|Proposal from steveire]]


===How To Handle Topic Branches===
===How To Handle Topic Branches===
"emerge with at least a skeleton of a workable, kdelibs-relevant workflow for feature devel" - aseigo
"emerge with at least a skeleton of a workable, kdelibs-relevant workflow for feature devel" - aseigo
* too many feature branches -> impossible to test?
* too many feature branches -> impossible to test?
  * feature branches always happen. in cmake they stay private, as they do no collaborate on feature branches
** 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
** general consensus that feature branches should be public
* feature branches in the main repo, they are easier to find BUT:
* feature branches in the main repo, they are easier to find BUT:
  * we need a naming convention
** we need a naming convention
  * they should be deleted after merge
** they should be deleted after merge
* Branch Naming
* 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"
** 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
* Dead branches
  * should we develop some sort of 'garbage collection' scheme
** should we develop some sort of 'garbage collection' scheme
    * every year
*** every year
    * every release?
*** every release?
    * deleted branches are automatically saved on git.kde.org under backups/
*** deleted branches are automatically saved on git.kde.org under backups/
  * is it even a problem?
** is it even a problem?
  * graveyard repo - push old branches there, delete from main
** graveyard repo - push old branches there, delete from main




Line 61: Line 66:


===Merging===
===Merging===
* forward-porting vs. backporting
* forward-porting vs. backporting
* backporting has the advantage of...
* backporting has the advantage of...
  * is what we do currently
** is what we do currently
  * people run and test master
** people run and test master
* forward-porting
* forward-porting
  * ensures that all bug fixes in the stable release branch end up in the master branch
** 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
*** 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
** cleans up the git history a bit; each commit is only there once instead of the cloned commits created by cherry-pick
* conclusions
* 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.
** 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
** I'm not clear if there was a consensus on which should be the suggested method for people


Documenting best practices considerations
Documenting best practices considerations
* Always use 'git merge --log' when merging something into one of the official branches (master, KDE/4.6 etc)
* Always use 'git merge --log' when merging something into one of the official branches (master, KDE/4.6 etc)


???STILL NEED MORE HERE ON MERGING FROM LOG???
???STILL NEED MORE HERE FROM LOG ON MERGING???


===Common Task Recipies===
===Common Task Recipes===


* Need to document simple recipes for common tasks, do's/don'ts and lessons learned
* Need to document simple recipes for common tasks, do's/don'ts and lessons learned
Line 86: Line 91:
** Is more educational for a new user
** Is more educational for a new user
** forces users to be explicit about what they want to do and think about it more
** forces users to be explicit about what they want to do and think about it more
** once more experienced can use shorcuts, have an "Intermediate Git" page for this
** once more experienced can use shortcuts, have an "Intermediate Git" page for this
* Need knowledgeable Git users to come up with recipes for the different workflows once confirmed
* Need knowledgeable Git users to come up with recipes for the different workflows once confirmed
* mpyne offered to try do some by next weekend
* mpyne offered to try do some by next weekend
Line 108: Line 113:
===Commit Template===
===Commit Template===


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


===Recommended Git Config Settings===
===Recommended Git Config Settings===


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


* other possibilities
* other possibilities
  * 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:
* more details added later by jlayt:
  * Git has 3 config levels in descending order: repo, user, system, that get merged just like KConfig
** 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
** 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
** 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
** system in /etc/gitconfig is irrelevant for our purposes
* need to determine if we can ship defaults in .git/config
* need to determine if we can ship defaults in .git/config
  * commit template
** commit template
  * kde: shortcuts
** kde: shortcuts
* other settings probably belong at user level unless user needs different email for other non-KDE repos.
* other settings probably belong at user level unless user needs different email for other non-KDE repos.


===Release Branch Naming===
===Release Branch Naming===


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


  * 4.6
** 4.6
    * was there first
*** was there first
    * is closer to old convention
*** is closer to old convention
    * is shorter to type
*** is shorter to type
    * easier for kdesrc-build
*** easier for kdesrc-build
    * is what most people call local branches leading to bad pushes if really KDE/4.6
*** is what most people call local branches leading to bad pushes if really KDE/4.6


  * KDE/4.6
** KDE/4.6
    * is clearer and easier to grep as being release branches especially with feature branches
*** 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"
      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:
* 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
** block new branches for 4.x and KDE/4.x, only release team can create these
  * Message displayed will be something like:
** Message displayed will be something like:
    "Creation of release branches is restricted to the KDE Release Team"
*** "Creation of release branches is restricted to the KDE Release Team"
    "Push declined - attempted repository integrity violation"
*** "Push declined - attempted repository integrity violation"


* Will need to fix existing repos anyway
* Will need to fix existing repos anyway
* Most participants were ambivalent, a coin toss decided in favour of 4.x, but this is open to further debate once feature branch naming scheme is decided.


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


===Issues Not Addressed===
The following points were not dealt with in the meeting:


* The following points were not dealt with in the meeting:
* dealing with an unmergable 4.6
  * dealing with an unmergable 4.6
* Documentation
  * Documentation
** Other common tasks that we should offer nice little recipes for?
    * Other common tasks that we should offer nice little recipes for?
** Adapting http://techbase.kde.org/Policies/SVN_Commit_Policy
    * Adapting http://techbase.kde.org/Policies/SVN_Commit_Policy
** Using content from http://community.kde.org/Sysadmin/GitKdeOrgManual
    * Using content from http://community.kde.org/Sysadmin/GitKdeOrgManual
** Identifying other pages on techbase that need work
    * Identifying other pages on techbase that need work
** First draft of workflow documentation
    * 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  
  * branch names, auto-completion and other bash/zsh magic,
* recommend strategy for those working in both stable and master: two clones, or magic scripts to change build/install paths?
    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?


===Issues Outstanding===
===Issues Outstanding===


* The following points were addressed but were not decided
The following points were addressed but were not decided or need more discussion


* Common Task Recipes
** Need knowledgeable Git users to come up with recipes for the different workflows once confirmed


* Large Binaries
** Wait for git to be fixed
** Work with i18n team to develop simple git workflow and tools to meet their needs


* Release Branch Naming
* Commit Template
  * Final decision to be made of KDE/4.x vs 4.x
** appropriate place to save in repo (repo root or .git/ ?)
  * All repos to have release branches renamed once decided
** find if possible to activate through .git/config
 
* Recommended Git Config Settings
** mpyne has a bash alias for shifting sourcedir/builddir
** need to determine if we can ship defaults in .git/config
*** commit template
*** kde: shortcuts
 
* Release Branch Naming
** Final decision to be made of KDE/4.x vs 4.x
** All repos to have release branches renamed once decided
 
* Documentation
** aseigo to arrange documentation day once required decisions are made


===Action Points===
===Action Points===


* The following items are to be actioned:
The following items are able to be actioned immediately:
 
* Admin
** aseigo to report back to k-c-d
** aseigo to send out request for second meeting if required
** jlayt to help with minutes and action plan
 
* Workflow
** eean, steveire and PovAddict to draw up alternative workflow proposals


* Admin
* Common Task Recipies
  * aseigo to report back to k-c-d
** mpyne to try document some recipes by next weekend
  * aseigo to send out request for second meeting if required
  * jlayt to help with minutes and action plan


* Workflow
* Large Binaries
  * eean, steveire and PovAddict to draw up alternative workflows
** toma to restore wallpapers to svn


* Release Branch Naming
* Commit Template
  * sysadmins to block new 4.x and KDE/4.x branches
** jlayt to complete template from k-c-d


* Documentation
* Release Branch Naming
  * aseigo to arrange documentation day once required decisions are made
** sysadmins to block new 4.x and KDE/4.x branches


== Attendees ==
== Attendees ==

Latest revision as of 00:32, 23 February 2011

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.

Examples We Can Learn From

Proposed workflows

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


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

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)

???STILL NEED MORE HERE FROM LOG ON MERGING???

Common Task Recipes

  • Need to document simple recipes for common tasks, do's/don'ts and lessons learned
  • Recipes should not give shortcut versions or rely on values being set or not set in git config other than kde: alias:
    • e.g. "git push origin KDE/4.6:KDE/4.6" instead of "git push"
    • Means will always work in all circumstances
    • Is more educational for a new user
    • forces users to be explicit about what they want to do and think about it more
    • once more experienced can use shortcuts, have an "Intermediate Git" page for this
  • Need knowledgeable Git users to come up with recipes for the different workflows once confirmed
  • mpyne offered to try do some by next weekend
  • jlayt offered to help them make newbie friendly
  • Still need more people to help and clearer idea of what recipes are needed.

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 restored back to SVN by toma in a location of his and Uninstall's choosing

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 template as previously proposed on k-c-d

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.

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
    • 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
  • Most participants were ambivalent, a coin toss decided in favour of 4.x, but this is open to further debate once feature branch naming scheme is decided.

Issues Not Addressed

The following points were not dealt with in the meeting:

Issues Outstanding

The following points were addressed but were not decided or need more discussion

  • Common Task Recipes
    • Need knowledgeable Git users to come up with recipes for the different workflows once confirmed
  • Large Binaries
    • Wait for git to be fixed
    • Work with i18n team to develop simple git workflow and tools to meet their needs
  • Commit Template
    • appropriate place to save in repo (repo root or .git/ ?)
    • find if possible to activate through .git/config
  • Recommended Git Config Settings
    • mpyne has a bash alias for shifting sourcedir/builddir
    • need to determine if we can ship defaults in .git/config
      • commit template
      • kde: shortcuts
  • Release Branch Naming
    • Final decision to be made of KDE/4.x vs 4.x
    • All repos to have release branches renamed once decided
  • Documentation
    • aseigo to arrange documentation day once required decisions are made

Action Points

The following items are able to be actioned immediately:

  • Admin
    • aseigo to report back to k-c-d
    • aseigo to send out request for second meeting if required
    • jlayt to help with minutes and action plan
  • Workflow
    • eean, steveire and PovAddict to draw up alternative workflow proposals
  • Common Task Recipies
    • mpyne to try document some recipes by next weekend
  • Large Binaries
    • toma to restore wallpapers to svn
  • Commit Template
    • jlayt to complete template from k-c-d
  • Release Branch Naming
    • sysadmins to block new 4.x and KDE/4.x branches

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)