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

Greg KH
2008-02-12T19:21:52Z

On Tue, Feb 12, 2008 at 10:59:00AM -0800, Linus Torvalds wrote:
>
>
> 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".

We usually get this warning today in -mm.

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

Sure, I have no objection to that at all.

thanks,

greg k-h