Re: cl-defstruct-based package.el, now with ert tests and no external tar!

[Dmitry Gutov <dgutov@yandex.ru>]

Daniel Hackney <dan@haxney.org> writes:
>> You can start with ChangeLog files. When writing a changelog entry,
>> one usually briefly describes and sometimes justifies the mechanical
>> transformations being performed on the code, and it helps other people
>> understand the changes.
>
> Since it is a complete refactoring, what should I say? Should I include
> a line for each new or changed function

I think so: http://www.gnu.org/prep/standards/html_node/Change-Logs.html

>> I see you've also already started on NEWS entries.
>
> How does it look so far? Any suggestions on how to improve it?

Actually, I'm not entirely sure the NEWS entries are appropriate in this
case.

Compare: "file named NEWS which contains a list of user-visible changes
worth mentioning"
(http://www.gnu.org/prep/standards/html_node/NEWS-File.html).

and

"User-facing commands have not changed and existing archives and files
will continue to work as before;"

You can put the justification in the email message accompanying
the patch, and then the person installing the patch can add the link to
the message in the ChangeLog. Alternatively, you can submit the patch as
a bug report, then the ChangeLog entry can reference it, this seems to
be the most proper option.

> One other change I made, which probably deserves some discussion, is
> that I created a folder "test/automated/data" which is intended to hold
> test-related data. I created a subfolder "package" (so it is
> "test/automated/data/package") which contains a test "archive-contents"
> file, as well as test elisp files. My hope is that such a directory
> could be useful for other tests which need example data.
>
> I also added a rule in the "Makefile.in" to skip byte-compilation of the
> files in "data".

Sounds good to me. I would probably make it test/automated/package/data
(and put the package tests inside automated/package, to bring them
closer), but I guess that would make the respective rule(s) in
Makefile.in more complicated, if/when other packages do the same.