On Friday 2009-07-17 16:31, Patrick McHardy wrote: >>> Yeah but in general? The - judging from their version numbers - >>> x.y.z.S stable versions like 1.4.3.1 used to receive lots of new >>> features because there is just master, in which case it should >>> have been the new 1.4.4 already. >>> So either z is bumped more often and S-versions will not >>> be released, or S only receives fixes, necessiting a separate branch. >>> Objections? >> >> It would be cool to get an answer here so I know how to twingle >> patchbranches that I'd like to submit. > >Well, I don't object to having a stable branch when we actually do >need to release pure bug-fix versions. But I'd say those can be >created on demand. > Yes, but it requires that any bugfix commit does not have master as a descendent (otherwise it would be perturbed by dev commits). The core essential of a (de facto) stable branch is that solely the most recent tag, (or stable commits), are a parent. That is what I want to be sure of, esp. when others send commits. Below's patches respect this. "Please pull from..." git://dev.medozas.de/iptables stable the two (2) things that Jan Engelhardt piled up: xt_conntrack: revision 2 for enlarged state_mask member libxt_helper: fix invalid passed option to check_inverse extensions/libxt_conntrack.c | 175 +++++++++++++++++++++++++++----- extensions/libxt_helper.c | 2 +- include/linux/netfilter/xt_conntrack.h | 13 +++ 3 files changed, 162 insertions(+), 28 deletions(-) -- 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