From: Joshua D. Drake <jd@commandprompt.com>
To: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Commitfest process
Date: Fri, 7 Mar 2008 10:14:13 -0800
Message-ID: <20080307101413.7d191e52@commandprompt.com> (raw)
In-Reply-To: <47D1521E.8090606@enterprisedb.com>
References: <47D1521E.8090606@enterprisedb.com>
-----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.
>
> 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-----
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jd@commandprompt.com, heikki@enterprisedb.com
Subject: Re: Commitfest process
In-Reply-To: <20080307101413.7d191e52@commandprompt.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox