On Wed, Jun 6, 2018 at 12:29 AM, Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Jun 05, 2018 at 11:03:33AM -0400, Stephen Frost wrote: > Let's keep the tech side of this simple and just do the rename as > suggested and then we can encourage committers to review the > smaller/older patches by providing information about the objective size > and age of them, which will likely lead to the same result without all > the fuss over what patch should be in what commitfest.
From a technical point of view with the CF app, it is possible to move a patch to the "next" CF but it is not possible to choose to which commit fest a patch is moved. I am not sure how the CF app chooses this next CF, does it choose based on the ID number of a CF, which increases for each new creation or based on its name? Magnus would know that, my bet goes for the ID-based selection.. If my guess is right and that you create a CF with a name older than an existing entry, then the whole patch flow would be messed up. So a rename is just much more simple at the end.
The logic for what it moves it to is basically:
* If there is an open CF, move it to that one unless we are moving from that one
* If there is more than one open CF, error
* Else find the "future" commitfest, if one exists, and movei t ther
* If more than one future commitfest exists, error
* If no future commitfest exists, error.
I think it's also setting us up for all sorts of fun errors if it get bounced *again*. E.g. if you "move to next cf" from the 09 cf to the 07, but then have to "move to next cf" *again* back to 09. That would violate a unique constraint, so it wouldn't work, and I'm unsure how the system would actually react to it.
Thus, if we don't want to have to risk doing surgery on the system (or guarantee we won't bounce any patches from the 07 CF, but that seems like the wrong thing to do), we should rename the existing 09 CF to 07, so all patches automatically end up there, and stick to only "bouncing patches in the forward direction".