Re: updating out-of-sync RC bugs on the day autoremoval would remove them
On Sat, Apr 11, 2020 at 07:46:22PM +0200, Paul Gevers wrote:
> Hi Adrian,
Hi Paul,
> Recently I have started filing RC bugs for packages that are out of sync
> between unstable and testing. Most packages are not key packages and
> without the package migrating to testing, get autoremoved. We noticed
> that you have updated meta information on several of those bugs (thank
> you in general for your QA efforts) on the day that the autoremoval
> would remove the package from testing. I assume good faith, but there
> are so many bugs updated this way that it doesn't look like coincidence.
this is not coincidence, the first thing I am doing when I spend time
on QA is always to check [1] which is for me a list of bugs ordered
by priority.
> We do allow autoremoval to be delayed by updates to the bug, but that is
> to give extra time if progress is being made but the bug isn't solved
> yet. If there isn't any progress, we ask you to not delay the
> autoremoval with these updates. Either do the updates much earlier, or
> hold off until the autoremoval happened.
Why is it a problem for you when a package stays 2 weeks longer
in testing, 1 year before the next freeze?
You can add a removal hint at any time if a removal is urgent for you.
Doing changes much earlier only gets me more abuse.
Doing changes after autoremoval is always more work for me for
manually tracking bugs, and for manually tracking testing migration
when I am doing NMUs for some of the bugs later.
If it took you 4 years to even notice that this is how I am doing
QA work, then I doubt it is such a huge problem.
> Paul
cu
Adrian
BTW: Please close the bugs when submitting them instead of just adding a
fixed version, otherwise the BTS will show them as open forever and
never archive them.
[1] https://udd.debian.org/cgi-bin/autoremovals.cgi?sort=time
Reply to: