Le 15/12/2013 13:03, 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? > > 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.
My proposal was in response to dropping a release architecture altogether. I had the feeling that this new intermediate status (let's call it "partial", "second-rate", or "technological preview") would not be too much additional work. > [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. I don't understand this remark. My proposal doesn't affect release architectures such as amd64/i386. And removals would be only from testing. Cheers, -- Stéphane -- 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/52aece6a.9050...@debian.org
