<!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;">On Friday 12 March 2010 15:34:31 you wrote:<br>
> Stephen Kelly schrieb:<br>
> > On Friday 12 March 2010 14:56:30 Stephen Kelly wrote:<br>
> >> > In particular, I would not use a special "Enterprise5-features"<br>
> >> > branch. Rather, I would create a separate feature branch for each<br>
> >> > feature that you invent. Then you can merge the features selectively<br>
> >> > to "KDE master" and "Enterprise5-release".<br>
> ><br>
> > Actually I think I misread your paragraph when I replied. We'd create a<br>
> > separate branch for each feature and merge that into the e5-features<br>
> > branch. That branch can always be merged into master and e5-release by<br>
> > definition and gives us both a tracking point (if a merge from it is a<br>
> > no-op, the features are already in the target branch) and separation<br>
> > (the features branch contains no BiC hacks, and can always be merged to<br>
> > master).<br>
><br>
> Is "KDE master" the community's KDE? <br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Yes.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> If so: does the community always want<br>
> *all* features that you invent? Does it never happen that you (KDAB) want<br>
> or need a feature, but the community does not want it (for whatever<br>
> reason, e.g. licensing)?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> If the community rejects a feature, then it<br>
> cannot merge your "Enterprise5-features" branch. For this reason, I<br>
> suggest to keep separate feature branches.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>If a feature is rejected after merge, then I think the fix is a revert commit on master either way, right?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>><br>
> [Oh, you say: "can be merged into master by definition", so the answer to<br>
> my second question is yes.]<br>
><br>
> Of course, for KDAB internal reasons it might make sense to collect all<br>
> features in "Enterprise5-features" branch.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>It also makes it easier for anyone else to get a long term stable branch with new features.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> But for the exchange with the<br>
> community, individual feature branches are better. <br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>I'm still not sure I see why, but maybe I'll think about it later and realize more of your reasoning.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> (And those feature<br>
> branches must *not* originate from your internal branches, obviously.)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Why is that? Which internal branches? Do you mean feature or fix branches which get merged into e5-release only?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>><br>
> >> > The way that you proposed it, you would be able to<br>
> >> > merge features to "KDE master" and "Enterprise5-release" only<br>
> >> > collectively.<br>
> ><br>
> > I don't think this is a problem?<br>
><br>
> See above: It's (only) a problem if "KDE master" does not want one of the<br>
> features.<br>
><br>
> > It does reduce the number of merge<br>
> > commits onto master, right?<br>
><br>
> What's bad with merge commits?<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> When the --first-parent log of the master<br>
> branch lists N commits of the form<br>
><br>
> Merge branch 'imap-over-ssl-speedup'<br>
> Merge branch 'issue-345-db-corruption-after-power-failure'<br>
> ...<br>
><br>
> I know a lot more than when it said only once<br>
><br>
> Merge branch 'Enterprise5-features'<br>
><br>
> (This implies that I suggest to be rather verbose with feature and bugfix<br>
> branch names.)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Yes, I see what you mean here, but again, that assumes a discipline that can not be guaranteed. People are lazy. <br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>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:<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>The case for having a -features branch where new features are merged into:<br>
* One place for people to merge into.<br>
* -features is always mergable into master, hopefully easily.<br>
* -features can be picked up by anyone who wants a stable release with some new features.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>The case against:<br>
* merge commits would contain less information about what was being merged.<br>
* The community could potentially reject a feature before it is merged into master instead of the all or nothing approach. <br>
* A branch which does not easily merge does not block other branches which could otherwise be easily merged.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>We can revisit that and decide either way when KDE has a policy that affects it.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>All the best,<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Steve.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>><br>
> -- Hannes<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>-- <br>
Stephen Kelly <stephen@kdab.com> | Software Engineer<br>
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company<br>
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090<br>
KDAB - Qt Experts - Platform-Independent Software Solutions</p></body></html>