linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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.LFD.1.00.0802121051341.2920@woody.linux-foundation.org>
Date:	Tue, 12 Feb 2008 10:59:00 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
	arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, 12 Feb 2008, Linus Torvalds wrote:
> 
> In other words, I'm perfectly happy to be an a*hole and tell people that I 
> simply won't merge things that cause undue API churn at all, and that were 
> not thought out sufficiently.

.. btw: I'd need to know this in advance. I usually don't see the problem 
until it's too late.

And this is very much an area where "Linux-next" can help: if some 
subsystem causes problems in Linux-next for other maintainers, I really 
think it shouldn't just be a matter of "drop the git tree that didn't 
merge cleanly", but it should literally be a question of "maybe we should 
drop the _earlier_ git tree that caused the later one not to merge 
cleanly".

In other words, maybe things like core block layer changes or device model 
changes should be *last* in the merge-list (or if first, also be first to 
be dropped if they cause merge errors downstream!).

That way, infrastructure changes that screw up others can only happen if 
the maintainer actively works with the others to make sure it works even 
before it would ever merge into Linux-next successfully.

That may sound odd, but it actually matches what I personally believe in: 
we have more driver code and other "outlying" things than we have core 
things, and most of our problems come from that - so we should prioritize 
*those* things, not the "fundmantal core changes".

So how about making that the default situation: drivers and other outliers 
merge first. If fundamental API changes happen, they merge last, and if 
their maintainers can't make it in time in the merge window, they just get 
dropped.

That sure as hell would put the pain on API changes solidly where it 
belongs.

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