I'm looking at the RPM packaging steps that Paul has done. AIUI, he uses a small python script to pick the changelog information out of the document's XML. Cool idea.
My question is this: should we build the RPM changelog from the XML content or from the CVS check-in log? Using the XML info is way cool, but we can get more file-specific information from the CVS log. I think developers, er, RPM users, would like the additional details.
Opinions?
Cheers
On Mon, 2005-10-31 at 07:40 -0600, Tommy Reynolds wrote:
I'm looking at the RPM packaging steps that Paul has done. AIUI, he uses a small python script to pick the changelog information out of the document's XML. Cool idea.
It is, if only I were indeed doing that! The only thing I do is a grab of the title information out of <title> within the <book> or <article>. I am just learning Python baby steps, so even that was a stretch. Didn't want to take credit where it wasn't due. I had considered this, though, as an eventual goal for Python learning... if I could figure out enough SAX stuff to make this work, that would be a real coup as far as I'm concerned. I was under the impression that there were ways to even parse and read back entities, but I have no idea if that's a correct impression.
My question is this: should we build the RPM changelog from the XML content or from the CVS check-in log? Using the XML info is way cool, but we can get more file-specific information from the CVS log. I think developers, er, RPM users, would like the additional details.
Opinions?
I think the CVS log would be nice, but my understanding is that it's difficult to parse for this content. A couple difficulties that occurred to me were (1) tying the CVS login name to an email address, which is normally used in the spec file's %changelog; (2) mitigating the situation with the CVS changelog having entries that do not correspond to RPM package versions -- in other words, CVS gets revisions for which a new package is not rolled; and (3) tying the CVS revision number into a version number used for the RPM package. I don't know if any of these are showstoppers, but they are definitely gobsmackers, if you get my meaning.
On the other hand, the DocBook XML <revisionhistory> at least has a "rational" version number and date which should roughly correspond with packaging. We still have the email address problem, however, and other problems likely exist with this way of doing it. *sigh* This is so much easier dealing with regular code like in Extras!
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
I think the CVS log would be nice, but my understanding is that it's difficult to parse for this content.
I hacked together the attached shell script and ran it against the current "release-notes/" document. It gave this output:
==[release-notes/rpm-Changelog]==
* Mon Oct 31 2005 04:48 bbbush fedora-docs-list@redhat.com - RELEASE-NOTES-zh_CN.xml (1.1), daemons-zh_CN.xml (1.1), - desktop-zh_CN.xml (1.1), development-tools-zh_CN.xml (1.1), - entertainment-zh_CN.xml (1.1), feedback-zh_CN.xml (1.1), - file-servers-zh_CN.xml (1.1), hardware-reqs-zh_CN.xml (1.1), - i18n-zh_CN.xml (1.1), install-notes-zh_CN.xml (1.1), intro-zh_CN.xml - (1.1), java-package-zh_CN.xml (1.1), kernel-zh_CN.xml (1.1), - legacy-zh_CN.xml (1.1), misc-server-zh_CN.xml (1.1), - multimedia-zh_CN.xml (1.1), networking-zh_CN.xml (1.1), - overview-zh_CN.xml (1.1), package-movement-zh_CN.xml (1.1), - package-notes-zh_CN.xml (1.1), printing-zh_CN.xml (1.1), - project-overview-zh_CN.xml (1.1), samba-zh_CN.xml (1.1), - security-zh_CN.xml (1.1), server-tools-zh_CN.xml (1.1), - splash-zh_CN.xml (1.1), web-servers-zh_CN.xml (1.1), xorg-zh_CN.xml - (1.1): Simplified Chinese translations of relnotes of fc5test1, of - test and incomplete quality. Problems in package-notes-en.xml are - translated AS-IS because of the freeze.
* Sat Oct 29 2005 21:36 Tommy Reynolds Tommy.Reynolds@MegaCoder.com - Makefile (1.5): If the document directory has a "figs/" subdirectory, - create an "figs/" subdirectory in the HTML output directory. Copy any - ordinary files with a dot in their names to the newly-created - "${DOCBASE}-${LANG}/figs/" subdirectory. To be copied, a graphics - file must: 1) Have an extention that is NOT ".eps", since HTML - doesn't grok EPS files. 2) Have a filename matching "*-${LANG}.*" -- - be a graphic for the selected language. 3) Have a filename that DOES - NOT HAVE A DASH at all -- this allows for "language-independent" - graphics.
* Sat Oct 29 2005 08:26 tsekine fedora-docs-list@redhat.com - Makefile (1.4): fix the figs directory making rule so that 2 or more - lauguages are able to be specified in LANGUAGES variable
* Tue Oct 25 2005 14:40 Karsten Wade Karsten.Wade@RedHat.com - package-movement-en.xml (1.4), package-notes-en.xml (1.4) (utags: - FC-5-TEST1-TRANS-FREEZE): Typos that broke the build, sorry, forgot - to test the build before I did my last commits.
<snip>
In addition to the attached shell script, I propose adding an "AUTHORS" file to each document. The example one I used above is:
==[release-notes/AUTHORS]==
######################################################################## # We use this AUTHORS file to map CVS checkin names to real names and # email addresses. ######################################################################## # DEFAULT fedora-docs-list@redhat.com - jtr Tommy.Reynolds@MegaCoder.com Tommy Reynolds kwade Karsten.Wade@RedHat.com Karsten Wade
Now that I look at the voluminous output, I'm less sure that we want the CVS log in the RPM. I think your current dummied-up %changelog is perhaps more useful.
Cheers
On Mon, 2005-10-31 at 12:49 -0600, Tommy Reynolds wrote:
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
I think the CVS log would be nice, but my understanding is that it's difficult to parse for this content.
I hacked together the attached shell script and ran it against the current "release-notes/" document. It gave this output:
[...snip...]
In addition to the attached shell script, I propose adding an "AUTHORS" file to each document. The example one I used above is:
==[release-notes/AUTHORS]==
######################################################################## # We use this AUTHORS file to map CVS checkin names to real names and # email addresses. ######################################################################## # DEFAULT fedora-docs-list@redhat.com - jtr Tommy.Reynolds@MegaCoder.com Tommy Reynolds kwade Karsten.Wade@RedHat.com Karsten Wade
This is probably a good idea regardless of the route we choose for populating the %changelog, IMHO.
Now that I look at the voluminous output, I'm less sure that we want the CVS log in the RPM. I think your current dummied-up %changelog is perhaps more useful.
I think James Laska had some input on the %changelog hacking, in that just setting a dummy was neither helpful nor advisable. (I'm kind of putting words in his mouth; he was less unkind, but in all honesty my solution didn't deserve a lot of kindness.) ;-) I think he suggested keeping a ChangeLog with the documents that would be used only for packaging. I am still mulling that over...
Hi
Now that I look at the voluminous output, I'm less sure that we want the CVS log in the RPM. I think your current dummied-up %changelog is perhaps more useful.
I think dummying up the change log might be the wrong solution here. Changelog should be split up from the RPM spec and stored seperately. File a enhancement request?
regards Rahul
On Tue, 2005-11-01 at 00:55 +0530, Rahul Sundaram wrote:
Hi
Now that I look at the voluminous output, I'm less sure that we want the CVS log in the RPM. I think your current dummied-up %changelog is perhaps more useful.
I think dummying up the change log might be the wrong solution here. Changelog should be split up from the RPM spec and stored seperately. File a enhancement request?
This is really a process change and not a bug, but as James has already made this suggestion on list, it's probably a good idea to discuss it here. Specifically, does doing this create any extra burdens on authors or editors, or should the ChangeLog file (to feed the RPM %changelog) simply include packaging-specific information? I would prefer the latter to avoid needless duplication of work. In other words, although the CVS log and/or revision history might have entries with info like this:
- style changes - push to version x.y.z, move to final editorial
...the ChangeLog file would instead only include packaging specific entries or things which have nothing to do with the CVS content (much like code packages):
- Update to x.y.z - Fix OMF file
Comments?
docs@lists.stg.fedoraproject.org
-
Paul W. Frields -
Rahul Sundaram -
Tommy Reynolds