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

Philip Kaludercic <[email protected]> writes:

> Daniel Mendler <[email protected]> writes:
>
>> Philip Kaludercic <[email protected]> writes:
>>
>>> Daniel Mendler <[email protected]> writes:
>>>
>>>> Philip Kaludercic <[email protected]> writes:
>>>>
>>>>>> I am not sure I see the problem you're trying to solve. When we know the
>>>>>> version 1.2.3, we can simply scan all headlines for 1.2.3, take the
>>>>>> first headline and we will be good?
>>>>>
>>>>> Then you have a subsection in underneath the section in 1.2.4 titled
>>>>> "Bugfixes since 1.2.3" and we accidentally pick up on that instead.  It
>>>>> is my experience that we are just inviting annoyances like this if we
>>>>> start with the flexible approach, which undermines the intention of
>>>>> providing the right changelog information for each release.
>>>>
>>>> This won't happen in the scheme I had in mind. When you scan for 1.2.3
>>>> you must take the changelog from git corresponding to version 1.2.3, and
>>>> there won't be a "since 1.2.3". However you have to check out the
>>>> changelogs for all the versions you want to include in the feed, for
>>>> instance the ten last versions, but this should be efficient enough.
>>>> Another alternative would be to detect the indentation depth from the
>>>> latest version and then only scan headings of the same depth for the
>>>> older version numbers.
>>>
>>> In any case, my argument is that this all sounds much more complicated
>>> (from our side) than requiring the package author to use org-mode and
>>> annotate the relevant section with a tag.  But I have now posted a
>>> thread on emacs-devel, so I think the discussion should continue there,
>>> and when we have a satisfactory/popular solution, we can return to the
>>> problem of including changelogs in the Atom feeds.
>>
>> Yes, I see where you are coming from. But your approach is strictly
>> speaking not correct. Feed entries which have already been published
>> should not change again. They are basically immutable and feed readers
>> will not refetch them, as long as their ids do not change. The ids
>> should also be stable since otherwise feed readers end up with duplicate
>> entries. This means that one has to derive the entries from the
>> changelogs extracted from the specific versions in git. Given these
>> constraints I don't see anything wrong with the scanning method.
>
> I do not get why tagging or scanning would make a difference here.  The
> question here is only how we detect and extract a section, what we do
> with the section contents afterwards, and how we process that into the
> atom feed, is unrelated.

We can use two different approaches: (1) use the latest changelog file
and extract everything from there or (2) use the changelogs from all the
released commits.

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.

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.

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.

>> Daniel