2021-09 Commitfest

On Wed, Sep 01, 2021 at 03:10:32PM +0200, Daniel Gustafsson wrote:

It is now 2021-09-01 Anywhere On Earth so I’ve set the September commitfest to
In Progress and opened the November one for new entries. Jaime Casanova has
volunteered for CFM [0], so let’s help him close the 284 still open items in
the queue.

Thank you Daniel for editing the commitfest entries, that's something I
cannot do.

And you're right, we have 284 patches in the queue (excluding committed,
returned with feedback, withdrawn and rejected)... 18 of them for more than
10 commitfests!

Needs review: 192.
Waiting on Author: 68.
Ready for Committer: 24

If you have a patch in this commitfest, please check in
http://commitfest.cputube.org/ if your patch still applies and passes
tests.

Thanks to all of you for your great work!

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

On Wed, Sep 1, 2021 at 4:26 PM Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:

On Wed, Sep 01, 2021 at 03:10:32PM +0200, Daniel Gustafsson wrote:

It is now 2021-09-01 Anywhere On Earth so I’ve set the September commitfest to
In Progress and opened the November one for new entries. Jaime Casanova has
volunteered for CFM [0], so let’s help him close the 284 still open items in
the queue.

Thank you Daniel for editing the commitfest entries, that's something I
cannot do.

I've added cf admin permissions to you as well now.

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

On Wed, Sep 01, 2021 at 06:32:38PM +0200, Magnus Hagander wrote:

On Wed, Sep 1, 2021 at 4:26 PM Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:

On Wed, Sep 01, 2021 at 03:10:32PM +0200, Daniel Gustafsson wrote:

It is now 2021-09-01 Anywhere On Earth so I’ve set the September commitfest to
In Progress and opened the November one for new entries. Jaime Casanova has
volunteered for CFM [0], so let’s help him close the 284 still open items in
the queue.

Thank you Daniel for editing the commitfest entries, that's something I
cannot do.

I've added cf admin permissions to you as well now.

I have the power! mwahahaha!
eh! i mean, thanks Magnus ;)

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

On Wed, Sep 01, 2021 at 09:26:33AM -0500, Jaime Casanova wrote:

On Wed, Sep 01, 2021 at 03:10:32PM +0200, Daniel Gustafsson wrote:

It is now 2021-09-01 Anywhere On Earth so I’ve set the September commitfest to
In Progress and opened the November one for new entries. Jaime Casanova has
volunteered for CFM [0], so let’s help him close the 284 still open items in
the queue.

Thank you Daniel for editing the commitfest entries, that's something I
cannot do.

And you're right, we have 284 patches in the queue (excluding committed,
returned with feedback, withdrawn and rejected)... 18 of them for more than
10 commitfests!

Needs review: 192.
Waiting on Author: 68.
Ready for Committer: 24

Hi everyone,

On the first 10 days of this commitfest some numbers have moved, mostly
thanks to Daniel Gustafsson and good work from committers:

Needs review: 171.
Waiting on Author: 79.
Ready for Committer: 15.

How could we advance on the "needs review" queue? It's just too long!

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

Hi Jaime,

Needs review: 171.
Waiting on Author: 79.
Ready for Committer: 15.

How could we advance on the "needs review" queue? It's just too long!

For the record, some patches marked as "Needs review" are in fact
rotted and need to be rebased http://cfbot.cputube.org/ I notified
several authors and changed the status to "Waiting for Author", but
somehow I don't feel comfortable doing it for 40+ patches at once...
Also, I recall that in the past the fact that the patch doesn't pass
CI was not considered enough not to review it.

--
Best regards,
Aleksander Alekseev

On Sat, Sep 11, 2021 at 12:52:10AM -0500, Jaime Casanova wrote:

On Wed, Sep 01, 2021 at 09:26:33AM -0500, Jaime Casanova wrote:

On Wed, Sep 01, 2021 at 03:10:32PM +0200, Daniel Gustafsson wrote:

It is now 2021-09-01 Anywhere On Earth so I’ve set the September commitfest to
In Progress and opened the November one for new entries. Jaime Casanova has
volunteered for CFM [0], so let’s help him close the 284 still open items in
the queue.

Thank you Daniel for editing the commitfest entries, that's something I
cannot do.

And you're right, we have 284 patches in the queue (excluding committed,
returned with feedback, withdrawn and rejected)... 18 of them for more than
10 commitfests!

Needs review: 192.
Waiting on Author: 68.
Ready for Committer: 24

Hi everyone,

On the first 10 days of this commitfest some numbers have moved, mostly
thanks to Daniel Gustafsson and good work from committers:

Needs review: 171.
Waiting on Author: 79.
Ready for Committer: 15.

Hi,

During this commitfest there around 40 patches committed, there where
some patches already committed at the beggining.

Committed: 55.

In the last hours Michael Paquier made a scan over the patch queue and
even after that we still have a lot of patches open.

Needs review: 131.
Waiting on Author: 47.
Ready for Committer: 12.

I understand this CF was in the middle of the release of 14 and that
affected too.

Anyway we need to advance to a close, so I need help with:

- what should we do with WoA patches? moving them to the Next CF?
- How can we reduce the number of Needs Review patches? some of them
have been in silence for more than a month!

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

On Fri, Oct 01, 2021 at 08:53:23AM -0500, Jaime Casanova wrote:

Anyway we need to advance to a close, so I need help with:

- what should we do with WoA patches? moving them to the Next CF?

Correcting myself, we cannot move WoA patches. So we should just close
them with RwF.

Barring objections I will do that in the next couple of hours.

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

Jaime Casanova <jcasanov@systemguards.com.ec> writes:

Correcting myself, we cannot move WoA patches. So we should just close
them with RwF.

Uh, really? I don't think that's been common practice in the past.
I thought we generally just pushed everything forward to the next CF
with the same status.

regards, tom lane

On Fri, Oct 01, 2021 at 01:34:45PM -0400, Tom Lane wrote:

Jaime Casanova <jcasanov@systemguards.com.ec> writes:

Correcting myself, we cannot move WoA patches. So we should just close
them with RwF.

Uh, really? I don't think that's been common practice in the past.
I thought we generally just pushed everything forward to the next CF
with the same status.

Actually i thought the same thing but found that I couldn't.

Just tried again to get the error message: "A patch in status Waiting on
Author cannot be moved to next commitfest."

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

On 10/1/21 1:31 PM, Jaime Casanova wrote:

On Fri, Oct 01, 2021 at 08:53:23AM -0500, Jaime Casanova wrote:

Anyway we need to advance to a close, so I need help with:

- what should we do with WoA patches? moving them to the Next CF?

Correcting myself, we cannot move WoA patches. So we should just close
them with RwF.

Barring objections I will do that in the next couple of hours.

Isn't the usual procedure to change their status, move them, and then
change it back again? ISTR something like that when I managed a CF.

cheers

andrew

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

On Fri, Oct 01, 2021 at 01:43:23PM -0400, Andrew Dunstan wrote:

On 10/1/21 1:31 PM, Jaime Casanova wrote:

On Fri, Oct 01, 2021 at 08:53:23AM -0500, Jaime Casanova wrote:

Anyway we need to advance to a close, so I need help with:

- what should we do with WoA patches? moving them to the Next CF?

Correcting myself, we cannot move WoA patches. So we should just close
them with RwF.

Barring objections I will do that in the next couple of hours.

Isn't the usual procedure to change their status, move them, and then
change it back again? ISTR something like that when I managed a CF.

Really?! That sounds tedious!
I will do that but we should improve that process.

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

Jaime Casanova <jcasanov@systemguards.com.ec> writes:

On Fri, Oct 01, 2021 at 01:43:23PM -0400, Andrew Dunstan wrote:

Isn't the usual procedure to change their status, move them, and then
change it back again? ISTR something like that when I managed a CF.

Really?! That sounds tedious!
I will do that but we should improve that process.

Indeed, that seems pretty silly.

regards, tom lane

On 1 Oct 2021, at 19:49, Jaime Casanova <jcasanov@systemguards.com.ec> wrote:
On Fri, Oct 01, 2021 at 01:43:23PM -0400, Andrew Dunstan wrote:

Isn't the usual procedure to change their status, move them, and then
change it back again? ISTR something like that when I managed a CF.

Correct, if one looks at the activity log for an old entry the pattern of
moving to needs review, then to the next CF, then WoA is clearly visible.

Really?!

Sadly yes.

That sounds tedious!

Correct.

I will do that but we should improve that process.

Correct again.

--
Daniel Gustafsson https://vmware.com/

On Fri, Oct 01, 2021 at 08:29:08PM +0200, Daniel Gustafsson wrote:

Correct, if one looks at the activity log for an old entry the pattern of
moving to needs review, then to the next CF, then WoA is clearly visible.

That's the tricky part. It does not really make sense either to keep
moving patches that are waiting on author for months. The scan of the
CF app I have done was about those idle patches waiting on author for
months. It takes time as authors and/or reviewers tend to sometimes
not update the status of a patch so the state in the app does not
reflect the reality, but this vacuuming limits the noise in for the
next CFs.

That sounds tedious!

Correct.

It consumes power.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

That's the tricky part. It does not really make sense either to keep
moving patches that are waiting on author for months. The scan of the
CF app I have done was about those idle patches waiting on author for
months. It takes time as authors and/or reviewers tend to sometimes
not update the status of a patch so the state in the app does not
reflect the reality, but this vacuuming limits the noise in for the
next CFs.

Yeah. I have been thinking of looking through the oldest CF entries
and proposing that we just reject any that look permanently stalled.
It doesn't do much good to leave things in the list when there's
no apparent interest in pushing them to conclusion. But I've not
done the legwork yet, and I'm a little worried about the push-back
that will inevitably result.

regards, tom lane

On 2021-Oct-01, Daniel Gustafsson wrote:

On 1 Oct 2021, at 19:49, Jaime Casanova <jcasanov@systemguards.com.ec> wrote:

I will do that but we should improve that process.

Correct again.

I think if we all agree that this is a desired workflow, then we should
update the app to allow WoA patches to be moved to next CF.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)

On 2021-Oct-02, Tom Lane wrote:

Yeah. I have been thinking of looking through the oldest CF entries
and proposing that we just reject any that look permanently stalled.
It doesn't do much good to leave things in the list when there's
no apparent interest in pushing them to conclusion. But I've not
done the legwork yet, and I'm a little worried about the push-back
that will inevitably result.

I was just going to say the same thing yesterday, and reference [1]/messages/by-id/20190930182818.GA25331@alvherre.pgsql
when I did it once in 2019. I think it was a useful cleanup exercise.
In hindsight, some of these patches were resubmitted later, and those
are either still ongoing or are already committed.
[1]: /messages/by-id/20190930182818.GA25331@alvherre.pgsql

(I did have the luxury of a local copy of the commitfest database, which
is perhaps a service we could offer to CFMs to make their lives easier.)

--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"Digital and video cameras have this adjustment and film cameras don't for the
same reason dogs and cats lick themselves: because they can." (Ken Rockwell)

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I think if we all agree that this is a desired workflow, then we should
update the app to allow WoA patches to be moved to next CF.

I'm fairly astonished that anyone would have thought that that
*wasn't* an expected case. For example, if someone reviews a
patch and sets the status to WoA on the last day of the CF,
what then? You can't expect the patch author to respond
instantaneously.

regards, tom lane

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

On 2021-Oct-02, Tom Lane wrote:

Yeah. I have been thinking of looking through the oldest CF entries
and proposing that we just reject any that look permanently stalled.

I was just going to say the same thing yesterday, and reference [1]
when I did it once in 2019. I think it was a useful cleanup exercise.
[1] /messages/by-id/20190930182818.GA25331@alvherre.pgsql

Right. Michael and Jaime have been doing some of that too in the last
few days, but obviously a CFM should only do that unilaterally in very
clear-cut cases of patch abandonment. I was intending to go after some
where maybe a bit of community consensus is needed for rejection.

regards, tom lane

On 2 Oct 2021, at 17:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

I think if we all agree that this is a desired workflow, then we should
update the app to allow WoA patches to be moved to next CF.

I'm fairly astonished that anyone would have thought that that
*wasn't* an expected case.

AFAIK this is a case of everyone agreeing and noone having had the time (or
priorities) to hack on the CF app to make it happen.

--
Daniel Gustafsson https://vmware.com/

On Sat, Oct 02, 2021 at 11:32:01AM -0400, Tom Lane wrote:

Right. Michael and Jaime have been doing some of that too in the last
few days, but obviously a CFM should only do that unilaterally in very
clear-cut cases of patch abandonment. I was intending to go after some
where maybe a bit of community consensus is needed for rejection.

One thing I have used in this process is what I'd call the two-week
rule: if a patch is listed in the CF app as waiting on author for two
weeks at the middle of the CF, and if it has stalled with the same
state by the end of the commit fest with the thread remaining idle, it
is rather safe to switch the patch as returned with feedback. I have
tried to follow this rule for the last couple of years and received
few complains when done this way. The CF patch tester has proved to
be really helpful regarding that, even if some patches have sometimes
a state in the CF app that does not reflect what the thread tells. In
short, it is important to check the state of the patches mid-CF
pinging the related threads if necessary, and at the end of the CF.
--
Michael

On Sat, Oct 2, 2021 at 7:31 AM Michael Paquier <michael@paquier.xyz> wrote:

On Fri, Oct 01, 2021 at 08:29:08PM +0200, Daniel Gustafsson wrote:

Correct, if one looks at the activity log for an old entry the pattern of
moving to needs review, then to the next CF, then WoA is clearly visible.

That's the tricky part. It does not really make sense either to keep
moving patches that are waiting on author for months. The scan of the
CF app I have done was about those idle patches waiting on author for
months. It takes time as authors and/or reviewers tend to sometimes
not update the status of a patch so the state in the app does not
reflect the reality, but this vacuuming limits the noise in for the
next CFs.

I'm pretty sure this is the original reason for adding this -- to enforce
that this review happens.

Prior to this being added, all patches moved would end up in "needs review"
status. When we changed it so that the patch would keep it's status in the
next CF, we explicitly wanted to avoid having lots of patches in WoA status
in the new CF.

But this was 5 years ago, and the feature was new at the time. This may
have been wrong already then, or it may simply be that we use the system in
a different way now (and we for example did not have the cfbot back then).
Either one of those is a good reason to re-visit the decision. And it
certainly sounds from this thread that nobody is actually arguing to keep
that behaviour -- unless that changes knowing the original reason?

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

Magnus Hagander <magnus@hagander.net> writes:

On Sat, Oct 2, 2021 at 7:31 AM Michael Paquier <michael@paquier.xyz> wrote:

That's the tricky part. It does not really make sense either to keep
moving patches that are waiting on author for months.

I'm pretty sure this is the original reason for adding this -- to enforce
that this review happens.

The CF tool is in no way able to enforce that, though. All it's doing
is making extra work for the CFM.

regards, tom lane

On Sat, Oct 02, 2021 at 11:32:01AM -0400, Tom Lane wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

On 2021-Oct-02, Tom Lane wrote:

Yeah. I have been thinking of looking through the oldest CF entries
and proposing that we just reject any that look permanently stalled.

I was just going to say the same thing yesterday, and reference [1]
when I did it once in 2019. I think it was a useful cleanup exercise.
[1] /messages/by-id/20190930182818.GA25331@alvherre.pgsql

Right. Michael and Jaime have been doing some of that too in the last
few days, but obviously a CFM should only do that unilaterally in very
clear-cut cases of patch abandonment. I was intending to go after some
where maybe a bit of community consensus is needed for rejection.

I have done so with 2 or 3 patches that has been stalled more than one
month and after asking in the thread if I receive no answer for 2 or 3
weeks.

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

On Sat, Oct 02, 2021 at 12:20:09PM -0300, Alvaro Herrera wrote:

On 2021-Oct-02, Tom Lane wrote:

Yeah. I have been thinking of looking through the oldest CF entries
and proposing that we just reject any that look permanently stalled.
It doesn't do much good to leave things in the list when there's
no apparent interest in pushing them to conclusion. But I've not
done the legwork yet, and I'm a little worried about the push-back
that will inevitably result.

I was just going to say the same thing yesterday, and reference [1]
when I did it once in 2019. I think it was a useful cleanup exercise.
In hindsight, some of these patches were resubmitted later, and those
are either still ongoing or are already committed.
[1] /messages/by-id/20190930182818.GA25331@alvherre.pgsql

(I did have the luxury of a local copy of the commitfest database, which
is perhaps a service we could offer to CFMs to make their lives easier.)

Right now, an option to bulk move everything in their current states to
Next CF would be handy... There are still 139 remaining patches to move.

11 of them "Ready for Committer"

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

On Sun, Oct 03, 2021 at 11:20:21AM -0500, Jaime Casanova wrote:

On Sat, Oct 02, 2021 at 11:32:01AM -0400, Tom Lane wrote:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

On 2021-Oct-02, Tom Lane wrote:

Yeah. I have been thinking of looking through the oldest CF entries
and proposing that we just reject any that look permanently stalled.

I was just going to say the same thing yesterday, and reference [1]
when I did it once in 2019. I think it was a useful cleanup exercise.
[1] /messages/by-id/20190930182818.GA25331@alvherre.pgsql

Right. Michael and Jaime have been doing some of that too in the last
few days, but obviously a CFM should only do that unilaterally in very
clear-cut cases of patch abandonment. I was intending to go after some
where maybe a bit of community consensus is needed for rejection.

I have done so with 2 or 3 patches that has been stalled more than one
month and after asking in the thread if I receive no answer for 2 or 3
weeks.

Actually it should be some kind of rule of thumb (that could be used as
guide) for doing so. Keeping around patches that has no expectation of
being worked on makes us no favor and the queue keeps growing.

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

On Sun, Oct 3, 2021 at 3:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Sat, Oct 2, 2021 at 7:31 AM Michael Paquier <michael@paquier.xyz>

wrote:

That's the tricky part. It does not really make sense either to keep
moving patches that are waiting on author for months.

I'm pretty sure this is the original reason for adding this -- to enforce
that this review happens.

The CF tool is in no way able to enforce that, though. All it's doing
is making extra work for the CFM.

I've now deployed this:
https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commitdiff;h=65073ba7614ba539aff961e59c9eddbbb8d095f9

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

On 4 Oct 2021, at 12:06, Magnus Hagander <magnus@hagander.net> wrote:

On Sun, Oct 3, 2021 at 3:48 PM Tom Lane <tgl@sss.pgh.pa.us <mailto:tgl@sss.pgh.pa.us>> wrote:
Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>> writes:

On Sat, Oct 2, 2021 at 7:31 AM Michael Paquier <michael@paquier.xyz <mailto:michael@paquier.xyz>> wrote:

That's the tricky part. It does not really make sense either to keep
moving patches that are waiting on author for months.

I'm pretty sure this is the original reason for adding this -- to enforce
that this review happens.

The CF tool is in no way able to enforce that, though. All it's doing
is making extra work for the CFM.

I've now deployed this: https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commitdiff;h=65073ba7614ba539aff961e59c9eddbbb8d095f9 <https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commitdiff;h=65073ba7614ba539aff961e59c9eddbbb8d095f9&gt;

AFAICT this should now allow for WoA patches to be moved to the next CF, but
trying that on a patch in the current CF failed with "Invalid existing patch
status" in a red topbar. Did I misunderstand what this change was?

--
Daniel Gustafsson https://vmware.com/

On Mon, Oct 4, 2021 at 2:41 PM Daniel Gustafsson <daniel@yesql.se> wrote:

On 4 Oct 2021, at 12:06, Magnus Hagander <magnus@hagander.net> wrote:

On Sun, Oct 3, 2021 at 3:48 PM Tom Lane <tgl@sss.pgh.pa.us <mailto:

tgl@sss.pgh.pa.us>> wrote:

Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>>

writes:

On Sat, Oct 2, 2021 at 7:31 AM Michael Paquier <michael@paquier.xyz

<mailto:michael@paquier.xyz>> wrote:

That's the tricky part. It does not really make sense either to keep
moving patches that are waiting on author for months.

I'm pretty sure this is the original reason for adding this -- to

enforce

that this review happens.

The CF tool is in no way able to enforce that, though. All it's doing
is making extra work for the CFM.

I've now deployed this:

https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commitdiff;h=65073ba7614ba539aff961e59c9eddbbb8d095f9
<
https://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commitdiff;h=65073ba7614ba539aff961e59c9eddbbb8d095f9

AFAICT this should now allow for WoA patches to be moved to the next CF,
but
trying that on a patch in the current CF failed with "Invalid existing
patch
status" in a red topbar. Did I misunderstand what this change was?

Ugh. i missed one of the two checks. That's what I get for not testing
properly when the change "was so simple"...

Please try again.

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

On 4 Oct 2021, at 14:56, Magnus Hagander <magnus@hagander.net> wrote:

Ugh. i missed one of the two checks. That's what I get for not testing properly when the change "was so simple"...

Please try again.

It works now, I was able to move a patch (3128) over to the 2021-11 CF. It
does bring up the below warning(?) in a blue bar when the move was performed
which at first made me think it hadn't worked.

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

--
Daniel Gustafsson https://vmware.com/

On Mon, Oct 4, 2021 at 3:05 PM Daniel Gustafsson <daniel@yesql.se> wrote:

On 4 Oct 2021, at 14:56, Magnus Hagander <magnus@hagander.net> wrote:

Ugh. i missed one of the two checks. That's what I get for not testing

properly when the change "was so simple"...

Please try again.

It works now, I was able to move a patch (3128) over to the 2021-11 CF. It
does bring up the below warning(?) in a blue bar when the move was
performed
which at first made me think it hadn't worked.

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

Did you try it with more than one patch? It could be a held back message
that got delivered late (yes, there are some such cases, sadly). I ask
because I'm failing to reproduce this one...

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

On 4 Oct 2021, at 18:51, Magnus Hagander <magnus@hagander.net> wrote:

On Mon, Oct 4, 2021 at 3:05 PM Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:

On 4 Oct 2021, at 14:56, Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>> wrote:

Ugh. i missed one of the two checks. That's what I get for not testing properly when the change "was so simple"...

Please try again.

It works now, I was able to move a patch (3128) over to the 2021-11 CF. It
does bring up the below warning(?) in a blue bar when the move was performed
which at first made me think it hadn't worked.

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

Did you try it with more than one patch? It could be a held back message that got delivered late (yes, there are some such cases, sadly). I ask because I'm failing to reproduce this one...

It was on the very same entry and I only tested that one, so it sounds likely
that it was a message that was late to the party.

--
Daniel Gustafsson https://vmware.com/