It's not clear how this commitfest thing is supposed to work in
practice. May I suggest that:
1. When a patch author wants to have a patch reviewed in the next
commitfest, he posts it to pgsql-patches as usual, and then adds it to
the list on the Todo:PatchStatus page (or perhaps even better, a new
page per commitfest with same layout) in the wiki himself, with status
"awaiting review".
2. When a patch is outright rejected, the patch author updates the
status accordingly.
3. Many patches will not be ready for committing yet, because there's
bugs that need fixing, or it needs performance testing or whatever. If
it's a quick thing, patch author can just submit an updated patch, or
test results or whatever and continue discussion. Otherwise, after
author knows what he's going to do next, he updates the status on the
wiki accordingly. The status can be something like "will do performance
testing", "will try approach suggested by X", "will clean up comments" etc.
4. The commitfest is over when there is no more tasks on the wiki page
with status "awaiting review".
The trick here is that the patch authors drive the process. An author
will not change the status of a patch until he knows what he is going to
do next. For example, you might get feedback from one person, but if you
feel like you want another opinion, you can keep the status at "awaiting
review" until you get that. (should reply on the mailing list with "what
do others think?" as well, of course)
It's also OK to submit design plans etc. non-patch items to the list, if
you want people to review them before you start writing a patch.
The commitfest will not go on forever because:
- Patch reviewers know where to look for patches to review, which makes
it easy for people to participate. The most active reviewers are also
most active patch authors, and they likely have a patch or two in the
list themselves, which they can't work on until the commitfest is over
(or at least that would be frowned upon). That's a good motivator to
review other people's patches.
- Patch authors don't want to hold up the commitfest, because after your
patch is one of the few ones left in the list, you will start to feel
the heat from people who want to move on, if you don't update the status.
I don't think we should have a reviewer field in the status page, BTW.
This will not help with items that no-one is actively working on, but at
least in my mind, the purpose of commitfests is to get attention to
patches people are working on, and need advice on how to proceed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
