|Main Archive Page > Month Archives > linux-kernel archives|
On Saturday 27 February 2010, Ingo Molnar wrote:
> * Rafael J. Wysocki <firstname.lastname@example.org> 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.
> 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.
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.
Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/