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.
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.
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.
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)
8. default/naive checkouts of cloudstack tree result in a very unstable and
sometimes unbuildable master
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.
> 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.
> 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
> 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...)
> 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
