Login  Register

Re: Request to All Committers

Posted by Jacques Le Roux on Apr 27, 2007; 11:00am
URL: http://ofbiz.116.s1.nabble.com/Request-to-All-Committers-tp180509p180511.html

This does make sense (applying bug fixes patches in release 1st, to have
a better documentation in the release branch). On the other hand, then
the trunk will be rather undocumented (regarding "why" bug fixes).
So it seems better to put the documentation (bug fix comment) in both
branches (not only a reference to rev in trunk, or vice versa).

Anybody aware of best practices in this area ?

What do you think folks ?

Jacques

----- Message d'origine -----
De : "Jonathon -- Improov" <[hidden email]>
À : <[hidden email]>
Envoyé : vendredi 27 avril 2007 10:10
Objet : Re: Request to All Committers


> > Of course, if there is a conflict in the merge or the bug was caused
after
>  > the release branch was done, then this will require more work or
won't be
>  > necessary.
>
> Determine what bug the bugfix was trying to fix in the trunk.
Determine if the same bug exists in
> the release branch. That is the minimum work required when applying
patches across branches.
>
> As I said before, once the trunk deviates too far from the release
branch, and it gets difficult
> to compare "apples to oranges", it may be time to discontinue support
for that release branch,
> unless someone steps up and says: "there's a whole lot of us still
using that branch, so let us
> maintain it".
>
>  > BTW, for everyone watching in this sort of overhead is one reason
why we
>  > haven't been really excited about doing release branches in the
past,
>  > but still it's great that OFBiz is reaching the level of maturity
where
>  > this is possible and happening!
>
> In general, the purpose of the release branch is to have a "quieter
stream" for those who need a
> situation where "number of bugs fixed is greater than the number
created". Such a situation is
> hardly possible (nor correct) in the trunk stream.
>
> Bug reports should come in for the release branch, not the trunk. The
whole point of publishing
> (and using) the release branch is to get more bugfixes and less new
bugs. It's best to fix bugs in
> the release branch first, then massage (if necessary) the bugfix for
the trunk. Fixing bugs on the
> "quieter stream" should be easier than fixing bugs in the trunk where
bug phenomena could be
> compounded by frequent radical changes.
>
> If we find no bug reports coming in for the release branch, then there
is absolutely no interest
> in the release branch (or no bugs!). In that case, the release branch
will progress very slowly to
> maturity/stability, and the whole community will have to live with
that.
>
> So, those who had complained like "please don't break existing
functionality!" should be advised
> to use the release branch. And those who need the "latest and greatest
though less tested" can try
> the trunk. And everybody is (or should be) happy.
>
> Jonathon
>
> David E. Jones wrote:
> >
> > To help maintain the release branch, I'd like to ask all committers
to
> > keep it in mind as we fix bugs.
> >
> > If you commit a bug fix to the trunk, go ahead and merge it into the
> > release branch as well.
> >
> > This should be pretty easy, just do the following:
> >
> > 1. keep a checkout of the release4.0 branch somewhere on your
machine
> > (the full URL is:
> > https://svn.apache.org/repos/asf/ofbiz/branches/release4.0)
> >
> > 2. after committing to the trunk make note of your commit revision
> > number and go into your release4.0 branch local checkout directory
and
> > run something like (replacing the rev number there with the one from
> > your commit):
> >
> > $ ./mergefromtrunk.sh 532994
> >
> > This doesn't take much time and it will make it easier for all of us
to
> > keep the release branch updated with the latest bug fixes that go
into
> > the trunk. Of course, if there is a conflict in the merge or the bug
was
> > caused after the release branch was done, then this will require
more
> > work or won't be necessary.
> >
> > BTW, for everyone watching in this sort of overhead is one reason
why we
> > haven't been really excited about doing release branches in the
past,
> > but still it's great that OFBiz is reaching the level of maturity
where
> > this is possible and happening!
> >
> > Thanks,
> > -David
> >