linux-kernel February 2010 archive
Main Archive Page > Month Archives  > linux-kernel archives
linux-kernel: Re: linux-next requirements

Re: linux-next requirements

From: Geert Uytterhoeven <geert_at_nospam>
Date: Sat Feb 27 2010 - 21:50:15 GMT
To: "Rafael J. Wysocki" <rjw@sisk.pl>


On Sat, Feb 27, 2010 at 20:07, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Saturday 27 February 2010, Ingo Molnar wrote:
>> * Rafael J. Wysocki <rjw@sisk.pl> wrote: >> >> > > > Lets see.  Over the last 60 days, I have reported 37 build errors.  Of >> > > > these, 16 were reported against x86, 14 against ppc, 7 against other >> > > > archs. >> > > >> > > So only 43% of them were even relevant on the platform that 95+% of the >> > > Linux testers use? Seems to support the points i made. >> > >> > Well, I hope you don't mean that because the majority of bug reporters (vs >> > testers, the number of whom is unknown to me at least) use x86, we are free >> > to break the other architectures. ;-) >> >> It means exactly that: just like we 'can' break compilation with gcc296, >> ancient versions of binutils, odd bootloaders, can break the boot via odd >> hardware, etc. When someone uses that architectures then the 'easy' bugfixes >> will actually flow in very quickly and without much fuss >
> Then I don't understand what the problem with getting them in at the linux-next
> stage is.  They are necessary anyway, so we'll need to add them sooner or
> later and IMO the sooner the better.
>
> Apart from this, that cross-build issues aren't always "easy" and sometimes
> they take quite some time and engineering effort to resolve.  IMO that's better
> done at the linux-next stage than during a merge window.
> >> - and without burdening developers to consider cases they have no good ways >> to test.  Why should rare architectures be more important than those other >> rare forms of Linux usage? >
> Because the Linus' tree is supposed to build on those architectures.  As long
> as that's the case, linux-next should build on them too.
> >> In fact those rare ways of building and booting the kernel i mentioned are >> probably used _more_ than half of the architectures that linux-next >> build-tests ... >
> I don't know and you don't know either.  That's just pure speculation and
> therefore meaningless.

If only the CE Linux Forum member companies would publish figures about the number of Linux devices they push onto the world population...

Yes I know, this still excludes `obsolete' architectures like parisc and alpha, but it would
change the balance towards x86 (and powerpc?) drastically. >> So yes, of course _all_ bugs need fixing if there's enough capacity, but the >> process in general should be healthy, low-overhead and shouldnt concentrate on >> an irrelevant portion of Linux usage in such a prominent way. >> >> Or, if it does, it should _first_ cover the other, much more burning areas of >> testing interest. All the while our _real_ bugreports are often rotting on >> bugzilla.kernel.org ... >
> All right.  There are two _separate_ questions to ask IMO:
>
> (1) Do we need the kind of community service that Stephen has been doing?
>
> (2) Do we need more testing of linux-next and if so, who's task should that be?
>
> I think you agree that the aswer to (1) is "yes, we do".  So _someone_ has to
> do it and I'm very grateful to Stephen for taking care of it.
>
> [Thanks, Stephen!]
>
> Now, the part of this service is to check that the resulting tree will actually
> build in all conditions it's supposed to build in, if possible, or the whole
> merging exercise wouldn't have much practical meaning.  Stephen has been
> doing just that and IMO to a good result.
>
> To some extent, though, that's a matter of defining in what conditions the
> kernel is supposed to build in, but I think for linux-next these conditions
> should be the same as for the Linus' tree, for the simple reason that
> linux-next is supposed to be a "future snapshot" of it.   So linux-next should
> build on all architectures that the future Linus' tree is supposed to build on.
> Even on "exotic" ones.
>
> [IMO that's actually important, because such corner cases tend to reveal
> runtime bugs we wouldn't have been aware of otherwise.  Now, in the majority
> of cases a casual tester will be discouraged by the kernel not compiling for
> him while he might have found a "real" bug otherwise.]
>
> Now, as far as (2) and is concerned, I think the answer here is also "yes, we
> do", but that's not a part of the Stephen's job.

While wearing my m68k hat, I can say that I suffer an order of magnitude more from
build failures than from boot failures. So I'm inclined to agree with Linus when he says
`if it compiles, it's great; if it boots, it's perfect' :-)

Or perhaps this says more about our review process: we're quite good at catching logical errors in our code, and worse at catching syntax and dependency errors. Fortunately we have tools (and linux-next) to catch those...

Gr{oetje,eeting}s,

                                                Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/