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

[Stephen Kelly]

On Friday 12 March 2010 13:59:28 Johannes Sixt wrote:
> Stephen Kelly schrieb:
> > 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.
>
> Don't do that. Never back-port.
>
> When you fix a bug, do so by making a branch at the "earliest" branch that
> *could* benefit from the fix; ideally, you branch off the commit that
> introduced the bug. Then forward-merge this branch into any other branch
> where you need the fix.

Yes. This is the intention. That is what Allen and Thomas currently do. 
However, not everybody does that. If you for example fix something in kdelibs, 
you might merge the fix into the KDE 4.8 branch and forward port to master. You 
might not even be aware of the enterprise5-fixes branch, so you would not start 
there and forward port. So if Allen or Thomas thought your fix should be in the 
enterprise branch, they would have to backport. Having everybody aware of a 
KDE4.5 branch which should get the fix first would help, but still, not 
everybody would do that for various reasons.

So I don't think "never back-port" works in the real world.

>
> > To the people who know git better than me, does this workflow make
> > sense? See
> > any holes in it?
>
> If I understand the problem and the graph correctly, your proposal makes a
> lot of sense. But it has room for improvement.
>
> In particular, I would not use a special "Enterprise5-features" branch.
> Rather, I would create a separate feature branch for each feature that you
> invent. Then you can merge the features selectively to "KDE master" and
> "Enterprise5-release". 

Yes, that was the intention. Sorry that wasn't clear. It must have been lost 
between other drafts of the proposal I was sending around.

> The way that you proposed it, you would be able to
> merge features to "KDE master" and "Enterprise5-release" only collectively.

The aim would be to make many merges into enterprise5-features and merge that 
less frequently into KDE master and e5-release. That way there is not one 
merge commit on master for each merge commit on e5-features, but only one per 
week/month/whatever makes sense.

>
> Your picture doesn't show that you would merge from KDE master or KDE
> release to your enterprise branches after each KDE major or minor release.
> Do you intend to create a new set of enterprise branches for each of these
> releases?

Nope. Enterprise5 stays based on KDE 4.5, so we can't just merge 4.{6,7,8} 
into it. That's why fixes should either get into an earlier branch, or be 
cherry-picked back in the case of someone applying a fix to the latest stable 
branch, but not the "long term stable" KDE 4.5.

Thanks for your input. Keep it coming.

Stephen

>
> -- Hannes

-- 
Stephen Kelly <stephen at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100312/020f2faf/attachment-0001.htm