Re: Commit fest queue

Warning - my "development" views and experiences are highly e-mail
dependant (i.e. linux-kernel style dependant).  So if you don't like
email, you probably shouldn't read my response below.

* Joshua D. Drake <jd@commandprompt.com> [080410 10:48]:
> I click the patch for EXPLAIN progress info:
> 
> http://archives.postgresql.org/message-id/87wsn82lda.fsf@oxford.xeocode.com
> 
> The message comes up.
> 
> Granted... very, very cool that this is all linked, so +1.
> 
> But now what?

I think the point is that the PostgreSQL development happens via e-mail
and on mailing lists.  So the goal is to point you to the mail, so you
can join in on the development (i.e. by mail on the mailing lists).

Maybe the archives should offer a way to download the raw message?  In
addition to all the normal stuff people want from archives that mhonarc
seems to do poorly ;-)

>  * Where do I comment?

In your mail program.

>  * Where do I submit my updated patch that fixes a small syntax error
> that Greg made?

Again - by mail, to -patches.  And hopefully someone (the patch author,
team of people, not Bruce) would update the "wiki/tracker" to say the
patch has been revised, version X is $MSGID

>  * How do I track it in the future? 
>     * Do I go to the wiki page again?

Well, only if you want to "pull" the last status (i.e. someone else, not
you may have updated it, and you haven't set yourself to be notified on
changes).  But again, since it's by email, you already have it all in
your inbox, right?

>     * If I go to the wiki page again and click on the patch is it going
> to take me right back to the archive page?

Only if the wiki/tracker *hasn't* been updated.

>     * If it takes me right back to the archives page, am I going to be
> plowing through 50 comments in the web archive format (which is
> laborious and inefficient for this sort of thing) in order to find the
> next relevant email (which would be the first one after I submitted my
> update to the patch?)

Uh, don't you read your e-mail already?  Any comment/discussions
on the patch would have had you in the reply-to chain.  All nicely
threaded in your mail reader or gmane, (or not-so nicely on
archives.postgresql.org)

>  * After I submitted my comments where do I go?
>    * Do I submit them to -patches?
>    * Or hackers?
>    * What about cross threads?

Well, generally your comments go as a "reply" to the patch, which should
(in theory) be already on -patches

>  * Am I going to have to do that for every single patch I review?

Well, you make it sound hard, but really, there is only "1" out-of-band
action needed to happen to make this all work easily:

Somebody (author, or team of people reading the mailling-lists) update
the wiki/tracker when
1) New patch comes in
2) New version of patch is sent
3) A decision/consensus on a patch (or part of it) has been made

> And in looking at this further, if I look at the Column Level
> privelages patch on the wiki, the archive page goes to a -hackers email.
> 
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php
> 
>  * Do I now respond to the hackers list?

Well, that's part of the general problem of the
archives.postgresql.org...

> Lastly, how is this sustainable? I don't see anything that is reducing
> Bruce's workload. (for example)

The only think that will ever reduce Bruce's workload is him trusting
that things aren't getting overlooked.  The value to the work Bruce does
is that he really doesn't let anything slip through the cracks.  One way
we can do that is by having a tracker/wiki which is an easy place for
Bruce to see that:  "Hey, this is/was looked after.  I don't have to worry about this  <thing>, I can delete it (and
thefollowups to it) from my huge list  of even more things to look at without expending lots of time  re-reading the
wholethread to make sure it didn't just die out"
 

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.