The 98% and N<=2 criteria (was: Vancouver meeting - clarifications)
Peter 'p2' De Schrijver <email@example.com> schrieb:
[quoting Andreas Barth]
>> | - the release architecture must have successfully compiled 98% of the
>> | archive's source (excluding architecture-specific packages)
>> well, that's just an "the architecture is basically working", so that we
>> don't get too many RC-bugs because of architecture-specific issues, and
>> also don't get too many packages kept out of testing for not all archs
>> being built. Of course, the 98% is not engraved into stone, and might just
>> be another arbitrary high number like 97.5%. From looking at the usual
>> level where we start noticing problems with testing migrations, a number
>> in this range is sane.
> I strongly disagree with this. There is a need for a set of base
> packages to work, but it's entirely reasonable to have a release for eg
> m68k without KDE or other large package sets. It's not as if debian/m68k
> would be unusable without KDE packages for example.
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.
For the porters to a specific architecture, this means they have an easy
way to get nearer to the 98% and the N<=2 criteria: Just convince the
maintainers of heavy-loaded desktop stuff, of big self-bootstrapping
numbercrunching applications, and whatever, to take your architecture
out of the Architecture field.
And this is not "cheating". If KDE is of no use on m68k or for most
mips applications; or if 98% of sparc users don't need a desktop, then
it's not unjust if those are simply excluded. Remember, in the old days
before Vancouver ;-) it was mainly compiled for the benefit of the
And for the 2% of sparc users that do use KDE, it would probably be okay
to have a separate archive for such stuff.
 this is just an example, I have no idea how a sparc compares to
other machines; I just read that they are today manly used for server
Inst. f. Biochemie der Univ. Zürich