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] 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 <aleksan...@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]/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
