Packaging progress

[Paul W. Frields]

On Fri, 2005-12-30 at 07:39 -0600, Tommy Reynolds wrote:
> Uttered "Paul W. Frields" <stickster at gmail.com>, spake thus:
> 
> > I had an interesting thought about this, which is that rather than
> > having a "version" and "release" attribute, only one of which is
> > applicable for each type of revision, why not use a single "revnumber"
> > attribute?  For docs, this would be a version change, and for new
> > package rolls it would be a release change.  The latest version for the
> > doc and the RPM would always be the "revnumber" attribute of the topmost
> > role="doc" revision, and the RPM's release would always be the
> > "revnumber" attribute of the topmost role="rpm" revision.
> 
> Which ever is easier to parse.  
> 
> Personally, I prefer the two-attribute approach because that seems
> more parallel to the actual update process: just change the version
> and release, similar to what would be done to manually construct the
> SPEC file.  The 'role="rpm"' seems a bit artificial to me; perhaps
> it's just NIH syndrome.

This seems counter-intuitive to me, since documents have a version, not
a release -- any document change means a version change (or it should if
the editor is doing his job).  Meanwhile, RPMs have a release, and the
version is tied to the document source inside.  The RPM may change
versions, but only in conjunction with a document source change.  And
documents may change versions several times without any release, as they
are progressively edited -- especially now that we have the webtest host
where drafts are rolled during the work-in-progress.

This might be just the occasion to move out of the attribute space and
into the subelement space, thus:

 <revision role="doc" date="2005-12-31">
   <author worker="me"/>
   <revnumber dim="version">0.15</revnumber>
   <details>Style changes</details>
 </revision>
 <revision role="rpm" date="Sat Dec 31 2005">
   <author worker="stickster"/>
   <revnumber dim="release">1</revnumber>
   <details>Update to 0.15</details>
 </revision>

But frankly, that doesn't get easier to parse for people, which I was
under the impression was the whole point behind XML and DTDs.  Plus it
leaves wiggle room for valid but erroneous entries.  We might be
well-served by making the DTD do the work for us:

 <docrevision date="2005-12-31" version="0.15">
   <author worker="me"/>
   <details>Style changes</details>
 </docrevision>
 <pkgrevision date="Sat Dec 31 2005" release="1">
   <author worker="me"/>
   <details>Update to 0.15</details>
 </pkgrevision>

This may be a case where it's good to sacrifice compactness on the altar
of comprehensibility.

> > The only possible issue I see in the commit you made to rpm-info.dtd
> > this evening is in requiring copyright holders to be workers.  For
> > example, Red Hat, Inc. and the Fedora Foundation won't fit that type of
> > element, although one or both of them will certainly be copyright
> > holders on several of our works.  If we're not going to keep it as
> > PCDATA, perhaps using subelements (worker|corp) might work.  I think the
> > KISS method, though, might dictate punting this one.
> 
> Oops, I forgot about corporate ownership.  OK, I'll revert it.
> /me updates CVS
> Done!

Saw this, thanks.  For some reason I'm getting your mail to the list
really late, which is why my response is so delayed in real time.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051231/740738e6/attachment.sig>