Commitfest process

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