Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Mark H Weaver <m...@netris.org> writes:
[..]
>>
>> I looked at your earlier reply to Tomas, and the gitea pull request that
>> you linked to. I didn't see any comments there addressing the potential
>> issue that Tomas raised. Apologies if I missed it.
>>
>> To clarify, the issue is this:
>>
>> By design, RSS feeds only publish the most recent entries, i.e. there is
>> no *flow control*. There is only the heuristic that if users check the
>> RSS feed sufficiently often, they will hopefully not miss any entries.
>>
>> Tomas indicated that the RSS feed for Guix commits includes only 30
>> entries at any given time. So what happens if 40+ commits are pushed at
>> once? Do you have reason to believe that no commits will be missed in
>> the RSS feed in this scenario?
>
> That was for the atom feed, I believe. The one I shared above is even
> more limited, including only the 10 most recent commits. The source that
> is responsible to do that is [0]:
>
> // ShowBranchFeed shows tags and/or releases on the repo as RSS / Atom feed
> func ShowBranchFeed(ctx *context.Context, repo *repo.Repository, formatType
> string) {
> commits, err := ctx.Repo.Commit.CommitsByRange(0, 10, "")
> if err != nil {
> ctx.ServerError("ShowBranchFeed", err)
> return
> }
>
> My understanding of RSS was naive, but now I see this could be a
> problem. I guess it depends of what we use the guix-commits mailing list
> for. Is it just for casually keeping track of what goes in the repo in
> near real time? Or is it because we want to review everything that was
> pushed for security or other reasons? If the former, I think that RSS
> feed is good enough. If the later, it isn't but then I'd argue that 'git
> log -p' is a better tool, as you never know with email if a message may
> have been lost in transit (as you had mentioned).
>
> Thoughts?
My use case is the former, just keeping track of what is going on. I do
not believe reviewing everything is actually possible at the Guix scale.
I mostly look only at the commit subjects, and only inside when it
sounds interesting.
Let me backtrack a bit. Were we approached by the FSF to shut down the
mailing list? Or is this a pro-active move from our side? If the
latter, would disabling the archiving achieve sufficient relieve on the
resources in your eyes?
Look, I have made my peace with losing the guix-commits when the
mirroring to savannah is disabled, but I did not expect it this soon.
If there is an actual need to shut it down, I will understand, but if
this is just us trying to be considerate, could we try the middle road
(no archiving) first?
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
