[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).


Reply to: