[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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

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


 \ /
  Last update: 2008-02-12 20:25    [W:0.219 / U:0.092 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site