linux-kernel - Re: Slow DOWN, please!!!

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: <alpine.DEB.1.10.0805011155520.9847@asgard>
Date:	Thu, 1 May 2008 12:07:53 -0700 (PDT)
From:	david@...g.hm
To:	Willy Tarreau <w@....eu>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!

On Thu, 1 May 2008, Willy Tarreau wrote:

> I also proposed to group merges by reduced overlapping areas, and to
> shorten the merge window and make it (at least) twice as often. Rafael
> also proposed to merge core first, then archs, which is a refined variation
> on the same principle. I'm not sure I've seen your opinion on this.

the problem with trying to make the cycle twice as fast is that it takes 
time to hunt down the hard bugs, even when you have some idea where they 
are.

go back through the last few kernels and look at the bugs that were fixed 
in the last couple of -rc releases (and in final), would they have really 
been fixed faster if other changes hadn't taken place?

I suspect that they would not have, and if I'm right the result of merging 
half as much wouldn't be twice as many releases, but rather approximatly 
the same release schedule with more piling up for the next release.

even individual git trees that do get a fair bit of testing (like 
networking for example) run into odd and hard to debug problems when 
exposed to a wider set of hardware and loads. having the networking 
changes go in every 4 months (with 4 months worth of changes) instead of 
every 2 months (with 2 months worth of changes) will just mean that there 
will be more problems in this area, and since they will be more 
concentrated in that area it will be harder to fix them all fast as the 
same group of people are needed for all of them.

if several maintainers think that you are correct that doing a merge with 
far fewer changes will be a lot faster, they can test this in the real 
world by skipping one release. just send Linus a 'no changes this time' 
instead of a pull request. If you are right the stable release will happen 
significantly faster and they can say 'I told you so' and in the next 
release have a fair chance of convincing other maintainers to skip a 
release.

it does worry me a bit that the release cycle seems to be slipping 
slightly each release, but I don't see a good way to fix this.

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