-longterm kernels (Was: Re: [stable] Patch Upstream: iwlwifi: fix skb usage after free)
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
(Removing Cc as probably not interested, adding LKML)
Quoted 5 lines · Greg KH
Quoted 1 line
Cc [email protected] # 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 [email protected] ?
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)
Hi,
Quoted 7 lines · Stanislaw Gruszka
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.
Quoted 4 lines
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
Quoted 5 lines · Stanislaw Gruszka
(Removing Cc as probably not interested, adding LKML)
Quoted 2 lines · Greg KH
Quoted 1 line
Cc [email protected] # 2.6.32+
Quoted 7 lines
Quoted 3 lines
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 [email protected] ?
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.
Quoted 6 lines
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.
Quoted 4 lines
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
Quoted 4 lines · Greg KH
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 6 lines
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 ...
Quoted 8 lines
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
Quoted 9 lines · Stanislaw Gruszka
Quoted 4 lines · Greg KH
Quoted 2 lines
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.
Quoted 5 lines
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? :)
Quoted 27 lines
Quoted 4 lines
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.
Quoted 9 lines
Quoted 6 lines
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 ...
Quoted 4 lines
If they want to have a
specific kernel version marked as "-longterm", then they do the work to do so.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 2 lines · Greg KH
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
Quoted 5 lines · Stanislaw Gruszka
Quoted 2 lines · Greg KH
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
Quoted 11 lines · Greg KH
Quoted 5 lines · Stanislaw Gruszka
Quoted 2 lines · Greg KH
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.
Quoted 4 lines
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
Re: -longterm kernels
In reply to Stanislaw GruszkaQuoted 9 lines · Stanislaw Gruszka
Quoted 4 lines · Greg KH
Quoted 2 lines
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