version tracking plans?
I've been looking at modifying a copy of dak/katie.py to list which
versions close which bugs, and to get a way to list all the different
versions from the changelog. I'm trying to work towards version tracking
as has been discussed before on this list.
-----
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.
I'm also worried about the possibility of changelogs getting truncated,
rotated etc.. Since katie only seems to look at the most recent changes
[1] then Maintainers might get away with deleting old entries[2].
Policy only says that one "should" explain things [3] in debian/changelog
which makes me wonder if it's possible of have a package without a Debian
changes and just a changes file.
-----
I could use some input on what my (or our should someone help) plan of
action should be. My first goal since I'm new to this code (and my perl's
rusty) will be to figure out how to take out a list of packages from a
changelog. From my list below it seems I need to add support for two
fields to the BTS (affected, and closed by?), to change katie to give the
BTS version information in a nice format when closing bugs (I guess
optional or else the BTS would have to learn the existing template), and
some sort of script to enter existing information.
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?
- 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]
- 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?
-----
Colin Watson, any progress on a test BTS? I know we decided that we should
get that up before planning, but I couldn't help myself. I'm going to dig
into katie and figure out how a update (of existing data) script might
look.
-----
[1] What's recent? Since the last upload, or only the current section?
[2] I'm not saying deleting old entries can't be a good thing, just that
it could make my task more difficult.
[3] Yes, specific things. I.e. things specific to Debian...
[4] It's possible to close a bug in two separate versions. Especially when
there's a backport.
Drew Daniels
Reply to: