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

Philip Kaludercic <[email protected]> writes:

>> If we want immutable feed entries, then we have to check out the
>> changelog for each released version from git, which is (2). Given this
>> constraint, there is no need for tagging at all, and no need for
>> specifying a precise changelog format. We can scan for the first
>> matching headline, such that there is no need to specify or fix a
>> specific changelog format.
>
> For immutable entries, we can also load an existing atom feed from disk,
> add a new entry and then dump it all back.

Yes, this is as good as reloading them from git. I simply see git as a
database. Give me the changelog for this version, for that version and
so on. What you propose is a cache on top of the git database. ;)

>> Even simpler, we could take the first 100 lines from the changelog from
>> the commit and use this as content for the entry. As you had pointed
>> out, then the entry content might include too little or too much - but I
>> think this is okay. Feed entries are often truncated.
>
> If it were only truncated it would be one thing, my main annoyance is
> when the new section is too short and then the message would end up
> including the next section as well.

I agree that this is not great, but it is just a fallback for odd
changelog formats like HY-NEWS. Did you see this file?

> Also, there are no guarantees that package maintainers have to add new
> sections to the beginning of the file.

This is far-fetched. I have never seen news files where the entries
appeared at the end. Let's please solve the practical problem, the
common case.

>> This is what I had in mind initially in the feature request, since it
>> would be similar to how ELPA release mails look like. They just contain
>> the first few lines from the changelog.
>
> I totally get that, and we certainly could do that right away, no issue,
> it is just that I think it would be a wasted opportunity to not at least
> try and see if we could come to some agreement about how we can reliably
> do some (very light) machine-friendly processing of NEWS files.  If it
> turns out that there is no reasonable way to agree on this, then there
> is no problem with falling back to this idea.

To be honest I don't see it as such. It is not my project right now to
define a machine-friendly NEWS format. This is not necessary for this
feature request and reaches to far. It requires finding a consensus,
causes coordination problems, and will lead to unnecessary churn and
work.

I would prefer to focus on solving the exact problem here and nothing
else. If you want to establish such a convention, go ahead. But I cannot
promise that I will adapt my changelogs accordingly, and I suspect that
at least some other maintainers will feel the same. My feeling has
always been that it is better to be more permissive as a package archive
(within reasonable limits), while you're more interested in supervision
and curation.

I think settling on the (approximate) Towncrier format could be viable,
since many projects already use something along these lines. In
contrast, adding :release: tags is a definite no from me. This will look
like noise in the human-readable changelog files, which is hardly
justifiably.

>>>> Daniel