Re: Git in GSoC 2025

[Patrick Steinhardt <ps@pks.im>]

On Fri, Jan 31, 2025 at 08:09:41AM -0800, Junio C Hamano wrote:
> 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".

I completely agree, we were simply talking past one another :) Retiring
an item from the list doesn't need any additional reason other than the
expiry date. But people can try to advocate for _keeping_ the item and
extend the expiry date in case they have a good reason.

Patrick