Re: Release sprint results - team changes, auto-rm and arch status
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
Reply to: