Red Hat Bugzilla – Bug 178968
automate creation of XML page of all packages changed in a release
Last modified: 2013-01-09 22:40:45 EST
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
email@example.com 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
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?
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.