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¬es=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 ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518810a9.9050...@pyro.eu.org
