<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;"><span style=" font-family:'dejavu sans mono';">Hi,<br /></span><br>
<span style=" font-family:'dejavu sans mono';">We've been discussing the proposed move to git and how it affects existing </span><br /><span style=" font-family:'dejavu sans mono';">workflows on the KDE PIM enterprise branches maintained by KDAB.<br /></span><br>
<span style=" font-family:'dejavu sans mono';">We've come to the conclusion that we should all move to Mercurial instead.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Just kidding :)<br /></span><br>
<span style=" font-family:'dejavu sans mono';">Some background again:</span><br /><br>
<span style=" font-family:'dejavu sans mono';">KDAB maintains enterprise branches of parts of KDE for customer maintenance </span><br /><span style=" font-family:'dejavu sans mono';">contracts, including kdelibs, kdebase runtime, kdepimlibs, and kdepim.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Currently the active enterprise branches are enterprise35 (based on KDE3.5), </span><br /><span style=" font-family:'dejavu sans mono';">enterprise5 (currently based on KDE trunk, to be based on KDE4.5 for its </span><br /><span style=" font-family:'dejavu sans mono';">release). Considering a future where KDE4.6 is released and master is to </span><br /><span style=" font-family:'dejavu sans mono';">become KDE 4.7, we have all of these branches:<br /></span><br>
<span style=" font-family:'dejavu sans mono';">enterprise 35 (e35)</span><br /><span style=" font-family:'dejavu sans mono';">enterprise 5 (e5)</span><br /><span style=" font-family:'dejavu sans mono';">KDE 4.6</span><br /><span style=" font-family:'dejavu sans mono';">KDE master</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Fixes should be forward ported down the list. However, fixes will also need to </span><br /><span style=" font-family:'dejavu sans mono';">be backported up the list. Anyone who fixes a bug in kdelibs is unlikely to fix </span><br /><span style=" font-family:'dejavu sans mono';">it in our enterprise branch first and forward port. Hopefully they'll fix in 4.6 </span><br /><span style=" font-family:'dejavu sans mono';">first and forward port though.<br /></span><br>
<span style=" font-family:'dejavu sans mono';">Some commits higher up the list should also not be forward ported down the </span><br /><span style=" font-family:'dejavu sans mono';">list, such as changelog changes, customer specific hacks, commits in e5 </span><br /><span style=" font-family:'dejavu sans mono';">introducing new strings need to skip KDE4.6, etc. Similarly some commits in </span><br /><span style=" font-family:'dejavu sans mono';">trunk should not be backported up the list.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Finally, some commits which should be forward or backward ported have not yet </span><br /><span style=" font-family:'dejavu sans mono';">been because it requires some porting work etc. There are some commits from </span><br /><span style=" font-family:'dejavu sans mono';">2008 which haven't been ported to trunk yet for example: </span><br /><span style=" font-family:'dejavu sans mono';">http://www.kdab.com/~thomas/avail/kdepim-e35_to_kdepim-trunk_20100123. </span><br /><span style=" font-family:'dejavu sans mono';">Sometimes that's because trunk is not yet in a situation where that can be </span><br /><span style=" font-family:'dejavu sans mono';">ported to Akonadi yet.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Enterprise 35 is so different to enterprise 5 or anything else KDE 4 related </span><br /><span style=" font-family:'dejavu sans mono';">that attempting to merge doesn't usually make sense. The proposed solution is </span><br /><span style=" font-family:'dejavu sans mono';">to create branches with similar names to track the status of a fix. Initially a </span><br /><span style=" font-family:'dejavu sans mono';">branch named e35-issue-123 would be created. The issue would be solved there, </span><br /><span style=" font-family:'dejavu sans mono';">and if the fix is to be forward ported, a branch called e5-issue-123 is created </span><br /><span style=" font-family:'dejavu sans mono';">and the e35-issue-123 branch is deleted. The existence of the e35 or e5 branch </span><br /><span style=" font-family:'dejavu sans mono';">indicates that the fix still needs to be forward ported. When the e5-issue-123 </span><br /><span style=" font-family:'dejavu sans mono';">branch is merged into e5 and everywhere else it is to go, it too is deleted. I </span><br /><span style=" font-family:'dejavu sans mono';">think there's a way to check whether a branch is a parent of another branch, </span><br /><span style=" font-family:'dejavu sans mono';">but I don't recall what it is. For e5-<something> branches that still exist, </span><br /><span style=" font-family:'dejavu sans mono';">that command would tell us which branches it has not yet been merged into.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Now onto the long-lived branches. This proposal is for 5 long lived branches:</span><br /><br>
<span style=" font-family:'dejavu sans mono';">KDE SC master</span><br /><span style=" font-family:'dejavu sans mono';">KDE SC 4.x stable (could be SC 4.7)</span><br /><span style=" font-family:'dejavu sans mono';">KDE SC 4.5 </span><br /><span style=" font-family:'dejavu sans mono';">Enterprise5-features</span><br /><span style=" font-family:'dejavu sans mono';">Enterprise5-release<br /></span><br>
<span style=" font-family:'dejavu sans mono';">The top two are self explanatory. </span><br /><br>
<span style=" font-family:'dejavu sans mono';">When we need to make "blocked" commits (eg, customer specific hacks, BiC </span><br /><span style=" font-family:'dejavu sans mono';">changes) we would merge them into the enterprise5-release branch and nowhere </span><br /><span style=" font-family:'dejavu sans mono';">else. New features (and bug fixes with new strings) get merged into the </span><br /><span style=" font-family:'dejavu sans mono';">enterprise5-features branch. New bug fixes get merged into the KDE 4.5 branch. </span><br /><span style=" font-family:'dejavu sans mono';">The KDE 4.5 branch can then periodically (monthly?) be merged into the latest </span><br /><span style=" font-family:'dejavu sans mono';">KDE stable release and into the enterprise5-release branch. The enterprise5-</span><br /><span style=" font-family:'dejavu sans mono';">features branch can periodically be merged into the KDE master branch and the </span><br /><span style=" font-family:'dejavu sans mono';">enterprise5-release branch. Having the enterprise5-features branch will also </span><br /><span style=" font-family:'dejavu sans mono';">insulate against large disruption in KDE5 times. It takes on the role and </span><br /><span style=" font-family:'dejavu sans mono';">workflow that enterprise35 has today.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Originally this proposal included a enterprise-fixes branch based on KDE4.5. </span><br /><span style=" font-family:'dejavu sans mono';">However, really it would probably make more sense to just use the same branch </span><br /><span style=" font-family:'dejavu sans mono';">for the lifetime of the fixes branch instead of branching off 4.5 with a </span><br /><span style=" font-family:'dejavu sans mono';">different name. The reasoning for that is that we would like to encourage more </span><br /><span style=" font-family:'dejavu sans mono';">fixes to be made there by the community and then forward ported to KDE stable </span><br /><span style=" font-family:'dejavu sans mono';">and KDE master. Backports require more work. I know that's a starry eyed </span><br /><span style=" font-family:'dejavu sans mono';">optimists view, however, there are distributions making long term support </span><br /><span style=" font-family:'dejavu sans mono';">releases, and debian stable is supported for years, other companies working in </span><br /><span style=" font-family:'dejavu sans mono';">KDE etc, so there is more than just KDAB that would benefit from having bug </span><br /><span style=" font-family:'dejavu sans mono';">fixes to a particular stable branch for a long period of time. Having said </span><br /><span style=" font-family:'dejavu sans mono';">that, it's also not a problem for us to create a e5-fixes, or e5-stable branch </span><br /><span style=" font-family:'dejavu sans mono';">once 4.6 is released and 4.5 effectively closed. The idea of having it as a </span><br /><span style=" font-family:'dejavu sans mono';">community maintained long term stable branch came up, so I wanted to share it. </span><br /><span style=" font-family:'dejavu sans mono';">It could be a useful aggregation point for long term support fixes without KDE </span><br /><span style=" font-family:'dejavu sans mono';">having to make releases from it. The branch will exist anyway. It's just a </span><br /><span style=" font-family:'dejavu sans mono';">case of what it is called.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">So that's forward porting. There will also inevitably be a need for </span><br /><span style=" font-family:'dejavu sans mono';">backporting into the enterprise branches. Currently Allen and Thomas backport </span><br /><span style=" font-family:'dejavu sans mono';">fixes in trunk or stable mostly as they see fit and without machine readable </span><br /><span style=" font-family:'dejavu sans mono';">tracking. It would most likely make sense to continue doing this without </span><br /><span style=" font-family:'dejavu sans mono';">machine readable tracking, however if we decide that it does make sense to </span><br /><span style=" font-family:'dejavu sans mono';">track from KDE latest stable release to e5/KDE4.5, we might be able to keep </span><br /><span style=" font-family:'dejavu sans mono';">track by using special keywords (BLOCKED, INTEGRATED) in git notes for the </span><br /><span style=" font-family:'dejavu sans mono';">commits.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">http://ftp.sunet.se/pub/Linux/kernel.org/software/scm/git/docs/git-notes.html</span><br /><br>
<span style=" font-family:'dejavu sans mono';">git notes can be added to commits without changing the commit hash.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">However, I don't think we will need to start doing that tbh.</span><br /><br>
<span style=" font-family:'dejavu sans mono';">You need a mono font or view the source of the email for this:</span><br /><br>
<span style=" font-family:'dejavu sans mono';"><br /></span><br>
<span style=" font-family:'dejavu sans mono';"> /- e5/bug321 -\ Not suitable for merging into </span><br /><span style=" font-family:'dejavu sans mono';"> / \ mainline KDE (hacks, BiC etc)</span><br /><span style=" font-family:'dejavu sans mono';"> / \ / Tag weekly</span><br /><span style=" font-family:'dejavu sans mono';">---- Enterprise5-release ( based on KDE 4.5 ) -----o--------------------></span><br /><span style=" font-family:'dejavu sans mono';"> / /</span><br /><span style=" font-family:'dejavu sans mono';"> (new features, new strings etc) /Merge weekly |</span><br /><span style=" font-family:'dejavu sans mono';"> /- e5/bug123 -\ /- e5/bug456 -\ / into release |</span><br /><span style=" font-family:'dejavu sans mono';"> / \ / \ / branch |</span><br /><span style=" font-family:'dejavu sans mono';"> / \ / \ / |</span><br /><span style=" font-family:'dejavu sans mono';">---- Enterprise5-features ( based on KDE 4.5 ) ------------------|------></span><br /><span style=" font-family:'dejavu sans mono';"> \ |</span><br /><span style=" font-family:'dejavu sans mono';">. | /</span><br /><span style=" font-family:'dejavu sans mono';">---- KDE lts/e5-fixes ( based on KDE 4.5 ) -|---------------------------></span><br /><span style=" font-family:'dejavu sans mono';"> \ |</span><br /><span style=" font-family:'dejavu sans mono';"> \ Merge into KDE |</span><br /><span style=" font-family:'dejavu sans mono';"> \ latest stable release |</span><br /><span style=" font-family:'dejavu sans mono';"> \ |</span><br /><span style=" font-family:'dejavu sans mono';">---- KDE release branch ( based on KDE 4.8 )|---------------------------></span><br /><span style=" font-family:'dejavu sans mono';"> \ |</span><br /><span style=" font-family:'dejavu sans mono';"> Merge fixes \ Contains new strings. Skip</span><br /><span style=" font-family:'dejavu sans mono';"> \ stable branches. Merge into master</span><br /><span style=" font-family:'dejavu sans mono';"> \ \</span><br /><span style=" font-family:'dejavu sans mono';">---- KDE master --------------------------------------------------------></span><br /><br>
<span style=" font-family:'dejavu sans mono';"> /- e35/bug123 -\ /- e35/bug789 - \ Not needed in any other</span><br /><span style=" font-family:'dejavu sans mono';"> / \ / \ branch</span><br /><span style=" font-family:'dejavu sans mono';"> / \ / \</span><br /><span style=" font-family:'dejavu sans mono';">---- Enterprise3.5 ( based on 3.5 ) ------------------------------------></span><br /><span style=" font-family:'dejavu sans mono';"> No merges into mainline 3.5 branch</span><br /><br>
<span style=" font-family:'dejavu sans mono';">To the people who know git better than me, does this workflow make sense? See </span><br /><span style=" font-family:'dejavu sans mono';">any holes in it?</span><br /><br>
<span style=" font-family:'dejavu sans mono';">All the best,</span><br /><br>
<span style=" font-family:'dejavu sans mono';">Steve.</span><br /></p></body></html>