Bug 178968 - automate creation of XML page of all packages changed in a release
Summary: automate creation of XML page of all packages changed in a release
Alias: None
Product: Fedora Infrastructure
Classification: Retired
Component: cvs   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike McGrath
QA Contact: Jeremy Katz
Depends On:
Blocks: fc-relnotes-traqr
TreeView+ depends on / blocked
Reported: 2006-01-25 20:44 UTC by Karsten Wade
Modified: 2013-01-10 03:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-07 02:59:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Karsten Wade 2006-01-25 20:44:52 UTC
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@redhat.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.

Comment 1 Rahul Sundaram 2006-01-31 13:10:26 UTC

Adding release engineer in hope for some black magic to get this done.

Comment 2 Jesse Keating 2006-01-31 17:36:09 UTC
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.

Comment 3 Karsten Wade 2006-01-31 20:18:00 UTC
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.

Comment 4 Jeremy Katz 2006-01-31 21:18:43 UTC
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

Comment 5 Rahul Sundaram 2006-02-01 04:23:52 UTC
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. 

Comment 6 Karsten Wade 2006-02-01 07:27:55 UTC
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.

Comment 7 Karsten Wade 2006-07-25 22:16:34 UTC
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?

Comment 8 Bill Nottingham 2006-07-25 22:46:42 UTC

Comment 9 Karsten Wade 2006-07-27 15:23:58 UTC
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. :)

Comment 10 Paul W. Frields 2007-02-10 15:56:21 UTC
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*

Comment 11 Paul W. Frields 2007-02-10 15:58:50 UTC
Blocking the F7 relnotes tracker so we get this resolved forthwith.

Note You need to log in before you can comment on or make changes to this bug.