Re: Commitfest process - Mailing list pgsql-hackers

Joshua D. Drake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 07 Mar 2008 14:33:02 +0000
> "Heikki Linnakangas" <heikki@enterprisedb.com> wrote:
> 
>> 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".
>>
> 
> This is a general workflow issue. You are asking patch submitters to do
> double work, (exactly what a tracker should be doing but I digress). We
> need to have a single point of entry. At this point I think the patch
> list is defunct. Have a patch category on the wiki. Each patch is a
> page. Each revision of the patch is uploaded to the page that is
> assigned to the patch.
> 
> 
>> 2. When a patch is outright rejected, the patch author updates the 
>> status accordingly.
> 
> I don't find this realistic. I believe we will just end up trolling
> back through patch archives trying to remember what the status was.

The idea is that a commit fest lasts for a short period, ideally a week 
or so. If the patch author drops the ball at this point, and doesn't 
respond to requests to close the case, it should be bright in everyone's 
mind that a patch has been rejected, and someone else can then go and 
mark it as such.

>> 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.
> 
> I assume this happens "After" discussion on -hackers?

The discussion and review will happen on -hackers / patches. After the 
author thinks he knows what he needs to do next, he will update the status.

If he doesn't update the status, he will start to get mails like "where 
are you on this?" and "what's up dude, didn't you understand what you 
were told?" fairly soon.

>> The trick here is that the patch authors drive the process. An author 
> 
> Yes and I believe it is a trick that is destined to bomb at the magic
> show. We can't convince hackers to follow standard bug tracker policies
> but we are going to convince them to keep a mailing list + wiki up to
> date?

Mailing list would function as they do now. The commitfests are there to 
help patch authors to get attention to their work. If you don't want to 
participate, or you can get that attention through other means, like 
just sending a patch to -patches and cross your fingers, that's 
perfectly fine.

I think we'll have more success convincing patch authors to update a 
wiki page, than we'll have to convince reviewers to do so. I know that's 
true at least for me. If I want people to review my patch, I'm ready to 
sing and dance if that's what it takes. But if there's extra steps in 
reviewing a patch, I might just not bother.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com