Re: RC bug tracking (was handling open security problems in woody with the BTS (here: thekernel)[was: Re: Bug#176178 acknowledged by developer (do not reopen)])
On Tue, Apr 08, 2003 at 02:58:48PM -0500, Drew Scott Daniels wrote:
> In http://bugs.debian.org/~cjwatson/version-tracking.html you say assuming
> distributions are always a branch is not reliable as the distribution may
> have it's "branch" included right into the next distribution? I see that
> this is a problem if there is only one place to upload a package, but I
> don't think it would be too unreasonable to ask the maintainer to close a
> bug in a later distribution or reupload the same package for different
> distributions (which they should be unless they don't depend on anything
> distribution specific).
It's not an issue of closing bugs. Given the following situation:
1.0-1 (stable)
|
+--------------+-------------+
| |
| |
1.0-1.woody.1 (stable) 1.0-2 (testing)
| |
| |
+----------------------------+
|
|
1.1-1 (unstable)
... you need to know that 1.1-1 is based on 1.0-1.woody.1 but 1.0-2
isn't (because it doesn't contain the code from, let's say, the broken
security update that was 1.0-1.woody.1), in order to know where to
display a bug that's reported against 1.0-1.woody.1 after the release of
both 1.0-2 and 1.1-1. You also need to be able to handle somebody saying
"yes, I fixed that in <version> two months ago" correctly; debbugs
should just know what versions are descended from that and not display
the bug for them.
I think it's very important to get this right as close to automatically
as possible. We want to reduce the load on maintainers to keep track of
their packages' versions, not increase it. Maintainers are already used
to closing bugs in changelogs, and many of them already merge changelog
entries from other branches, so asking them to do that to help out the
BTS isn't much of an imposition. This is especially true if we have some
sensible defaults, so that perhaps bugs are always displayed for all
versions after the reported one until you say "I fixed this in
<version>" in order to display it for only the other branches. Or
something like that.
> Because of this whole mess of problems, I suggest starting with only
> scanning the latest entry in the changelog(s) of uploaded packages and
> using whatever distribution/version tracking that seems appropriate. I
> guess only checking the last changelog is not as thorough and may not
> produce desirable results as often and perhaps should only be looked to if
> there's problems parsing changelog files.
I think we genuinely need to know the shape of the whole version tree
(at least as far as is recorded) in order to do this properly. Parsing
changelogs is pretty easy; I've got a moderately stupid prototype that
does it already when given a .dsc. The next stage is to figure out how
to merge in data about new versions, which I don't expect to be too
difficult.
We don't need to scan changelog entries beyond pulling the versions out
of them. katie can have its closing mail changed to give us parseable
version information without much difficulty. Looking for "closes: #bug"
entries is not the reason why reading the package's changelog is useful.
> The big question I have is how are the versions or branches going to be
> tracked? A new field or fields? Some method of extending the use of tags?
> I'm guessing that it'll be new fields, but what will they be used for and
> called?
I'm not overly concerned about that. A new field for versions in which a
bug has been reported, a new field for versions in which it has been
fixed, and some files with the version trees for each package. People
can add/remove things from each of the first two, and the third is
adjusted on each upload or daily or something. The CGI scripts get an
extra argument for what suite to look at, defaulting to unstable, and we
figure out how to migrate old bugs and what all the corner cases should
do.
New fields are easy once Adam overhauls the .status format, which I'm
told is Real Soon Now, and then with any luck we can stop overloading
everything onto tags.
> > (God, I can't decide whether all these threads make me want to give up
> > in despair or implement something broken now just so they stop. :P I
> > have three weeks of holiday coming up ...)
>
> This problem has been around ever since (slink?) stable has had upgrades
> (or even longer). I don't want this rushed, or dropped. I'd like people to
> know about the problems with the BTS, how they could work around the
> problems, and what may come in the future.
Sorry to snap. It just seems ironic that another design discussion
starts up just as I'd got a plausible design fairly well sorted out in
my head and started on trying to come up with a prototype that I could
show to people. :-/ I'm going to stop talking about designs now until I
have a reasonable amount of code, as with the kind of work I'm thinking
of doing we can fit whatever policy we like over the top of it and see
what works.
If you want to help, I suggest waiting until we can do more than talk;
wait until we can run a real prototype alongside the BTS for a while.
Then all the abstract discussion will be a lot more real, and ideas
about policy and defaults and such will be much more valuable.
(Is anybody else on -debbugs already working on prototyping something
like this?)
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: