linux-kernel - Plans for 2.6.35-longterm was Re: Linux stable kernel release procedure changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20101203093519.GA8800@basil.fritz.box>
Date:	Fri, 3 Dec 2010 10:35:20 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, stable@...nel.org, lwn@....net,
	Andi Kleen <andi@...stfloor.org>, tim.bird@...sony.com
Subject: Plans for 2.6.35-longterm was Re: Linux stable kernel release
 procedure changes

> 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: stable@...nel.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 
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

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/