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.
Yes.
> 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
announcements.)
Ian.
Reply to: