fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

On Tue, Dec 17, 2013 at 3:05 AM, Victor Denisov <vdenisov@xxxxxxxxxxxx> wrote:
> First of all, I see, when you have a bugfix for 3.2.1 you do two commits one
> to master and one to 3.2 fixes branch,
> you don't event cherry pick - this is lame.

That's a bit harsh, and not exactly correct. If you search for
Change-Id from one of the more recent 3.2.1 commits, you will find two
commits for each change, one merged to master, and the other to
3.2-fixes, e.g.:
https://review.openstack.org/#/q/Ic70eaeccdcf314b2823622b8d6b28ea409e93f0b,n,z

This proves that cherry-pick is exactly what was used to propagate the
same commit from master to 3.2-fixes, at least most of the time.

> Fixes should be introduced to the oldest branch and then this branch should
> be merged into all branches where this commit should go to.

With a few minor corrections/clarifications (oldest branch = master,
this branch should be merged -> this _commit_ should be merged) this
matches the flow that we have agreed to.

> I would recommend to review these two documents before introducing any new
> branching model:
> http://nvie.com/posts/a-successful-git-branching-model/
> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

Both of these documents propose models for vanilla Git and have no
provisions for instrumented code review and continuous integration.
Gerrit's requirement to merge the changes one commit at a time is at
odds with the concept of feature branches, but I believe it is well
justified. I found this document more relevant for our case:

http://qt-project.org/wiki/Branch-Guidelines

"The first rule is that you should avoid creating public branches if possible"

As Mike has already said, if you need a public branch when working on
a feature, most likely you're doing it wrong. Break up your change,
stub out the missing bits, and update the unit tests. Do all of the
above at least once a day, and you're going to be able to move forward
and not have a disruptive merge that breaks the world, too.

Regards,
-Dmitry Borodaenko