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

Daniel Mendler <[email protected]> writes:

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

For immutable entries, we can also load an existing atom feed from disk,
add a new entry and then dump it all back.

> 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.  Also, there are no guarantees that
package maintainers have to add new sections to the beginning of the
file.

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

>>> Daniel