Bug 178968
Summary: | automate creation of XML page of all packages changed in a release | ||
---|---|---|---|
Product: | [Retired] Fedora Infrastructure | Reporter: | Karsten Wade <kwade> |
Component: | cvs | Assignee: | Mike McGrath <imlinux> |
Status: | CLOSED NOTABUG | QA Contact: | Jeremy Katz <katzj> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | dcantrell, katzj |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-11-07 02:59:37 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 151189 |
Description
Karsten Wade
2006-01-25 20:44:52 UTC
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. |