On Wed, Jul 30, 2014 at 1:21 AM, Leo Simons <lsim...@schubergphilis.com> wrote:
> On Jul 30, 2014, at 1:14 AM, Sheng Yang <sh...@yasker.org> wrote: > > The issue with current development process? > > 1. Cherry-pick is needed for RM to choose stable fix commit after code > > freeze to enforce quality. > > 2. Bug fix to current release branch need to be checked in both release > > branch and MASTER. > > 3. I believe there would be more. Please comment. > > 4. where commits need to go is dependent on what phase of the release > process you’re in, which requires sync. For example, if you’re working on a > bug fix against 4.4 but then that is frozen you have to rebase against > 4.4-forward. If you are doing this work on a public feature branch you have > to re-cut your branch since you don’t want to rebase those. > In gitflow model, feature always branch out develop branch, not release branch. In this case, 4.4 is release branch, 4.4-forward is develop branch(for 4.4), both are descendence of old 4.4 branch the feature based on, so I don't understand the difference here. > 5. requires using synchronous process (freezes) to keep track of what is > going on. This is not very healthy for a distributed project with > contributors across many continents and companies. In contrast if you > branch early and often you don’t freeze, you just avoid merging things that > could destabilize things. > In gitflow model, feature branch is coming from develop branch, which is also not stable I think? You need to live with unstable sometime. > 6. does not allow looking into history to see what happened. I.e. if you > were to cut a 4.5 branch from master, its code history is not at all the > same or comparable (using git tools) to the code history of 4.4. > Yeah, this is an issue. In theory they should be the same, since every fixes goes to where it should go. > 7. reliant on error-prone human checking of merge status (looking if all > cherries have been picked properly) rather than tool support (git > confirming for you all changes from branch A made it to branch B) > git cherry provide that ability in this case. > 8. default/naive checkouts of cloudstack tree result in a very unstable > and sometimes unbuildable master > If we expect master to be stable, this is a problem. Though it's not expected to be stable in our current model. > > The list goes on! But I don’t see why we should repeat all these things > here when the internet is full of these kinds of discussions already, as > are this mailing list’s archives… > > > 3. Code freeze: No such concept in the flow. Need to know how to guide > the > > check in. > > Mostly by discipline. Committers normally commit to develop and/or feature > branches, and switch only to the release branch to commit very specific > bugfixes. You can agree a policy (for example like Alena described) for how > to make the decision what should and should not go on onto the release > branch. > I don't quite believe in this. I believe self-discipline is not enough when we facing something like release. I even don't like only one RM working as gatekeeper. We should have all set of tools support from mandatory review to automatic testing, and probably QA specific testing. In Linux kernel, every commit would pass at least two person: subsystem maintainer and Linus, before enter RC. Of course there would be more people reviewing in the mailing list as well. But I think even now we trusted too much on self-discipline, result in issues in code quality. > > > 5. The original post didn't mention minor release. I suppose it may work > > like this: > > > > 1. Branch out MASTER to 4.4 release > > 2. Any bug fixes happened on 4.4 need to be merge to MASTER. > > 3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's > needed > > is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can we > fix > > it in develop branch(which meant for test)? I can't see how you can > avoid > > cherry-pick or extra commit if you want to have a maintenance release. > > There will be extra commits, but they will be merge commits. I.e. > > master ------4.3-----4.4--------------x4.5 > | \ / > release/4.4.1 | \——----x-- / > | \ / / > bugfix/CLOUDSTACK-1234 | \—x/ / > | \ \ / > release/4.5 | \—x—-/ > | \ \ > develop --------------y-----------x--------- > > the commit x will always be there exactly once, it will get exactly one > sha1 checksum and one spot in the git index, and git will forever remember > all the different branches that include x. > > On some of those branches there may be merge commits (if you explicitly > chose to have them, or if git decided they were needed) following x, to > record the merges that were done. > > You can basically always do this as long as you *start your fix on the > oldest branch* that you want to fix. So if you want to fix a bug in 4.4.1, > 4.5.0, and all future releases, you develop the fix against the 4.4.1 > branch, and then merge from there to the 4.5 branch, and then merge from > there to the develop branch. > > This works very well with git because it remembers the complete history of > everything (if you don’t cherry-pick). I.e. if commit y is the last commit > that is in common between master and develop, when it becomes time > to merge x to develop, git will traverse the whole history of x until it > finds y, then consider the situation from there. As long as you don’t > cherry-pick, git can do this logic provably correctly looking mostly at > sha1 commit ids. > 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. And in this model, one error in the old release's fix would have chain effect to all the newer stable release, which make me a little concerned. > > > Before realizing the maintenance release issue, I was quite like this > > approach, which means no more duplicate work need to be done. But sadly > the > > most usage for cherry-pick is due to we need to fix multiple versions. > > Current I can't see how utilize gitflow or git merge would solve the > issue. > > Is there a better way to handle this? > > I hope the above helps. If it doesn’t, what I recommend to you (and anyone > else having these kinds of questions is) to just _try it_. These kinds of > conversations are very hard, and the diagrams can be confusing, but, when > you’re actually doing the work and typing in the commands, it is really > much much easier to follow than the discussion itself. If you’ve never > worked on a many-branches git project before you’re in for a treat: the > first time you do what you think is a complex merge, and git just does it > for you, it feels like magic :-) > > > And, I think gitflow model doesn't have "code freeze" period which we can > > have a gatekeeper to keep the quality. So, if we want to compare to > gitflow > > model, we would simply skip "code freeze" stage in our current process. I > > don't think it make much sense. > > You know, you could keep the concept of a freeze, git-flow doesn’t mind. > The way it would look is that after a release branch freeze, all further > bugfixes to that release would be required to be on their own bug fix > branches, and the gatekeeper(s) would be the only ones merging those into > the release branch. > > But, generally, teams find that increased discipline in what&how to commit > combined with a solid branch workflow means they don’t need such > heavy-handed methods. It’s one of the true joys of distributed version > control to let go of things like this! > > 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, they do have an strict code freeze. Whenever Linus close the merge window and cut RC1, it's in code freeze. They have only stage of one freeze. The ultimate gatekeeper Linus, and subsystem maintainers would keep everything under their eyes. Unless you're maintainer who is able to let Linus pull your tree directly, your commit need to be approved twice - by subsystem maintainer and Linus, along with the big community scrutinize your work. The things happened from time to time that subsystem maintainer want to smugger something to in RC stage(often small enough but not strictly a bug fix) but somehow spotted by Linus, then you know what would happen. The minor release of Linux is different from mainstream development. Greg KH would maintain all these stable releases in separate branches. He would answer to pull requests for stable release from subsystem maintainers, which work already passed subsystem maintainer and community's scrutiny. Even though, no flow/merge would across the stable releases. There are thousands of active developers in Linux kernel community, only subsystem maintainers have git permission, everyone else have to submit patch through mail. So I don't understand why you said Linux doesn't need freeze. > > > 3. How about the workload for merge between release and develop branch? > It > > would be quite frequently. > > Yes it would be frequent. Exactly because it is frequent, it should be > relatively effortless, no more work than 'git pull'. (after all, git pull > is nothing more than 'git fetch' followed by 'git merge'...you do lots of > merging already...) > git pull is on the same code base. I hope it would be no more work that git pull. --Sheng > > > Btw, that no-cherry-picking( > > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html) > article > > has a mistake in it. The result it's showing in fact shows that git > cherry > > -v DID recongize the cherry-pickup result by showing "-" in front of the > > commit. I guess git is smart enough to know that. > ... > > The equivalence test is based on the diff, after removing > whitespace > > and line numbers. git-cherry therefore detects when commits have been > > "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1). > > Yeah, it’s pretty powerful :-) > > Unfortunately comparing the diff is not nearly as powerful as comparing > the sha1 ID. Those commit ids don’t just point at a diff, they point at a > _commit_, which is that diff *as applied to all the history that came > before*. With that extra detail, you can do much more powerful things, and > git can do much more powerful things for you. > > > cheers, > > > Leo > >
