On 2013-11-29 10:27, Stéphane Glondu wrote: > Le 28/11/2013 21:52, Niels Thykier a écrit : >>> [...] >> >> Keeping them around is different from them being considered as release >> architectures (or even just keeping them in testing). Keeping these >> architectures in testing do involve a burden, like blocking testing >> migration when they FTBFS[1]. > > And what about (somehow automatically, like RC-buggy packages) removing > packages from testing only on these architectures? > > > Cheers, >
Maybe I am misreading you proposal, but it seems to me that a change like that would undermine the concept of build regressions being RC for release architectures. Alternatively, we would end up with "second-rate" release architectures[1], where build regressions are no longer RC bugs. However, at that point I am not sure we are willing to call it a release architecture. ~Niels [1] Assuming here you don't want packages to be removed from amd64/i386 when a maintainer uploads a truly broken package to sid and leaves it there for 3 months. There has been examples of this in the past. If you look for it, you can probably find an example of it in the archive right now as well. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ad9a81.1020...@thykier.net
