Hi all,
Over 5 1/2 years ago we started the stable Linux kernel releases, and by
all merits they seem to be pretty popular.
The stable series started out as a "once the next release is out, drop
the old one and move on" type of thing. This worked really well until I
decided to have the 2.6.16 be a "longterm" release. Then I did the same
thing for the 2.6.27 and later the 2.6.32 release.
These longterm releases have become very popular for the distros to base
their work on, and are getting so popular, people are now asking to do
the same thing for almost all of the recent kernels.
As this is way beyond the amount of time I have to spend on this, I've
been discussing with some people how to handle this type of thing. In
working through the issues, I've decided that a change is due.
So, it's "back to our roots" time, and I'm now only going to be doing
-stable releases for the last kernel released, with the usual one or two
release overlap with the latest release from Linus to give people a
chance to move over and have the new release stabilize a bit.
I'm doing this as it's just way too confusing to try to explain to
people exactly what kernels are being maintained longer than others, and
why they are being maintained. Not to mention the confusion on the
kernel.org web site where it's hard to tell what kernel release is
currently being maintained or not.
I think this is a good thing and will help both the community and
developers get back on track and focusing on the latest releases and not
needlessly waste their time on years old kernels that only distros care
about.
Oh, wait, what about those older kernels that I said I would maintain
for a long time? Don't worry, they are sticking around but they now
have a new name "longterm" to better reflect what they are. These
kernels will have a specific maintainer, and we will show them on the
kernel.org site in some way to show what exactly is going on with them.
These longterm kernels will abide by the same stable_kernel_rules.txt
that I've been using for the older stable rules.
For now, I'll be continuing to maintain the .27 and .32 kernels as
"longterm" kernels, but will probably be handing .27 off soon, as I'm
getting tired of it and my resources are getting limited.
I already have someone lined up who wants to maintain the .35 kernel in
a longterm manner that I trust, Andi Kleen, and I'll let him write to
explain his goals for this kernel and what he's going to do.
Also, as many people have asked about this in the past, I'm now happy to
announce that the [email protected] email address is now a mailing list
that anyone can subscribe to in order to see the patches that are sent
to it, if they wish to comment or maintain their own kernel tree. I
will warn you, it's pretty boring, and high volume at times, but hey,
it's better to work in the open as that's how we need to operate.
You can subscribe to the list at the following link if you are so
interested:
http://linux.kernel.org/mailman/listinfo/stable
So, that's a lot of information, but if anyone has any questions about
this please let me know. We're still figuring out what git tree we are
going to use for the longterm patch queue(s) and where to put the
releases on the kernel.org site. Hopefully all that will be hashed out
in the next week or so.
thanks,
greg k-h
tl;dr:
stable kernel releases only for the last kernel version,
longterm releases for older releases done by me and different
people but with stable_kernel_rules.txt rules, [email protected]
mailing list is now open.
I appreciate the amount of work involved in a "-longterm", and had
been hoping that .37 would be the next candidate. In addition to
the distros, those of us embedding Linux have enjoyed the ability
to base a variety of products on a common "-longterm" kernel.
I could use some idea of the hours/{week,month} needed for an
experienced kernel maintainer to keep a "-longterm" updated for,
at least, bug fixes from later kernels.
Thank you for your time and effort.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Greg KH
> Sent: Thursday, December 02, 2010 4:43 PM
> To: [email protected]; Andrew Morton;
> [email protected]; [email protected]
> Cc: [email protected]; Andi Kleen; [email protected]
> Subject: Linux stable kernel release procedure changes
>
> Hi all,
>
> Over 5 1/2 years ago we started the stable Linux kernel
> releases, and by
> all merits they seem to be pretty popular.
>
> The stable series started out as a "once the next release is out, drop
> the old one and move on" type of thing. This worked really
> well until I
> decided to have the 2.6.16 be a "longterm" release. Then I
> did the same
> thing for the 2.6.27 and later the 2.6.32 release.
>
> These longterm releases have become very popular for the
> distros to base
> their work on, and are getting so popular, people are now asking to do
> the same thing for almost all of the recent kernels.
>
> As this is way beyond the amount of time I have to spend on this, I've
> been discussing with some people how to handle this type of thing. In
> working through the issues, I've decided that a change is due.
>
> So, it's "back to our roots" time, and I'm now only going to be doing
> -stable releases for the last kernel released, with the usual
> one or two
> release overlap with the latest release from Linus to give people a
> chance to move over and have the new release stabilize a bit.
>
> I'm doing this as it's just way too confusing to try to explain to
> people exactly what kernels are being maintained longer than
> others, and
> why they are being maintained. Not to mention the confusion on the
> kernel.org web site where it's hard to tell what kernel release is
> currently being maintained or not.
>
> I think this is a good thing and will help both the community and
> developers get back on track and focusing on the latest
> releases and not
> needlessly waste their time on years old kernels that only
> distros care
> about.
>
>
> Oh, wait, what about those older kernels that I said I would maintain
> for a long time? Don't worry, they are sticking around but they now
> have a new name "longterm" to better reflect what they are. These
> kernels will have a specific maintainer, and we will show them on the
> kernel.org site in some way to show what exactly is going on
> with them.
>
> These longterm kernels will abide by the same stable_kernel_rules.txt
> that I've been using for the older stable rules.
>
> For now, I'll be continuing to maintain the .27 and .32 kernels as
> "longterm" kernels, but will probably be handing .27 off soon, as I'm
> getting tired of it and my resources are getting limited.
>
> I already have someone lined up who wants to maintain the .35
> kernel in
> a longterm manner that I trust, Andi Kleen, and I'll let him write to
> explain his goals for this kernel and what he's going to do.
>
>
> Also, as many people have asked about this in the past, I'm
> now happy to
> announce that the [email protected] email address is now a
> mailing list
> that anyone can subscribe to in order to see the patches that are sent
> to it, if they wish to comment or maintain their own kernel tree. I
> will warn you, it's pretty boring, and high volume at times, but hey,
> it's better to work in the open as that's how we need to operate.
>
> You can subscribe to the list at the following link if you are so
> interested:
> http://linux.kernel.org/mailman/listinfo/stable
>
>
> So, that's a lot of information, but if anyone has any questions about
> this please let me know. We're still figuring out what git
> tree we are
> going to use for the longterm patch queue(s) and where to put the
> releases on the kernel.org site. Hopefully all that will be
> hashed out
> in the next week or so.
>
> thanks,
>
> greg k-h
>
>
> tl;dr:
> stable kernel releases only for the last kernel version,
> longterm releases for older releases done by me and different
> people but with stable_kernel_rules.txt rules, [email protected]
> mailing list is now open.
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi Greg,
On Thu, Dec 02, 2010 at 04:42:47PM -0800, Greg KH wrote:
> I'm doing this as it's just way too confusing to try to explain to
> people exactly what kernels are being maintained longer than others, and
> why they are being maintained. Not to mention the confusion on the
> kernel.org web site where it's hard to tell what kernel release is
> currently being maintained or not.
I'm just thinking that maybe the kernel.org site could reflect only
the versions for which a "LATEST-IS" entry exists. That way, it's
easy to remove old files when an old kernel is not supported anymore.
> I think this is a good thing and will help both the community and
> developers get back on track and focusing on the latest releases and not
> needlessly waste their time on years old kernels that only distros care
> about.
I'd say that not only distros care about them, your support of 2.6.27
is very much appreciated by people who have to install and maintain
servers they can't afford to upgrade every month. But I certainly
understand the amount of work it represents and when I see you post
500 patches at once, I always wonder how much time it takes to you
to prepare that, and whether you're going to blow a fuse or not !
> I already have someone lined up who wants to maintain the .35 kernel in
> a longterm manner that I trust, Andi Kleen, and I'll let him write to
> explain his goals for this kernel and what he's going to do.
Good news !
> Also, as many people have asked about this in the past, I'm now happy to
> announce that the [email protected] email address is now a mailing list
> that anyone can subscribe to in order to see the patches that are sent
> to it, if they wish to comment or maintain their own kernel tree. I
> will warn you, it's pretty boring, and high volume at times, but hey,
> it's better to work in the open as that's how we need to operate.
Ah that's really nice. I've been following your announces to pick/review
patches there, now I won't bother you to know if you got patch X or Y :-)
BTW I think we should be careful not to discuss too much on the list in
order not to pollute it, otherwise some patches risk to be lost.
Thanks!
Willy
> I already have someone lined up who wants to maintain the .35 kernel in
> a longterm manner that I trust, Andi Kleen, and I'll let him write to
> explain his goals for this kernel and what he's going to do.
Thanks Greg, for all your work on this.
I plan to maintain the 2.6.35 tree longterm for now. My employer
(Intel) is interested in basing a distribution on it, and there are others
(like CELF) who also want to base long term trees on 2.6.35.
The longterm tree will continue where Greg left 2.6.35-stable.
It will not be called "stable", but called "longterm" to make
the distinction clear.
The tree will follow the stable rules in Documentation/stable_kernel_rules.txt.
My plan is to look at all patches that go into later stables (that is which
are sent to stable@ or marked Cc: [email protected] in the git description)
and merge them into 2.6.35 when applicable. I don't expect there will be many
patches only for 2.6.35 and not for later stable trees. If there are and
they are submitted to stable@ I will consider them. I plan to be fairly
conservative.
I will follow a similar flow as Greg: There will be candidate trees which
are posted to Linux kernel and have a 48h review period, with patches
being dropped then as needed. Then the candidates will turn into
releases.
Right now I only plan to post them to linux-kernel and not bother the
usual review comittee, but this may change if the reviewers want to see
2.6.35 too. There are also at least one volunteer (hi Tim) who plans
to test the tree (but it still needs to be worked out if that should
be done before or after the release). Any others doing reviewing and testing
would be also appreciated.
For security problems there will be faster releases, using a similar
procedure as Greg uses today.
The exact locations for the candidate and release trees on kernel.org
still need to be worked out and will be announced at a future date.
I should also add I will be on vacation for three weeks in December. I plan
to release a catchup release before that and then pick up everything
else left after that.
-Andi
--
[email protected] -- Speaking for myself only.