Re: Commitfest process

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: Commitfest process
Дата
Msg-id 20080307101413.7d191e52@commandprompt.com
обсуждение исходный текст
Ответ на Commitfest process  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Ответы Re: Commitfest process  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Список pgsql-hackers
-----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-----

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Commitfest status
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Add: > o Add SQLSTATE severity to PGconn return status > >