On Thu, May 01, 2008 at 08:26:27AM -0700, Linus Torvalds wrote:
quoted text
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/