http://ofbiz.116.s1.nabble.com/Request-to-All-Committers-tp180509p180512.html
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,
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
In any case, including the original log/doc of the bugfix is a helpful thing to do, and doesn't
> 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
>>>
>
>