[Olsr-dev] 0.6.4 release and "howto do it"

Felix Fietkau (spam-protected)
Sun Jul 22 14:36:23 CEST 2012


On 2012-07-19 9:33 PM, Henning Rogge wrote:
> On Thu, Jul 19, 2012 at 9:26 PM, Ferry Huberts <(spam-protected)> wrote:
>> Well, that depends entirely on the situation. What you propose is not so
>> common. A few examples:
>> - Assume that normal development will continue on master.
>> - A bug is fixed on master. For this bug it is clear that it also exists on
>> one or more release branches: we backport the fix to those branches that we
>> deem necessary.
>> - A bug is fixed on a release branch. For this bug it is clear that it also
>> exists on master: we forward-port to master.
>>
>> And now the tricky parts:
>>  - A bug is fixed on master. For this bug it is NOT clear that it also
>> exists on one or more release branches. Now what do we do? I for one will
>> not waste time trying to reproduce it in any release branch. I propose to
>> backport it only when a specific bug report on it comes in.
>> - A bug is fixed on a release branch. For this bug it is NOT clear that it
>> also exists on master: now what do we do? This is perhaps the most difficult
>> situation.
>>
>> I think we'll need to communicate better for this to work properly ;-)
> 
> Okay, thats a good argument.
> 
> Maybe fixing stuff on the stable branch(es) and merging it back to
> master from time to time is really easier.
This discussion reminds me a lot about the Linux kernel discussion
regarding merging non-mainline patches to the stable tree.

Fixing in release-branch and merging to master later makes it too easy
for regressions to creep in at a later point in time.
Doing so should be a rare exception rather than the rule, only to be
used if the branches have diverged so much that it's really hard to
verify if the fix applies to master as well.

Every committer should make an effort to verify if a fix is master
material *before* merging it into a release branch, at least that's my
experience from the Kernel discussion and from working with some other
projects as well.

It may not be easier, but it's important for long term stability.

- Felix




More information about the Olsr-dev mailing list