Re: What to do with bug reports against non-existing/removed packages
Neil Williams <codehelp@debian.org> writes:
> On Fri, 18 May 2012 14:34:40 +0100
> "Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com> wrote:
>
>> Hi,
>>
>> 2012/5/18 Daniel Leidert <Daniel.Leidert.Spam@gmx.net>:
>> > Hi,
>> >
>> > Our bug tracker contains items for packages, which do (not longer) exist. What should happen to them? I see, that it might be a good idea to keep them for the case, a package is re-introduced. But this might happen only for a few packages. Most of them got removed because newer versions were released. What about closing those reports, if an RM-request is filed?
>> >
>> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=
>>
>> As others have said, I asked the question only a few weeks ago:
>>
>> http://lists.debian.org/debian-devel/2012/03/msg00946.html
>>
>> Reassigning 300 bugs from emacsX (X<23) to current emacs packages is
>> not very helpful, really. What I did is to notify the maintainers (or
>> related mailing lists) of the three biggest groups (linux, gcc, emacs)
>> to decide what to do.
>
> There's a big difference between these bugs and the rest - here there
> are clear migration paths to later packages which can be used to triage
> the bug reports in order not to lose reports. A lot of the rest *can*
> be closed without more triage work because the package was removed, not
> replaced. e.g. gcc-4.4 bugs may be applicable with gcc-4.7 and need to
> be triaged. The opensync/multisync bugs just had to be closed without
> even looking at any of them.
>
> Identifying this subset (which could be quite large) which apply only
> to packages which have no appropriate replacement packages would be a
> very useful QA step and dramatically improve the total number of bugs
> in this situation.
For packages like gcc-x.y that know that there will be a continious
progression of new sources with old sources becoming obsolete wouldn't
it make sense to declare some sort of meta-source-package for
them. Something like
Package: gcc-4.4
Version: 4.4.7-1
Meta-Source: gcc-x.y
The BTS could then not just track the binary/source package of a bug but
also the meta-source package. That way when gcc-4.4 is removed from the
archive the bugs can still be associated with the gcc-x.y meta package
and won't be completly lost. The gcc maintainers would still be
listed as repsonsible for the bug.
Similary when a source package is renamed (but the old not yet removed)
all the old bugs could be assigned "Meta-Source: <new name>" so on
removal of the old package they automatically default to the new source
name. This could be semi automatic so that new bugs against the old
packages automatically get the Meta-Source info too.
Just an idea.
MfG
Goswin
Reply to: