Re: commitfest.postgresql.org is no longer fit for purpose

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: commitfest.postgresql.org is no longer fit for purpose
Дата
Msg-id CAKFQuwb2+X=ZCrgVseUosWiVBH7Nk0e-+mpPjAiXr9qUy=UXYw@mail.gmail.com
обсуждение исходный текст
Ответ на commitfest.postgresql.org is no longer fit for purpose  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: commitfest.postgresql.org is no longer fit for purpose  (Jacob Champion <jacob.champion@enterprisedb.com>)
Список pgsql-hackers
On Thu, May 16, 2024 at 11:30 AM Robert Haas <robertmhaas@gmail.com> wrote:
Hi,

The original intent of CommitFests, and of commitfest.postgresql.org
by extension, was to provide a place where patches could be registered
to indicate that they needed to be reviewed, thus enabling patch
authors and patch reviewers to find each other in a reasonably
efficient way. I don't think it's working any more. I spent a good
deal of time going through the CommitFest this week, and I didn't get
through a very large percentage of it, and what I found is that the
status of the patches registered there is often much messier than can
be captured by a simple "Needs Review" or "Waiting on Author," and the
number of patches that are actually in need of review is not all that
large. For example, there are:

- patches parked there by a committer who will almost certainly do
something about them after we branch
- patches parked there by a committer who probably won't do something
about them after we branch, but maybe they will, or maybe somebody
else will, and anyway this way we at least run CI
- patches parked there by a committer who may well do something about
them before we even branch, because they're not actually subject to
the feature freeze

If a committer has a patch in the CF that is going to be committed in the future unless there is outside action those should be put under a "Pending Commit" status.

- patches that we've said we don't want but the author thinks we do
(sometimes i agree with the author, sometimes not)
- patches that have long-unresolved difficulties which the author
either doesn't know how to solve or is in no hurry to solve
- patches that have already been reviewed by multiple people, often
including several committers, and which have been updated multiple
times, but for one reason or another, not committed

Use the same software but a different endpoint - Collaboration.  Or even the same endpoint just add an always open slot named "Work In Process" (WIP).  If items can be moved from there to another open or future commitfest slot so much the better.

- patches that actually do need to be reviewed

If we can distinguish between needs to be reviewed by a committer (commitfest dated slots - bimonthlies) and reviewed by someone other than the author (work in process slot) that should help everyone.  Of course, anyone is welcome to review a patch that has been marked ready to commit.  I suppose "ready to commit" already sorta does this without the need for WIP but a quick sanity check would be that ready to commit shouldn't (not mustn't) be seen in WIP and needs review shouldn't be seen in the bimonthlies.  A needs review in WIP means that the patch has been seen by a committer and sent back for more work but that the scope and intent are such that it will make it into the upcoming major release.  Or is something like a bug fix that just goes right into the bimonthly instead of starting out as a WIP item.


I think there are a couple of things that have led to this state of
affairs. First, we got tired of making people mad by booting their
stuff out of the CommitFest, so we mostly just stopped doing it, even
if it had 0% chance of being committed this CommitFest, and really
even if it had a 0% chance of being committed ever.

Those likely never get out of the new WIP slot discussed above.  Your patch tracker basically.  And there should be less angst in moving something in the bimonthly into WIP rather than dropping it outright.  There is discussion to be had regarding WIP/patch tracking should we go this direction but even if it is just movIng clutter from one room to another there seems like a clear benefit and need to tighten up what it means to be in the bimonthly slot - to have qualifications laid out for a patch to earn its way there, either by effort (authored and reviewed) or need (i.e., bug fixes), or, realistically, being authored by a committer and being mostly trivial in nature.
 
Second, we added
CI, which means that there is positive value to registering the patch
in the CommitFest even if committing it is not in the cards.

The new slot retains this benefit.

And those
things together have created a third problem, which is that the list
is now so long and so messy that even the CommitFest managers probably
don't manage to go through the whole thing thoroughly in a month.

The new slot wouldn't be subject to this.

We'll still have a problem with too many WIP patches and not enough ability or desire to resolve them.  But setting a higher bar to get onto the bimonthly slot while still providing a place for collaboration is a step forward that configuring technology can help with.  As for WIP, maybe adding thumbs-up and thumbs-down support tracking widgets will help draw attention to more desired things.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: commitfest.postgresql.org is no longer fit for purpose
Следующее
От: Maciek Sakrejda
Дата:
Сообщение: Re: commitfest.postgresql.org is no longer fit for purpose