Re: Commitfest process

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 07 Mar 2008 14:33:02 +0000
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)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.

>
> 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?

>
> 4. The commitfest is over when there is no more tasks on the wiki
> page with status "awaiting review".

Nod.

>
> 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?

Please don't misunderstand I certainly thinking working about the kinks
of the commit fest are important. It is new to us but I don't think
adding multiple points of entry and multiple documentation paths is
going to help.

Sincerely,

Joshua D. Drake

- --
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH0YX3ATb/zqfZUUQRAgD4AJsFGgnuaVKbLe89xvdfzXm0AuuZRwCdFswJ
qm1cLFj8GySWaMNbco+Ydts=
=cj5Y
-----END PGP SIGNATURE-----