Commitfest process - Mailing list pgsql-hackers
From | Heikki Linnakangas |
---|---|
Subject | Commitfest process |
Date | |
Msg-id | 47D1521E.8090606@enterprisedb.com Whole thread Raw |
Responses |
Re: Commitfest process
|
List | pgsql-hackers |
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
pgsql-hackers by date: