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

[Stephen Kelly]

On Friday 12 March 2010 15:34:31 you wrote:
> Stephen Kelly schrieb:
> >  On Friday 12 March 2010 14:56:30 Stephen Kelly wrote:
> >> > 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".
> >
> > Actually I think I misread your paragraph when I replied. We'd create a
> > separate branch for each feature and merge that into the e5-features
> > branch. That branch can always be merged into master and e5-release by
> > definition and gives us both a tracking point (if a merge from it is a
> > no-op, the features are already in the target branch) and separation
> > (the features branch contains no BiC hacks, and can always be merged to
> > master).
>
> Is "KDE master" the community's KDE? 

Yes.

> If so: does the community always want
> *all* features that you invent? Does it never happen that you (KDAB) want
> or need a feature, but the community does not want it (for whatever
> reason, e.g. licensing)?

I'm not aware of that happening before, but if it happens in the future, that 
feature would not be merged into the e5-features branch, but only the e5-
release branch. That way the invariant that e5-features is always mergable 
into master is held, and e5 can still be released with the feature.

> If the community rejects a feature, then it
> cannot merge your "Enterprise5-features" branch. For this reason, I
> suggest to keep separate feature branches.

If a feature is rejected after merge, then I think the fix is a revert commit 
on master either way, right?

If the feature is rejected before being merged into master that would not be 
needed, but really I don't see that happening anyway. The fix is trivial anyway 
(the revert commit)

This way, there is only one place to merge features into, we don't have to 
think about it, we just merge the features into the -features branch instead 
of both the e5-release branch and master. It's a judgment call whether a 
feature is suitable for master, just as it is now.

>
> [Oh, you say: "can be merged into master by definition", so the answer to
> my second question is yes.]
>
> Of course, for KDAB internal reasons it might make sense to collect all
> features in "Enterprise5-features" branch.

It also makes it easier for anyone else to get a long term stable branch with 
new features.

> But for the exchange with the
> community, individual feature branches are better. 

I'm still not sure I see why, but maybe I'll think about it later and realize 
more of your reasoning.

> (And those feature
> branches must *not* originate from your internal branches, obviously.)

Why is that? Which internal branches? Do you mean feature or fix branches which 
get merged into e5-release only?

>
> >> > The way that you proposed it, you would be able to
> >> > merge features to "KDE master" and "Enterprise5-release" only
> >> > collectively.
> >
> > I don't think this is a problem?
>
> See above: It's (only) a problem if "KDE master" does not want one of the
> features.
>
> > It does reduce the number of merge
> > commits onto master, right?
>
> What's bad with merge commits?

My second-hand knowledge is that it makes git-bisect more painful. I don't 
recall exactly why right now. Something about having to traverse both merged 
branches manually when a merge commit is hit.

> When the --first-parent log of the master
> branch lists N commits of the form
>
>  Merge branch 'imap-over-ssl-speedup'
>  Merge branch 'issue-345-db-corruption-after-power-failure'
>  ...
>
> I know a lot more than when it said only once
>
>  Merge branch 'Enterprise5-features'
>
> (This implies that I suggest to be rather verbose with feature and bugfix
> branch names.)

Yes, I see what you mean here, but again, that assumes a discipline that can 
not be guaranteed. People are lazy. 

This is also influenced by what KDE decides the workflow and policy should be 
wrt branches and merges in KDE-on-git in general. Does KDE want all commits to 
master to be merge commits of separate branches, or does KDE want a linear 
history? If linear history is preferred we can use the -features branch. If 
everything-is-a-merge is preferred, I'm sure we can do that instead as per 
your idea.

I don't want to dwell a long time on this e5-features branch issue, because it 
is side-line to whether the workflow as a whole is sensible and will work, so 
I'll summarize here and we can move on:

The case for having a -features branch where new features are merged into:
* One place for people to merge into.
* -features is always mergable into master, hopefully easily.
* -features can be picked up by anyone who wants a stable release with some 
new features.

The case against:
* merge commits would contain less information about what was being merged.
* The community could potentially reject a feature before it is merged into 
master instead of the all or nothing approach. 
* A branch which does not easily merge does not block other branches which 
could otherwise be easily merged.

We can revisit that and decide either way when KDE has a policy that affects 
it.

All the best,

Steve.

>
> -- 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/7a7744e7/attachment.htm