Re: Hurd and the archive

[Steven Chamberlain <steven@pyro.eu.org>]

On 06/05/13 20:27, Joerg Jaspert wrote:
> Adding it and then keeping it out of the usual migration rules is asking
> for failure from the beginning, accumulating cruft. Not a way to go, IMO.

In that case would there be 150-200 RC-severity bugs introduced right
away by its inclusion?  (Packages which FTBFS on hurd-i386 that are
already 'out of date' in sid, counting Failed + Build-Attempted) :

https://buildd.debian.org/status/architecture.php?a=hurd-i386&suite=sid&notes=out-of-date

This was the best figure I could think of to quantify the 'burden' of a
particular arch being included in testing.  For comparison, kfreebsd
arches tally ~50, armel/mipsel ~50, ia64 ~60, amd64/i386 only 10-20.

There is a lot of overlap though, e.g. fixing a kfreebsd build failure
may fix hurd-i386.


I found some mention/suggestion that for arch-specific issues, a
'technology preview' may be released even if some RC-severity bugs
remain (though probably not when packages FTBFS);  and relaxed criteria
might be used during freeze and for stable updates:

https://lists.debian.org/debian-bsd/2011/06/msg00365.html

Regards,
-- 
Steven Chamberlain
steven@pyro.eu.org