|| ||Andi Kleen <andi-AT-firstfloor.org> |
|| ||Greg KH <greg-AT-kroah.com> |
|| ||Plans for 2.6.35-longterm was Re: Linux stable kernel release
procedure changes |
|| ||Fri, 3 Dec 2010 10:35:20 +0100|
|| ||linux-kernel-AT-vger.kernel.org, Andrew Morton <akpm-AT-linux-foundation.org>,
torvalds-AT-linux-foundation.org, stable-AT-kernel.org, lwn-AT-lwn.net,
Andi Kleen <andi-AT-firstfloor.org>, tim.bird-AT-am.sony.com|
|| ||Article, Thread
> 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: firstname.lastname@example.org 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
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
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.
email@example.com -- Speaking for myself only.
to post comments)