On Tue, Aug 10, 2010 at 12:52:12PM -0400, Don Armstrong wrote: > On Tue, 10 Aug 2010, Steve Langasek wrote: > > Is there a way that the BTS could retain information about > > previously present packages, and avoid nagging tbm on follow-ups to > > existing bugs?
> That could be done, though I think a bug should always be assigned to > at least one currently existing package. So perhaps the notification > should be something like this: > IF bug is assigned to at least one currently existing package > and all packages assigned existed at some point THEN > do nothing > ELSE > bug tbm I think that sounds sane, yes. > However, in this case, there never was a binary package openldap2.3; > in etch, the source package was openldap2.3 which also built the > openldap binary package, so assigning it to only the openldap binary > package should be perfectly fine, and doesn't lose history. Only because the BTS semantics for handling of source packages were changed post-hoc and no effort was made to fix up the bug data to comply with the newly-imposed rules. But that's a bug report for another day. > [If you wanted to have it specifically assigned to both, then it should be > assigned to src:openldap2.3 and src:openldap... but I don't really see > the point.] In this particular case the benefit of recording that the bug was present in all versions of a package only present in oldstable and earlier is minimal. But in other cases (incl. future cases), there may be richer data available, such as information about versions of the package that the bug is closed in that may be useful to admins of systems that are desperately in need of upgrade, or useful in the aggregate. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
