Re: My Wishlist
On Fri, Nov 08, 2002 at 03:26:09AM +1000, Anthony Towns wrote:
> On Mon, Oct 28, 2002 at 12:30:11AM +1000, Anthony Towns wrote:
> > So, a blast from the past:
>
> I'm taking silence as assent,
Mostly, yeah. The main thing that concerns me is how maintainers are
going to drive this; we don't want to have to spend too much time
micromanaging versions, for instance. That implies to me that:
* we want to interpret the Version: pseudo-header in follow-ups as
well as initial reports, since people already seem to be using that
due to reportbug and such;
* we need to scan the bug archive and try to retrofit found-in values
to existing bugs, which will also give us an idea of how much effort
we need to parse whatever junk people put in Version: pseudo-headers
at the moment and how many "future" bugs we have already;
* it might be nice if debbugs could make an educated guess at a
version if the submitter doesn't provide one, by taking the current
version in either unstable or the latest explicitly tagged suite -
I'm guessing this needs more glue into projectb than is currently
available on master, but of course the latter is necessary in order
to support &suite=stable anyway;
* what happens to reassigns? Invalidating all version information is
probably the minimum, although that could be avoided if the reassign
was within the same source package.
I think that much would make it acceptably easy to drive.
> This means if X 4.2 is in the archive, and you file a bug against one
> of the packages from X 4.3, then your bug *won't be displayed*. The
> best way of handling this seems to be bouncing the report back to the
> submitter: if it's from a third party it should definitely be going to
> their BTS anyway, and most maintainers actively discourage filing bug
> reports about experimental packages. For the rest, the packages should
> probably just be being uploaded to experimental anyway.
Currently we don't bounce bug reports with unknown package names, but
instead send them to a group that sorts them out manually. This seems to
work fairly well, and isn't too much load. Perhaps a similar approach
would work for unknown versions, which might also help when people say
"Version: whatever's currently on master" or "Version: some-random-date"
or whatever. I don't feel strongly about it though, as long as we have
something like &suite= or &suite=future to deal with existing bugs.
Changelog tricks: this looks perfect as long as we can cope with JoeyH's
debconf changelog truncation. :) Have katie run 'dpkg-parsechangelog
-vlast-known-version' on each source upload, or something? Unfortunately
-v0 to get all versions since the dawn of time for bootstrapping doesn't
work with older packages that still have stuff lying around from the old
source format.
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: