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