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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110507145503.GA2276@redhat.com>
Date:	Sat, 7 May 2011 16:55:03 +0200
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Greg KH <greg@...ah.com>
Cc:	stable@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: -longterm kernels

On Thu, May 05, 2011 at 08:25:01AM -0700, Greg KH wrote:
> > 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.

> 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.

> > 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 ...

>  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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ