Thread: 2021-09 Commitfest
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. -- Daniel Gustafsson https://vmware.com/ [0] https://postgr.es/m/20210826231608.GA7242@ahch-to
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
Attachment
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] 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] https://postgr.es/m/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] https://postgr.es/m/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
Attachment
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 <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] https://postgr.es/m/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] https://postgr.es/m/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] https://postgr.es/m/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
> 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? -- 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.
> 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...
> 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 suchcases, 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/