Throwing this out there for anyone interested. Karsten (quaid) has requested a script that will compare the packages between two releases. Below is a quick IRC chat we had. I've been busy with other stuff so I won't be able to get to it right away. The idea of coming to us is maintainability. Whatever we end up with will end up in CVS and maintained by us so anyone out there that's good with Perl/Python/XML sign up. Don't take it if you don't have time to do it, I already did that :) Whoever wants it go ahead and reply to the list so everyone knows, and add it to: http://fedoraproject.org/wiki/Infrastructure/Schedule If you need any help let me know and I'll point you in the right direction. -Mike ======== From #fedora-docs =========== [15:16:54] * quaid gets an example [15:17:36] <quaid> http://fedora.redhat.com/docs/release-notes/fc5/#sn-PackageChanges [15:18:06] <quaid> and someone did help with that list, which I just put into a <screen> block [15:19:30] <quaid> so, you can see a bit of the package info in there, and the designation of if it is coming in or out. [15:20:11] <quaid> naturally, it would be cool for it to say what happened to a package leaving, such as going to Extra, but that doesn't seem doable ... that info isn't stored anywhere to extract. [15:20:24] <quaid> so, here is the need, in cascading order: [15:20:29] <mmcgrath> k [15:20:31] <quaid> 1. treediff -> a nice list [15:20:39] <quaid> 2. nice list -> XML list [15:21:06] <quaid> 3. a nice script that can be run somewhere to let a clueless editor do this easily [15:21:10] <quaid> </> [15:21:49] <quaid> we want to put in the set for each test, etc., so it shows the package changes incrementally in that way. [15:23:25] <mmcgrath> I got'cha. [15:23:45] <mmcgrath> So what of that stuff would you like the infrastructure team to do? [15:26:37] <mmcgrath> quaid: I think I'm following you now, you just really want some scripts to do all of this stuff automatically and then stick the results somewhere for you guys to do some final touches. [15:27:34] <quaid> mmcgrath: right, although the results could be a 100% valid XML document (header declaring it as e.g. a 'section'), and we really don't need to anything more than XInclude it. [15:28:45] <quaid> also, a reason for turning to Infrastructure v. cooking it up ourselves in maintainability ... we want something that is part of the formal process and has some support so when e.g. treediff or something changes, the smarts are there to fix it. :) [15:29:57] <mmcgrath> I don't think that will be too much of a problem. We can at least have SOMETHING to you soon. you'll probably have to get back to me a few times about how to fine tune it
