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
