Re: dchanges
Bruce Perens writes ("changelog format"):
> Bill Mitchell writes ("Unidentified subject!"):
> > I've received no feedback on this one way or the other.
>
> That's because Ian Jackson, you, and I might be the only people on earth
> who care about this issue.
Perhaps ...
> Ian Jackson:
> > My changelog/announcement format has almost all[*] the information
> > that is in yours, but is more human-readable.
>
> OK - this is where we aren't communicating. The change-log format I
> designed is first and foremost the input to a program. The program
> processes package uploads, and posts a change announcement to
> debian-changes for each upload after it has verified the upload and
> moved it into the visible area of the archive. The change announcement
> that is sent to the mailing list can be reformatted for human
> consumption - in fact it can be output in _your_ change format if we
> desire. It will no doubt also make it onto a WWW page, etc. The file
> destination information can be stripped from the human-readable copy
> if we wish.
Oh, I see. My changelog format is actually the format I use for the
debian.Changelog file inside each of my packages. I merely cut and
paste the appropriate `paragraph' into the release announcement.
> My change log format is derived from the dpkg control-file format that
> you designed. It's explicitly intended to be unambiguous to parse, thus
> the RFC-822-like format. The format you submitted is more well-suited
> for human consumption than an unambiguous parse, since the formatting
> rules aren't as immediately evident to the file creator.
Really (re the rules not being evident) ? I think that they are, with
appropriate application of common sense ...
If you want the release announcements to be submitted initially in a
non-human-friendly format then I have to convert them from my own
format to yours before mailing them (or use the unfriendly format for
my own debian.Changelog, which I don't really want to do).
Also, my format has in one respect slightly more information than
yours: I can leave a gap or not between different change entries, so
grouping them in ways that seem appropriate. Furthermore, my format
allows me to pre-format the change entries for the space they're going
to occupy, and to provide lists and the like.
I make a distinction between changes (which come out of the changelog)
and file upload and integrity information (which I generate
automatically using md5sum and ls). I don't think we need the MD5
checksums for each version ever released in the global Changelog ...
> We could split the destination information into another file before we
> upload it, but why? That's just another file for the uploader to edit
> and PGP-sign. Since all proposed changes file formats include file
> integrity information for the upload, we might as well put the only
> remaining datum concerning the upload in the same file.
I was expecting the destination information to be maintained centrally
by the site admin or someone, rather than having it be supplied by the
package maintainer.
The upload-processor would just look up the package in the database
(and would presumably have an `unclassified' or `new' directory for
packages which it didn't know about yet).
Ian.
Reply to: