Re: Release sprint results - team changes, auto-rm and arch status

[Niels Thykier <niels@thykier.net>]

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.