-longterm kernels (Was: Re: [stable] Patch Upstream: iwlwifi: fix skb usage after free)

-longterm kernels (Was: Re: [stable] Patch Upstream: iwlwifi: fix skb usage after free)

[Stanislaw Gruszka]

(Removing Cc as probably not interested, adding LKML)

On Wed, May 04, 2011 at 03:36:05PM -0700, Greg KH wrote:
> > Cc: stable@kernel.org # 2.6.32+
> 
> This doesn't apply to the .32 or .33-stable kernels.  If you wish to see
> it there, can someone please provide a backport and send it to
> stable@kernel.org ?
Done.

BTW, Greg, perhaps -logterm releasing policy should be revised somehow.
Currently we have .32, .33, .34, .35 -longterm, what is kind a much. If
I could suggest something, would be nice to have longterm chosen
versions predictable and constants i.e. one from every 3 kernel
releases, like .35, .38, .41 ... . That would make distributions, that
try to do release every half year very happy, because they will know
what kernel to choose, which will be widely supported and tested. Also
developers will have a bit less work with backporting fixes, as having
same bug in n and n-3 release is less probable, than having the same bug
in n and n-1.

Stanislaw

Re: [stable] -longterm kernels (Was: Re: Patch Upstream: iwlwifi: fix skb usage after free)

[Willy Tarreau]

Hi,

On Thu, May 05, 2011 at 04:58:55PM +0200, Stanislaw Gruszka wrote:
> BTW, Greg, perhaps -logterm releasing policy should be revised somehow.
> Currently we have .32, .33, .34, .35 -longterm, what is kind a much. If
> I could suggest something, would be nice to have longterm chosen
> versions predictable and constants i.e. one from every 3 kernel
> releases, like .35, .38, .41 ... . That would make distributions, that
> try to do release every half year very happy, because they will know
> what kernel to choose, which will be widely supported and tested.

Longterm kernels are maintained on a voluntary basis, which explains
there is no rule. We had 2.6.16, 2.6.27 and now 2.6.32 which were
initially announced as longterm supported. When Greg announced dropping
2.6.27, I proposed to take it over because I have some uses for it and
I know other people who rely on it. Most likely for very similar reasons
Paul and Andi volunteered to maintain 2.6.34 and 2.6.35 alive.

I agree it would be much easier for everyone if all longterm kernels were
announced early. Still there are a lot of users who can't easily upgrade
for whatever reason and who are happy with someone keeping their kernel
updated. I tend to consider that Greg's kernels are more "official" than
other ones, and if some backporting must be done by patch authors, I think
it should be for these kernels first. Also, .32 is not that far away from
the 3 other longterm kernels, so when a developer writes a .32 backport,
chances are that adaptations will not be too hard for the 3 other ones.

> Also
> developers will have a bit less work with backporting fixes, as having
> same bug in n and n-3 release is less probable, than having the same bug
> in n and n-1.

While less probable, I'm still amazed by the number of fixes from -master
that still apply to 2.6.27, and sometimes (but to a less extent) even to
2.4.37 ! The fact that fixes and regressions span that many kernel versions
probably is one of the reasons there is demand for longterm kernels.

Just my 2 cents,
Willy

Re: -longterm kernels (Was: Re: [stable] Patch Upstream: iwlwifi: fix skb usage after free)

[Greg KH]

On Thu, May 05, 2011 at 04:58:55PM +0200, Stanislaw Gruszka wrote:
> (Removing Cc as probably not interested, adding LKML)
> 
> On Wed, May 04, 2011 at 03:36:05PM -0700, Greg KH wrote:
> > > Cc: stable@kernel.org # 2.6.32+
> > 
> > This doesn't apply to the .32 or .33-stable kernels.  If you wish to see
> > it there, can someone please provide a backport and send it to
> > stable@kernel.org ?
> Done.
> 
> BTW, Greg, perhaps -logterm releasing policy should be revised somehow.
> Currently we have .32, .33, .34, .35 -longterm, what is kind a much.

It's not "much" if you rely on that kernel version, right?

Nor if you aren't doing the work, no one forces anyone to backport any
patches to older kernels if they don't want to.  The above patch was
asked to be backported as the original submitter wanted it there, hence
my asking for them to do it if they really wanted it.

> If
> I could suggest something, would be nice to have longterm chosen
> versions predictable and constants i.e. one from every 3 kernel
> releases, like .35, .38, .41 ... . That would make distributions, that
> try to do release every half year very happy, because they will know
> what kernel to choose, which will be widely supported and tested.

The distros are the ones doing this -stable and -longterm work, so they
very well know exactly what is going on.  If they want to have a
specific kernel version marked as "-longterm", then they do the work to
do so.

What happens in the future, with future releases, is always unknown, as
hey, it's the future :)

So I really fail to understand what you are asking for here.

> Also
> developers will have a bit less work with backporting fixes, as having
> same bug in n and n-3 release is less probable, than having the same bug
> in n and n-1.

Again, no developer has to backport anything they don't want to, please
never feel any pressure from me or any other stable/longterm maintainer
to do so.  In this specific case, that was the request of the original
developer, hence my request back to them.

thanks,

greg k-h

Re: -longterm kernels

[Stanislaw Gruszka]

On Thu, May 05, 2011 at 08:25:01AM -0700, Greg KH wrote:
> > BTW, Greg, perhaps -logterm releasing policy should be revised somehow.
> > Currently we have .32, .33, .34, .35 -longterm, what is kind a much.
> 
> It's not "much" if you rely on that kernel version, right?

Yes, but maybe would be better if they do not relay on some versions in
long term manner, and i.e. .33 users would use .32 and .34 users would
use .35 instead?

So perhaps having well defined kernel.org rule/policy about which kernel
version will be longterm updated, will allow distributions/users choose
the same kernel version for they long live project. What in consequence
will result that they together will have better tested and supported
kernel.

> Nor if you aren't doing the work, no one forces anyone to backport any
> patches to older kernels if they don't want to.  The above patch was
> asked to be backported as the original submitter wanted it there, hence
> my asking for them to do it if they really wanted it.

Sure. Actually I didn't want to complain about that. When I wrote
"less work", I rather meant "less work" for these who want to fix old
kernels bugs for whatever reason.

> > If
> > I could suggest something, would be nice to have longterm chosen
> > versions predictable and constants i.e. one from every 3 kernel
> > releases, like .35, .38, .41 ... . That would make distributions, that
> > try to do release every half year very happy, because they will know
> > what kernel to choose, which will be widely supported and tested.
> 
> The distros are the ones doing this -stable and -longterm work, so they
> very well know exactly what is going on.

Hmm, I consider -stable rather as kernel.org project. People from
different distributions/communities cc patches to -stable, review them,
do backports ...

>  If they want to have a
> specific kernel version marked as "-longterm", then they do the work to
> do so.
> 
> What happens in the future, with future releases, is always unknown, as
> hey, it's the future :)
> 
> So I really fail to understand what you are asking for here.

We have -stable rule that released kernel will be be updated until next
release - about 2 months.

I would like to add rule about -longterm kernels. That it have to be one
form every 3 release, it will be updated about half a year - until next
-longterm (with possibility of longer updates). Or some similar rule.

That version should be good choice for distros and any other long live
project, and natural candidate for "real longterm" i.e. a few years
updated/supported kernel version.

Stanislaw

Re: -longterm kernels

[Greg KH]

On Sat, May 07, 2011 at 04:55:03PM +0200, Stanislaw Gruszka wrote:
> On Thu, May 05, 2011 at 08:25:01AM -0700, Greg KH wrote:
> > > BTW, Greg, perhaps -logterm releasing policy should be revised somehow.
> > > Currently we have .32, .33, .34, .35 -longterm, what is kind a much.
> > 
> > It's not "much" if you rely on that kernel version, right?
> 
> Yes, but maybe would be better if they do not relay on some versions in
> long term manner, and i.e. .33 users would use .32 and .34 users would
> use .35 instead?

You would think, but those kernels are being maintained for a reason
that those people feel matter.

> So perhaps having well defined kernel.org rule/policy about which kernel
> version will be longterm updated, will allow distributions/users choose
> the same kernel version for they long live project. What in consequence
> will result that they together will have better tested and supported
> kernel.

Perhaps, but we've been doing just fine so far for over 5 years, right?
:)

> > Nor if you aren't doing the work, no one forces anyone to backport any
> > patches to older kernels if they don't want to.  The above patch was
> > asked to be backported as the original submitter wanted it there, hence
> > my asking for them to do it if they really wanted it.
> 
> Sure. Actually I didn't want to complain about that. When I wrote
> "less work", I rather meant "less work" for these who want to fix old
> kernels bugs for whatever reason.
> 
> > > If
> > > I could suggest something, would be nice to have longterm chosen
> > > versions predictable and constants i.e. one from every 3 kernel
> > > releases, like .35, .38, .41 ... . That would make distributions, that
> > > try to do release every half year very happy, because they will know
> > > what kernel to choose, which will be widely supported and tested.
> > 
> > The distros are the ones doing this -stable and -longterm work, so they
> > very well know exactly what is going on.
> 
> Hmm, I consider -stable rather as kernel.org project. People from
> different distributions/communities cc patches to -stable, review them,
> do backports ...
> 
> >  If they want to have a
> > specific kernel version marked as "-longterm", then they do the work to
> > do so.
> > 
> > What happens in the future, with future releases, is always unknown, as
> > hey, it's the future :)
> > 
> > So I really fail to understand what you are asking for here.
> 
> We have -stable rule that released kernel will be be updated until next
> release - about 2 months.

It's an informal rule, yes.

> I would like to add rule about -longterm kernels. That it have to be one
> form every 3 release, it will be updated about half a year - until next
> -longterm (with possibility of longer updates). Or some similar rule.

Nope, I'm not making such a rule, as you are trying to tell others what
to do here.  And I'm not going to do that.

Also, I'm not going to promise to do such maintainership either, and
last I checked, no distro is going to do that either.

> That version should be good choice for distros and any other long live
> project, and natural candidate for "real longterm" i.e. a few years
> updated/supported kernel version.

Again, distros know exactly what is going on here, they don't need
anything new.

sorry,

greg k-h

Re: -longterm kernels

[Stanislaw Gruszka]

On Sat, May 07, 2011 at 08:40:40AM -0700, Greg KH wrote:
> Nope, I'm not making such a rule, as you are trying to tell others what
> to do here.  And I'm not going to do that.

That was only a proposition, telling you what to do was not my intention.

Regards
Stanislaw

Re: -longterm kernels

[Greg KH]

On Sat, May 07, 2011 at 05:57:50PM +0200, Stanislaw Gruszka wrote:
> On Sat, May 07, 2011 at 08:40:40AM -0700, Greg KH wrote:
> > Nope, I'm not making such a rule, as you are trying to tell others what
> > to do here.  And I'm not going to do that.
> 
> That was only a proposition, telling you what to do was not my intention.

Ah, but that's the main issue here.

It's a matter of people stepping up and doing things, not setting rules
for what others are to maintain, right?

Back to one of your points, is Red Hat somehow not aware of the current
stable/longterm situation and wishes to have things change here?  Last
time I discussed this with the kernel maintainers there, they were fine
with how things are working, has this now changed?

thanks,

greg k-h

Re: -longterm kernels

[Mike Galbraith]

On Sat, 2011-05-07 at 16:55 +0200, Stanislaw Gruszka wrote:
> On Thu, May 05, 2011 at 08:25:01AM -0700, Greg KH wrote:
> > > BTW, Greg, perhaps -logterm releasing policy should be revised somehow.
> > > Currently we have .32, .33, .34, .35 -longterm, what is kind a much.
> > 
> > It's not "much" if you rely on that kernel version, right?
> 
> Yes, but maybe would be better if they do not relay on some versions in
> long term manner, and i.e. .33 users would use .32 and .34 users would
> use .35 instead?

Ceasing to rely upon .33 isn't a trivial choice for -rt tree users.

	-Mike

Re: -longterm kernels

[Stanislaw Gruszka]

On Sat, May 07, 2011 at 12:01:24PM -0700, Greg KH wrote:
> On Sat, May 07, 2011 at 05:57:50PM +0200, Stanislaw Gruszka wrote:
> > On Sat, May 07, 2011 at 08:40:40AM -0700, Greg KH wrote:
> > > Nope, I'm not making such a rule, as you are trying to tell others what
> > > to do here.  And I'm not going to do that.
> > 
> > That was only a proposition, telling you what to do was not my intention.
> 
> Ah, but that's the main issue here.
> 
> It's a matter of people stepping up and doing things, not setting rules
> for what others are to maintain, right?

Right. I quite realize, that I should wrote "I like to maintain regular
longterm kernel releases, what you think?", but well ... my todo queue
is bigger and bigger instead of being smaller - I can not take such task
now, nor in the near future.

I just wanted to share idea about regular longterm releases. Having also
maintainers time in mind. Taking into account that in last time -longterm
kernels arise like mushrooms after the rain, I can imagine that soon
maintained -longterm versions would be i.e. 32,33,34,35,42,43,44,45.
Having 32,35,38,41,44 instead could save maintainers as well as
developers time.

Anyway, I didn't want to tell anyone what to do. Apologize that my posts
sounded that way.

> Back to one of your points, is Red Hat somehow not aware of the current
> stable/longterm situation and wishes to have things change here?  Last
> time I discussed this with the kernel maintainers there, they were fine
> with how things are working, has this now changed?

No, I only speak for myself here not Red Hat at all nor any other RH
employee, all I wrote in this thread were my opinions and ideas.

Thanks
Stanislaw