[rules-dev] Quite a few commits on master that look like bug fixes are not on the 5.2.x branch and are not in CR1 (and final)

[Geoffrey De Smet]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110501/23b9f838/attachment-0001.html