Re: linux-next requirements (Was: Re: [tip:x86/ptrace] ptrace: Addsupport for generic PTRACE_GETREGSET/PTRACE_SETREGSET)

[Ingo Molnar]

* Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:

> Hi Ingo,
> 
> On Mon, 22 Feb 2010 11:27:45 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> > 
> > > On Mon, 22 Feb 2010 10:07:10 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:
> > > >
> > > > I'll keep them in tip:master to get them tested, but note that i cannot 
> > > > push any of these patches into linux-next until this is fixed, as 
> > > > linux-next requires all architectures to build, with no regard to which 
> > > > architectures are tested by kernel testers in practice.
> > > 
> > > I merely expect people not to push known broken code into linux-next.
> > 
> > FYI, this 'mere' kind of indiscriminate definition of 'breakage' is what i am 
> > talking about.
> 
> OK, let me remove "merely" from this.
> 
> I expect people not to push known broken code into linux-next.  Code in
> linux-next is meant to be as ready as possible to be sent to Linus.  If
> you know that it breaks some architecture then it should obviously be
> fixed some how (unless the architecture maintainer really doesn't care,
> of course).
> 
> This is different from not knowing that it breaks some architecture even
> though you have done reasonable testing.
> 
> > The occasional driver build breakage can be tested relatively easily: one 
> > allyesconfig build and it's done. Build testing 22 architectures is 
> > exponentially harder: it requires the setup (and constant maintenance) of 
> > zillions of tool-chains, plus the build time is significant as well.
> > 
> > So this kind of linux-next requirement causes the over-testing of code that 
> > doesnt get all that much active usage, plus it increases build testing 
> > overhead 10-fold. That, by definition, causes the under-testing of code that 
> > _does_ matter a whole lot more to active testers of the Linux kernel.
> 
> Which is why linux-next does *not* require that. [...]

How can you reconcile that with:

> I expect people not to push known broken code into linux-next.  Code in

?

So is it your point that technically you 'expect' but dont 'require'?

That's mostly word games really IMO, as in the end there's not much of a 
difference in practice: because you report build failures of non-mainstream 
architectures pretty much the same way as the main architectures.

I.e. indirectly you push up their importance, while taking away resources from 
the main architectures. Testing and maintainer attention is a finite resource, 
it's all a zero-sum game.

So in the end maintainers either cross-build to all architectures and avoid 
all the squeaky-wheel overhead of linux-next, or avoid pushing to it all that 
frequently. Which causes the collateral damage i mentioned:

> The occasional driver build breakage can be tested relatively easily: one 
> allyesconfig build and it's done. Build testing 22 architectures is 
> exponentially harder: it requires the setup (and constant maintenance) of 
> zillions of tool-chains, plus the build time is significant as well.
>
> So this kind of linux-next requirement causes the over-testing of code that 
> doesnt get all that much active usage, plus it increases build testing 
> overhead 10-fold. That, by definition, causes the under-testing of code that 
> _does_ matter a whole lot more to active testers of the Linux kernel.
>
> Which is a problem, obviously.

The solution? Stop this anti-real-world-usage bias already. Stop pretending 
that those cross-build results are as important as say the thousands of real 
bugzilla entries we have. They are fine info, but the kind of priority you are 
giving them is causing a waste of resources.

The thing is, testing whether the kernel still builds with gcc33 has more 
practical relevance to Linux users than testing about half of the 
architectures. The ancient NE2000 driver probably still has ten times more 
users than half of the architectures we have. Do you boot-test NE2000 with 
linux-next?

Developers simply cannot be expected to build for 22 architectures, and they 
shouldnt be. It's somewhat of a waste of time even on the subsystem maintainer 
level. (although it's certainly more contained there, plus subsystem 
maintainers generally have more hw resources as well.)

The thing is, last i checked you didnt even _test_ x86 as the first step in 
your linux-next build tests. Most of your generic build bug reports are 
against PowerPC. They create the appearance that x86 is a second class citizen 
in linux-next.

IMHO a generic tree like linux-next should be fundamentally neutral and its 
testing should be weighted _towards_ real Linux usage. You should try hard to 
avoid even the _apperance_ of pro-PowerPC (and anti-x86) bias - but AFAICS you 
dont even try.

Which i see as a problem.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/