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

[Hans-Christoph Steiner]

On Jul 22, 2012, at 8:36 AM, Felix Fietkau wrote:

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


The Linux kernel workflow is vastly more complex than the olsrd workflow, with layers and layers of people surrounding Linus, each maintaining their own Linux repos.  It also has longer and much more complex release cycles.  For example, Linus puts outs many RC releases for each point release, all while the layers of people around him are also putting out their own RC releases.  So its easy to see how commits could get lost in all that.   olsrd currently doesn't put out any RC releases.

I've been happy with the bug-fixes-in-release-branch workflow for a number of years maintaining Pure Data, which is of similar scale to olsrd.  It works well if there is a general agreement to take a brief pause (like a week or two) from normal development and focus on getting out a stable release.

I suppose it might not work well if there is a lot of asynchronous dev activity, since those devs who are out of sync would not be aware of the release cycle when the synced devs are focusing on release bugfixes.

One thing about keeping the bugfixes in the release branch during the release cycle is that I think it would be easier to rebase the commits in the release branch on master than vice versa.

.hc