bug#81116: 31.0.60; [FR] ELPA: Include changelog in the Atom feeds

Philip Kaludercic <[email protected]> writes:

>>                                                              I think we
>> can simply try out various extraction/truncation methods. There is no
>> risk.
>
> One issue I think we want to keep in mind is that when we have changelog
> files that are too long, we are burdening the server by serving more
> data that spiders and RSS clients will periodically ping.

Right, this is some small risk. Elfeed at least won't refetch the file
if it has not changed in the meantime (HTTP ETag). Ideally the entry
only contains the corresponding part from the changelog, which would
ensure that the feed doesn't grow too much. But then, we only keep a
small number of old versions, and the feed could be similarly limited,
so it doesn't sound too problematic.

>> Maybe it also helps nudging package maintainers to use a relatively
>> uniform changelog format, e.g, Org files where the headlines contain the
>> released version number as substring. For ELPA-devel snapshots it is
>> less clear what to use.
>
> For ELPA-devel I wouldn't argue that we need to worry about this too
> much, since these are by definition not releases so there is no need for
> complete changelogs.  But if we choose to promote a fixed org-mode
> format, we can also fix some header tag like "devel" to select for
> extraction.

Well, I disagree with this definition. ;) They are snapshot releases and
I use them as such for testing purposes. From my observation they do not
differ in any way from stable releases except by their version numbers.

But indeed, I wouldn't worry too much, and if the snapshot feeds are not
great, so be it. I usually write "* Development" headers in my
changelog, so if you scan for headers including the string "devel" it
would work.

>> But as I wrote above, the mails which are sent to [email protected]
>> already contain an excerpt of the changelog, so couldn't one simply do
>> the same for the feed entries? The difficulty is probably that one has
>> to checkout all versions and extract the changelog content when
>> regenerating the new feed.
>
> The reason I did not do that when we first implemented the feature is
> that the result would be unsatisfying (to me) since basically all
> entries would include either too little or too much information.

I like that the ELPA release mails include some information, even if
imperfect. So I would like to have the same for the feeds.

> My suggestion would be to come up with some "privileged" formats for
> changelog files and only include the changelogs from those files in the
> RSS feeds.  To get the ball rolling, I would suggests the simplest
> format would be to use org-mode as you suggested and extract only the
> sections with a "release" tag for ELPA-regular and "devel" for
> ELPA-devel.  If we think it is necessary/helpful, we can use properties
> to annotate the specific versions of each release.

Let's please not fix an overspecific format. My suggestion would be to
scan for "^[*]+.*<version>.*$" lines, and then include that part up to
the next header of the same level. For development scan for
"^[*]+.*devel.*$" lines. This should work in Org. For Markdown use [#]
instead, in case Markdown is supported too.

> I would personally also like to continue supporting "News" sections
> within the main files.

Sure, why not. I am not fond of such news sections in Elisp files, but
this is a matter of taste.

>> Daniel