Re: Git in GSoC 2025

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

>> How about making the rule a lot simpler?
>> 
>>     The expiration date kicks in _mechanically_, i.e. stale entries
>>     are unconditionally dropped at the date, based solely on the
>>     comparison between the timestamp and the wall clock.
>> 
>> People are free to advocate for its continued existence, and when
>> such an effort achieves a concensus among then-active members of the
>> community by the stated expiration date, a patch to update the
>> entry's expiration date may be accepted, thereby prolonging its
>> shelf life.  Unless such a thing happens before the expiration date
>> comes, we will mechanically drop the entry.
>> 
>> Of course people _can_ resurrect an expired entry later as a new
>> one when it seems appropriate.
>> 
>> That makes the decision to expire things from the list easy to make.
>
> Works for me. Ideally, as any other topic, the retirement should be sent
> to the mailing list as a normal patch series so that people may chime in
> on the retirement and state reasons why they don't think that is a good
> idea.

That is the complete opposite of the ideal from my point of view.
The whole point of making the list items expire by default is that
the onus is on those who want to have them on list to justify why
these items must remain on the list.  A patch to remove an item that
hasn't had anybody advocating for its retention shouldn't have to be
chimed in to be supported.  There shouldn't even have to be a patch;
that is what I mean by "stale entries expire mechanically by default".

Thanks.