Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Steve Langasek writes ("Re: Package marked for autoremoval due to closed bug?"):
> Migration to testing is largely out of control of the maintainers at this
> point, it's very much dependent on folks rebootstrapping armel and armhf
> against the new library names. Should these bugs be downgraded again to
> important severity?
Yes.
It seems we have consensus on this.
Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"):
> For bookkeeping purposes, please usertag downgraded bugs with user
> release.debian.org@packages.debian.org and usertag time_t-downgrade.
Rather than every maintainer affected by unactionable autoremoval
warnings[1][2] doing this by hand:
Steve, could you please do this for *all* the time_t transition RC
bugs?
That will reduce the scope for individual slips and mistakes,
fulfilling Paul's request:
> Please be careful with downgrading RC bugs.
[1] IMO unactionable autoremoval warnings are extremely undesirable.
The autoremoval system has two purposes: one is to get rid of things
that are in the way of other work, or just rotten. Another is to spur
action where action is needed. Action by a responsible maintainer, or
failing that by anyone else.
An unactionable autoremoval warning represents, at best, a robot
shouting at a human to do something that cannot be done. That can
lead to many humans from afar all turning up being confuseed at the
same problem trying to "help" (or at least, to try to stop the
screaming). If the autoremovals were to actually occur, it would be
automated destruction of non-broken stuff.
To preserve autorm's usefulness, unactionable autoremoval warnings
must be very rare. In this situation, Debian's processes have failed
to ensure this, and there hasn't been an effective backstop.
I suggest that when a widely-applicable problem is generating
unactionable autoremovals, the whole autoremoval system should be
suspended.
The problem is particularly severe when an underlying cause is that
some package, which contains the underlying RC bugfix, isn't
migrating. This seems to be becoming more common.
[2] In my case src:dgit depends on git-buildpackage. The autoremoval
robot wants to remove git-buildpackage because of the time_t bugs
against rpm, xdelta, and pristine-tar. One root cause is that
src:dpkg isn't migrating because of #1066952.
The logic of the autoremoval system is that as an affected maintainer
I ought to go and involve myself with #1066952.
And all of this is nonsense since surely we're not going to autorm
git-buildpackage, but right now we have a giant klaxon saying that's
what's going to happen.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Reply to: