From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: "netfilter-devel@vger.kernel.org" <netfilter-devel@vger.kernel.org>
Subject: Re: iptables release plans
Date: Mon, 21 Mar 2011 23:43:24 +0100 [thread overview]
Message-ID: <4D87D48C.7080902@trash.net> (raw)
In-Reply-To: <alpine.LNX.2.01.1103212008460.15338@obet.zrqbmnf.qr>
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.
next prev parent reply other threads:[~2011-03-21 22:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 18:48 iptables release plans Patrick McHardy
2011-03-21 19:48 ` Jan Engelhardt
2011-03-21 22:43 ` Patrick McHardy [this message]
2011-03-21 23:22 ` Jan Engelhardt
2011-03-21 21:09 ` Jozsef Kadlecsik
2011-03-21 22:44 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D87D48C.7080902@trash.net \
--to=kaber@trash.net \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).