Re: new commitfest transition guidance

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> I didn't have an opinion on this during the developer meeting, but after
> thinking about it I think having an up to date status for the patch is a
> reasonable requirement.

> It wouldn't need to be very long / detailed, it could even point to an
> earlier message in the thread, if it's still accurate.

> How did you propose to submit/track the status? Would it be sent to the
> mailing list, or would it be entered into the CF app while adding the
> patch to the next commitfest? (The latter wouldn't have the problem of
> cluttering the mailing list, but the information would be "split".)

I am very strong -1 on the idea of requiring a status email before a
entry can be pushed to the next CF. The whole activity is make-work
already from the patch submitter's viewpoint, and you're proposing
to at least double the cost of doing it (probably a lot more than
double it, considering the effort of writing an email vs. the effort
of clicking a button). And totally aside from the submitter's effort,
this will result in clogging pgsql-hackers yet more with emails that
in most cases won't carry any very useful info.

I could see asking people to type a sentence or so into the CF app
itself when they are making the change, but I wouldn't put a lot of
faith in getting valuable information that way either.

As of right now, I see that 79 CF entries have been manually pushed to
2025-03 (but it's hard to tell how many of those were moved before
2025-01 closed). 180 live entries are still in 2025-01, including
20 RfC ones. I think this experiment is already proving to be a
failure, and if you increase the cost of compliance substantially,
people just won't do it at all.

(Of course, if the idea is to drastically prune the set of active
patches, maybe losing two-thirds of them isn't a "failure". But
we're going to lose track of some good stuff this way.)

regards, tom lane