linux-kernel - Re: [RFC] Kernel version numbering scheme change

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]

Date:	Wed, 22 Oct 2008 20:11:49 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Alex Howells <alex@...emark.co.uk>
CC:	Greg KH <greg@...ah.com>,
	Alexandre Oliva <oliva@....ic.unicamp.br>,
	"H. Peter Anvin" <hpa@...nel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Kernel version numbering scheme change

Alex Howells wrote:
> So with regards to supported kernels, the following springs to mind:
> 
>    *  how long is kernel 2.6.xx supported?
>    *  is kernel 2.6.xx one of the "longer term" supported ones?
>    *  what are the requirements for a maintainer to push a
>       new release, a la 2.6.xx.yy? Is it based on time elapsed,
>       severity of any fixes included?
>    *  how do we define "support" in this context?
>       does it mean security problems discovered/fixed *after*
>       development focus has moved on to new stuff is backported?
>       does it mean [critical] bug fixes? regression fixes?

That's all quite simple to answer with a firm "depends".

  1. Remember, it's all volunteer work (by companies and individuals).

  2. Watch the release announcements and changelogs to learn about the
     lifetimes of -stable lines (they vary due to circumstances) and
     about what goes in into these lines.  There are also some bits in
     Documentation/stable_kernel_rules.txt.

Among else, it depends on volunteered manpower for patch verification
and even on sheer coincidence (somebody needs to be aware that an issue
is relevant to an active -stable line) whether a fix goes into -stable
or not.

Circumstances which lead to a -stable line remaining active for longer
than usual typically boil down to the motives of an individual developer
who picks up maintenance, like Adrian happened to do with 2.6.16.y and
plans to repeat with 2.6.27.y, or like Greg kept/ keeps 2.6.25.y active
alongside 2.6.26.y because it's directly useful to other work of his, AFAIU.

If you are interested in more structured release policies, you shouldn't
hesitate to have a look at vendor kernel lines.
-- 
Stefan Richter
-=====-==--- =-=- =-==-
http://arcgraph.de/sr/
--
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/