On Thu, Jul 31, 2003 at 01:38:51PM -0500, Drew Scott Daniels wrote:
> One problem that I'm worried about is Debian Policy 4.4 says:
> Mistakes in changelogs are usually best rectified by making a new
> changelog entry rather than "rewriting history" by editing old changelog
> entries.
> Although I'd hope this doesn't happen much and would be something fairly
> easily handled by a maintainer.
] To: control@bugs.debian.org
]
] package foo
] reopen 123456 1.2.3-1
] thanks
]
] Ooops, 1.2.3-1 changelog erroneously said this bug was fixed.
> I'm also worried about the possibility of changelogs getting truncated,
> rotated etc..
We're handling this by keeping the changelog history in the BTS,
essentially. If version 3 is based on 2 and 1; as long as the version
4 changelog mentions it's based on 3; the prior history will be
automatically inferred.
> Since katie only seems to look at the most recent changes
> [1] then Maintainers might get away with deleting old entries[2].
That's a bit trickier; and will probably be resolved by just having katie
extract the changelog and do some extra parsing.
> Things I would like:
> - A list of package versions affected by a bug.
> - All packages versions before that bug by default?
> - Where would this data be stored? A new BTS field?
> - If new affected packages are uploaded does katie need to tell the
> BTS?
We're doing as follows:
* from the package's changelog, establish a version history, for
the version of the package we're looking at, a la:
1.0-1 1.0-2 1.1-1 1.1-1.1 1.1-2 2.0-0.1 2.1-1
* obtain the found-in and fixed-in lists for the bug we're looking
at (say, found-in: 1.0-2, 1.1-2; fixed-in: 1.1-1.1, 2.0-0.1)
* walk the list of versions backwards until we match an entry from
found-in/fixed-in (in this case 2.0-0.1). If it's from found-in,
the bug applies to that version of the package, if it's from
fixed-in, the bug's closed in that version of the package.
* if there's no matches; check for other branches. if there's
a hit on another branch, assume it was specific to that branch
until told otherwise; if there's not, do some special case
handling, since the version information is bogus (ie, typoed, or
applies to packages that've never been uploaded).
> - katie telling the BTS in some control structure what package version
> closes a bug
> - Packages are affected unless the changelog says they aren't? (They'd
> likely also have the entire changelog entry for the package that
> closes a bug) [4]
> - Is a new BTS field needed to store the closing package version
> number(s) [4]
For .debs, the version number matches the binary version number, not the
source. So if you have a source package foo.dsc version 1, which generates
foo.deb version 1x, and bar.deb version 3.14x, and bugs against foo and
bar, the versions in the BTS will correspond to 1x and 3.14x, not 1. Debbugs
won't do any processing for this, so source version numbering should only
be used in bugs when it matches the binary version numbering exactly, or
when the source package doesn't have a binary package of the same name.
This is usually not a problem, but gcc-3.2 and similar packages hit this case.
It means that katie needs to tell the BTS /all/ the version numbers, since
it doesn't know which package any given bug belongs to. A la:
] To: 12345-done@bugs.debian.org, 12346-done@bugs.debian.org
]
] Source: foo
] Version: 1
] Packages:
] foo (1x)
] bar (3.14x)
]
] The bug you reported is claimed to be fixed in the latest upload
] to unstable. The maintainer's change log is as follows:
]
] ...
> - An update to the current BTS data to import the changelogs.
> After this is done we _could_ depreciate the distribution tags, but then
> the update_excuses (or testing migration) script would need to be changed.
> Could it be changed if this new system worked?
After this is done, the distribution tags get a subtly different meaning.
Instead of "this bug applies to, and needs fixing in _suite_", it becomes
"this bug needs fixing in _suite_", and is interpreted by the BTS to mean
"do not archive this bug, until the version in _suite_ fixes this bug".
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Is this some kind of psych test?
Am I getting paid for this?''
Attachment:
pgpehE22ZhOif.pgp
Description: PGP signature