From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Commitfest process |
Date: | 2008-03-07 18:14:13 |
Message-ID: | 20080307101413.7d191e52@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----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-----
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-03-07 18:25:25 | Maximum statistics target |
Previous Message | Bruce Momjian | 2008-03-07 18:13:00 | Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > > |