[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)

On Sat, Mar 19, 2005 at 09:52:18AM -0600, Gunnar Wolf wrote:
> Steve Langasek dijo [Fri, Mar 18, 2005 at 11:32:08PM -0800]:
> > > There are packages we recognize will be of little use in certain
> > > architectures - say, KDE on m68k, qemu on a !i386, etc. They should be
> > > built anyway on all architectures where expected to run be buildable,
> > > anyway, as a QA measure - many subtle bugs appear as the result of
> > > architecture-specific quirks.

> > > "Architecture: any" means "build anywhere". We could introduce a
> > > second header, say, Not-deploy-for: or Not-required-for:. This would
> > > mean that KDE _would_ be built for m68k if the buildds are not too
> > > busy doing other stuff, and probably would not enter our archive (or
> > > would enter a different section - just as we now have contrib and
> > > non-free, we could introduce not-useful ;-) )

> > As pointed out in a recent thread, most of the core hardware portability
> > issues are picked up just by building on "the big three" -- i386, powerpc,
> > amd64.  If we know the software isn't going to be used, is it actually
> > useful to build it as a "QA measure"?  What value is there, in fact, in
> > checking for bugs that will only be tripped while building software that
> > isn't going to be used?

> As you say, _most_ of the issues are triggered by one of those three
> chips, not all. And, by not making a hard requirement to compile the
> packages which will not be used, you are not holding the project back
> waiting for m68k's KDE. Probably m68k will _never_ compile KDE, as I
> doubt their buildds are ever idle - But what do you prefer, say, for
> our ia64 buildd, to just sit there waiting for a new package to
> arrive, or to start compiling something that will be useful only for
> QA, and only probably?

But, er, ia64 isn't a slow architecture at all, so there's no reason that
the packages being built there wouldn't be usable in the real world -- ia64
should build kde, and then upload it, because it's useful.  What was being
proposed here, OTOH, was to build packages for architectures where the
packages wouldn't be used in the real world due to architecture constraints.

I can think of two great reasons not to use random, never-to-be-used
packages as a means of doing QA on embedded architectures: it's a waste of
electricity, and it doesn't bring a benefit in proportion to the effort.  If
we find that our toolchains for embedded architectures are weak, then we
should certainly try to do better QA on them -- by finding tests that are
relevant to the real world, not just by proving that our buildds are
heavyweight compilation champions.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: