Web lists-archives.com

Re: Removing packages perhaps too aggressively?




Andrej Shadura wrote...

> It has happened to me in the recent years quite a few times that a
> package which I was using has a RoQA bug filed against it, and the
> package's got removed at a very short notice.

+1

You meant "RM"? Let me extend this to package removals in general since
I'm not to happy with the current situation, too.

While certainly most RMs are obviously the right thing to do, every now
and then I get surprised by a removal - to find this has happened months
ago.

Then reading the related RM I saw a vague justifications like
"Alternatives exist" a bit too often. This is not helpful, I'd at least
expect a list of packages that are actually an alternative.

Or for example the xmem removal (#733668): It indeed failed to build
due to a libprocps transition but the fix was trivial. Also "shows
nothing" was a misunderstanding, xmem really shows nothing for the first
ten seconds.[1] 

Points like these might be brought up immediatly after the RM was filed,
but not a year later.

> Should we maybe give it *a bit* more visibility? Let RoQA bugs hang
> around for *at least* a month, maybe post notification emails every
> fortnight so that they can be noticed? Encourage newcomers to pick them
> up? Prodding DDs who's last reported bugs against the package to maybe
> pick it up?

At first, let's exclude auto-cruft and similar removals since I doubt
there was much dispute about these.

More suggestions for the, say, manual removals (mostly ROM, ROP, RoQA):
To make sure they get attention, send them to d-d as this happens for
ITPs, send them to <package>@packages.qa.debian.org so all subscribers
of the package learn it's important to take action.

And also give it some time, I'd suggest some two to four weeks.

    Christoph

[1] Don't get me wrong, resurrecting xmem is not a good idea today, the
    program shows garbage, probably due to kernel changes.

Attachment: signature.asc
Description: PGP signature