Re: Freeze Please?
On Sat, Feb 08, 2003 at 06:26:27PM +0000, Colin Watson wrote:
That's an extension, not a redesign, IMHO;
No, it's not a simple extension. You could glom additional stuff onto
the existing bts, but what you end up with is a bts with stuff glommed
onto it rather than a solution designed from the ground up.
The details of storing additional metadata and adjusting the query
interfaces are the straightforward bits of the job.
No, that's the hard part. Sticking data into a database is easy, and a
solved problem. The hard part is designing the schema by which data is
stored in the database, and coming up with efficient mechanisms for
accessing that data.
The current bts is based around the concept of a "package". (A concept
which is heavily overloaded by things like ftp.debian.org, which is
hardly a package.) A bug has a single "severity". (Again heavily
overloaded by things like the wnpp "package".) A bug has a version. A
bug has a bunch of tags. There are a few static queries that can be done
against the bts, e.g., looking for bugs by maintainer or package, and a
few simple filters for things like severity.
What things are bad? First, the concept "archiving" bugs. Having two
distinct databases to search for essentially the same information is
terrible, especially when there's no way for a user to tell which
database he should search.
Second, there's no interface for complex queries. I can't say something
like "find all the bugs in my packages which aren't fixed but have
patches included."
Third, there's no association in the bts for a package version which
fixes a bug. Really there should be the possibility of more than one
version, to address things like stable security uploads, which are on a
seperate branch from unstable uploads. This is a legacy of our
development model, which really is "we only work on unstable," in which
case one should just track the latest unstable.
Fourth, there's no real association of bugs and releases. This shouldn't
be maintained seperately within the bts, but should fall out of the
version association. I.e., a query should be able to cross reference the
version of a package which closes a bug with the version of the package
in a particular release. (IOW, there should not be a tag for a release
version.) This would allow nifty things like "show me the bugs fixed in
package x between stable and testing".
Fifth, there's no way to keep track of who's working on what bug.
(Reading the whole bug log doesn't count.) This would be useful
especially in the growing number of packages with multiple maintainers.
Sixth, IIRC, there's no real publically-accesible indication of which
bugs the RM considers to be RC.
I'm cramped for time, so I'll stop there. The point is that there are a
lot of things that could be done, many of which are really essential if
we go further down this road of maintaining four (or more!) release
trees. (Right now, potato, woody, sarge, and sid.) Some of these can be
added to the existing bts, but we really need to decide if this
multi-tree approach is really something we want, and design from the
ground up a bts that specifically addresses that goal. This is not an
indictment of the current bts, which was not designed for this radically
different approach that people are nibbling at.
Mike Stone
Reply to: