On Sat, 2011-01-15 at 18:23 +0100, Andrea Arcangeli wrote: > > > By all means next times I'll try to get through linux-next too if this > is preferred, but the brainer part has been heavily tested and that's > the important thing as far as I can see. Linux-next is the integration testing essentially. That's where we find such build regression and to a lesser extent maybe, runtime regressions. I think you under estimate the pain caused by build breakage. The main problem is that it makes bisection difficult, and that's a pretty big deal in a merge window. If everybody stops caring about build breakage, bisection would essentially become unusable accross merge windows. > I'm also not sure if having it in linux-next instead of -mm, would > have been better in terms of handling of the patchstream. I think > having it managed in -mm reviewed by all other -mm developers using > raw patches floating in the linux-mm and mm-commit lists, was ideal > and potentially more valuable for an increased amount of review, than > what a blind pull from linux-next could provide. For the brainer part, > maximizing the reviewing was certainly more valuable than checking if > it builds and boots on some arch not affected in any functional way. It's not a matter of -mm vs. -next. You should not have a patch set that is still a work in progress in -next. The later is for things that are essentially ready to merge, to simmer there for a few days to find out typically bad patch collisions (more than simple fixups), such build breakages, major runtime breakages, etc... Ideally, things in -next don't need a respin before going upstream but at least there's a last chance to do so. The question becomes should -mm itself go into -next, and that I'm less certain of. It depends on what criterias Andrew applies to things that go into -mm I suppose, but if they qualify as "mature stuff ready to go upstream" then by all means. > I think the sparc/arm build issues because of cleanup code refactoring > are not worth worrying too much about, or at least they shouldn't be > the argument for lack of testing. Said that, I apologize for the > annoyance and I appreciate your help in the arm case. ia64 I fixed it > with a one liner already. But that's the whole point... all those "little issues" have actually broken build on 3 architectures so far, and this is -bad-. Yes, none of them is major, all of them are easily fixed ... and all of them have been a pain in the neck for some people somewhere and have broken bisection accross a portion of the merge window. Having a bit of time in -next allows to easily avoid most of this. > Overall I think the end result is great, perfection was the goal and > if these build issues are the only error I think we got as close as > humanly possible to it. And it's definitely thanks to an huge amount > of help and feedback from the whole Linux community (both developers, > maintainers and testers) if we could achieve this result, I could > never achieve this alone. Cheers, Ben. -- 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
