Hi Ansgar,

Thanks for the feed-back, we indeed need to agree how we want to work and the current situation might not be optimal.
I've replied inline. (Note that all true/false statements are my opinion only.)

Op 01-05-11 11:42, Ansgar Konermann schreef:

... the amount of cherrypicking necessary seems a bit overwhelming to me.

True. Cherry picking to the branch should be an exception.
But most people are still working on fixing bugs for the release.
A few (especially community members) are doing refactors/improvements that we really don't want to risk putting in the release, so we needed to branch.

As CR1 is probably more 'stable' than master,

True. The release branch 5.2.x is undergoing iterative manual, general testing.
Meanwhile, master already has new refactors/improvements commits that aren't tested by anyone else but the original developer.

I guess that it might help to just merge into the master all commits which were originally made to CR1. After all, fixes which were made to the release branch should also be incorporated into the mainline, shouldn't they?

Interesting point. The problem in this approach is that you'll also merge in the CR1 specific changes (setting version numbers etc).
Also, after 5.1.0 is release, back-porting patches (= cherry picking) really is the exception and switching workflows than is confusing.

I also did not quite get why multiple CR/release branches are created _from the master_

False. There's only one release branch: 5.2.x
This release branch will be tagged with 5.2.0.CR1, 5.2.0, 5.2.1, ...

The milestone branch (5.2.0.M2.x) might be confusing to some.
If we can get hudson all blue most of time, I believe we might be able to release milestones directly from master without the need for a milestone release branch.
If we can get the release of a milestone down to a non-event, we could release every 6 weeks.

As the release should be as stable and error-free as possible, committing bug fixes to the same release branch until all relevant bugs are fixed seems more natural to me.

True

Re-creating a CR branch from master multiple times bears the risk of introducing *new* bugs from master into the release.

True. Final won't be re-created from master.

Merging commits from the CR/release-branch into the master can easily be automated, unless conflicts occurr (then of course they need to be resolved manually).

Completely automated is not possible.
Semi-automated by an "integration guy" is maybe possible, but there's no single person who know all modules intimately enough to fix all merge conflicts.

We apply a similar scheme at work, and automated the merge down from release/bugfix branch into master using our CI server. Works like a charm. Whenever an automatic merge fails due to conflicts, we get a red build in our XV information radiator so we know we have to fix it.

Sounds like yet another reason why hudson can be red more often,
which is the opposite of something I believe is very important: hudson should be rarely or never be red.
Because of our number of committers and the timezone differences (there's always someone wanting to build), this is very disruptive.

Personally, I believe most in the current workflow:
Every developer is responsible for his own commits:
he must apply his commits on master
and if his commits are required to backport and if they are non-risky, he should cherry pick them to the release branch.

But most of us still need to become used to the fact the release branch is now created a few days before the release
(so it can be tested without new refactors/features/improvements sneaking in).

Looking forward to your comments.

Thank you for your comments, looking forward to what you and others think of it :)

Best regards

Ansgar


_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet