Re: julia_1.0.0-1_amd64.changes REJECTED
Sean Whitton:
> Hello,
>
> On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote:
>
>> On Wed, Nov 21, 2018 at 05:57:40PM +0000, Dimitri John Ledkov wrote:
>>> Before we get there, we should first start autoremoving packages from
>>> unstable, if we consider rc-buggy in unstable to be unacceptable. We
>>> do have quite a bit of things in unstable, that are neither getting
>>> fixed, nor getting removed. And are in this limbo state of "no longer
>>> in testing.... no longer in stable.... no longer in old-stable...
>>> still in unstable".
>>
>> I'm all for it.
>
> What harm are the packages doing sitting in unstable? Distributing them
> does not have much point, but neither does removing them.
>
Hi,
Since most of our QA is based on unstable, it is hard to tell when some
particular problem is *solved* when we got a number of extra packages in
sid that are RC-buggy and that you can "ignore".
Presumably this is an argument for having dedicated QA reports only for
testing, so you can tell the state of a particular issue only for the
next stable release.
> If someone does want to come along and fix the package, having it pass
> through NEW again is not a good use of ftpteam time.
>
Nothing is gratis. Currently, our archive-wide QA is paying the price
by making it difficult to see when we can stop supporting deprecated
features (or which packages to focus on to fix it).
Plus our current garbage collection process for unstable is not gratis
either on volunteer time. It involves someone identifying a package for
removal and then asking the FTP team to spend time removing it.
If we automated the removal here (with some trivial stop gaps for
people in the situation you refer to), then we could save time from the
FTP team and distribute it to the people actively working on the packages.
~Niels
Reply to: