Re: commitfest.postgresql.org is no longer fit for purpose - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: commitfest.postgresql.org is no longer fit for purpose
Date
Msg-id CAKFQuwbTstwFuGTDO4ymbtccR0JCFQ8z+HOAyuN3mCSvDrC8OA@mail.gmail.com
Whole thread Raw
In response to Re: commitfest.postgresql.org is no longer fit for purpose  (Melanie Plageman <melanieplageman@gmail.com>)
List pgsql-hackers
On Thu, May 16, 2024 at 1:46 PM Melanie Plageman <melanieplageman@gmail.com> wrote:

I should probably simply
withdraw and re-register them. My justification was that I'll lose
them if I don't keep them in the commitfest app. But, I could just,
you know, save them somewhere myself instead of polluting the
commitfest app with them. I don't know if others are in this
situation. Anyway, I'm definitely currently guilty of parking.


I use a personal JIRA to track the stuff that I hope makes it into the codebase, as well as just starring the corresponding emails in the short-term.  Every patch ever submitted sits in the mailing list archive so I have no real need to preserve git branches with my submitted work on them.  At lot of my work comes down to lucky timing so I'm mostly content with just pinging my draft patches on the email thread once in a while hoping there is interest and time from someone.  For stuff that I would be OK committing as submitted I'll add it to the commitfest and wait for someone to either agree or point out where I can improve things.

Adding both these kinds to WIP appeals to me, particularly with something akin to a "Collaboration Wanted" category in addition to "Needs Review" for when I think it is ready, and "Waiting on Author" for stuff that has pending feedback to resolve - or the author isn't currently fishing for reviewer time for whatever reason.  Ideally there would be no rejections, only constructive feedback that convinces the author that, whether for now or forever, the proposed patch should be withdrawn pending some change in circumstances that suggests the world is ready for it.

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is citext/regress failing on hamerkop?
Next
From: Nathan Bossart
Date:
Subject: optimizing pg_upgrade's once-in-each-database steps