Re: ChangeLog format
Bill Mitchell writes ("Re: ChangeLog format"):
> All this is a bit structured for maintainers with just a few
> packages, but I've got about 20.
I have a total of about 20 lines of script to do all of my changelog
generation, and I have about 10 packages.
I think there are some people who are doing an awful lot of automatic
copying of information from one place to another, with reformatting
en-route ...
> > The Changelog (for a package or the distribution) will contain all the
> > relevant Changelog entries, but no filenames &c.
>
> I've got some misgivings about mandating stuff like this. It seems
> to be getting a bit deep into micro-managing how individual maintainers
> go about doing their source package housekeeping.
>
> [ stuff about per-package Changelog files ]
I didn't intend to make a comment about how package maintainers should
organise the changelog in the package (I think they should keep one,
but putting that in the guidelines may be too strong).
I was just saying that a changelog file, as a log of changes, doesn't
need to contain information about the md5 checksums &c of each
released version.
> Is the name "ChangeLog" and the format you favor an emacs thing?
> I'm not an emacs person, and wouldn't know about emacs-isms.
I favour the name Changelog (note lowercase L) because I don't like
capitals in the middle of words.
My preferences are nothing to do with Emacs (indeed, Emacs has a mode
for generating changelogs that look different to mine and are IMO
inferior for our purposes, and it likes to use the capital L). I
happen to use Emacs to create it, but I to do it only use features of
Emacs common to almost all text editors.
If someone wants a fancy Emacs mode to edit Changlogs in my format I
can do that too, though I find that cut-and-paste and a bit of use of
the fill-prefix to get the change entries to word-wrap to the correct
left-hand margin is quite sufficient.
> Horrible, etc. seems a bit harsh. I'm not rabid about the dchanges
> format (which, after all, wasn't my idea in the first place), but I
> don't think it's all that bad. I think having the dchanges tool
> available to syntax check it before uploading is a big plus if
> it's supposed to be machine-parsed after uploading. If the group
> wants to go to some other format, and someone is willing to field,
> document, and maintain a tool to support building and syntax-checking
> package announcements using that format, I'll retire dchanges(1) and
> switch with little or no complaint.
I'll build whatever tools people want, if they specify them.
I think the problem I have here is that my way of working doesn't
involve having a tool that generates release announcements. I make
them by cutting and pasting the easily hand-edited Changelog entry
into my mailer, together with the output from my `Upload.sh' script
(which basically does md5sum * and ls -l *, as I said before). This
all seems far too trivial for me to try to turn these tiny scripts
into released software. Surely people who are building software for
release and hacking debian.rules files and so forth can write a 5 or
10-line utility shellscript to fit their way of working ?
Ian.
Reply to: