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 - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
