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]

Date:	Thu, 1 May 2008 14:35:51 -0400
From:	Chris Frey <cdfrey@...rsquare.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: Slow DOWN, please!!!

On Thu, May 01, 2008 at 08:26:27AM -0700, Linus Torvalds wrote:
> So let me repeat:
> 
>  (1) we have new code. We always *will* have new code, hopefully. A few
>      million lines pe year.

Pardon this comment from an inexperienced kernel hacker, but it seems to
me that one of the main problems is subsystems stomping on each other
during the merge window, and a general confusion as to who is responsible
for what bugs that appear.

Perhaps a shorter merge window, using a round-robin approach, based on
subsystem, would help alleviate these issues?

This would:

	- give people a "known" tree to base their subsystem patches on,
		when their turn comes around

	- give a rough schedule if the round-robin was always consistent
		in order, or made known in advance

	- a shorter window would keep people from waiting too long for
		their turn

	- give those responsible for the currently merged subsystem
		motivation and clarity to fix bugs that do appear during
		their merge window

Problems I see with this approach:

	- those at the end of the cycle get the shaft, if previous changes
		affect their work

	- political issues with determining the order of the round-robin
		schedule

If I'm overlooking something, I'm sure someone will correct me. :-)

- Chris

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