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

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

On Fri, Mar 18, 2005 at 09:35:04PM -0600, Gunnar Wolf wrote:
> Frank Küster dijo [Tue, Mar 15, 2005 at 02:15:15PM +0100]:
> > This whole argument is bogus.  Up to before Vancouver, we always said:
> > "A package should be Architecture: any if it can in principle be
> > compiled on every arch; the fact that it might not be useful there does
> > not justify excluding it from that arch."  And AFAIK the rationale for
> > this was overall quality of the distribution.

> > Now with the requirement for 98% compiled (and N<=2 buildd's being able
> > to take the workload) the focus has shifted: From overall quality to
> > timely release and quality of individual architectures.
> > (...)

> Ummm... What do you think about this:

> 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?

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: