[Olsr-dev] 0.6.4 release and "howto do it"
Thu Jul 19 21:48:49 CEST 2012
On 19-07-12 21:33, 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
>> 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.
However, the whole point of branches is that they diverge. so merging
will become impractical at some point...
And master must never be inhibited by merging concerns from release
That point usually is a good indication to start thinking about a new
release or dropping support for that release :-)
>> I took a look at the debian repo and am not really pleased with the patches
>> in there. We had a big discussion with the OpenWRT guys on that they need to
>> upstream their patches and they did: they now basically have zero patches
>> against upstream olsrd.
>> Debian seems to care much less about that. I'd urge the debian guys to work
> I would say at least half of them could easily go upstream... and
> maybe we should talk about the rest.
More information about the Olsr-dev