Dealing with suite tracking

The bug versioning stuff is getting out of hand, wrt complexity anyway.

How are bugs really tracked?

Fundamentally, each bug is assigned to a given "package", identified by a package name and a version.

(Actually a bug can be assigned to multiple packages and versions; at present those are independent, but they certainly shouldn't be; dealing with bugs assigned to multiple packages has always been crufty)

Additionally, bugs often have a "closed-in" package/version pair.

These bits of information then deduce other properties of a bug, such as the reponsible maintainer, and associated source package, and whether a bug is considered to be open or not.

It may make sense to be able to say "I'll call it version 2 when this bug is fixed", and have debbugs automatically close the bug when version 2 is uploaded. This might not be an entirely crazy way of handling fixed-in-cvs / pending type bugs.

If that's the case, what should the communication with the submitter be?

There should be two phases:

  1. "Hello! The maintainer claims this bug is fixed in version 2.0, due to the following changes..."
  2. "This bug is fixed in 2.0-1, available in Debian unstable."

It might make sense to allow developers to submit their own microdists, so debbugs can say:

This would be done through the <src>@packages.debian.org user, I guess.

Actually, there should be two other phases:

  1. "This bug has reappeared in 2.0-4, currently in Debian unstable."
  2. "Version 3.0-1, currently in Debian unstable, is branched from an earlier version of the code base, believed not to have this bug."

So if we look at that differently, we have two sorts of message: the maintainer's notification that a bug is fixed, and how that was achieved; and status updates as to the state of the fix in the relevant suites. Hrm, that's not really accurate.

What we've really got is the maintainer's notification as to what version a bug is (or will be) fixed in, and the BTS's notifications as to what suite that version is in. In which case, maybe it should be:

  1. "Version 2.0 has been uploaded, and claims to fix this bug. Changelog follows: ..."
  2. "Version 2.0 (which fixes this bug) is available from Debian unstable."
  3. "Version 1.3sarge1 has been uploaded, and claims to fix this bug. Changelog follows: ..."
  4. "Version 2.2 (based on version 2.0, which fixes this bug) is available from Debian testing."
  5. "Version 1.3sarge1 (which fixes this bug) is available from Debian stable."

I wonder if that's too much information. I guess the only one that's avoidable is "it's entered unstable". And actually, if the BTS is generating the ones about changing suite, it can just be stored as a boring message, just like the regular annotations, which should avoid it getting too confusing.

Although, I wonder if the log of fixes making it into and out of unstable really should be recorded forever. I dunno, I'm not convinced.

I guess if you consider it to be tracking bugs in Debian -- rather than just for a particular package -- it does make perfect sense.

binNMU bug tracking

Another complexity is tracking bugs that are specific to a particular build of a package, rather than it's source. This can apply in a very architecture specific way, such as problems in the build environment (broken compiler, toolchain, hardware, eg), or in a less architecture specific way, such as when packages need to be relinked against a newer library, but this doesn't require any source changes.

In either case, though, if we expect the fix to be handled by a binNMU, the bug has to be tracked on a per-architecture basis -- and thus not considered closed until fixes are uploaded for all architectures.

That means there should be some way to say something like found-in: foo/1.0-1; fixed-in: foo/1.0-1.0.1/arm, foo/1.0-1.0.2/i386, ....

However another problem here is that if no source changes are needed, it's probably inappropriate to require an entry in the permanent changelog (since there was no change to the source), and there's no history through the binNMUs for version tracking to make note of.

It might be appropriate to treat "build specific" bugs completely differently -- that is, rather than assuming the bug will continue to apply, instead assume that it won't apply to new uploads. That instead means that the bug should only note that it's found-in: foo/1.0-1; build-specific: yes and the bug will be treated as closed automatically once foo is no longer at version 1.0-1 in any architecture.

For arch-specific problems, this could probably be converted to found-in: foo/1.0-1; build-specific: yes; architecture: arm. Note that this means the entire bug is architecture-specific; if it's a general transition that just needs a new binNMU on one arch, you can't track that without filing a separate bug -- there would be no way to make a bug both general (for version 1.0-1) and arch-specific (for version 1.0-1.0.1 on arm). I think that's probably acceptable -- generalising to pkg/ver/arch tuples would be quite irksome.

It's not entirely clear that the BTS is the ideal way to track these issues -- debbugs aims to facilitate humans talking to each other, but it probably makes more sense for transitions to be a case of something automated talking to a human. Perhaps debbugs should simply be optimised towards better handling that case, anyway.

Noticing version changes and optimisation

Version tracking's slow, and changes in testing/unstable don't result in actions, which they should.

To deal with the latter part, we need some processing hooked in with cron.daily: 

for s in suites:
    for c in components:
        for src in sources[s][c]:
            oldv = old_version(s,c,src)
            newv = new_version(s,c,src)
            if oldv == newv: continue
            for b in bugsbysource(src):
                oldp = get_pending(b, src, oldv)
                newp = get_pending(b, src, newv)
                if oldp == newp: continue
                report_changed_pending(b, src, oldv, oldp, newv, newp)

But if we're doing this anyway, it probably makes sense to cache the pending status for each bug, so we don't have to do the complicated "am i open/closed/irrelevent" analysis for the common cases.

Such a cache would probably be a hash from bug# to an array of pending states, one for each suite. Probably better would be an array of version/state pairs, so it's possible to reduce duplication, and have better reliability in case the cache gets out of sync with the actual state of the suites.

Simplify

So then, the summary.

I think that's reasonably sane.

More generally:

I think that has pretty close to the right balance between simplicity, functionality and generality.

debbugs/BugVersioningNotes (last edited 2005-09-26 09:51:37 by AnthonyTowns)