Thread

new commitfest transition guidance

Peter Eisentraut <peter@eisentraut.org> — 2025-02-03T11:22:52Z

During the developer meeting at FOSDEM last Thursday, there was strong 
consensus that we should no longer move patches to the next commitfest 
in a semi-automatic, mechanical way, has commitfest managers have 
traditionally done.  Patches should only be moved forward by someone 
involved in the patch who knows that the patch is actually being worked 
on.  That way, there is a higher likelihood that the patches arriving in 
the next commitfest actually have someone currently invested in them.

My interpretation of this is that patches should be moved forward by 
either an author, possibly a reviewer, possibly a committer signed up 
for the patch, or maybe even a colleague of an author who knows that the 
author is on vacation and will get back to it in a couple of weeks, or 
some similar situation.

CF 2025-01 has just ended, so I suggest that everyone try this now.  We 
can check in perhaps two weeks whether this results in lots of stuff 
falling through the cracks or still too much stuff with unclear status 
being moved forward, and then see what that might mean going forward.

Re: new commitfest transition guidance

Aleksander Alekseev <aleksander@timescale.com> — 2025-02-03T12:53:44Z

Hi Peter,

> CF 2025-01 has just ended, so I suggest that everyone try this now.  We
> can check in perhaps two weeks whether this results in lots of stuff
> falling through the cracks or still too much stuff with unclear status
> being moved forward, and then see what that might mean going forward.

This doesn't work unfortunately.

When I try to move my patches from CF 2025-01 to CF 2025-03 I get an error:

"""
The status of this patch cannot be changed in this commitfest. You
must modify it in the one where it's open!
"""

-- 
Best regards,
Aleksander Alekseev

Re: new commitfest transition guidance

Aleksander Alekseev <aleksander@timescale.com> — 2025-02-03T12:55:37Z

Hi,

> This doesn't work unfortunately.
>
> When I try to move my patches from CF 2025-01 to CF 2025-03 I get an error:
>
> """
> The status of this patch cannot be changed in this commitfest. You
> must modify it in the one where it's open!
> """

Ooops, never mind. The application asked me to log in and I didn't
notice that when I did it also moved the patch to the next CF. This
was the actual reason why I got an error.

Sorry for the noise.

-- 
Best regards,
Aleksander Alekseev

Re: new commitfest transition guidance

Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-02-03T16:19:55Z

On Mon, 3 Feb 2025 at 13:56, Aleksander Alekseev
<aleksander@timescale.com> wrote:
> > """
> > The status of this patch cannot be changed in this commitfest. You
> > must modify it in the one where it's open!
> > """
>
> Ooops, never mind.

I also thought that error was pretty silly. So it will be changed in
the next release[1] of the commitfest app by this commit[2].

[1]: https://www.postgresql.org/message-id/flat/CAGECzQTbHhaZMY-%3DY%3DOGMU_jik4MqCfsc7rDf6AnT%3DAq-B6cZA%40mail.gmail.com
[2]: https://github.com/postgres/pgcommitfest/commit/013eeb1befa3cf3f38b7ccb7977881f2c7c0f38d

Re: new commitfest transition guidance

Mihail Nikalayeu <michail.nikolaev@gmail.com> — 2025-02-03T16:57:05Z

Hello!

I think it is a good idea to sent notification (at least once) to the
authors of entries. Because it is easy to miss that thread.

Best regards,
Mikhail.

Re: new commitfest transition guidance

Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-04T05:50:23Z

Peter Eisentraut <peter@eisentraut.org> writes:
> During the developer meeting at FOSDEM last Thursday,

BTW, are there minutes available from that meeting?  In past years
some notes have been posted on the wiki, but I'm failing to find
anything right now.

			regards, tom lane

Re: new commitfest transition guidance

Daniel Gustafsson <daniel@yesql.se> — 2025-02-04T06:39:12Z

> On 4 Feb 2025, at 06:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Peter Eisentraut <peter@eisentraut.org> writes:
>> During the developer meeting at FOSDEM last Thursday,
> 
> BTW, are there minutes available from that meeting?  In past years
> some notes have been posted on the wiki, but I'm failing to find
> anything right now.

They will be on the wiki shortly, I've taken notes of all discussions and am
busy tidying them up to be able to publish them once the participants have
proofread to ensure noone is misattributed.

--
Daniel Gustafsson

Re: new commitfest transition guidance

Jeff Davis <pgsql@j-davis.com> — 2025-02-04T20:11:29Z

On Mon, 2025-02-03 at 12:22 +0100, Peter Eisentraut wrote:
> My interpretation of this is that patches should be moved forward by 
> either an author, possibly a reviewer, possibly a committer signed up
> for the patch, or maybe even a colleague of an author who knows that
> the 
> author is on vacation and will get back to it in a couple of weeks,
> or 
> some similar situation.

I also suggested: when someone does move a patch forward, that they
summarize the current state if that's not obvious from recent messages
on the thread.

There was some concern that it would clutter up -hackers with unhelpful
status messages. I still like the idea: if someone is writing an
unhelpful status message (e.g. no clear next steps or blockers), that's
a sign that they aren't close enough to the patch and someone else
needs to carry it forward. Also, we don't need to decorate the message
with "This is an official end-of-fest patch status message" -- the
message should flow with the rest of the conversation.

Regards,
	Jeff Davis

Re: new commitfest transition guidance

Tomas Vondra <tomas@vondra.me> — 2025-02-05T00:38:50Z

On 2/4/25 21:11, Jeff Davis wrote:
> On Mon, 2025-02-03 at 12:22 +0100, Peter Eisentraut wrote:
>> My interpretation of this is that patches should be moved forward by 
>> either an author, possibly a reviewer, possibly a committer signed up
>> for the patch, or maybe even a colleague of an author who knows that
>> the 
>> author is on vacation and will get back to it in a couple of weeks,
>> or 
>> some similar situation.
> 
> I also suggested: when someone does move a patch forward, that they
> summarize the current state if that's not obvious from recent messages
> on the thread.
> 
> There was some concern that it would clutter up -hackers with unhelpful
> status messages. I still like the idea: if someone is writing an
> unhelpful status message (e.g. no clear next steps or blockers), that's
> a sign that they aren't close enough to the patch and someone else
> needs to carry it forward. Also, we don't need to decorate the message
> with "This is an official end-of-fest patch status message" -- the
> message should flow with the rest of the conversation.
> 

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

regards

-- 
Tomas Vondra

Re: new commitfest transition guidance

Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-05T01:10:46Z

Tomas Vondra <tomas@vondra.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

Re: new commitfest transition guidance

Jeff Davis <pgsql@j-davis.com> — 2025-02-05T01:33:50Z

On Wed, 2025-02-05 at 01:38 +0100, Tomas Vondra wrote:
> 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".)

The former: sent to -hackers as a normal message in the thread. I don't
think we should make it overly formal. It should flow with the rest of
the conversation as a periodic patch summary, which many authors
already do when threads start to get too long.

And if it would add zero information, no need to send it.

Regards,
	Jeff Davis

Re: new commitfest transition guidance

Jeff Davis <pgsql@j-davis.com> — 2025-02-05T01:40:41Z

On Tue, 2025-02-04 at 20:10 -0500, Tom Lane wrote:
> I am very strong -1 on the idea of requiring a status email before a
> entry can be pushed to the next CF.

OK, I retract the idea.

Regards,
	Jeff Davis

Re: new commitfest transition guidance

Peter Geoghegan <pg@bowt.ie> — 2025-02-06T00:14:14Z

On Tue, Feb 4, 2025 at 8:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Evidently this new policy is why my skip scan patch series wasn't
being tested by CI.

I just don't think that this new policy makes sense. At least not as
implemented. Do we all now need to set ourselves reminders to re-enter
patches to each CF, lest we be accused of abandoning patches due to a
lack of interest?

-- 
Peter Geoghegan

Re: new commitfest transition guidance

Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-06T00:29:35Z

Peter Geoghegan <pg@bowt.ie> writes:
> Evidently this new policy is why my skip scan patch series wasn't
> being tested by CI.

Well no, the reason CI wasn't testing anything was the cfbot was
broken.  See nearby "CFBot is broken" thread.

> I just don't think that this new policy makes sense. At least not as
> implemented.

I'm a little dubious about it too, but let's not conflate this
question with plain ol' infrastructure bugs.

			regards, tom lane

Re: new commitfest transition guidance

Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-02-06T12:53:03Z

On Thu, 6 Feb 2025 at 01:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Geoghegan <pg@bowt.ie> writes:
> > Evidently this new policy is why my skip scan patch series wasn't
> > being tested by CI.
>
> Well no, the reason CI wasn't testing anything was the cfbot was
> broken.  See nearby "CFBot is broken" thread.

That's not entirely true. CFBot never runs on patches that are only in
closed commitfests. So even if it had been working fine, it would have
not picked up Peter G's skip scan patch until after he moved the patch
to the new commitfest.

I definitely agree with Peter G that that's a problem i.e. having
CFBot not run on patches for ~X days until the author notices they
were not moved and moves them. Ofcourse the CFBot could be changed to
behave differently, but then the question becomes how should it behave
then? When do we want to stop running CFBot on patches?

Related: What do we do in general with patches that have been moved?
And when do we do that?

Re: new commitfest transition guidance

Jeff Davis <pgsql@j-davis.com> — 2025-02-06T17:52:03Z

On Wed, 2025-02-05 at 19:14 -0500, Peter Geoghegan wrote:
> I just don't think that this new policy makes sense. At least not as
> implemented.

Perhaps the answer is to go in the other direction, and the CF app
would just be a patch tracker without specific start and stop dates
(aside from a few deadlines like the feature submission deadline or the
feature freeze deadline)? We very briefly discussed that at the
meeting, as well.

It seems weird to have "new" commitfests but just bring over all of the
patches.

Regards,
	Jeff Davis

Re: new commitfest transition guidance

Jacob Brazeal <jacob.brazeal@gmail.com> — 2025-02-06T17:57:20Z

>
>
> That's not entirely true. CFBot never runs on patches that are only in
> closed commitfests.
>


> Ofcourse the CFBot could be changed to
> behave differently, but then the question becomes how should it behave
> then? When do we want to stop running CFBot on patches?
>
> Related: What do we do in general with patches that have been moved?
> And when do we do that?
>

It seems clear that if new patches are pushed to a message thread that was
registered with commitfest at some point, we'd like CFBot to run on them.

What if we automatically move any patches to the current commitfest if new
patch attachments are sent to the corresponding message thread? Heck,
perhaps if there are any new messages *at all* in the message thread, and
the commitfest entry has not been closed already, we should move it to the
current commitfest. We could even have commitfest respond to the message
thread to inform when automated actions of this nature have been taken.

Re: new commitfest transition guidance

Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-06T18:18:56Z

Jacob Brazeal <jacob.brazeal@gmail.com> writes:
> What if we automatically move any patches to the current commitfest if new
> patch attachments are sent to the corresponding message thread? Heck,
> perhaps if there are any new messages *at all* in the message thread, and
> the commitfest entry has not been closed already, we should move it to the
> current commitfest.

+1 ... this would go a long way towards reducing the manual effort
needed to maintain these things.

> We could even have commitfest respond to the message
> thread to inform when automated actions of this nature have been taken.

Dunno that we need automated mail about it though.

(I don't care for the other idea of not having dated CFs at all.
That would mean that an entry never disappears unless manual action
is taken to remove it.  Making untouched threads silently age out
seems like the better path forward.)

			regards, tom lane

Re: new commitfest transition guidance

Aleksander Alekseev <aleksander@timescale.com> — 2025-02-07T10:48:16Z

Hi,

> > What if we automatically move any patches to the current commitfest if new
> > patch attachments are sent to the corresponding message thread? Heck,
> > perhaps if there are any new messages *at all* in the message thread, and
> > the commitfest entry has not been closed already, we should move it to the
> > current commitfest.
>
> +1 ... this would go a long way towards reducing the manual effort
> needed to maintain these things.
>
> > We could even have commitfest respond to the message
> > thread to inform when automated actions of this nature have been taken.
>
> Dunno that we need automated mail about it though.
>
> (I don't care for the other idea of not having dated CFs at all.
> That would mean that an entry never disappears unless manual action
> is taken to remove it.  Making untouched threads silently age out
> seems like the better path forward.)

Perhaps we should consider the other way around. All the patches are
moved to the next CF automatically, as we did before. Except for the
cases when there were no updates for a certain amount of time (e.g. a
few months). In this case the application sends an email to the
corresponding thread notifying that the CF entry was closed due to
inactivity, but if this was done by mistake feel free moving it by
hand to the upcoming CF.

I believe this would be more productive / convenient. In certain cases
it may take a couple of months to get attention from the reviewers and
the patch doesn't necessarily need a rebase during this time period.
This is a normal situation. However if there was no activity in the
thread for several months this indeed is a good indicator that
something is off.

Even if the application closes an entry by mistake few of the authors
have dozens of simultaneously open entries, so reopening an entry or
two several times a year doesn't take too much effort. In all other
respects the proposed approach is not worse than what we did until
now.

-- 
Best regards,
Aleksander Alekseev

Re: new commitfest transition guidance

Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-02-19T09:25:01Z

Since the next commitfest is starting soon, I think for now we should
move all entries still open in the January commitfest to the March
commitfest. There's a bunch that are still not moved, that I know
should be moved. For example[1] which we discussed at FOSDEM and seems
to have a reasonable chance of even being committed. I've moved that
specific one already, but there's a bunch more. Unless someone feels
like actually going over the list, I think we should just move it.
Then we can try a new flow for the new development cycle.

On Fri, 7 Feb 2025 at 11:48, Aleksander Alekseev
<aleksander@timescale.com> wrote:
> Perhaps we should consider the other way around. All the patches are
> moved to the next CF automatically, as we did before. Except for the
> cases when there were no updates for a certain amount of time (e.g. a
> few months). In this case the application sends an email to the
> corresponding thread notifying that the CF entry was closed due to
> inactivity, but if this was done by mistake feel free moving it by
> hand to the upcoming CF.

I think this sounds much more reasonable than what's happening now.
But I think we need to make the flow a bit more clear:
1. Add a "no interest" reason for closing.
2. Add a label[2]/column that specifies that an entry will be closed
as "no interest" automatically at the end of this CF, e.g. a "pending
no interest" label.
3. If at the end of a commitfest a patch has had 3 or more months
without any emails, it automatically gets that "pending no interest"
label.
4. Anyone subscribed to emails for this patch will get notified about
that change.
5. If a patch is Ready for Committer and has a committer assigned,
never add this label.
6. At the end of the commitfest, move all patches without that label.
And close all patches with such a label.

[1]: https://commitfest.postgresql.org/patch/5117/
[2]: https://github.com/postgres/pgcommitfest/issues/11

Re: new commitfest transition guidance

Aleksander Alekseev <aleksander@timescale.com> — 2025-02-19T14:29:32Z

Hi,

> I think this sounds much more reasonable than what's happening now.
> But I think we need to make the flow a bit more clear:
> 1. Add a "no interest" reason for closing.
> 2. Add a label[2]/column that specifies that an entry will be closed
> as "no interest" automatically at the end of this CF, e.g. a "pending
> no interest" label.
> 3. If at the end of a commitfest a patch has had 3 or more months
> without any emails, it automatically gets that "pending no interest"
> label.
> 4. Anyone subscribed to emails for this patch will get notified about
> that change.
> 5. If a patch is Ready for Committer and has a committer assigned,
> never add this label.
> 6. At the end of the commitfest, move all patches without that label.
> And close all patches with such a label.

Sounds perfect to me.

-- 
Best regards,
Aleksander Alekseev

Re: new commitfest transition guidance

Daniel Gustafsson <daniel@yesql.se> — 2025-02-19T15:02:34Z

> On 19 Feb 2025, at 10:25, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> 
> Since the next commitfest is starting soon, I think for now we should
> move all entries still open in the January commitfest to the March
> commitfest. There's a bunch that are still not moved, that I know
> should be moved. For example[1] which we discussed at FOSDEM and seems
> to have a reasonable chance of even being committed. I've moved that
> specific one already, but there's a bunch more. Unless someone feels
> like actually going over the list, I think we should just move it.
> Then we can try a new flow for the new development cycle.
> 
> On Fri, 7 Feb 2025 at 11:48, Aleksander Alekseev
> <aleksander@timescale.com> wrote:
>> Perhaps we should consider the other way around. All the patches are
>> moved to the next CF automatically, as we did before. Except for the
>> cases when there were no updates for a certain amount of time (e.g. a
>> few months). In this case the application sends an email to the
>> corresponding thread notifying that the CF entry was closed due to
>> inactivity, but if this was done by mistake feel free moving it by
>> hand to the upcoming CF.
> 
> I think this sounds much more reasonable than what's happening now.
> But I think we need to make the flow a bit more clear:
> 1. Add a "no interest" reason for closing.
> 2. Add a label[2]/column that specifies that an entry will be closed
> as "no interest" automatically at the end of this CF, e.g. a "pending
> no interest" label.
> 3. If at the end of a commitfest a patch has had 3 or more months
> without any emails, it automatically gets that "pending no interest"
> label.
> 4. Anyone subscribed to emails for this patch will get notified about
> that change.
> 5. If a patch is Ready for Committer and has a committer assigned,
> never add this label.
> 6. At the end of the commitfest, move all patches without that label.
> And close all patches with such a label.

I don't think it makes much sense to encode value judgments into the system
with arbitrarily chosen deadlines (X months between January and re-opening
master after the freeze is different from X months around September etc). 

The opposite, which was discussed at length at FOSDEM, was to ask authors to
click a single button once a month at most.  If that level of engagement is too
much to ask then maybe said authors should question why they in return ask
others to spend hours reviewing?

--
Daniel Gustafsson

Re: new commitfest transition guidance

Robert Haas <robertmhaas@gmail.com> — 2025-02-19T15:05:45Z

> On Feb 19, 2025, at 10:02 AM, Daniel Gustafsson <daniel@yesql.se> wrote:
> The opposite, which was discussed at length at FOSDEM, was to ask authors to
> click a single button once a month at most.  If that level of engagement is too
> much to ask then maybe said authors should question why they in return ask
> others to spend hours reviewing?

Exactly this.

…Robert

Re: new commitfest transition guidance

Aleksander Alekseev <aleksander@timescale.com> — 2025-02-19T15:13:51Z

Hi,

> > On Feb 19, 2025, at 10:02 AM, Daniel Gustafsson <daniel@yesql.se> wrote:
> > The opposite, which was discussed at length at FOSDEM, was to ask authors to
> > click a single button once a month at most.  If that level of engagement is too
> > much to ask then maybe said authors should question why they in return ask
> > others to spend hours reviewing?
>
> Exactly this.

True, but didn't we just discover that it doesn't work?

"""
There's a bunch that are still not moved, that I know should be moved. [...]
"""

I agree about the fact that "no interest" status might be a bit too
judgmental. There might be interest but no time. Perhaps something
like "no activity" or "closed due to inactivity" would be more
appropriate / neutral. We should also emphasise in the emails that the
author is free to reopen the entry if he/she believes it was closed by
mistake.

I also agree that we should account for feature freezes.

-- 
Best regards,
Aleksander Alekseev

Re: new commitfest transition guidance

Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-19T15:19:44Z

Aleksander Alekseev <aleksander@timescale.com> writes:
>> On Feb 19, 2025, at 10:02 AM, Daniel Gustafsson <daniel@yesql.se> wrote:
>>> The opposite, which was discussed at length at FOSDEM, was to ask authors to
>>> click a single button once a month at most.  If that level of engagement is too
>>> much to ask then maybe said authors should question why they in return ask
>>> others to spend hours reviewing?

>> Exactly this.

> True, but didn't we just discover that it doesn't work?

I think what we discovered is that the amount of effort that was put
into *notifying authors of this new requirement* was woefully
inadequate.  One email thread within the firehose that is
pgsql-hackers doesn't cut it.

How about having the cfbot send out some nagmail to patch authors,
saying "please move your patch forward, or close it if no longer
interested"?  If nothing happens after a few rounds of that,
an auto-close could be justified.

			regards, tom lane

Re: new commitfest transition guidance

Aleksander Alekseev <aleksander@timescale.com> — 2025-02-19T15:24:19Z

Hi,

> How about having the cfbot send out some nagmail to patch authors,
> saying "please move your patch forward, or close it if no longer
> interested"?  If nothing happens after a few rounds of that,
> an auto-close could be justified.

Well, it is a possibility of course. If I read the current status of
January CF correctly this means sending 80 emails to an unknown number
of pgsql-hackers@ subscribers though.

-- 
Best regards,
Aleksander Alekseev

Re: new commitfest transition guidance

Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-02-19T15:30:11Z

On Wed, 19 Feb 2025 at 16:02, Daniel Gustafsson <daniel@yesql.se> wrote:
> The opposite, which was discussed at length at FOSDEM, was to ask authors to
> click a single button once a month at most.  If that level of engagement is too
> much to ask then maybe said authors should question why they in return ask
> others to spend hours reviewing?

Moving stuff to the next commitfest is incredibly painful at the
moment. It currently takes 4 clicks per patch to move it to the next
commitfest. We could probably get this to 1 per patch with some UX
redesign. But that still means that if you have 10 patches on the
commitfest, then you have to click 10 times. It seems kind of silly to
have to do that for a patch for which you sent an email to the thread
last week.

Re: new commitfest transition guidance

Daniel Gustafsson <daniel@yesql.se> — 2025-02-19T16:24:24Z

> On 19 Feb 2025, at 16:24, Aleksander Alekseev <aleksander@timescale.com> wrote:
> 
> Hi,
> 
>> How about having the cfbot send out some nagmail to patch authors,
>> saying "please move your patch forward, or close it if no longer
>> interested"?  If nothing happens after a few rounds of that,
>> an auto-close could be justified.
> 
> Well, it is a possibility of course. If I read the current status of
> January CF correctly this means sending 80 emails to an unknown number
> of pgsql-hackers@ subscribers though.

There is functionality in the CF app to send an email to authors with a patch
still in the previous commitfest, it would be quite trivial to alert everyone.

We should of course also add some form of messaging in the app itself to make
it known that patches need to be moved etc.

--
Daniel Gustafsson

Re: new commitfest transition guidance

David G. Johnston <david.g.johnston@gmail.com> — 2025-02-19T16:27:13Z

On Wed, Feb 19, 2025 at 8:30 AM Jelte Fennema-Nio <postgres@jeltef.nl>
wrote:

> On Wed, 19 Feb 2025 at 16:02, Daniel Gustafsson <daniel@yesql.se> wrote:
> > The opposite, which was discussed at length at FOSDEM, was to ask
> authors to
> > click a single button once a month at most.  If that level of engagement
> is too
> > much to ask then maybe said authors should question why they in return
> ask
> > others to spend hours reviewing?
>
> Moving stuff to the next commitfest is incredibly painful at the
> moment. It currently takes 4 clicks per patch to move it to the next
> commitfest. We could probably get this to 1 per patch with some UX
> redesign. But that still means that if you have 10 patches on the
> commitfest, then you have to click 10 times. It seems kind of silly to
> have to do that for a patch for which you sent an email to the thread
> last week.
>

It seems like a less obnoxious version of squeaky mouse gets the cheese -
which is reality.  One or Four clicks isn't a big difference, IMO, and 10
for a person seems like an over-estimate (they are likely to stop
contributing out of frustration long before they post that many).
Establishing a new expectation that one tracks their patches if they don't
get immediately committed and the author at least still deems them
worthwhile even if no one is commenting, let alone reviewing.

I do agree we need to make it clear to authors that we are no longer moving
their commitfest entries for them.  This thread isn't that, even if it
worked for someone like me.

David J.

Re: new commitfest transition guidance

Robert Haas <robertmhaas@gmail.com> — 2025-02-19T16:32:34Z

On Wed, Feb 19, 2025 at 10:30 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> Moving stuff to the next commitfest is incredibly painful at the
> moment. It currently takes 4 clicks per patch to move it to the next
> commitfest. We could probably get this to 1 per patch with some UX
> redesign. But that still means that if you have 10 patches on the
> commitfest, then you have to click 10 times. It seems kind of silly to
> have to do that for a patch for which you sent an email to the thread
> last week.

I respectfully but firmly question your definition of "incredibly
painful". What *I* think is incredibly painful is that I can spend an
hour going through the CommitFest and not find a single patch that
needs a review. And it's not just me. I have heard of multiple cases
of people wanting to get involved in patch reviewing and being unable
to find anything that seemed like a good candidate. We are literally
driving people out of our development community by having a CF app
that is totally unusable. The first priority here, at least IMHO,
should be improving the signal to noise ratio to something bearable.
If we can fix that - even partially - by making someone with ten
patches in the CommitFest -- who is thus, most likely, hoping for
something *at least* 50 to 100 hours of someone else's review time --
have to click 40 times once every two months, that is well worth it.

I am not saying that is the best possible experience for the
developer. I wish we could keep up on top of all the patch submissions
much better than we do. But insisting that we have to keep track of
the ones that maybe nobody cares about any more on top of the ones
that somebody definitely still does care about is not helping.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Re: new commitfest transition guidance

Maciek Sakrejda <maciek@pganalyze.com> — 2025-02-19T18:01:02Z

On Wed, Feb 19, 2025 at 8:32 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I respectfully but firmly question your definition of "incredibly
> painful". What *I* think is incredibly painful is that I can spend an
> hour going through the CommitFest and not find a single patch that
> needs a review. And it's not just me. I have heard of multiple cases
> of people wanting to get involved in patch reviewing and being unable
> to find anything that seemed like a good candidate. We are literally
> driving people out of our development community by having a CF app
> that is totally unusable.

Big +1. I'm not sure if forcing patch submitters to click more will
fix this, but it's sad how one of the biggest bottlenecks in Postgres
seems to be lack of patch review while the patch review process is so
baroque and unwelcoming.

Re: new commitfest transition guidance

Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-02-19T18:03:40Z

On Wed, 19 Feb 2025 at 17:32, Robert Haas <robertmhaas@gmail.com> wrote:
> What *I* think is incredibly painful is that I can spend an
> hour going through the CommitFest and not find a single patch that
> needs a review. And it's not just me.I have heard of multiple cases
> of people wanting to get involved in patch reviewing and being unable
> to find anything that seemed like a good candidate. We are literally
> driving people out of our development community by having a CF app
> that is totally unusable.

Agreed. For that reason, I've stopped using it for that purpose
completely. And I'm mostly using my inbox for that now. That's also
why I recently added the ability to sort by patch size and the cfbot
status, because those seemed like good indicators to find patches that
I could review with the limited time I have available for that.
Another thing that's high on my list is allowing labeling of entries.
So people can add labels like "dev tooling"/"docs only"/"poc" to make
it clearer for reviewers what to expect. If people have other/better
ideas for commitfest app changes to find patches of interest for them
in the current pile, I'm all ears.

> The first priority here, at least IMHO,
> should be improving the signal to noise ratio to something bearable.
> If we can fix that - even partially - by making someone with ten
> patches in the CommitFest -- who is thus, most likely, hoping for
> something *at least* 50 to 100 hours of someone else's review time --
> have to click 40 times once every two months, that is well worth it.

I'm very skeptical that it will actually meaningfully address the
problem you're describing. Especially given the results of the current
"no notice trial" that was attempted this time. The people that
figured out that they had to do move patches manually, moved 170
patches to the next commitfest while only closing 5 explicitly. There
are currently 84 patches "undecided" and a lot of those are by active
committers/contributors, so I'm very doubtful that with good
communication we would have trimmed more than 40 patches from the
commitfest. And while 40 patches is a decent amount, I don't think we
could expect similar results the following commitfest, due to most of
the dead patches already being trimmed the time before.

> I am not saying that is the best possible experience for the
> developer. I wish we could keep up on top of all the patch submissions
> much better than we do. But insisting that we have to keep track of
> the ones that maybe nobody cares about any more on top of the ones
> that somebody definitely still does care about is not helping.

I think we agree here. I mainly think that having everyone do that
*clearly care about*, is a waste of everyone's time and is going to
make quite a few people pretty annoyed with this process.

So to summarize my opinion:
Requiring manually moving inactive patches: worth trying
Requiring manually moving clearly active patches: stupid busywork

Re: new commitfest transition guidance

Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-02-19T22:18:36Z

On Wed, 19 Feb 2025 at 17:24, Daniel Gustafsson <daniel@yesql.se> wrote:
> There is functionality in the CF app to send an email to authors with a patch
> still in the previous commitfest, it would be quite trivial to alert everyone.
>
> We should of course also add some form of messaging in the app itself to make
> it known that patches need to be moved etc.

Could someone that has sent emails through the commitfest app like
that before send one telling people to move their patches? I would do
it myself but I'm pretty sure that my DKIM/SPF settings are not set up
to allow the following:

> Please ensure that the email settings for your domain (DKIM, SPF) allow emails from external sources.

Looking at the unmoved patches, I'm pretty sure we'd like to have a
bunch of those moved to the March commitfest.

Re: new commitfest transition guidance

Andrew Dunstan <andrew@dunslane.net> — 2025-02-19T22:33:27Z

On 2025-02-19 We 1:03 PM, Jelte Fennema-Nio wrote:
> On Wed, 19 Feb 2025 at 17:32, Robert Haas<robertmhaas@gmail.com> wrote:
>> What *I* think is incredibly painful is that I can spend an
>> hour going through the CommitFest and not find a single patch that
>> needs a review. And it's not just me.I have heard of multiple cases
>> of people wanting to get involved in patch reviewing and being unable
>> to find anything that seemed like a good candidate. We are literally
>> driving people out of our development community by having a CF app
>> that is totally unusable.
> Agreed. For that reason, I've stopped using it for that purpose
> completely. And I'm mostly using my inbox for that now. That's also
> why I recently added the ability to sort by patch size and the cfbot
> status, because those seemed like good indicators to find patches that
> I could review with the limited time I have available for that.
> Another thing that's high on my list is allowing labeling of entries.
> So people can add labels like "dev tooling"/"docs only"/"poc" to make
> it clearer for reviewers what to expect. If people have other/better
> ideas for commitfest app changes to find patches of interest for them
> in the current pile, I'm all ears.
>
>> The first priority here, at least IMHO,
>> should be improving the signal to noise ratio to something bearable.
>> If we can fix that - even partially - by making someone with ten
>> patches in the CommitFest -- who is thus, most likely, hoping for
>> something *at least* 50 to 100 hours of someone else's review time --
>> have to click 40 times once every two months, that is well worth it.
> I'm very skeptical that it will actually meaningfully address the
> problem you're describing. Especially given the results of the current
> "no notice trial" that was attempted this time. The people that
> figured out that they had to do move patches manually, moved 170
> patches to the next commitfest while only closing 5 explicitly. There
> are currently 84 patches "undecided" and a lot of those are by active
> committers/contributors, so I'm very doubtful that with good
> communication we would have trimmed more than 40 patches from the
> commitfest. And while 40 patches is a decent amount, I don't think we
> could expect similar results the following commitfest, due to most of
> the dead patches already being trimmed the time before.
>
>> I am not saying that is the best possible experience for the
>> developer. I wish we could keep up on top of all the patch submissions
>> much better than we do. But insisting that we have to keep track of
>> the ones that maybe nobody cares about any more on top of the ones
>> that somebody definitely still does care about is not helping.
> I think we agree here. I mainly think that having everyone do that
> *clearly care about*, is a waste of everyone's time and is going to
> make quite a few people pretty annoyed with this process.
>
> So to summarize my opinion:
> Requiring manually moving inactive patches: worth trying
> Requiring manually moving clearly active patches: stupid busywork


I doubt too may will get very annoyed. So (following Tom's suggestion) 
once every couple of months you get an email that says "Hi, the 
following patches of yours were left over at the end of the CF just 
ended. If you want them to continue being considered, please move them 
to the next CF. Click Here"

Maybe that's stupid busywork, but it's kinda trivial.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

Re: new commitfest transition guidance

Daniel Gustafsson <daniel@yesql.se> — 2025-02-19T22:42:51Z

> On 19 Feb 2025, at 23:18, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> 
> On Wed, 19 Feb 2025 at 17:24, Daniel Gustafsson <daniel@yesql.se> wrote:
>> There is functionality in the CF app to send an email to authors with a patch
>> still in the previous commitfest, it would be quite trivial to alert everyone.
>> 
>> We should of course also add some form of messaging in the app itself to make
>> it known that patches need to be moved etc.
> 
> Could someone that has sent emails through the commitfest app like
> that before send one telling people to move their patches? I would do
> it myself but I'm pretty sure that my DKIM/SPF settings are not set up
> to allow the following:
> 
>> Please ensure that the email settings for your domain (DKIM, SPF) allow emails from external sources.

I'll take a stab at it tomorrow.

--
Daniel Gustafsson

Re: new commitfest transition guidance

Magnus Hagander <magnus@hagander.net> — 2025-02-19T22:44:13Z

On Wed, Feb 19, 2025 at 11:19 PM Jelte Fennema-Nio <postgres@jeltef.nl>
wrote:

> On Wed, 19 Feb 2025 at 17:24, Daniel Gustafsson <daniel@yesql.se> wrote:
> > There is functionality in the CF app to send an email to authors with a
> patch
> > still in the previous commitfest, it would be quite trivial to alert
> everyone.
> >
> > We should of course also add some form of messaging in the app itself to
> make
> > it known that patches need to be moved etc.
>
> Could someone that has sent emails through the commitfest app like
> that before send one telling people to move their patches? I would do
> it myself but I'm pretty sure that my DKIM/SPF settings are not set up
> to allow the following:
>

Ugh. I had allowed myself to forget about that one :/ We really need to fix
that thing so it uses a noreply to send from. But that will of course not
be done in time for *this* round...

One thing that should work is to send it from an account with the actual
postgresql.org domain on it.  If we have a bike-shedded text ready I can
look at sending it out tomorrow.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

Re: new commitfest transition guidance

Daniel Gustafsson <daniel@yesql.se> — 2025-02-19T22:55:05Z

> On 19 Feb 2025, at 23:44, Magnus Hagander <magnus@hagander.net> wrote:

> One thing that should work is to send it from an account with the actual postgresql.org domain on it.

I've just confirmed that this works, so we have a way forward on this.

--
Daniel Gustafsson

Re: new commitfest transition guidance

Michael Paquier <michael@paquier.xyz> — 2025-02-27T05:16:55Z

On Mon, Feb 03, 2025 at 12:22:52PM +0100, Peter Eisentraut wrote:
> CF 2025-01 has just ended, so I suggest that everyone try this now.  We can
> check in perhaps two weeks whether this results in lots of stuff falling
> through the cracks or still too much stuff with unclear status being moved
> forward, and then see what that might mean going forward.

CF 2025-03 is to begin in more or less 48 hours, and we have still a
grand total of 72 patches still listed in CF 2025-01:
https://commitfest.postgresql.org/51/

It's a good score, as 286 patches have been moved without doing any
kind of massive bulky and manual vacuum work on all these entries.

As these have not been moved by their respective authors and/or
reviewers, perhaps, based on the guidance I am reading from this
thread, it would be time to give up on these rather than move them
around?
--
Michael

Re: new commitfest transition guidance

Andrew Dunstan <andrew@dunslane.net> — 2025-02-27T12:27:24Z

On 2025-02-27 Th 12:16 AM, Michael Paquier wrote:
> On Mon, Feb 03, 2025 at 12:22:52PM +0100, Peter Eisentraut wrote:
>> CF 2025-01 has just ended, so I suggest that everyone try this now.  We can
>> check in perhaps two weeks whether this results in lots of stuff falling
>> through the cracks or still too much stuff with unclear status being moved
>> forward, and then see what that might mean going forward.
> CF 2025-03 is to begin in more or less 48 hours, and we have still a
> grand total of 72 patches still listed in CF 2025-01:
> https://commitfest.postgresql.org/51/
>
> It's a good score, as 286 patches have been moved without doing any
> kind of massive bulky and manual vacuum work on all these entries.
>
> As these have not been moved by their respective authors and/or
> reviewers, perhaps, based on the guidance I am reading from this
> thread, it would be time to give up on these rather than move them
> around?



There are 4 marked "Ready For Committer" - all authored by committers :-)

Maybe the message isn't getting through, After I got the email message, 
I moved one yesterday that I am listed on as an author although I'm not 
really, but the real author had not moved.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Re: new commitfest transition guidance

Robert Haas <robertmhaas@gmail.com> — 2025-02-27T16:07:14Z

On Thu, Feb 27, 2025 at 12:17 AM Michael Paquier <michael@paquier.xyz> wrote:
> CF 2025-03 is to begin in more or less 48 hours, and we have still a
> grand total of 72 patches still listed in CF 2025-01:
> https://commitfest.postgresql.org/51/
>
> It's a good score, as 286 patches have been moved without doing any
> kind of massive bulky and manual vacuum work on all these entries.
>
> As these have not been moved by their respective authors and/or
> reviewers, perhaps, based on the guidance I am reading from this
> thread, it would be time to give up on these rather than move them
> around?

I mean, for now, yes. The authors may show up later and move them and
that's fine, we can consider them when they're actually moved. It
doesn't have to be that those patches are 100% dead, never to be
considered again.

But let's not make the mistake of saying "we're not going to move
things automatically because we want to find out if the authors are
still interested" and then getting really concerned when some stuff
doesn't get moved. That's missing the whole point.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Re: new commitfest transition guidance

Tom Lane <tgl@sss.pgh.pa.us> — 2025-02-27T16:14:45Z

Robert Haas <robertmhaas@gmail.com> writes:
> But let's not make the mistake of saying "we're not going to move
> things automatically because we want to find out if the authors are
> still interested" and then getting really concerned when some stuff
> doesn't get moved. That's missing the whole point.

+1.  Having a significant fraction of patches drop off the radar
was the desired outcome, wasn't it?

			regards, tom lane

Re: new commitfest transition guidance

Robert Haas <robertmhaas@gmail.com> — 2025-02-27T17:03:48Z

On Thu, Feb 27, 2025 at 11:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > But let's not make the mistake of saying "we're not going to move
> > things automatically because we want to find out if the authors are
> > still interested" and then getting really concerned when some stuff
> > doesn't get moved. That's missing the whole point.
>
> +1.  Having a significant fraction of patches drop off the radar
> was the desired outcome, wasn't it?

Well, not if the authors really are still actively caring about them.
But there's been a funny evolution of our thinking about CommitFests
over the years. When I first started managing CommitFests, I evicted
patches that the author didn't update -- following a review -- within
four days. Not four business days - four calendar days. After all, it
was a CommitFest -- it was supposed to be for patches that were ready
to be committed. That policy was, I think, viewed by many as too
draconian, and it probably was. But now we've gotten to a point where
the one month gap between CommitFest N and CommitFest N+1 is thought
to be so short that it might be unreasonable to expect a patch author
to move their patch forward sometime during that time. And I think
that's clearly going too far the other way.

Perhaps even way, way too far the other way. I think it's completely
fine if somebody has a patch that they update occasionally as they
have and it putters along for a few years and it finally either gets
committed or it doesn't. I one hundred percent support part-time
developers having the opportunity to participate as and when their
schedule permits and I think that is an important part of being a good
and welcoming open source community. But there are also people who are
working very hard and very actively to progress patches and staying on
top of the CF status and any new review emails every day, and that is
ALSO a great way to do development, and it's reasonable to treat those
cases differently. I'm not sure exactly how we can best do that, but
it makes my head hurt every time I find something in the CF where the
patch author was like "well, I'll get back to this at some point" and
then three CFs later it's still sitting there in "Needs Review" or
something.

Probably not moving things forward automatically is only one part of
that problem -- we could very much use some better tooling for judging
how active certain patches are and, if not so active, whether that's
more a lack of reviewers or more author inactivity. But we're not
doing ourselves any favors by working super-hard to keep everything
that anybody might potentially care about in the same bucket as things
that are actually active.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Re: new commitfest transition guidance

jian he <jian.universality@gmail.com> — 2025-03-04T14:10:14Z

On Tue, Feb 4, 2025 at 2:39 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 4 Feb 2025, at 06:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Peter Eisentraut <peter@eisentraut.org> writes:
> >> During the developer meeting at FOSDEM last Thursday,
> >
> > BTW, are there minutes available from that meeting?  In past years
> > some notes have been posted on the wiki, but I'm failing to find
> > anything right now.
>
> They will be on the wiki shortly, I've taken notes of all discussions and am
> busy tidying them up to be able to publish them once the participants have
> proofread to ensure noone is misattributed.
>

hi.
i can only found 2024 version.
https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2024_Developer_Meeting#FOSDEM_2024_Developer_Meeting_schedule_by_Time_and_Room

google:
site: https://wiki.postgresql.org/wiki  PGDay 2025 fosdem
didn't have any interesting results.

Re: new commitfest transition guidance

Daniel Gustafsson <daniel@yesql.se> — 2025-03-05T17:00:00Z

> On 4 Mar 2025, at 15:10, jian he <jian.universality@gmail.com> wrote:
> On Tue, Feb 4, 2025 at 2:39 PM Daniel Gustafsson <daniel@yesql.se> wrote:

>> They will be on the wiki shortly, I've taken notes of all discussions and am
>> busy tidying them up to be able to publish them once the participants have
>> proofread to ensure noone is misattributed.
> 
> hi.
> i can only found 2024 version.
> https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2024_Developer_Meeting#FOSDEM_2024_Developer_Meeting_schedule_by_Time_and_Room
> 
> google:
> site: https://wiki.postgresql.org/wiki  PGDay 2025 fosdem
> didn't have any interesting results.

I would avoid using Google for finding content on the wiki, the search function
on the wiki itself is generally more reliable.  Searching for FOSDEM 2025
returns the following as the top result:

    https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2025_Developer_Meeting

--
Daniel Gustafsson

Re: new commitfest transition guidance

Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-03-05T18:32:35Z

On 2025-Mar-05, Daniel Gustafsson wrote:

> I would avoid using Google for finding content on the wiki, the search function
> on the wiki itself is generally more reliable.  Searching for FOSDEM 2025
> returns the following as the top result:
> 
>     https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2025_Developer_Meeting

The category system in the wiki is very useful for this kind of thing.

https://wiki.postgresql.org/wiki/Category:Developer_Meeting

I encourage everybody to tag the pages they create with one or more
category tags.  In this case, it means adding this at the bottom of the
page:

[[Category:Developer_Meeting]]

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

Re: new commitfest transition guidance

Daniel Gustafsson <daniel@yesql.se> — 2025-03-06T07:53:53Z

> On 5 Mar 2025, at 19:32, Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> On 2025-Mar-05, Daniel Gustafsson wrote:
> 
>> I would avoid using Google for finding content on the wiki, the search function
>> on the wiki itself is generally more reliable.  Searching for FOSDEM 2025
>> returns the following as the top result:
>> 
>>    https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2025_Developer_Meeting
> 
> The category system in the wiki is very useful for this kind of thing.
> 
> https://wiki.postgresql.org/wiki/Category:Developer_Meeting
> 
> I encourage everybody to tag the pages they create with one or more
> category tags.  In this case, it means adding this at the bottom of the
> page:
> 
> [[Category:Developer_Meeting]]

Very good point, and a belated thank you for tagging this page with the right
category which I had failed to do.

--
Daniel Gustafsson

Re: new commitfest transition guidance

jian he <jian.universality@gmail.com> — 2025-03-06T14:01:32Z

hi.

It seems we don't have much info about "Patch Triage" in 2025.

but 2023, 2024 we do have.
like:
https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2024_Developer_Meeting#v17_Patch_Triage
and
https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2023_Developer_Meeting#v16_Patch_Triage

Re: new commitfest transition guidance

Peter Geoghegan <pg@bowt.ie> — 2025-12-02T00:16:31Z

On Wed, Feb 5, 2025 at 7:14 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Evidently this new policy is why my skip scan patch series wasn't
> being tested by CI.

It happened again, this time with the index prefetching patch that
Tomas and I are working on.

I checked the CF app entry, but didn't notice that the entry wasn't in
the current CF. It was in 2025-11-01 – 2025-11-30, but technically
when I posted the patch that was already over (not in my time zone, in
UTC). Technically I hadn't submitted the patch to the next open commit
fest yet, and yet there is no real indication that that's a problem on
the CF page.

I thought it was a bug in the CF app, and then complained about it on
Discord. Then Jelte wasted a couple of hours of his own time on this,
before he finally noticed that the patch just wasn't in a CF anymore.
Of course, there was no email about this, no notification -- nothing.

At a minimum, there needs to be better tooling for this -- it's just
too easy for something to fall through the cracks. But what I really
think we should do is simply end with this misguided policy. I
personally had no say in it. I didn't go to the FOSDEM developer
meeting. The first I heard about all this on this thread.

-- 
Peter Geoghegan

Re: new commitfest transition guidance

Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-02T01:28:20Z

Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Feb 5, 2025 at 7:14 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> Evidently this new policy is why my skip scan patch series wasn't
>> being tested by CI.

> It happened again, this time with the index prefetching patch that
> Tomas and I are working on.
> ...
> I thought it was a bug in the CF app, and then complained about it on
> Discord. Then Jelte wasted a couple of hours of his own time on this,
> before he finally noticed that the patch just wasn't in a CF anymore.
> Of course, there was no email about this, no notification -- nothing.

Well, if you check your commitfest dashboard [1] you'll see all
such patches listed under

"Your still open patches in a closed commitfest (you should move or
close these)"

or at least that's what I'm seeing for mine, and I'll go take that
advice momentarily.  But I agree that some more-active prodding would
be a good idea.  If we send an email nag for your-patch-needs-rebased,
I don't understand why there's not one for your-patch-just-dropped-
off-the-radar-and-you-need-to-fix-that.

			regards, tom lane

[1] https://commitfest.postgresql.org/?author=-3

Re: new commitfest transition guidance

Peter Geoghegan <pg@bowt.ie> — 2025-12-02T01:51:39Z

On Mon, Dec 1, 2025 at 8:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, if you check your commitfest dashboard [1] you'll see all
> such patches listed under
>
> "Your still open patches in a closed commitfest (you should move or
> close these)"

I did notice that, once Jelte figured out the problem. I wasn't
initially logged in, though. More importantly, I effectively saw
nothing about the problem on the CF entry for the patch in question
(besides, I might have never have thought to look at the dashboard had
I been logged in).

Clearly, if somebody is looking at the CF entry for a patch, they
should always see a prominent "patch needs to be resubmitted" notice
when the patch happens to be in that state. Something right at the
top, that's really hard to miss. It shouldn't matter if they're logged
in or not -- it's very basic information.

Theoretically I could have inferred all this by scrolling down and
noticing that the dozen or so CFs that this patch was submitted to
*doesn't* include the next CF, but evidently that just doesn't work
very well.

> But I agree that some more-active prodding would
> be a good idea.  If we send an email nag for your-patch-needs-rebased,
> I don't understand why there's not one for your-patch-just-dropped-
> off-the-radar-and-you-need-to-fix-that.

Right, that seems like the bare minimum.

-- 
Peter Geoghegan