20110213 GitWorkflowAgenda

From KDE Community Wiki
Revision as of 23:10, 15 February 2011 by Steveire (talk | contribs) (Add section for proposed workflows)

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