Re: Patch queue -> wiki (was varadic patch)

Hi,

I created a page for our current commitfest:

http://wiki.postgresql.org/wiki/CommitFest:March

Not all patches are there yet. I only added the latest version of each
patch. I'll continue after lunch.

I also created one for the next commitfest:

http://wiki.postgresql.org/wiki/CommitFest:May

HTH

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

"Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:

> Hi,
>
> I created a page for our current commitfest:
>
> http://wiki.postgresql.org/wiki/CommitFest:March
>
> Not all patches are there yet. I only added the latest version of each
> patch. I'll continue after lunch.
>
> I also created one for the next commitfest:
>
> http://wiki.postgresql.org/wiki/CommitFest:May

Hm, at the same time as you were doing this I wrote a perl script to dump
Bruce's mail box into a table. The results are at:

http://wiki.postgresql.org/wiki/CommitFest:Bruce

I think the next step is to manually go through them and remove the comments,
replacing them with a single "status" cell. (And sending mail to the author
and -hackers with the meat of the review).

(Note that the "author" is just the author of the first message Bruce saved --
in some cases that's not the right person. And the "reviewer" is just the
author of the last comment.)

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

Gregory Stark wrote:

> Hm, at the same time as you were doing this I wrote a perl script to dump
> Bruce's mail box into a table. The results are at:

Heh. I should have guessed.

> http://wiki.postgresql.org/wiki/CommitFest:Bruce

It is a lot harder to trawl though ... I think it's easier to finish my
version than get the weed out of yours -- one reason my list is so much
shorter is that there was a huge lot of stuff in the patch queue that
has no actual patch; and there are multiple versions of certain patches.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Ok, AFAICT it is complete:

http://wiki.postgresql.org/wiki/CommitFest:March

It is a reasonably short page, so it's really easy to search for things
you might want to work on for this commit fest.

I also added the patches submitted on March 2008 to the May commitfest
page.

Patch submitters: please have a look at the current commitfest page and
check for possible nuisances.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Hello

there is some noises about my patches :(

I sent EXECUTE USING - it's important (against to SQL injection and
faster dynamic SQL), this patch is linger time in queue.

variadic function, named params exist only as WIP and I see it for
next commit fest. I'll send new version in next months.

Regards
Pavel Stehule

On 25/03/2008, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Ok, AFAICT it is complete:
>
> http://wiki.postgresql.org/wiki/CommitFest:March
>
> It is a reasonably short page, so it's really easy to search for things
> you might want to work on for this commit fest.
>
> I also added the patches submitted on March 2008 to the May commitfest
> page.
>
> Patch submitters: please have a look at the current commitfest page and
> check for possible nuisances.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Because of this:

> variadic function, named params exist only as WIP and I see it for
> next commit fest. I'll send new version in next months.

This has been saved for the next commit-fest:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Pavel Stehule wrote:
> Hello
>
> there is some noises about my patches :(
>
> I sent EXECUTE USING - it's important (against to SQL injection and
> faster dynamic SQL), this patch is linger time in queue.
>
>
> Regards
> Pavel Stehule
>
>
>
> On 25/03/2008, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> > Ok, AFAICT it is complete:
> >
> > http://wiki.postgresql.org/wiki/CommitFest:March
> >
> > It is a reasonably short page, so it's really easy to search for things
> > you might want to work on for this commit fest.
> >
> > I also added the patches submitted on March 2008 to the May commitfest
> > page.
> >
> > Patch submitters: please have a look at the current commitfest page and
> > check for possible nuisances.
> >
> > --
> > Alvaro Herrera http://www.CommandPrompt.com/
> > The PostgreSQL Company - Command Prompt, Inc.
> >
> >
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
> >
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian escribió:
>
> Because of this:
>
> > variadic function, named params exist only as WIP and I see it for
> > next commit fest. I'll send new version in next months.
>
> This has been saved for the next commit-fest:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold

Yes, it was already listed here:

http://wiki.postgresql.org/wiki/CommitFest:May

Upon verifying this I noticed that you broke all the permanent links the
other day, thus rendering both commitfest wiki pages useless -- just
fixed them. It would be nice that if you promise things to be
permanent, they are really permanent. Otherwise they are no better than
the other urls with message numbers.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian escribi??:
> >
> > Because of this:
> >
> > > variadic function, named params exist only as WIP and I see it for
> > > next commit fest. I'll send new version in next months.
> >
> > This has been saved for the next commit-fest:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Yes, it was already listed here:
>
> http://wiki.postgresql.org/wiki/CommitFest:May
>
> Upon verifying this I noticed that you broke all the permanent links the
> other day, thus rendering both commitfest wiki pages useless -- just
> fixed them. It would be nice that if you promise things to be
> permanent, they are really permanent. Otherwise they are no better than
> the other urls with message numbers.

Can you give me an example of a link that changed? They shouldn't.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian escribió:
> Alvaro Herrera wrote:

> > Upon verifying this I noticed that you broke all the permanent links the
> > other day, thus rendering both commitfest wiki pages useless -- just
> > fixed them. It would be nice that if you promise things to be
> > permanent, they are really permanent. Otherwise they are no better than
> > the other urls with message numbers.
>
> Can you give me an example of a link that changed? They shouldn't.

They used to be
http://momjian.us/mhonarc/patches/162867790801260650t32ab221t5d6aac36643bac50(at)mail(dot)gmail(dot)com(dot)html

but now are
http://momjian.us/mhonarc/message-id/162867790801260650t32ab221t5d6aac36643bac50@mail.gmail.com.html

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian escribi??:
> > Alvaro Herrera wrote:
>
> > > Upon verifying this I noticed that you broke all the permanent links the
> > > other day, thus rendering both commitfest wiki pages useless -- just
> > > fixed them. It would be nice that if you promise things to be
> > > permanent, they are really permanent. Otherwise they are no better than
> > > the other urls with message numbers.
> >
> > Can you give me an example of a link that changed? They shouldn't.
>
> They used to be
> http://momjian.us/mhonarc/patches/162867790801260650t32ab221t5d6aac36643bac50(at)mail(dot)gmail(dot)com(dot)html
>
> but now are
> http://momjian.us/mhonarc/message-id/162867790801260650t32ab221t5d6aac36643bac50@mail.gmail.com.html

Oh, OK, the first one was my _old_ permanent version that is permanent
while messages are added/removed, but obviously not permanent for
mailbox movement. The new permanent ones are permanent against mailbox
movement, and in fact the comments and thread merging also travels with
the email.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Upon verifying this I noticed that you broke all the permanent links the
> other day, thus rendering both commitfest wiki pages useless -- just
> fixed them. It would be nice that if you promise things to be
> permanent, they are really permanent. Otherwise they are no better than
> the other urls with message numbers.

I don't think the wiki pages should be relying on Bruce's queue at all
--- they should just link into the mail archives.

regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Upon verifying this I noticed that you broke all the permanent links the
> > other day, thus rendering both commitfest wiki pages useless -- just
> > fixed them. It would be nice that if you promise things to be
> > permanent, they are really permanent. Otherwise they are no better than
> > the other urls with message numbers.
>
> I don't think the wiki pages should be relying on Bruce's queue at all
> --- they should just link into the mail archives.

Except the comments are on my queue, and they are updated to join
threads by adding comments to patches posted months ago.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> I don't think the wiki pages should be relying on Bruce's queue at all
>> --- they should just link into the mail archives.

> Except the comments are on my queue, and they are updated to join
> threads by adding comments to patches posted months ago.

Well, as I told you yesterday, I don't see why you're expending large
amounts of effort to create facilities that already exist trivially
if the patch queue was just a bunch of URLs and comment text on a wiki
page. I feel that your current approach to the patch queue is dead
after this commit fest, so there's little point in putting so much work
into it.

regards, tom lane

On Wed, 2 Apr 2008, Bruce Momjian wrote:

> The new permanent ones are permanent against mailbox movement, and in
> fact the comments and thread merging also travels with the email.

The "someone replied to your comment" links in e-messages I've been
getting the last few days have all been working, which is a first. The
configuration you're running right now I'd consider the first candidate to
be a "stable" version, so thumbs up from me for reaching that point.

It's clear to me only now that you can think of the patch queue as being a
list with this structure:

1) Patch name (defaults to the subject of the first message)
2) List of messages related to that patch
3) List of comments
4) Status
5) Assigned reviewers

Bruce's toolchain converts an mbox of messages to generate the first two,
then has a web interface to allow adding the third. Right now the message
list is internally consistant but not useful in the long term (doesn't
have links to the archives, just this temporary page). Until the "search
for message ID" feature is added to the archives I don't know that this
situation can be improved.

Those hacking on tools to convert Bruce's currently preferred working form
(that revolves around mbox files) into something else that's web oriented
are stuck with considering how all the above information is going to be
handled before everybody will be satisfied. I can see how a script that
converts the current pages into wiki markup, with placeholders where
someone can manually update the comments to summarize those on the page,
would be helpful. That basically creates an easier to read "Queue
summary" like Stephan was doing for 8.3--that included items 1,4,5 from
the above. But that's a one-way operation that doesn't really help with
the commenting situation, and it's inevitably going to lag behind the
mailbox-centered queue unless it's made fully automatic. I can't think of
anything better that doesn't require building some sort of database that
holds all this information and drives page generation.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> Those hacking on tools to convert Bruce's currently preferred working form
> (that revolves around mbox files) into something else that's web oriented
> are stuck with considering how all the above information is going to be
> handled before everybody will be satisfied. I can see how a script that
> converts the current pages into wiki markup, with placeholders where
> someone can manually update the comments to summarize those on the page,
> would be helpful. That basically creates an easier to read "Queue
> summary" like Stephan was doing for 8.3--that included items 1,4,5 from
> the above. But that's a one-way operation that doesn't really help with
> the commenting situation, and it's inevitably going to lag behind the
> mailbox-centered queue unless it's made fully automatic. I can't think of
> anything better that doesn't require building some sort of database that
> holds all this information and drives page generation.

This seems to be ignoring the possibility of those involved with the
patch queue simply manually editing the wiki page.

For the past couple of weeks I've been dealing with both Bruce's queue
and the one at
http://wiki.postgresql.org/wiki/CommitFest:March
and frankly I find the latter a *whole* lot more satisfactory, despite
the fact that it's got exactly zero custom tooling or infrastructure
behind it. It doesn't have artificial constraints on page organization;
I can update it as soon as I've done something rather than waiting
around for Bruce to do so; and there's an automatically maintained
history of changes. Bruce has put a whole lot of man-hours into
getting his page to do a few of the things we could do for free with
the wiki page, but it's still got a long way to go.

Now it would certainly be nice if there were some tools that would
assist with dumping URLs for newly-arrived messages into the wiki page.
Perhaps some of the pgsql-www crowd can think about how to do that.
But even if we had to do that entirely by hand, I'd rather go with the
wiki page.

At some point it might be worth building the sort of heavy-duty
infrastructure for the patch queue that you have in mind here.
I don't think we need it yet, though, and I definitely don't think
we understand our requirements well enough yet to start designing
it. One of the reasons I like the wiki approach is exactly that
there's such a low barrier to getting started with it.

regards, tom lane

Tom Lane wrote:
>
> For the past couple of weeks I've been dealing with both Bruce's queue
> and the one at
> http://wiki.postgresql.org/wiki/CommitFest:March
> and frankly I find the latter a *whole* lot more satisfactory, despite
> the fact that it's got exactly zero custom tooling or infrastructure
> behind it. It doesn't have artificial constraints on page organization;
> I can update it as soon as I've done something rather than waiting
> around for Bruce to do so; and there's an automatically maintained
> history of changes. Bruce has put a whole lot of man-hours into
> getting his page to do a few of the things we could do for free with
> the wiki page, but it's still got a long way to go.
>
> Now it would certainly be nice if there were some tools that would
> assist with dumping URLs for newly-arrived messages into the wiki page.
> Perhaps some of the pgsql-www crowd can think about how to do that.
> But even if we had to do that entirely by hand, I'd rather go with the
> wiki page.
>
> At some point it might be worth building the sort of heavy-duty
> infrastructure for the patch queue that you have in mind here.
> I don't think we need it yet, though, and I definitely don't think
> we understand our requirements well enough yet to start designing
> it. One of the reasons I like the wiki approach is exactly that
> there's such a low barrier to getting started with it.
>
>
>

+ MAXINT.

cheers

andrew

Tom Lane wrote:
> For the past couple of weeks I've been dealing with both Bruce's queue
> and the one at
> http://wiki.postgresql.org/wiki/CommitFest:March
> and frankly I find the latter a *whole* lot more satisfactory, despite
> the fact that it's got exactly zero custom tooling or infrastructure
> behind it. It doesn't have artificial constraints on page organization;
> I can update it as soon as I've done something rather than waiting
> around for Bruce to do so; and there's an automatically maintained
> history of changes. Bruce has put a whole lot of man-hours into
> getting his page to do a few of the things we could do for free with
> the wiki page, but it's still got a long way to go.
>
> Now it would certainly be nice if there were some tools that would
> assist with dumping URLs for newly-arrived messages into the wiki page.
> Perhaps some of the pgsql-www crowd can think about how to do that.
> But even if we had to do that entirely by hand, I'd rather go with the
> wiki page.
>
> At some point it might be worth building the sort of heavy-duty
> infrastructure for the patch queue that you have in mind here.
> I don't think we need it yet, though, and I definitely don't think
> we understand our requirements well enough yet to start designing
> it. One of the reasons I like the wiki approach is exactly that
> there's such a low barrier to getting started with it.

It is not clear to me how a wiki can be easily created for 2k emails and
then maintained in a reasonable way, or how emails can be added to it
easily.

There are several steps:

o getting those 2k emails to start the commit fest
o getting them into a wiki in a way that is fast/efficient
o updating the wiki for changes efficiently

Keep in mind the patch emails are pretty dynamic. As you get closer to
the end of the commit fest, the wiki is easier because the list of open
items becomes more stable.

I am able to give others the ability to add, move, and delete emails in
my patch queue, if desired.

If people want to use the wiki, go ahead --- this would be one less job
for me to do.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Thu, Apr 3, 2008 at 12:35 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> It is not clear to me how a wiki can be easily created for 2k emails and
> then maintained in a reasonable way, or how emails can be added to it
> easily.

That seems like a *really* odd thing for one of the founders of the
world's most advanced OSS DBMS project to say. It's all relational
(which we do do pretty well) - we can add links to the wiki to threads
in the archives, and anything posted from then on is self-maintaining
(except when new threads are started - but even if each patch gets 5
threads that's not a huge chore).

I see no reason to go manually copying all 2k emails to the wiki.

--
Dave Page
EnterpriseDB UK Ltd: http://www.enterprisedb.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk

The one concern I have with the way the last commitfest went (and I say
this as strictly an observer), there was no "discussion" on anything.

Now, I know that "discussion" happened, but it happened somewhere, in some
web-forum, in a community that seems to generally promote mailing lists
as the preferred method of "discussion".

As an observer, who generally doesn't have much input "code wise", but
occasionally might have an observation as a user, *I* would love to see
the "commitfest patch-queue" be something pretty "simple", along the
lines of a big list of:

1) item name, submission date, author
2a) item intention (maybe a see $MSGID)
2b) item (see $MSGID)
3) status summary (in discussion, applied, needs $improvements,
rejected, see $MSGID"

Note I said "item" because it appears as if the consensus is that the
commit-fest has to deal with more than just patches, but also proposals,
and "fork-in-the-road" details.

And no, I don't think it should included the 2K emails. It should can
the $N "items" needing to be dealt with, and a list of pointers to
messages (which generally lead to threads), with a simple status
list/summary for each one (again with pointers to $MSGID where specific
information might be needed).

Basically, I would like to see the "patch queue" be more a
summary/pointer of/to discussion, then some web forum where the
discussion happens. And I would like the "mailling lists" be where the
discussion of items in the patch queue happens.

But all this is the opinion of an observing devellopper, not involved in
any of the heavy-lifting, but as someone who would like to keep an eye
on what patches are presented, and their strengths/deficiencies, so that
when I present my first patch/proposal, hopefully I can avoid most of
the pitfalls.

But don't cater to me. Cater to Tom and Bruce, who are the ones who
actually use whatever is in place. Since they are the ones doing the
work, I have to accept (or ignore) whatever system they use.

a.

* Bruce Momjian <bruce(at)momjian(dot)us> [080402 19:36]:

> It is not clear to me how a wiki can be easily created for 2k emails and
> then maintained in a reasonable way, or how emails can be added to it
> easily.
>
> There are several steps:
>
> o getting those 2k emails to start the commit fest
> o getting them into a wiki in a way that is fast/efficient
> o updating the wiki for changes efficiently
>
> Keep in mind the patch emails are pretty dynamic. As you get closer to
> the end of the commit fest, the wiki is easier because the list of open
> items becomes more stable.
>
> I am able to give others the ability to add, move, and delete emails in
> my patch queue, if desired.
>
> If people want to use the wiki, go ahead --- this would be one less job
> for me to do.

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

Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> The one concern I have with the way the last commitfest went (and I say
> this as strictly an observer), there was no "discussion" on anything.

Umm ... in the first place, the fest isn't over yet. In the second
place, the reason you haven't seen much discussion is that we've been
working primarily on the stuff that could be committed without much
discussion. That underbrush has mostly been cleared away at this point,
and we're starting to get down to the stuff that actually will need
extended discussion. That should definitely happen on this list.

The remaining open issues are listed here:
http://momjian.us/cgi-bin/pgpatches
Feel free to start talking about any of them ...

regards, tom lane

Dave Page wrote:
> On Thu, Apr 3, 2008 at 12:35 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > It is not clear to me how a wiki can be easily created for 2k emails and
> > then maintained in a reasonable way, or how emails can be added to it
> > easily.
>
> That seems like a *really* odd thing for one of the founders of the
> world's most advanced OSS DBMS project to say. It's all relational
> (which we do do pretty well) - we can add links to the wiki to threads
> in the archives, and anything posted from then on is self-maintaining
> (except when new threads are started - but even if each patch gets 5
> threads that's not a huge chore).
>
> I see no reason to go manually copying all 2k emails to the wiki.

Well, I am waiting for someone to show me how it is done because I can't
figure out a way. Do it and I will gladly stop doing what I am doing.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Thu, Apr 3, 2008 at 4:55 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> > That seems like a *really* odd thing for one of the founders of the
> > world's most advanced OSS DBMS project to say. It's all relational
> > (which we do do pretty well) - we can add links to the wiki to threads
> > in the archives, and anything posted from then on is self-maintaining
> > (except when new threads are started - but even if each patch gets 5
> > threads that's not a huge chore).
> >
> > I see no reason to go manually copying all 2k emails to the wiki.
>
> Well, I am waiting for someone to show me how it is done because I can't
> figure out a way. Do it and I will gladly stop doing what I am doing.

We must be talking at cross purposes because I really cannot believe
you're asking me how to add a link to a wiki page :-o

Just in case though, the most simple way is to just add the URL with
square brackets surrounding it:

[http://archives.postgresql.org/pgsql-hackers/2008-04/msg00131.php]

To use different link text just add it after the URL:

[http://archives.postgresql.org/pgsql-hackers/2008-04/msg00131.php
Patch queue -> Wiki]

To link to another wiki page, put the target page title in double
square brackets

[[Developer and Contributor Resources]]

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Fri, 4 Apr 2008, Dave Page wrote:

> We must be talking at cross purposes because I really cannot believe
> you're asking me how to add a link to a wiki page :-o

He wants to know how to automate turning an entire mbox file full of them
into wiki markup, now how to do one at a time. Other people have been
running such tools for Bruce but he doesn't have one he can become
comfortable with running himself yet.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

"Greg Smith" <gsmith(at)gregsmith(dot)com> writes:

> On Fri, 4 Apr 2008, Dave Page wrote:
>
>> We must be talking at cross purposes because I really cannot believe
>> you're asking me how to add a link to a wiki page :-o
>
> He wants to know how to automate turning an entire mbox file full of them into
> wiki markup, now how to do one at a time. Other people have been running such
> tools for Bruce but he doesn't have one he can become comfortable with running
> himself yet.

Well since we stuck with the mbox for the March commitfest there's no need to
do a batch migration. We'll just start with a wiki page for the May
commitfest. There are only a handful of lines to put in the May commitfest and
I think Alvaro's already put them in.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

Gregory Stark wrote:
> "Greg Smith" <gsmith(at)gregsmith(dot)com> writes:
>
> > He wants to know how to automate turning an entire mbox file full of them into
> > wiki markup, now how to do one at a time. Other people have been running such
> > tools for Bruce but he doesn't have one he can become comfortable with running
> > himself yet.
>
> Well since we stuck with the mbox for the March commitfest there's no need to
> do a batch migration. We'll just start with a wiki page for the May
> commitfest. There are only a handful of lines to put in the May commitfest and
> I think Alvaro's already put them in.

Yeah, the May commitfest page is already up. I have been requesting
patch submitters to add their entries there.

The problem we had with the 20000 emails was that we didn't have any
record of patches waiting for review -- a problem that we will hopefully
have only once. I would expect our next release (this one) to not have
such a long queue of things, because of the whole commitfest idea.

I agree with what some are saying here: there's no automatic
notification when we add, remove or change status of patches, or other
issues. I did voice my opinion that I thought a wiki page was not a
real tracker. Hopefully, in working with the wiki we will gather enough
experience that we'll be able to decide _how_ we want our tracker to
work -- if we decide we want to switch from the wiki at all.

BTW, Greg Stark already dumped the patch queue into a wiki page some
time ago: http://wiki.postgresql.org/wiki/CommitFest:Bruce Do you think
that's more useful than the other commitfest layout? I don't.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> BTW, Greg Stark already dumped the patch queue into a wiki page some
> time ago: http://wiki.postgresql.org/wiki/CommitFest:Bruce Do you think
> that's more useful than the other commitfest layout? I don't.

No.

The bottom line is that I used to do this tracking in my own mailboxes
but people wanted to see what was outstanding so the web pages were
created.

Basically a Wiki takes 10x more time for me to modify something, so
unless I get another 9 people to do the same amount of work I do on
tracking, we are going to fall behind. I am not willing to increase the
amount of time I already spend doing this. Perhaps distributed over the
community there will be 9x more time spent on tracking, but I doubt it.

I think ultimately we are going to have to remove the patches email list
and require patch submitters to add their patches to a patch tracker.
Then all patch discussion will happen on hackers and in the patch
tracker. I will continue to gather TODO emails, but those are not
time-sensitive and few people seem to want to work on that.

Frankly, few people seem to want to apply patches either. :-) Even
with two patch queue web sites, Tom is doing the bulk of the work. I
kept some of the easy ones in the queue for a long time hoping people
would at least take those, but no one did. I am doing them at this
point because we want this commit fest to be over.

Also frankly, I feel I am hearing, "Oh, we want to help but we don't
know what to do", and when you show people what to do, they don't help.

Yes, I am disapointed. If someone can explain why I shouldn't feel
disapointed, I would love to hear it.

If you want I will take my web pages offline and the community can see
how it does with tracking. I will keep my mbox current just in case.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Bruce Momjian" <bruce(at)momjian(dot)us> writes:

> Basically a Wiki takes 10x more time for me to modify something, so
> unless I get another 9 people to do the same amount of work I do on
> tracking, we are going to fall behind. I am not willing to increase the
> amount of time I already spend doing this. Perhaps distributed over the
> community there will be 9x more time spent on tracking, but I doubt it.

On a busy day we might get 5 patches submitted or updated. That's five lines
of text to add or edit. The hard part is reading the email and figuring out
what status the patch is in. Not coincidentally the lack of that info is also
why your list isn't very helpful.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Bruce Momjian" <bruce(at)momjian(dot)us> writes:
>> Basically a Wiki takes 10x more time for me to modify something, so
>> unless I get another 9 people to do the same amount of work I do on
>> tracking, we are going to fall behind. I am not willing to increase the
>> amount of time I already spend doing this. Perhaps distributed over the
>> community there will be 9x more time spent on tracking, but I doubt it.

> On a busy day we might get 5 patches submitted or updated. That's five lines
> of text to add or edit.

I think what Bruce is really complaining about here is that he's got
years worth of development in his current infrastructure, and so it only
costs him a few seconds and keystrokes to push stuff into his existing
patch queue; while there's no such shortcuts for the wiki. Which is a
fair complaint, but it's hardly insoluble.

> The hard part is reading the email and figuring out
> what status the patch is in.

Certainly. What we've got to do is make sure that after someone has
made that decision, it doesn't cost them a couple of minutes of drudgery
to look up the appropriate email-archives URL and push it into the wiki
page (probably with a comment). I can't imagine that this is terribly
difficult, but web page scripting isn't one of my strengths ...

regards, tom lane

Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > "Bruce Momjian" <bruce(at)momjian(dot)us> writes:
> >> Basically a Wiki takes 10x more time for me to modify something, so
> >> unless I get another 9 people to do the same amount of work I do on
> >> tracking, we are going to fall behind. I am not willing to increase the
> >> amount of time I already spend doing this. Perhaps distributed over the
> >> community there will be 9x more time spent on tracking, but I doubt it.
>
> > On a busy day we might get 5 patches submitted or updated. That's five lines
> > of text to add or edit.
>
> I think what Bruce is really complaining about here is that he's got
> years worth of development in his current infrastructure, and so it only
> costs him a few seconds and keystrokes to push stuff into his existing
> patch queue; while there's no such shortcuts for the wiki. Which is a
> fair complaint, but it's hardly insoluble.

My infrastructure really took no time to construct because it is just
pushing email around. I don't care if I have to scrap it.

Basically it is an outgrowth of something I already do, and that is read
the email stream. My guess is that no matter what we set up I am going
to want to track things others don't want to see so I am still going to
have my private list of emails I want to address.

That private email list has grown into something official because I am
more thorough about it than most. If the community wants a more
collaborative tool, they can create one or ask for additions to my web
pages. If I need to take my pages offline to help, fine.

If the new system is 10x harder than I what I do now, I will probably
just keep doing what I am doing and just not make it visible. I can put
some work into using the collaborative tool, but as I said before, we
are going to need another 9x of effort.

Personally I don't think either the March or May wiki pages are accurate
enough, so that isn't a good sign.

FYI, others can add to the patch queue now; the email address is at the
top of each page.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>
>> The hard part is reading the email and figuring out
>> what status the patch is in.
>
> Certainly. What we've got to do is make sure that after someone has
> made that decision, it doesn't cost them a couple of minutes of drudgery
> to look up the appropriate email-archives URL and push it into the wiki
> page (probably with a comment). I can't imagine that this is terribly
> difficult, but web page scripting isn't one of my strengths ...

Hm, the way you describe this I fear we would get the list of every individual
email on the topic. What I think we want is usually to add a link to an
existing entry and update the status. That pretty much does require going to
the page and finding the entry in question.

It probably would be neat if the email footer thingy added a url to each email
it distributed via the lists pointing to the permanent message-id-based url in
the archives for that message. Then at least you would have that handy.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> I think ultimately we are going to have to remove the patches email list
> and require patch submitters to add their patches to a patch tracker.

That's outright silly. The email list and archives are a critical part
of what we do, because they provide a historical record. Nor is raising
the bar for submitting patches a good idea.

The patch queue is by definition transient --- nobody particularly cares
about what its past state was, as shown by the fact that you've gotten
along for years with an implementation that's incapable of recalling
past state. (Now I do like the idea that a wiki-based patch queue would
retain some history, but I'm not expecting that it'll archive every
change indefinitely.)

The right way to think about and design the patch queue is as a changing
index into the archives. One of the things I seriously dislike about
your current implementation is that it ignores the archives. You've
whacked us around two or three times this month developing "permanent"
and then "really permanent" URLs, but that whole thing is wrong from the
get-go. You are not the keeper of the project's historical record.
The patch queue should be trafficking in URLs that do point into the
historical record.

> Frankly, few people seem to want to apply patches either. :-)

Yeah, tell me about it :-(

regards, tom lane

Tom Lane wrote:
> The patch queue is by definition transient --- nobody particularly cares
> about what its past state was, as shown by the fact that you've gotten
> along for years with an implementation that's incapable of recalling
> past state. (Now I do like the idea that a wiki-based patch queue would
> retain some history, but I'm not expecting that it'll archive every
> change indefinitely.)
>
> The right way to think about and design the patch queue is as a changing
> index into the archives. One of the things I seriously dislike about
> your current implementation is that it ignores the archives. You've
> whacked us around two or three times this month developing "permanent"
> and then "really permanent" URLs, but that whole thing is wrong from the
> get-go. You are not the keeper of the project's historical record.
> The patch queue should be trafficking in URLs that do point into the
> historical record.

Sure, it would be nice if an email link could jump right into the
archives, but until we have a way to get to the archives via a
message-id, I know of know way to automate that.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, 04 Apr 2008 22:37:17 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I think ultimately we are going to have to remove the patches email
> > list and require patch submitters to add their patches to a patch
> > tracker.
>
> That's outright silly. The email list and archives are a critical
> part of what we do, because they provide a historical record. Nor is
> raising the bar for submitting patches a good idea.

Command Prompt uses a tool that allows us to transform emails to
tickets via Trac. It is not perfect but it works for us. It has two
modes, autocreate and not.

With autocreate every email that hits the list is automatically a
ticket.

Without autocreate you must put: @trac create into the message body for
a ticket to be created.

The flow works like this:

email testlist(at)lists(dot)commandprompt(dot)com
email->tracman->trac->list

Where the email is intercepted by tracman, which reads the email to see
if it is already a ticket, if so the ticket within trac gets updated
and then the email is released to the listserv.

If the email is not a ticket (and autocreate is on), tracman intercepts
the email, creates a ticket in trac, rewrites the subject of the email
to have the ticket number and releases the ticket to the list serv.

Further if you want to update a ticket via the web interface to trac
you can and it will also correctly deal with list traffic.

The following commands are supported:

@trac create : creates a ticket

@trac assign : takes a second argument which allows you to assign to a
person

@trac close : closes a ticket

In the current infrastructure the missing things for CMDs workflow is:

1. Attachments if sent via email stay a part of the email, if they are
attached via trac, they stay part of the ticket. So you can actually
have two sources of attachments.

2. There is no merge capability. At some point we want to be able to
say this:

@trac merge 27

And the email getting intercepted would automatically merge into ticket
27.

I am not saying we should use this for the project. I am not even
saying it is a good tool for the project. I am saying that if some
hackers want to play with the idea for a patch queue using it, I would
be happy to provide resource to that. I would also be willing to
provide resources to make reasonable modifications to tracman to allow
it to work for our environment.

The key to this is, with very little effort we would have:

* Proper attachment capability (gets saved into postgresql)
* A single source for communication about patches
* If we add merge, we can even forward an email from hackers that is
relevant and merge it into a patch (which is a ticket).
* Always see what the latest patch is because the ticket will have a
patch and timestamp associated with when the patch came in
* Have a wiki that can associate explicitly with the tickets/patches

And if we ever change to mercurial, svn or git, we can use Trac as the
front end and not only have a wiki,tickets,patches but also source tree
references including changesets etc...

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Saturday, April 05, 2008 03:37:08 +0100 Gregory Stark
<stark(at)enterprisedb(dot)com> wrote:

> It probably would be neat if the email footer thingy added a url to each email
> it distributed via the lists pointing to the permanent message-id-based url in
> the archives for that message. Then at least you would have that handy.

Actually, I think it was Magnus that asked me about this (or similar) ... I can
add either an X-header, or something in the body, that includes the Message-Id,
as ppl desire it ...

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iEYEARECAAYFAkf2+/8ACgkQ4QvfyHIvDvMd6ACeOLY0WZNmhxuGxlUO/p0yIzRz
xVQAoOxeO4o8R6RHv5PJNODjRpIjMxHM
=FJhs
-----END PGP SIGNATURE-----

[ redirected to -www ]

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> - --On Saturday, April 05, 2008 03:37:08 +0100 Gregory Stark
> <stark(at)enterprisedb(dot)com> wrote:
>> It probably would be neat if the email footer thingy added a url to each email
>> it distributed via the lists pointing to the permanent message-id-based url in
>> the archives for that message. Then at least you would have that handy.

> Actually, I think it was Magnus that asked me about this (or similar) ... I can
> add either an X-header, or something in the body, that includes the Message-Id,
> as ppl desire it ...

What we need is a link into the archives. At the moment the Message-ID
is useless for that. Is it feasible to make links like
http://archives.postgresql.org/message-id?id=something
work? I'd be a bit worried about scalability myself...

regards, tom lane

Tom Lane wrote:
> [ redirected to -www ]
>
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
>> - --On Saturday, April 05, 2008 03:37:08 +0100 Gregory Stark
>> <stark(at)enterprisedb(dot)com> wrote:
>>> It probably would be neat if the email footer thingy added a url to each email
>>> it distributed via the lists pointing to the permanent message-id-based url in
>>> the archives for that message. Then at least you would have that handy.
>
>> Actually, I think it was Magnus that asked me about this (or similar) ... I can
>> add either an X-header, or something in the body, that includes the Message-Id,
>> as ppl desire it ...
>
> What we need is a link into the archives. At the moment the Message-ID
> is useless for that. Is it feasible to make links like
> http://archives.postgresql.org/message-id?id=something
> work? I'd be a bit worried about scalability myself...

Once I clean up my code, we will be having an URL on
http://search.postgresql.org that does this. We already index things in
a postgresql database there, so it's the best place to stick it.

//Magnus

Tom Lane wrote:

> What we need is a link into the archives. At the moment the Message-ID
> is useless for that. Is it feasible to make links like
> http://archives.postgresql.org/message-id?id=something
> work? I'd be a bit worried about scalability myself...

I think it is -- I've been doing some prep work for that in the recent
past; we're almost there.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > What we need is a link into the archives. At the moment the Message-ID
> > is useless for that. Is it feasible to make links like
> > http://archives.postgresql.org/message-id?id=something
> > work? I'd be a bit worried about scalability myself...
>
> I think it is -- I've been doing some prep work for that in the recent
> past; we're almost there.

And Alvaro has dealt with scalability.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Saturday, April 05, 2008 09:32:45 +0200 Magnus Hagander
<magnus(at)hagander(dot)net> wrote:

> Once I clean up my code, we will be having an URL on
> http://search.postgresql.org that does this. We already index things in a
> postgresql database there, so it's the best place to stick it.

'k, would it be useful to add something now, vs later, within the message
itself?

Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iEYEARECAAYFAkf3kIEACgkQ4QvfyHIvDvN9cQCg7LCoOHQXWWSqEitijoZ1Jwys
daAAoI+MDPJmhhqHTpWluKuSmyvIA9sk
=dUSn
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> - --On Saturday, April 05, 2008 09:32:45 +0200 Magnus Hagander
> <magnus(at)hagander(dot)net> wrote:
>
> > Once I clean up my code, we will be having an URL on
> > http://search.postgresql.org that does this. We already index things in a
> > postgresql database there, so it's the best place to stick it.
>
> 'k, would it be useful to add something now, vs later, within the message
> itself?

I think we should have an email header contain the URL. Right now if I
want to add a URL to the TODO list, I have to wait for it to appear in
the archives to get a URL.

One idea would be to just search index the message-id email header, but
that only gives us the ability to get a one-email search result. The
idea is that the URL would go right to the message.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Marc G. Fournier wrote:
>> 'k, would it be useful to add something now, vs later, within the message
>> itself?

> I think we should have an email header contain the URL.

I think you missed the point: once Magnus' CGI code is in, the message
ID gives you a permanent URL for it.

As far as I understand, there is simply no way for the current
year/month/message-number URL to be included in the messages,
because it doesn't get assigned until after the message is sent.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Marc G. Fournier wrote:
> >> 'k, would it be useful to add something now, vs later, within the message
> >> itself?
>
> > I think we should have an email header contain the URL.
>
> I think you missed the point: once Magnus' CGI code is in, the message
> ID gives you a permanent URL for it.

Right. The question is are we going to supply a URL that embeds the
message-id as a new header or just allow people to construct the
permanent URL on their own? Someone was talking about putting the
permanent URL in the email footer, but I think that is overkill.

> As far as I understand, there is simply no way for the current
> year/month/message-number URL to be included in the messages,
> because it doesn't get assigned until after the message is sent.

Right.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:

> As far as I understand, there is simply no way for the current
> year/month/message-number URL to be included in the messages,
> because it doesn't get assigned until after the message is sent.

Wrong -- we used to have it, but it was removed at some point (my guess
is that this happened when the List-* headers were added). You can see
them if you download an old mbox, say
http://archives.postgresql.org/pgsql-bugs/mbox/pgsql-bugs.2001-01.gz

there you have this header:

X-Archive-Number: 200101/30

which you can translate to

http://archives.postgresql.org/pgsql-bugs/2001-01/msg00029.php

However! Casual experimentation shows that it doesn't work all that
well -- Majordomo seems to have given the number 46 to these two
messages:
http://archives.postgresql.org/pgsql-bugs/2001-01/msg00045.php
http://archives.postgresql.org/pgsql-bugs/2001-01/msg00046.php
and of course Mhonarc loses sync from there.

In any case, they're not useful because they're missing in at least a
year's worth of list traffic.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:

> I think it is -- I've been doing some prep work for that in the recent
> past; we're almost there.

Ok, we're one more step ahead -- things like
http://archives.postgresql.org/message-id/1189170032.4175.513.camel@ebony.site
now work. I haven't set up the automatic script to create them yet, and
there is a small problem with certain types of Message-Ids (I think
about 100 messages whose links won't work until I fix it, in the last 8
years of pgsql-hackers and pgsql-patches). I have changed the URLs in
the wiki patch queue.

So far I have only run it in -patches and -hackers; the rest will follow
as soon as I fix the remaining glitches.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > I think it is -- I've been doing some prep work for that in the recent
> > past; we're almost there.
>
> Ok, we're one more step ahead -- things like
> http://archives.postgresql.org/message-id/1189170032.4175.513.camel@ebony.site
> now work. I haven't set up the automatic script to create them yet, and
> there is a small problem with certain types of Message-Ids (I think
> about 100 messages whose links won't work until I fix it, in the last 8
> years of pgsql-hackers and pgsql-patches). I have changed the URLs in
> the wiki patch queue.
>
> So far I have only run it in -patches and -hackers; the rest will follow
> as soon as I fix the remaining glitches.

OK, I updated my permanent URL references.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So you don't need any extra headers in the email itself for this?

- --On Saturday, April 05, 2008 16:49:19 -0400 Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:

> Alvaro Herrera wrote:
>
>> I think it is -- I've been doing some prep work for that in the recent
>> past; we're almost there.
>
> Ok, we're one more step ahead -- things like
> http://archives.postgresql.org/message-id/1189170032.4175.513.camel@ebony.site
> now work. I haven't set up the automatic script to create them yet, and
> there is a small problem with certain types of Message-Ids (I think
> about 100 messages whose links won't work until I fix it, in the last 8
> years of pgsql-hackers and pgsql-patches). I have changed the URLs in
> the wiki patch queue.
>
> So far I have only run it in -patches and -hackers; the rest will follow
> as soon as I fix the remaining glitches.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iEYEARECAAYFAkf4AK8ACgkQ4QvfyHIvDvPKhwCgtiOseYnAtfDmOTnCogmrBtCh
8rsAoLoV2ZXm6uKHPpruKwRE7stXzeuk
=gRXR
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:

> So you don't need any extra headers in the email itself for this?

I don't think so ... they would be a nicety in any case -- the URL can
be derived from the Message-Id header directly.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > I think it is -- I've been doing some prep work for that in the recent
> > past; we're almost there.
>
> Ok, we're one more step ahead -- things like
> http://archives.postgresql.org/message-id/1189170032.4175.513.camel@ebony.site
> now work. I haven't set up the automatic script to create them yet, and
> there is a small problem with certain types of Message-Ids (I think
> about 100 messages whose links won't work until I fix it, in the last 8
> years of pgsql-hackers and pgsql-patches). I have changed the URLs in
> the wiki patch queue.
>
> So far I have only run it in -patches and -hackers; the rest will follow
> as soon as I fix the remaining glitches.

FYI, this email URL is failing:

http://archives.postgresql.org/message-id/D9BA8B9B-A1CF-44E9-9F7A-B166875AEABB@apple.com

Because the email:

http://archives.postgresql.org/pgsql-patches/2007-03/msg00066.php

is not searchable via the archives:

http://search.postgresql.org/search?m=1&q=the+PID+inside+the+lockfile+and+trying+to+restart&l=&d=&s=

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

> FYI, this email URL is failing:
>
> http://archives.postgresql.org/message-id/D9BA8B9B-A1CF-44E9-9F7A-B166875AEABB@apple.com

Ah -- thanks, fixed that problem; that particular email is now
retrievable via message-id.

> Because the email:
>
> http://archives.postgresql.org/pgsql-patches/2007-03/msg00066.php
>
> is not searchable via the archives:
>
> http://search.postgresql.org/search?m=1&q=the+PID+inside+the+lockfile+and+trying+to+restart&l=&d=&s=

Actually the message-id stuff is not related to search at all, so if the
search is failing there must be another cause ... ah, got it, you have
to change the "post date" in order to get it:

http://search.postgresql.org/search?q=the+PID+inside+the+lockfile+and+trying+to+restart&m=1&l=&d=-1&s=r

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > FYI, this email URL is failing:
> >
> > http://archives.postgresql.org/message-id/D9BA8B9B-A1CF-44E9-9F7A-B166875AEABB@apple.com
>
> Ah -- thanks, fixed that problem; that particular email is now
> retrievable via message-id.
>
> > Because the email:
> >
> > http://archives.postgresql.org/pgsql-patches/2007-03/msg00066.php
> >
> > is not searchable via the archives:
> >
> > http://search.postgresql.org/search?m=1&q=the+PID+inside+the+lockfile+and+trying+to+restart&l=&d=&s=
>
> Actually the message-id stuff is not related to search at all, so if the
> search is failing there must be another cause ... ah, got it, you have
> to change the "post date" in order to get it:
>
> http://search.postgresql.org/search?q=the+PID+inside+the+lockfile+and+trying+to+restart&m=1&l=&d=-1&s=r

Oh, thanks. It does work now. Yea, I was confused by the search.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Saturday, April 05, 2008 19:53:50 -0400 Bruce Momjian <bruce(at)momjian(dot)us>
wrote:

> Alvaro Herrera wrote:
>> Alvaro Herrera wrote:
>>
>> > I think it is -- I've been doing some prep work for that in the recent
>> > past; we're almost there.
>>
>> Ok, we're one more step ahead -- things like
>> http://archives.postgresql.org/message-id/1189170032.4175.513.camel@ebony.si
>> te now work. I haven't set up the automatic script to create them yet, and
>> there is a small problem with certain types of Message-Ids (I think about
>> 100 messages whose links won't work until I fix it, in the last 8 years of
>> pgsql-hackers and pgsql-patches). I have changed the URLs in the wiki patch
>> queue.
>>
>> So far I have only run it in -patches and -hackers; the rest will follow
>> as soon as I fix the remaining glitches.
>
> FYI, this email URL is failing:
>
> http://archives.postgresql.org/message-id/D9BA8B9B-A1CF-44E9-9F7A-B166875AEA
> BB(at)apple(dot)com

I just clicked on it and it worked from here ... *shrug*

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iEYEARECAAYFAkf4MPsACgkQ4QvfyHIvDvNobACgoj6hQKTFZEd+MIV3JgCkN+sV
QJkAoIzv5b7nNW4HD1G8Wi8QQnPTimDx
=fWS+
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:

> - --On Saturday, April 05, 2008 19:53:50 -0400 Bruce Momjian <bruce(at)momjian(dot)us>
> wrote:
>
> > FYI, this email URL is failing:
> >
> > http://archives.postgresql.org/message-id/D9BA8B9B-A1CF-44E9-9F7A-B166875AEA
> > BB(at)apple(dot)com
>
> I just clicked on it and it worked from here ... *shrug*

That's because I just fixed it ;-)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Saturday, April 05, 2008 22:22:00 -0400 Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:

> Marc G. Fournier wrote:
>
>> - --On Saturday, April 05, 2008 19:53:50 -0400 Bruce Momjian
>> <bruce(at)momjian(dot)us> wrote:
>>
>> > FYI, this email URL is failing:
>> >
>> > http://archives.postgresql.org/message-id/D9BA8B9B-A1CF-44E9-9F7A-B166875
>> > AEA BB(at)apple(dot)com
>>
>> I just clicked on it and it worked from here ... *shrug*
>
> That's because I just fixed it ;-)

Ya, noticed that after I responded to Bruce's ... :)

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iEYEARECAAYFAkf4NQ0ACgkQ4QvfyHIvDvNRAQCgvutqC9ph3dlyqwhw6J4B6cqd
FB0AoKYHiWVuIbqQbqpLnc6er6plGzFH
=reRl
-----END PGP SIGNATURE-----

Bruce Momjian wrote:

> That private email list has grown into something official because I am
> more thorough about it than most. If the community wants a more
> collaborative tool, they can create one or ask for additions to my web
> pages. If I need to take my pages offline to help, fine.
>
> If the new system is 10x harder than I what I do now, I will probably
> just keep doing what I am doing and just not make it visible. I can put
> some work into using the collaborative tool, but as I said before, we
> are going to need another 9x of effort.
>
> Personally I don't think either the March or May wiki pages are accurate
> enough, so that isn't a good sign.

To me, what this means is that you're the perfect person to be helping
making the wiki pages more accurate to cover all items that need
attention. The fact that you seem to be fighting them (the pages), in
spite of the fact that everyone else has started using them, seems a bit
worrying to me.

I don't know how to measure how much harder using the wiki page is on
terms of the effort it takes you to update your pgpatches page -- so I
don't know about 10x, 9x or how many X's I have already used up. But
while I certainly spent a fair amount of work to create the initial
version, the fact that they're up and running now means the work needed
to keep them up to date is not tremendous.

FWIW I've been asking patch submitters (privately) to add the patches
they submit to the May commitfest pages, and they've mostly done it
right away. If you click the history link on the May page you can see
changes from Pavel Stehule, Teodor, Andrew Dunstan, Greg Start and Tom
-- so we already have a reasonably complete overview of what we need to
do on the next commitfest. I don't expect this to be a one-time affair.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

"Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:

> FWIW I've been asking patch submitters (privately) to add the patches
> they submit to the May commitfest pages, and they've mostly done it
> right away. If you click the history link on the May page you can see
> changes from Pavel Stehule, Teodor, Andrew Dunstan, Greg Start and Tom
> -- so we already have a reasonably complete overview of what we need to
> do on the next commitfest. I don't expect this to be a one-time affair.

I think asking submitters to add their patches is a good idea and in fact
Heikki's suggestion of having the wiki be primarily driven by submitters is a
good idea. It gives people a central place to go back and check and find all
the collected reviews and CVS status of their work and keeps us honest.

I would like to suggest a few attributes we want for each patch:

1) Patch maturity (whether it was proposed as a design, WIP, or submission for
committing).

2) Reviewers interested in working on the patch. I think it would help
organize ourselves and make sure all the patches get covered. Also, it
would help get people involved who are otherwise overtaken by more "senior"
postgres hackers. Those hackers would probably focus on patches that were
beyond the ability of more "junior" hackers and were otherwise getting
ignored.

3) Committers working on integrating the code. No point in risking duplication.

My first instinct is to convert it to a table. But perhaps we could just stick
these attributes in the current format as sublist items under each major
bullet point.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

Gregory Stark wrote:

> I would like to suggest a few attributes we want for each patch:

[...]

> My first instinct is to convert it to a table. But perhaps we could just stick
> these attributes in the current format as sublist items under each major
> bullet point.

I agree -- having these attributes on sight would be good. OTOH it
wouldn't be good if having them means the wiki is much harder to edit,
which makes me think that a table is not a good idea. Keeping the whole
thing easy to edit is important to keep overhead low.

Perhaps we should offer an empty template at the top of the page so that
when a submitter wants to add a new patch, he puts the empty fields
there so that a reviewer/commiter needs only complete them.

For "maturity" I think we should have "design", "WIP", "ready for final
review" (as in: the submitter thinks this is ready to commit),
"committed". Having a "status: committed" means we no longer need to
move patches from one section to another. (OTOH having a separate
section for committed patches is good because you can see at a glance
how the commitfest is progressing, so maybe this is not such a hot idea.)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> > Personally I don't think either the March or May wiki pages are accurate
> > enough, so that isn't a good sign.
>
> To me, what this means is that you're the perfect person to be helping
> making the wiki pages more accurate to cover all items that need
> attention. The fact that you seem to be fighting them (the pages), in
> spite of the fact that everyone else has started using them, seems a bit
> worrying to me.

I have offered to remove my web site pages.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +