Request to All Committers

[David E Jones]

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

[jonwimp]

 > 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
>

[Jacques Le Roux]

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
> >

[BJ Freeman]

[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".]

on this note, the usage will be high till the next stable release. for
those of us that support clients. So support may be for the bug fixes in
the release branch only if the trunk deviates too far.

Jonathon -- Improov sent the following on 4/27/2007 12:10 AM:

>> 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
>>
>
>
>
>

[jonwimp]

First, we do need to enter a log like "brought in patch from trunk r123:456", just so we know
where we patched from. After that, it's optional to include the full log of the patch.

I would recommend including the full log of the bugfix being brought in. At some point, the
release branch may be left to "outsiders" (interested parties not within OFBiz team) to maintain,
and they'll need good docs.

At times, we may find ourselves pulling in a part of a commit (there certainly are some commits in
trunk that are large and sweeping). In that case, the target log can include just the relevant
part of the source log.

In any case, including the original log/doc of the bugfix is a helpful thing to do, and doesn't
cost much.

Jonathon

Jacques Le Roux wrote:

> 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
>>>
>
>

[David E Jones]

On Apr 27, 2007, at 1:31 PM, Jonathon -- Improov wrote:

> I would recommend including the full log of the bugfix being  
> brought in. At some point, the release branch may be left to  
> "outsiders" (interested parties not within OFBiz team) to maintain,  
> and they'll need good docs.

This is not likely to ever happen. In fact, the vetting and  
monitoring on the release branch will be more strict, not less, than  
the trunk.

-David

[jonwimp]

Agreed.

Would it be feasible to dedicate a committer to the release branch, a committer who will become
very familiar with the branch?

Are you also saying that there will not be any release branches that are too old to be maintained
by OFBiz committers? It's quite usual to see project developers shelf a release branch, and to see
a group of "outsiders" offer to maintain it just because they have clients using it. Those project
teams that don't ever "leave any branch behind" are those who are willing to work new bugfixes
into the old branches, no matter how far the trunk has deviated from those branches.

What happens when OFBiz wants to move to the next version (5.0?).

Jonathon

David E. Jones wrote:

>
> On Apr 27, 2007, at 1:31 PM, Jonathon -- Improov wrote:
>
>> I would recommend including the full log of the bugfix being brought
>> in. At some point, the release branch may be left to "outsiders"
>> (interested parties not within OFBiz team) to maintain, and they'll
>> need good docs.
>
> This is not likely to ever happen. In fact, the vetting and monitoring
> on the release branch will be more strict, not less, than the trunk.
>
> -David
>
>
>

[David E Jones]

Jonathon,

With all of these comments I think you're forgetting the basic idea  
of how OFBiz is structured: it is community driven, ie driven from  
the outside in. It is not centrally driven or driven from the inside  
out.

So...


On Apr 27, 2007, at 10:21 PM, Jonathon -- Improov wrote:

> Agreed.
>
> Would it be feasible to dedicate a committer to the release branch,  
> a committer who will become very familiar with the branch?

There is no way to do this. If someone wanted to take this on they  
certainly could, but neither I nor anyone is in a position to tell  
any other committer what to do and require something like this of them.

A single volunteer would probably not be sufficient anyway. As  
described in the release plan in order for the release branch to  
result in a successful stable release, lots of people from the  
community need to get involved.

> Are you also saying that there will not be any release branches  
> that are too old to be maintained by OFBiz committers? It's quite  
> usual to see project developers shelf a release branch, and to see  
> a group of "outsiders" offer to maintain it just because they have  
> clients using it. Those project teams that don't ever "leave any  
> branch behind" are those who are willing to work new bugfixes into  
> the old branches, no matter how far the trunk has deviated from  
> those branches.
>
> What happens when OFBiz wants to move to the next version (5.0?).

There is no "OFBiz" to even want such a thing. A release branch will  
eventually stagnate and die when there aren't enough organizations/
people using it or they are no longer interested in maintaining it.

-David

> David E. Jones wrote:
>> On Apr 27, 2007, at 1:31 PM, Jonathon -- Improov wrote:
>>> I would recommend including the full log of the bugfix being  
>>> brought in. At some point, the release branch may be left to  
>>> "outsiders" (interested parties not within OFBiz team) to  
>>> maintain, and they'll need good docs.
>> This is not likely to ever happen. In fact, the vetting and  
>> monitoring on the release branch will be more strict, not less,  
>> than the trunk.
>> -David
>