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)
2:51 a.m.
Hi guys,
Since the branch was made on Friday morning, there have been quite a few
commits on master.
Some of these are refactorings/features/improvements, which we don't
want on the 5.2.x as they will jeopardize the stability of the release.
But quite a few of those commits are bug fixes and many of those bug
fixes haven't been cherry-picked to the 5.2.x,
so *those commits will not be in CR1 (and final).*
Here's an easy way to compare the commits on master and the branch:
https://github.com/droolsjbpm/drools/commits/master
https://github.com/droolsjbpm/drools/commits/5.2.x
The dev mail about the creation fo the 5.2.x branch:
http://drools.46999.n3.nabble.com/Branch-date-for-5-2-x-CR-1-and-final-Th...
"If you want any of your not-yet-pushed commits to be included in the
5.2.0 release,
you 'll have to cherry pick those commits from master to the release
branch."
To learn how to cherry pick:
http://drools.46999.n3.nabble.com/Cherry-picking-with-git-from-master-to-...
--
With kind regards,
Geoffrey De Smet
4:42 a.m.
Am 01.05.2011 09:51, schrieb Geoffrey De Smet:
Hi guys,
Since the branch was made on Friday morning, there have been quite a
few commits on master.
Some of these are refactorings/features/improvements, which we don't
want on the 5.2.x as they will jeopardize the stability of the release.
But quite a few of those commits are bug fixes and many of those bug
fixes haven't been cherry-picked to the 5.2.x,
so *those commits will not be in CR1 (and final).*
Hi Geoffrey, hi all,
I'm relatively new to the development process of drools, but the amount
of cherrypicking necessary seems a bit overwhelming to me.
As CR1 is probably more 'stable' than master, 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? Each developer could
then switch his local repository between the CR1 and master branch,
depending on with which branch he'd like to work (release fixes should
be committed to CR1 branch, regular development to master). This way,
the CR branch becomes more and more stable while the master continues to
evolve independently.
I also did not quite get why multiple CR/release branches are created
_from the master_ (that's what I understood of how it currently works;
correct me if I'm wrong). 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. Re-creating
a CR branch from master multiple times bears the risk of introducing
*new* bugs from master into the release.
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).
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.
Looking forward to your comments.
Best regards
Ansgar
7:51 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
5007
days inactive
5007
days old
2 comments
2 participants
participants (2)
-
Ansgar Konermann -
Geoffrey De Smet