[Kde-scm-interest] KDE PIM branches workflow with git

[Stephen Kelly]

Hi,

We've been discussing the proposed move to git and how it affects existing 
workflows on the KDE PIM enterprise branches maintained by KDAB.

We've come to the conclusion that we should all move to Mercurial instead.

Just kidding :)

Some background again:

KDAB maintains enterprise branches of parts of KDE for customer maintenance 
contracts, including kdelibs, kdebase runtime, kdepimlibs, and kdepim.

Currently the active enterprise branches are enterprise35 (based on KDE3.5), 
enterprise5 (currently based on KDE trunk, to be based on KDE4.5 for its 
release). Considering a future where KDE4.6 is released and master is to 
become KDE 4.7, we have all of these branches:

enterprise 35 (e35)
enterprise 5 (e5)
KDE 4.6
KDE master

Fixes should be forward ported down the list. However, fixes will also need to 
be backported up the list. Anyone who fixes a bug in kdelibs is unlikely to 
fix 
it in our enterprise branch first and forward port. Hopefully they'll fix in 
4.6 
first and forward port though.

Some commits higher up the list should also not be forward ported down the 
list, such as changelog changes, customer specific hacks, commits in e5 
introducing new strings need to skip KDE4.6, etc. Similarly some commits in 
trunk should not be backported up the list.

Finally, some commits which should be forward or backward ported have not yet 
been because it requires some porting work etc. There are some commits from 
2008 which haven't been ported to trunk yet for example: 
http://www.kdab.com/~thomas/avail/kdepim-e35_to_kdepim-trunk_20100123. 
Sometimes that's because trunk is not yet in a situation where that can be 
ported to Akonadi yet.

Enterprise 35 is so different to enterprise 5 or anything else KDE 4 related 
that attempting to merge doesn't usually make sense. The proposed solution is 
to create branches with similar names to track the status of a fix. Initially 
a 
branch named e35-issue-123 would be created. The issue would be solved there, 
and if the fix is to be forward ported, a branch called e5-issue-123 is 
created 
and the e35-issue-123 branch is deleted. The existence of the e35 or e5 branch 
indicates that the fix still needs to be forward ported. When the e5-issue-123 
branch is merged into e5 and everywhere else it is to go, it too is deleted. I 
think there's a way to check whether a branch is a parent of another branch, 
but I don't recall what it is. For e5-<something> branches that still exist, 
that command would tell us which branches it has not yet been merged into.

Now onto the long-lived branches. This proposal is for 5 long lived branches:

KDE SC master
KDE SC 4.x stable (could be SC 4.7)
KDE SC 4.5 
Enterprise5-features
Enterprise5-release

The top two are self explanatory. 

When we need to make "blocked" commits (eg, customer specific hacks, BiC 
changes) we would merge them into the enterprise5-release branch and nowhere 
else. New features (and bug fixes with new strings) get merged into the 
enterprise5-features branch. New bug fixes get merged into the KDE 4.5 branch. 
The KDE 4.5 branch can then periodically (monthly?) be merged into the latest 
KDE stable release and into the enterprise5-release branch. The enterprise5-
features branch can periodically be merged into the KDE master branch and the 
enterprise5-release branch. Having the enterprise5-features branch will also 
insulate against large disruption in KDE5 times. It takes on the role and 
workflow that enterprise35 has today.

Originally this proposal included a enterprise-fixes branch based on KDE4.5. 
However, really it would probably make more sense to just use the same branch 
for the lifetime of the fixes branch instead of branching off 4.5 with a 
different name. The reasoning for that is that we would like to encourage more 
fixes to be made there by the community and then forward ported to KDE stable 
and KDE master. Backports require more work. I know that's a starry eyed 
optimists view, however, there are distributions making long term support 
releases, and debian stable is supported for years, other companies working in 
KDE etc, so there is more than just KDAB that would benefit from having bug 
fixes to a particular stable branch for a long period of time. Having said 
that, it's also not a problem for us to create a e5-fixes, or e5-stable branch 
once 4.6 is released and 4.5 effectively closed. The idea of having it as a 
community maintained long term stable branch came up, so I wanted to share it. 
It could be a useful aggregation point for long term support fixes without KDE 
having to make releases from it. The branch will exist anyway. It's just a 
case of what it is called.

So that's forward porting. There will also inevitably be a need for 
backporting into the enterprise branches. Currently Allen and Thomas backport 
fixes in trunk or stable mostly as they see fit and without machine readable 
tracking. It would most likely make sense to continue doing this without 
machine readable tracking, however if we decide that it does make sense to 
track from KDE latest stable release to e5/KDE4.5, we might be able to keep 
track by using special keywords (BLOCKED, INTEGRATED) in git notes for the 
commits.

http://ftp.sunet.se/pub/Linux/kernel.org/software/scm/git/docs/git-notes.html

git notes can be added to commits without changing the commit hash.

However, I don't think we will need to start doing that tbh.

You need a mono font or view the source of the email for this:



    /- e5/bug321 -\  Not suitable for merging into 
   /                 \ mainline KDE (hacks, BiC etc)
  /                   \                             / Tag weekly
---- Enterprise5-release ( based on KDE 4.5 ) -----o-------------------->
                                                  /               /
     (new features, new strings etc)             /Merge weekly   |
    /- e5/bug123 -\        /- e5/bug456 -\      / into release   |
   /               \      /               \    /  branch         |
  /                 \    /                 \  /                  |
---- Enterprise5-features ( based on KDE 4.5 ) ------------------|------>
                                           \                     |
.                                           |                   /
---- KDE lts/e5-fixes ( based on KDE 4.5 ) -|--------------------------->
           \                                |
            \ Merge into KDE                |
             \ latest stable release        |
              \                             |
---- KDE release branch ( based on KDE 4.8 )|--------------------------->
                             \              |
                 Merge fixes  \        Contains new strings. Skip
                               \       stable branches. Merge into master
                                \            \
---- KDE master -------------------------------------------------------->

    /- e35/bug123 -\        /- e35/bug789 - \  Not needed in any other
   /                \      /                 \ branch
  /                  \    /                   \
---- Enterprise3.5 ( based on 3.5 ) ------------------------------------>
             No merges into mainline 3.5 branch

To the people who know git better than me, does this workflow make sense? See 
any holes in it?

All the best,

Steve.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100312/9797bf54/attachment.htm