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 CAKFQuwbTstwFuGTDO4ymbtccR0JCFQ8z+HOAyuN3mCSvDrC8OA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: commitfest.postgresql.org is no longer fit for purpose  (Melanie Plageman <melanieplageman@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why is citext/regress failing on hamerkop?
Следующее
От: Nathan Bossart
Дата:
Сообщение: optimizing pg_upgrade's once-in-each-database steps