Re: ia64 broken by transparent huge pages - other arches too?

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.