This is a regular documentation request. Even Red Hat customers request it, meaning part of this may be solved in the RHEL release notes. See jha for more information about that. We could use treediff.py to make some nice output, then Python to convert it to an XML DocBook table. It can be something that we run as a Make target for the release-notes that gets the current status of all the packages when it's run. This way we can quickly update the XML page right before spinning the ISO, so that the relnotes and the ISO are 100% matching.
Adding release engineer in hope for some black magic to get this done.
This begs the question 'what constitutes change'? In the case of dist-fc5, each and every compilable package will have been rebuilt with the new gcc4.1. Does this count as a change? If so, then all packages.
I think the bottom line is, people want to see: 1. What the package version was for their old release. 2. What the new package version is for the new release. 3. Some relationship between the two. 4. If possible or with it, a comment on wassup. foo.1.2-7.rpm ==> foo.1.4-2rc3.rpm # 1.4-2 not ready in time, but rc3 is solid If it is every package, then it is every package. If the developers could be persuaded to put *docs* in their changelog ... or another keyword (*packagenote*) that gives us a trigger to grab that changelog and make it a comment about why a package was updated across a release. Do this only where it matters the most, maybe in normally stable packages that don't change much, etc. Or don't do it at all, but make it available to developers to use.
But once we've done this, then how is it _really_ different than just having the user look at the changelogs? Because that's what you're going to end up getting and I maintain what I did before -- this is fundamentally not interesting information
Everytime we didnt mention this package change there has been requests to provide this information. I have seen this happen in fedora user lists and forum too. If we dont provide this information in the release notes, we can do so in the website and just provide a link. Other websites like distrowatch has been providing this package changes and it is fairly popular for that.
In reference to comment #4: * Obtaining a changelog from a package is fundamentally different than looking at a long list of package changes to see what happened with your favorite package. * I have heard the same requests that Rahul mentions in comment #5. I figure, anyone who feels as you do that the information is uninteresting, can just skip reading that section of the relnotes.
I think Bill Nottingham did something nicer with FC5 release, in terms of getting the treediff into XML, but I can't find any notes about it. Bill -- didn't you do some automagic for FC5 package changes into XML?
No.
Removing Bill, sorry for the distraction. Mike -- find me on #fedora-docs, when you can, and I can explain this in more detail. We can paste the discussion back here, but I think an interaction would be better than me writing down a novella of everything I recall. :)
If we absolutely have to have this information somewhere -- and I agree with Jeremy that this is uninteresting, and further posit that it's annoying for many relnotes readers -- then let's put it on the Wiki using a Python script, and simply link to it in the relnotes. That way we can have not only a current release page (i.e. Fedora N-1 ==> Fedora N changes), but daily or hourly Rawhide changes (Fedora N ==> Rawhide). I don't relish the idea of any human having to figure out which changelog entries are relevant for every package in the new happy merged universe, and then edit that into the relnotes. *shudder*
Blocking the F7 relnotes tracker so we get this resolved forthwith.