On Thu, Jul 31, 2014 at 12:55 AM, Leo Simons <lsim...@schubergphilis.com> wrote:
> On Jul 31, 2014, at 12:55 AM, Sheng Yang <sh...@yasker.org> wrote: > > I suppose it would work like this: > > 1. In the original model, every release branch would be deleted after > merge > > into develop and master branch. There is no release/4.4.1 or release/4.5 > > branch. > > 2. Say we don't follow original model, when one release is released, you > > keep it. Say we have release/4.4 and release/4.5. And currently we're > > working on 4.7 which is develop branch, MASTER is 4.6. > > 3. I have one bug in 4.4, I checked in a fix in 4.4. Release 4.4.1. > > 4. Then, conflict would happen when you merge release/4.4. branch to > > release/4.5. Since the version number changed to 4.4.1. You need to deal > > with version number conflict every time when merge to upper release. > > 5. Suppose you dealt with version number change. New release/4.5 would > > merge release/4.4 which merged release/4.3. Then you want to merge to > > master because there is a fix. Well, dealt with version number change > > conflict again. > > 6. Then, you would need to merge master to develop branch? > > > > I am little worry about the conflict every time when merge happened. > Seems > > version number conflict need to be dealt with everytime, and probably > some > > other conflict. The conflict need to be solved may result in more > > error-prone situation. > > Well, yes, _that_ would be horrible! :-) > > Fortunately a merge only considers things that haven’t been merged before. > If V means ‘bump version’, given > > master ----------------------------------------- > \ / \ > r/4.5 V1---y----------V2 \ > \ \ > r/4.6 \ V3--z----------- > \ / > fix x--------------- > > because V1 is an ancestor of V3, when you merge x into r/4.6, git knows > not to consider V1 commit again. It knows it only has to consider x. There > is no conflict due to V1 or V2 at z. If you would do this > > master ------------------------------------------ > \ \ / > r/4.5 V1-----\-V2---------------------------- > \ \ \ > r/4.6 V3---\-----z——-\----------z2-- > \ / \ / > fix x—- \ / > \ / > fix2 x2-- > > you will have a merge conflict once, at spot z, where you will have to > resolve the conflict created by having conflicting ancestors V2 and V3. But > you won’t have to deal with it at spot z2, since git will remember you > already resolved that conflict before. > > As long as you merge, instead of cherry-pick. > If no matter how many times you merged from old release, you would only need to solve version conflict once, that would be quite nice! Hope this can get things done well. Still, in this approach, one error in the old release would affect all the following releases. That's something we need to be more careful than before. > >> For example, the linux kernel has at least two active minor releases at > >> any given time, and many more minor releases and forks going on at that > >> same time, with hundreds (thousands?) of active developers, and even > _they_ > >> don’t need freezes. Instead the power is in their choices of what they > do > >> and do not > > > > I've worked on Linux kernel for years, > > If you have experience with linux’ approach, I’d suggest you just look at > git-flow as a massively simplified version of roughly that, which is easier > to get into, something to hold on to while you develop experience and then > good judgement [1] of when/what/where to merge. A reasonable starting > point. Also, now I _really_ don’t understand why we have to have this > discussion :) > IMO, git-flow is really different from Linux's approach. Linux kernel never merge between different maintenance versions, and the maintenance of stable tree is mostly made up of individual patches rather than merge, using cherry-pick. Only large amount of fixes would need merge probably. Linux mainstream utilized merge is for pull in a large set of commits for either feature or fixes. Not for maintain workflow. Relative stable code based is maintained by subsystem maintainer, which a feature would start from. After testing and mature the code, subsystem maintainer would ask Linus to pull(merge) a specific tree for next merge window. To my understand, Linux's approach is much simple and straightforward than git-flow: 1. Linus give 2 week merge window, merge everything he thinks proper from subsystem maintainer(thinking about feature branch merge), then cut RC1. 2. No feature would be in after RC1. Linus would only pull fixes from subsystem maintainer. Then cut on one RC about every 2 weeks. 3. When community think the release is stable enough after a few RC(mostly around 7), Linus would cut release. Then the release would be branched out by Gerg KH, start stable maintenance work. There is no merge between branches in Linux's case, no master/develop/release branch. Records of same fix in different stable trees are not maintained by merge record, but by cherry-pick. I started this discussion is because I want to make sure community and myself know exactly what we're heading to. I didn't know much about git-flow, and I did have lots of question. I am sure most of the community would have a better idea of how things work after these discussion. > > they do have an strict code freeze. > > Well, sure, but the linux freeze is a very _different_ kind of code freeze > to what cloudstack has been doing :). All that happens is the maintainers > decide to stop merging things into their RC branches. The wider linux > community doesn’t skip a beat. Heck, IMHO, if cloudstack were to adopt a > more linux-like model that would be awesome…but you have to walk before you > can run…for some reason I suspect this community is not ready to start > rejecting commits because the first line of their message overruns 72 > characters…or because someone’s eclipse made unrelated whitespace changes… > I didn't see our community stopped as well. :) I think up to this point, I am kind of understand what git-flow about to do in general. And here are my remaining concerns: 1. The original model is pretty elegant, but when we need to maintain older releases, which is not included in original model, it seems become more complex. 2. I think we'd better need some control on release branch, rather than leave it wide open for everyone. If we have an automation review/testing system, I would agree to leave it open. 3. For most bug fixes, I didn't see a need for an separate branch for now. And it's not in original git-flow model. So far, if we would start a vote, I would vote +0. BTW, back to the days I was working on it, I hadn't seen anyone use Eclipse in Linux kernel... --Sheng > > cheers, > > > Leo > > [1] http://yarchive.net/comp/linux/git_merges_from_upstream.html > https://lkml.org/lkml/2008/5/21/351 > http://lwn.net/Articles/328438/ > …etc…
