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
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]/messages/by-id/CAGECzQTbHhaZMY-=Y=OGMU_jik4MqCfsc7rDf6AnT=Aq-B6cZA@mail.gmail.com of the commitfest app by this commit[2]https://github.com/postgres/pgcommitfest/commit/013eeb1befa3cf3f38b7ccb7977881f2c7c0f38d.
[1]: /messages/by-id/CAGECzQTbHhaZMY-=Y=OGMU_jik4MqCfsc7rDf6AnT=Aq-B6cZA@mail.gmail.com
[2]: https://github.com/postgres/pgcommitfest/commit/013eeb1befa3cf3f38b7ccb7977881f2c7c0f38d
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.
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 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
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]https://commitfest.postgresql.org/patch/5117/ 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]https://github.com/postgres/pgcommitfest/issues/11/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
