Joshua D. Drake wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 07 Mar 2008 14:33:02 +0000
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
