iptables release plans

iptables release plans

[Patrick McHardy]

About a potential iptables release for 2.6.38 - we don't have any
new features in the kernel that would require a new release.
However we've had a lot of other changes that would be good to
get out for wider testing.

Unfortunately due some confusion at the time of the last kernel
release, all patches for the upcoming feature in 2.6.39 have been
added to the master branch. I don't want to release extensions
for new kernel features while we're in the -rc phase since we
might still decide to change the userspace API.

So the options basically are:

- branch off the current HEAD, remove all new extension for upcoming
  features and release that branch

- skip the release for 2.6.38

Any opinions?

Re: iptables release plans

[Jan Engelhardt]

On Monday 2011-03-21 19:48, Patrick McHardy wrote:
>
>So the options basically are:
>
>- branch off the current HEAD, remove all new extension for upcoming
>  features and release that branch

I find deletions just for the sake of making a release not very
aesthetic to the git history. It duplicates commits in a way, but
above all, interrupts the flow when tracking changes with "git
blame". Better branch off earlier...
	~/envisioning a git topic for the next NFWS.~


>- skip the release for 2.6.38
>
>Any opinions?

Since there was no iptables release for 2.6.37 was skipped, features
do have accumulated. In fact, there were features added (socket r1)
in 2.6.31 that were not made available up to iptables-1.4.10+git. In
reverse chronological order:

├─[mdz/master]──iptables: add -C to check for existing rules──(d59b9db)
├ extensions: add extension for devgroup match──(9ee2a9f)
├ Fix listing/saving the new revision of the SET target──(6f03bf7)
├ extensions: libxt_conntrack: add support for specifying port ranges──(c8f28cc)
├ extensions: libxt_NFQUEUE: add v2 revision with --queue-bypass option──(6924b4
├ libxt_AUDIT: add AUDIT target──(773438b)
...
│ ├ │ socket: add support for revision 1──(4d2a77f)
│ ├ │ TPROXY: add support for revision 1──(9e152fa)

	~Graphs produly presented by git-forest. *recordscreech*[1]~


Not to mention a handful of actual program fixes to parsing and
slightly improved robustness (like NULL deref avoidance, I think
there was at least one).

So yeah, time for a release or so. Not for 2.6.38, but for the
general benefit.

Other than that, no, I don't see a reason to do a mandatory filler
release for new kernels when there is nothing "worth" in the
userspace side to make a release of.




-- 
[1] http://www.youtube.com/watch?v=oRp_mVi969I
--
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 release plans

[Jozsef Kadlecsik]

On Mon, 21 Mar 2011, Patrick McHardy wrote:

> About a potential iptables release for 2.6.38 - we don't have any
> new features in the kernel that would require a new release.
> However we've had a lot of other changes that would be good to
> get out for wider testing.
> 
> Unfortunately due some confusion at the time of the last kernel
> release, all patches for the upcoming feature in 2.6.39 have been
> added to the master branch. I don't want to release extensions
> for new kernel features while we're in the -rc phase since we
> might still decide to change the userspace API.
> 
> So the options basically are:
> 
> - branch off the current HEAD, remove all new extension for upcoming
>   features and release that branch
> 
> - skip the release for 2.6.38
> 
> Any opinions?

I don't really like either one, but if we have to choose then the first 
one seems better. At least the release will contain the bugfixes.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: iptables release plans

[Patrick McHardy]

On 21.03.2011 20:48, Jan Engelhardt wrote:
> 
> On Monday 2011-03-21 19:48, Patrick McHardy wrote:
>>
>> So the options basically are:
>>
>> - branch off the current HEAD, remove all new extension for upcoming
>>  features and release that branch
> 
> I find deletions just for the sake of making a release not very
> aesthetic to the git history. It duplicates commits in a way, but
> above all, interrupts the flow when tracking changes with "git
> blame". Better branch off earlier...
> 	~/envisioning a git topic for the next NFWS.~

That's really not the question, I'm not going to release
extensions for kernel modules which are so far in -rc.
There's a reason for -rc, one of them is that we still
have a chance to fix things in case we messed up.

>> - skip the release for 2.6.38
>>
>> Any opinions?
> 
> Since there was no iptables release for 2.6.37 was skipped, features
> do have accumulated. In fact, there were features added (socket r1)
> in 2.6.31 that were not made available up to iptables-1.4.10+git. In
> reverse chronological order:
> 
> ...
> Not to mention a handful of actual program fixes to parsing and
> slightly improved robustness (like NULL deref avoidance, I think
> there was at least one).
> 
> So yeah, time for a release or so. Not for 2.6.38, but for the
> general benefit.

Yeah, that's my opinion as well. Which means branching and
removing new extensions from that branch.

Re: iptables release plans

[Patrick McHardy]

On 21.03.2011 22:09, Jozsef Kadlecsik wrote:
> On Mon, 21 Mar 2011, Patrick McHardy wrote:
> 
>> About a potential iptables release for 2.6.38 - we don't have any
>> new features in the kernel that would require a new release.
>> However we've had a lot of other changes that would be good to
>> get out for wider testing.
>>
>> Unfortunately due some confusion at the time of the last kernel
>> release, all patches for the upcoming feature in 2.6.39 have been
>> added to the master branch. I don't want to release extensions
>> for new kernel features while we're in the -rc phase since we
>> might still decide to change the userspace API.
>>
>> So the options basically are:
>>
>> - branch off the current HEAD, remove all new extension for upcoming
>>   features and release that branch
>>
>> - skip the release for 2.6.38
>>
>> Any opinions?
> 
> I don't really like either one, but if we have to choose then the first 
> one seems better. At least the release will contain the bugfixes.

Yeah, it certainly was a mistake, but to me the first option
seems better as well.

Thanks!

Re: iptables release plans

[Jan Engelhardt]

On Monday 2011-03-21 23:43, Patrick McHardy wrote:
>> 
>> I find deletions just for the sake of making a release not very
>> aesthetic to the git history. It duplicates commits in a way, but
>> above all, interrupts the flow when tracking changes with "git
>> blame". Better branch off earlier...
>> 	~/envisioning a git topic for the next NFWS.~
>

>> So yeah, time for a release or so. Not for 2.6.38, but for the
>> general benefit.
>
>Yeah, that's my opinion as well. Which means branching and
>removing new extensions from that branch.

The removal can be avoided if it is branched from the right point.
Right, this was not exactly done like that in the last cycle, which
is why I can see why you would like to hold a release.

>That's really not the question, I'm not going to release
>extensions for kernel modules which are so far in -rc.

Makes sense.

So then in that case, let's hold. Most distros had just fixated
their version anyway, so throwing something out the door now
does not yield that much.

Regarding the history tree, let's start doing it with better
branching from now. I offer to take up all the patches (since that's
just minimally more than already doing), and place them into
the right spot in the tree such that there be no deletions
or cherry-picks required in future.