Revision as of 01:29, 14 February 2011 by Eean (talk | contribs) (→Minutes)(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff) 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 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) 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=9817" Content is available under Creative Commons License SA 4.0 unless otherwise noted.