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
<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]/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
