Re: What to do with bug reports against non-existing/removed packages
Hello,
(I'm not subscribed to QA --perhaps I should for coordinating this?--,
so if you expect replies of me make sure that I'm in CC. Also, I'm on
holidays so my replies can have quite a bit of delay depending on the
day...).
>> An additional problem with having multiple people watch new bugs, is
>> that it's not easy to coordinate. Altough... if we were both on IRC, we
>> could announce on #debian-qa when we're looking for new misfiled bugs,
>> and/or paste a list of reassigned bugs to the channel, so we don't
>> duplicate work.
>
> IMHO this is (or not) an issue whether we talk about the backlog or the
> new bugs. After the discussions on -devel I've started looking at the
> bug list and yesterday I tried to take care of a few classes where I was
> quite certain about a course of action.
>
> It turns out that at least for the links-ssl bugs Manuel (in CC) has
> done some work as well (but in at least one case my new prod helped and
> the maintainer took care of a lot of them, phew), so IMHO:
I think that I already told about this before (I'm the originator of
one of these threads):
1) I reported the issue to Linux mantainers, Ben Hutchings took care of those
2) I reported to GCC maints, they wanted my help. I started to triage
bugs slowly, trying to confirm them and so on. I slowed down recently
due to other (Debian and non-Debian) commitments.
These need a lot of care, some of them are e.g. optimisation
issues reported to Debian and upstream and still being worked on
(e.g., closed after 4.7 release). I plan to continue taking care
about these, with a higher priority than for others.
3) I reported old Emacs bugs, but the only maintainer is swamped
already by the ones in the current version. I dealt with some of
these, but there are huge amounts of those.
4) The ones of links-ssl (and other random that I dealt with) are ones
that I stumbled upon for some reason or another. Since I knew the
maintainer, I mostly let him deal with those as well (I think that
after closing a few).
With 1+2+3, they made for about 1/3 of the total bugs at the time,
~500 in about ~1500 open.
> Old bugs
> --------
> As my experience shows these do need some coordination, otherwise we
> risk pissing of maintainers with repeated un-coordinated prods. One tool
> could be a wiki page by classes/sub-classes of bugs, with recommended
> action, who is dealing with them, etc.
If I am understanding it correctly, I think that this is a good idea.
For example, I would like to take care of all the ones related to GCC
packages, so I declare this, modify the wiki, and off I go to take
care of them (or coordinate with other people interested in those).
As with maintaining packages, this works much better if the user has
some genuine interest in the packages that the orphaned bugs are
reported against.
Cheers.
Reply to: