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