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

Re: Another changelog format, automating the FTP server, etc.

Ian Murdock writes ("Re: new mailing list: debian-changes@pixar.com"):
>    Date: Wed, 16 Aug 95 00:15 BST
>    From: Ian Jackson <iwj10@cus.cam.ac.uk>
>    At this point I'd like to put in another plug for my own favourite
>    Changelog entry format, which I think is less wasteful of space, more
>    flexible, more informative and better-looking than the Emacs one.
> I like your ChangeLog format, and I wouldn't be opposed to adopting
> it as the official format.  Do you have a script that generates the
> ChangeLog for you?  If so, could you send a copy to debian-devel?

No, I don't - I just write it by hand (with a bit of cut-and-paste).

I have trivial script to generate the md5sum and ls -l output at the
same time as moving the files to my `to upload' directory, and this
small Perl script to produce the RFC-822 date format:

#!/usr/bin/perl --
# I hereby place this in the public domain - Ian Jackson, 1995.
@ARGV && die "usage: 822-date\n";
$x=time; sub z { $_[1]+$_[2]*60; }; @l=localtime($x); $od=1440;
$d=&z(@l)-&z(gmtime($x)); $d+=$od; $d%=$od; $s=$d>$od/2?($d=$od-$d,'-'):'+';
printf("%s, %d %s %d %02d:%02d:%02d %s%02d%02d\n",
 (Sun,Mon,Tue,Wed,Thu,Fri,Sat)[$l[6]], $l[3],
 (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)[$l[4]], $l[5]+1900,
 $l[2],$l[1],$l[0], $s,$d/60,$d%60) || die "822-date: output error: $!\n";

(I paste the output into the debian.Changelog, and cut-and-paste the
most recent debian.Changelog entry into each release announcement.)

If anyone wants to pick it up and put it in a package, please feel
free.  I have it as /usr/local/bin/822-date.

Bruce Perens writes ("Another changelog format, automating the FTP server, etc."):
> > Does anyone have opinions about the ChangeLog format?
> I would suggest we make it machine-readable.

I agree.  My format is machine-readable.

> That would make it a bit easier to look up changes for a
> specific package, log changes for packages together, etc. It might even
> allow us to automate the FTP site. I haven't looked at Ian Jackson's
> format, so pardon me if I have duplicated any of his ideas. The fields
> we use can be the same as the control file and the bug reporting
> script, as in: [ proposed format deleted ]

Why do we need such an unfriendly format for what is supposed to be
used primarily by humans ?  It also seems to me that the structure
you're trying to express in a changelog doesn't fit well into the kind
of field-value scheme of things.

> Now, say the automatic program at the FTP site receives this debian-changes
> posting. It can look in Incoming and verify the files. If they pass
> verification, it can move them to the destination. It may even be that we
> mail the package announcements to the FTP server, and it only sends them
> to debian-changes if the files all verify and it has installed them in the
> right place - otherwise it bounces the message back to the maintainer for
> repair. We can use PGP to verify that the package maintainer is
> legitimate.


> This also gives us a package-verification mechanism that can be used to
> verify the packages at any point in the pipeline between main FTP site and
> user.

It would be better to build this into the packages themselves, IMO.

rdm@tad.micro.umn.edu writes:
> Um.. this gets into the question of: what is the purpose of the
> ChangeLog?
> The original purpose was a human-readable record of the kinds of
> changes that have been made to the system so that people could have an
> idea of what's going on with a new distribution.
> Most of the times I've seen ChangeLog used, it's been so that multiple
> programmers working on the same project can keep tabs on where the
> action is.
> We've had a semi-formal requirement that package announcements should
> include text from the relevant ChangeLog.  This is supposed to give
> our audience a way of recognizing if they're interested in a new
> version.
> The best format I've seen for this purpose is a simple list of changes
> -- there's generally no need to know stuff like the time the change
> was made, or the source file where the changes went in.  This kind of
> thing is almost meaningless with a binary distribution (but could be
> important with a source distribution).

Quite.  My format is just a simple list of changes.  All the other
information is just to tell you which version of the package (rather
than the individual files) the changes apply to, and a flag to tell
the user whether the upgrade is important.

> Personally, I have a hard time with the ChangeLog discipline.  There's
> an art to getting the right level of abstraction, and I generally
> don't get it right till well after the changes have been made.

Me too.  I usually write Changelog entries after making the relevant
changes; sometimes I even wait until I'm ready to release.

Bruce Perens writes ("closure on the changes file format?"):
> A few days ago I posted a new formal package announcement and package
> change documentation format that would allow the automation of the FTP
> site and the changes list and archive, and could be used to provide
> maintainer-to-user protection from package tampering.

The format I'm using for my package announcements at the moment allows
this too.  (Modulo the fact that I don't PGP-sign most of my release


Reply to: