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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
