iptables branch management

iptables branch management

[Jan Engelhardt]

Hei


I would like to propose a "stable" branch that would be rooted 
in the most recent tag and only receive fixes. Furtheremore, 
the branch is merged time and again into master, so that the 
fix is available in both without cherry-pick. 1.4.12.x releases be made 
from stable, and 1.4.y from master.
How about it?

Re: iptables branch management

[Maciej Żenczykowski]

On Fri, Sep 2, 2011 at 07:20, Jan Engelhardt <jengelh@medozas.de> wrote:
> I would like to propose a "stable" branch that would be rooted
> in the most recent tag and only receive fixes. Furtheremore,
> the branch is merged time and again into master, so that the
> fix is available in both without cherry-pick. 1.4.12.x releases be made
> from stable, and 1.4.y from master.
> How about it?

I've actually been thinking about suggesting something pretty much identical.
So, I'm all for it.

Maintaining the version x stable branch maybe just a tiny little bit
(~1 month) past the release of version x+1 would probably be
appreciated.

ie. timeline of something along these lines:

initial state:
- version X.0 is released from master, stable is branched from master.
- obvious fixes committed to stable branch, stable branch merged into
master branch, periodically (as needed, every week or two or so) a
stable release is cut from the stable branch, and even if it's not
cut, you can still just use stable HEAD with much happiness.
- features go into master branch
- at some point master branch is cut to produce (X+1).0
- bugfixes which can, still go into the stable branch (which ist still
based off of X.0), X.N continue to be cut as needed
- other bugfixes queue up (or go into master), features are queued
- about 2-3 weeks after the release of X+1, assuming there are bug
fixes queued, a final X.N is cut, and X+1.0 is merged into stable, the
bugfixes are applied and a X+1.1 is cut.
- life continues...

Re: iptables branch management

[Pablo Neira Ayuso]

Hi Jan,

On Fri, Sep 02, 2011 at 04:20:13PM +0200, Jan Engelhardt wrote:
> Hei
> 
> I would like to propose a "stable" branch that would be rooted 
> in the most recent tag and only receive fixes. Furtheremore, 
> the branch is merged time and again into master, so that the 
> fix is available in both without cherry-pick. 1.4.12.x releases be made 
> from stable, and 1.4.y from master.
> How about it?

Hm, I remember that we had this discussion before.

I think it's probably too much overhead for it, looking at how other
similar net-tools are maintained, the amount of contributions that
er receive and amount of changes that get into every version.

Re: iptables branch management

[Patrick McHardy]

Am 05.09.2011 19:54, schrieb Pablo Neira Ayuso:
> Hi Jan,
> 
> On Fri, Sep 02, 2011 at 04:20:13PM +0200, Jan Engelhardt wrote:
>> Hei
>>
>> I would like to propose a "stable" branch that would be rooted 
>> in the most recent tag and only receive fixes. Furtheremore, 
>> the branch is merged time and again into master, so that the 
>> fix is available in both without cherry-pick. 1.4.12.x releases be made 
>> from stable, and 1.4.y from master.
>> How about it?
> 
> Hm, I remember that we had this discussion before.
> 
> I think it's probably too much overhead for it, looking at how other
> similar net-tools are maintained, the amount of contributions that
> er receive and amount of changes that get into every version.

I also think this is probably overkill, what's wrong with simply
creating stable branches on demand if there are important fixes
that require a new release?

Re: iptables branch management

[Jan Engelhardt]

On Thursday 2011-09-08 12:05, Patrick McHardy wrote:

>Am 05.09.2011 19:54, schrieb Pablo Neira Ayuso:
>> Hi Jan,
>> 
>> On Fri, Sep 02, 2011 at 04:20:13PM +0200, Jan Engelhardt wrote:
>>> Hei
>>>
>>> I would like to propose a "stable" branch that would be rooted 
>>> in the most recent tag and only receive fixes. Furtheremore, 
>>> the branch is merged time and again into master, so that the 
>>> fix is available in both without cherry-pick. 1.4.12.x releases be made 
>>> from stable, and 1.4.y from master.
>>> How about it?
>> 
>> Hm, I remember that we had this discussion before.
>> 
>> I think it's probably too much overhead for it, looking at how other
>> similar net-tools are maintained, the amount of contributions that
>> er receive and amount of changes that get into every version.
>
>I also think this is probably overkill, what's wrong with simply
>creating stable branches on demand if there are important fixes
>that require a new release?

Nothing wrong, it just has not been done consistently or at all in the 
past. I believe it does not hurt to go ahead with this, also since I am 
statistically taking care of most submissions these days anyway.

Re: iptables branch management

[Patrick McHardy]

Am 08.09.2011 13:59, schrieb Jan Engelhardt:
> On Thursday 2011-09-08 12:05, Patrick McHardy wrote:
> 
>> Am 05.09.2011 19:54, schrieb Pablo Neira Ayuso:
>>> Hi Jan,
>>>
>>> On Fri, Sep 02, 2011 at 04:20:13PM +0200, Jan Engelhardt wrote:
>>>> Hei
>>>>
>>>> I would like to propose a "stable" branch that would be rooted 
>>>> in the most recent tag and only receive fixes. Furtheremore, 
>>>> the branch is merged time and again into master, so that the 
>>>> fix is available in both without cherry-pick. 1.4.12.x releases be made 
>>>> from stable, and 1.4.y from master.
>>>> How about it?
>>>
>>> Hm, I remember that we had this discussion before.
>>>
>>> I think it's probably too much overhead for it, looking at how other
>>> similar net-tools are maintained, the amount of contributions that
>>> er receive and amount of changes that get into every version.
>>
>> I also think this is probably overkill, what's wrong with simply
>> creating stable branches on demand if there are important fixes
>> that require a new release?
> 
> Nothing wrong, it just has not been done consistently or at all in the 
> past. I believe it does not hurt to go ahead with this, also since I am 
> statistically taking care of most submissions these days anyway.

What has been done in the past doesn't really matter, we can of course
agree to have a stable branch when needed. But I don't see the point of
having a stable branch as long as it doesn't contain any fixes.

Re: iptables branch management

[Jan Engelhardt]

On Thursday 2011-09-08 14:52, Patrick McHardy wrote:
>> 
>> Nothing wrong, it just has not been done consistently or at all in the 
>> past. I believe it does not hurt to go ahead with this, also since I am 
>> statistically taking care of most submissions these days anyway.
>
>What has been done in the past doesn't really matter, we can of course
>agree to have a stable branch when needed. But I don't see the point of
>having a stable branch as long as it doesn't contain any fixes.

Oh we are nicely accumulating fixes & trivials already - do not worry 
about that. Just let me pull this off, all it means is that
there is another branch head on iptables.git, and something convenient 
for the release manager to tag should the need arise for a .y release. 
Users already seem to like the idea[1].
[1] http://marc.info/?l=netfilter-devel&m=131499886708085&w=2

Re: iptables branch management

[Patrick McHardy]

Am 08.09.2011 16:41, schrieb Jan Engelhardt:
> 
> On Thursday 2011-09-08 14:52, Patrick McHardy wrote:
>>>
>>> Nothing wrong, it just has not been done consistently or at all in the 
>>> past. I believe it does not hurt to go ahead with this, also since I am 
>>> statistically taking care of most submissions these days anyway.
>>
>> What has been done in the past doesn't really matter, we can of course
>> agree to have a stable branch when needed. But I don't see the point of
>> having a stable branch as long as it doesn't contain any fixes.
> 
> Oh we are nicely accumulating fixes & trivials already - do not worry 
> about that. Just let me pull this off, all it means is that
> there is another branch head on iptables.git, and something convenient 
> for the release manager to tag should the need arise for a .y release. 
> Users already seem to like the idea[1].
> [1] http://marc.info/?l=netfilter-devel&m=131499886708085&w=2
> 

Sure, go ahead.

Re: iptables branch management

[Peter Volkov]

В Чтв, 08/09/2011 в 16:41 +0200, Jan Engelhardt пишет:
> Oh we are nicely accumulating fixes & trivials already - do not worry 
> about that. Just let me pull this off, all it means is that
> there is another branch head on iptables.git, and something convenient 
> for the release manager to tag should the need arise for a .y release. 
> Users already seem to like the idea[1].
> [1] http://marc.info/?l=netfilter-devel&m=131499886708085&w=2

As the iptables maintainer in Gentoo I really appreciate such branch
management. BTW, I'd like to know how long stable branch will be
maintained? Or IOW how we'll find out that it's not maintained any more?

With best regards,
--
Peter.

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iptables branch management

[Jan Engelhardt]

On Friday 2011-09-09 11:31, Peter Volkov wrote:

>В Чтв, 08/09/2011 в 16:41 +0200, Jan Engelhardt пишет:
>> Oh we are nicely accumulating fixes & trivials already - do not worry 
>> about that. Just let me pull this off, all it means is that
>> there is another branch head on iptables.git, and something convenient 
>> for the release manager to tag should the need arise for a .y release. 
>> Users already seem to like the idea[1].
>> [1] http://marc.info/?l=netfilter-devel&m=131499886708085&w=2
>
>As the iptables maintainer in Gentoo I really appreciate such branch
>management. BTW, I'd like to know how long stable branch will be
>maintained? Or IOW how we'll find out that it's not maintained any more?

From my point of understanding: like we always have done, in other 
words:

All release numbers are strictly monotonically increasing. The 
appearance of a iptables-1.4.13 will close any iptables-1.4.12.x.

[ This is, if you have not noticed, the same way the Linux kernel is 
done. Once linux-3.1 appears, the linux-3.0.x line usually ceases. ]
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html