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

Daniel Mendler <[email protected]> writes:

> 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.

Really, this entire discussion boils down to the question of extracting
the "corresponding part from the changelog".

>>> 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.

I know, there are different conceptions of what ELPA-devel is, but that
is sort of the issue.  I don't recommend anyone uses the snapshots of my
packages for instance, so for an arbitrary package, there are no
guarantees (though to be fair, ELPA-stable/regular also doesn't have
this, so this really doesn't matter)

> 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.

To be clear, I was not thinking about just scanning headers, but using
`org-export-select-tags'.  We should probably get some Org people in for
ideas if we decide to go this way.

>>> 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.

One of the motivations for adding the feeds was to use them as a
stepping stone to provide news about ELPA packages on the Fediverse.
And while I know that this is not a rational argument, having posts that
end mid sensitize with a "..." seemed unsatisfying -- and having these
"better formatted" news entries only for packages that provide a "better
changelog" seems like an incentive as well.

>> 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 don't think that is so much more complicated, in fact if we were to
restrict ourselves to org-mode files, the entire extraction logic is
already implemented.  If we search for sections like you suggest, it
seems more brittle as we are more likely to miss the right headers or
confuse code blocks that might contain something that looks like a
heading.

>> 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.

Note that my counter-argument from above applies to my argument here ^^

>>> Daniel