Comment 24 for bug 163694

On Wed, Feb 10, 2010 at 06:13:53PM -0000, Matthew Paul Thomas wrote:
> I agree that the version field is the hairiest part of the plan. It
> would be useful to be able to say, for example, that a security bug in
> Ubuntu is fixed in Ubuntu 8.04 LTS, 9.04, 9.10, and Lucid alpha 2 and
> later, or that a FooBarHum project bug is fixed in versions 2.2.1,
> 3.0.5, and trunk r775 and later. But any database schema smart enough to
> recognize those various version types would be quite a challenge, and I
> don't think solving that problem should be a prerequisite.

I'm not sure I understand why this is a database schema problem. We
already have versions of projects and distribution source packages in
the database. Adding distribution versions ("8.04", "Lucid Alpha 2",
etc.) is certainly harder since in some cases those objects aren't in
the database at all, and I agree that there's no particular reason for
that to block the rest.

Fixes are (relatively) easy, anyway; you can use bzr bug revision
properties for lots of this, and then you just have to link *those* up
to versions, which in many cases we already have thanks to tags.
Information on where bugs were found is trickier, since you don't get
help from bzr.

The most challenging part of implementing version tracking in Debian was
representing the tree of available versions and figuring out how to
propagate found and fixed information across it. Launchpad quite often
has (and indeed draws) the project version tree already; it doesn't have
version trees for distribution source packages, but it has all the
changelog data so that could be reconstructed in the same way as we did
in Debian. The algorithm for propagating information across the tree is
now a solved problem, although it's possible that it would need
optimisation to work better in Launchpad's database model.

There are certainly UI problems, including how to deal with version
input, how to present the ability to adjust the found and fixed versions
recorded for a bug, and how (or whether!) to display information such as
"the version you're using suffers from this bug, but it was fixed over
here" versus "this bug has been fixed, but we don't know whether the
version you're using ever had it". In some cases it might make sense
for information only to be available via the API. debbugs is much more
heavily developer-targeted, so didn't need to solve these problems to
the same extent.

> Hypothetically, if you introduced version tracking later on, the free-
> form version info that had been entered for bugs fixed before version
> tracking was introduced would be no more problematic than the complete
> lack of version info for the older bugs fixed before the Fixed statuses
> were merged.

There is certainly no immediate problem introduced by not doing version
tracking, since we have no choice but to handle those problems in other
ways (inadequate though they often are). It's merely a big scary
problem that gets bigger and scarier the longer we leave it.

I do think it's appropriate to bring it up here, since it would be one
valid way to address the problem represented by this bug.