Thread: new commitfest transition guidance
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.
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
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
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
> 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
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
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
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
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
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
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
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?
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
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.
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
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
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
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
> 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
> 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
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
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
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
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.
> 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
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.
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
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.
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
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.
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
> 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
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.
> 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
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
Attachment
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
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
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
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
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.
> 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
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/
> 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
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