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

[Ferry Huberts]

On 19-07-12 20:32, Henning Rogge wrote:
> On Thu, Jul 19, 2012 at 6:36 PM, Hans-Christoph Steiner
> <(spam-protected)> wrote:
>> - move current 'master' to some descriptive name, 'historic_master' is ok,
>>    but doesn't say much about the content of what's in that branch.
>
> The other option would be to put it into a "historic" repository...
> maybe with all other branches that are not in use anymore.

Why bother. Just name it historic_master like you proposed.

>
>> - the current 'stable' branch becomes the new 'master'
>> - master is the main development branch is always open for committing.
>
> Yes
>
>> - when the release cycle is started, a new branch with the upcoming
>
> Yes.
>
>>    release version is made (i.e. stable_0.6.4).  Only fixes are committed
>>    or cherry-picked here.
>
> Yes.
>
>> - work on bug fixes should focus on the stable_0.6.4 branch and be
>>    only committed there.
>
> I would say bugfixes need to be made both in master and stable. Sounds
> stupid not to put the fixes into both branches at once.

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


>
>> - when the release is made, the HEAD of the release branch is tagged
>>    (i.e. v0.6.4) and that branch is no longer used.
>
> we don't need to create a "release branch", we can just tag a version
> of stable_x.y.z and continue fixing there.

yes, we already branched the release branch on feature freeze.

>
>> - bug fixes from stable_0.6.4 are folded into master, either merged
>>    or cherry-picked
>
> I would like to do this earlier. Might even be a good idea to fix
> problems in master first (to test them there) and if they work out, we
> can port/cherry-pick them to stable.

I'd say that fixes must be done where they're appropriate.
The way you'll get the best tools (git) support is to fix it on the 
oldest version first.

>
>> About the debian branch, I don't think that'll be very helpful.  Its easiest work out of one source repo for that, and that's currently the debian one.
>
> I would suggest keeping both repositories in sync. But this should be
> easy by pulling the changes from one of this repositories into the
> other one.
>

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




-- 
Ferry Huberts