<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Ansgar,<br>
<br>
Thanks for the feed-back, we indeed need to agree how we want to
work and the current situation might not be optimal.<br>
I've replied inline. (Note that all true/false statements are my
opinion only.)<br>
<br>
Op 01-05-11 11:42, Ansgar Konermann schreef:<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
... the amount of cherrypicking necessary seems a bit overwhelming
to me.<br>
</blockquote>
True. Cherry picking to the branch should be an exception.<br>
But most people are still working on fixing bugs for the release.<br>
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.<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
<br>
As CR1 is probably more 'stable' than master,</blockquote>
True. The release branch 5.2.x is undergoing iterative manual,
general testing.<br>
Meanwhile, master already has new refactors/improvements commits
that aren't tested by anyone else but the original developer.<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
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?</blockquote>
Interesting point. The problem in this approach is that you'll also
merge in the CR1 specific changes (setting version numbers etc).<br>
Also, after 5.1.0 is release, back-porting patches (= cherry
picking) really is the exception and switching workflows than is
confusing.<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
I also did not quite get why multiple CR/release branches are
created _from the master_</blockquote>
False. There's only one release branch: 5.2.x<br>
This release branch will be tagged with 5.2.0.CR1, 5.2.0, 5.2.1, ...<br>
<br>
The milestone branch (5.2.0.M2.x) might be confusing to some.<br>
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.<br>
If we can get the release of a milestone down to a non-event, we
could release every 6 weeks.<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">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.</blockquote>
True<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
Re-creating a CR branch from master multiple times bears the risk
of introducing *new* bugs from master into the release.<br>
</blockquote>
True. Final won't be re-created from master.<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
<br>
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).<br>
</blockquote>
Completely automated is not possible.<br>
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.<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
<br>
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.<br>
</blockquote>
Sounds like yet another reason why hudson can be red more often,<br>
which is the opposite of something I believe is very important:
hudson should be rarely or never be red.<br>
Because of our number of committers and the timezone differences
(there's always someone wanting to build), this is very disruptive.<br>
<br>
Personally, I believe most in the current workflow:<br>
<b> Every developer is responsible for his own commits:<br>
he must apply his commits on master<br>
and if his commits are required to backport and if they are
non-risky, he should cherry pick them to the release branch.</b><br>
<br>
But most of us still need to become used to the fact <i>the release
branch is now created a few days before the release</i><br>
(so it can be tested without new refactors/features/improvements
sneaking in).<br>
<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
<br>
Looking forward to your comments.<br>
</blockquote>
Thank you for your comments, looking forward to what you and others
think of it :)<br>
<blockquote cite="mid:4DBD2B06.1010405@googlemail.com" type="cite">
<br>
Best regards<br>
<br>
Ansgar<br>
<br>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
With kind regards,
Geoffrey De Smet</pre>
</body>
</html>