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]
Date:	Wed, 21 May 2008 18:15:30 +0300
From:	Tarkan Erimer <tarkan@...one.net.tr>
To:	Mike Snitzer <snitzer@...il.com>
CC:	Pekka Enberg <penberg@...helsinki.fi>,
	Arjan van de Ven <arjan@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Suggestion About Kernel Releases

Mike Snitzer wrote:
> I think you're missing Arjan and Pekka's point: your proposal doesn't
> _really_ offer any change to the current procedure.  It might make you
> feel more warm and fuzzy but in practice:
> 1) Linus would still release a kernel (be it to -testX or "final")
> when he and others feel it is time
> 2) The stable team will track fixes and release stable kernels as needed
>
> The only thing that is different in your approach is the "final"
>   
Yes, that's what I'm talking about. The change will be the "testX" 
thing. And as you already stated it will help more stable releases.
> release would theoretically be more well tested.  Unfortunately that
> is not a valid assumption because the wider Linux audience likely
> won't embrace the latest kernel until it is "final" anyway.  This
> delayed uptake can/will result in early stable fixes.
>
>   
Of course as didn't embrace like the "rc" releases. I don't think that 
it will cause early stable fixes. Contrarily, it will produce more 
tested/stable releases. You may think it as a kind of "rc" series.


> Again, no real change... we know that the "final" release that Linus
> makes _could_ have some minor oversight that will be fixed fairly
> quickly by the stable team.
>
> Mike
>   
It is. As I described above : the "testX" series will change the things 
as producing more tested /stable releases. BTW, it should be much better 
to release less, trouble free kernels instead of releasing fast but 
fixing soon. Also, it will take the load of deep kernel testing. Linus 
should only do the applying the patches for the next kernel release via 
"rc" releases. Then when Linus decided all the patches, for the next 
kernel, applied he will pass it to the "testX" series maintainer as 
Chris did for 2.6.x.y.



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