Subject: partial dump of patch queue to wiki

From: Alvaro Herrera <[email-masked]>
Date: Tue, 25 Mar 2008 13:23:46 -0300

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

---

From: Gregory Stark <[email-masked]>
Date: Tue, 25 Mar 2008 16:49:25 +0000

> 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!

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 25 Mar 2008 14:28:04 -0300

> 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.

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 25 Mar 2008 15:29:32 -0300

Ok, AFAICT it is complete:

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.

---

From: "Pavel Stehule" <[email-masked]>
Date: Tue, 25 Mar 2008 20:18:25 +0100

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 <[email-masked]> wrote:
>  Sent via pgsql-hackers mailing list ([email-masked])
>  To make changes to your subscription:
>  http://www.postgresql.org/mailpref/pgsql-hackers
>

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 1 Apr 2008 22:40:03 -0400 (EDT)

> 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

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

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 2 Apr 2008 11:17:47 -0400

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

Yes, it was already listed here:

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.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 2 Apr 2008 11:21:47 -0400 (EDT)

Alvaro Herrera wrote:
> Bruce Momjian escribi??:

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

---

From: Alvaro Herrera <[email-masked]>
Date: Wed, 2 Apr 2008 11:37:49 -0400

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

They used to be 
http://momjian.us/mhonarc/patches/[email-masked]

but now are
http://momjian.us/mhonarc/message-id/[email-masked]

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 2 Apr 2008 11:48:02 -0400 (EDT)

> http://momjian.us/mhonarc/message-id/[email-masked]

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.

---

From: Tom Lane <[email-masked]>
Date: Wed, 02 Apr 2008 11:50:00 -0400

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 2 Apr 2008 11:51:33 -0400 (EDT)

> --- 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.

---

From: Tom Lane <[email-masked]>
Date: Wed, 02 Apr 2008 11:58:02 -0400

> 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

---

From: Greg Smith <[email-masked]>
Date: Wed, 2 Apr 2008 13:58:03 -0400 (EDT)

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 [email-masked] http://www.gregsmith.com Baltimore, MD

---

From: Tom Lane <[email-masked]>
Date: Wed, 02 Apr 2008 15:21:02 -0400

> 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

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 02 Apr 2008 15:43:48 -0400

> there's such a low barrier to getting started with it.

+ MAXINT.

cheers

andrew

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 2 Apr 2008 19:35:44 -0400 (EDT)

> 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.

---

From: "Dave Page" <[email-masked]>
Date: Thu, 3 Apr 2008 09:12:32 +0100

>  then maintained in a reasonable way, or how emails can be added to it

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

---

From: Aidan Van Dyk <[email-masked]>
Date: Thu, 3 Apr 2008 10:04:57 -0400

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.

-- 
Aidan Van Dyk                                             Create like a god,
[email-masked]                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

---

From: Tom Lane <[email-masked]>
Date: Thu, 03 Apr 2008 10:45:17 -0400

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 3 Apr 2008 11:55:59 -0400 (EDT)

> 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.

---

From: "Dave Page" <[email-masked]>
Date: Fri, 4 Apr 2008 09:36:08 +0100

> 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

---

From: Greg Smith <[email-masked]>
Date: Fri, 4 Apr 2008 11:15:22 -0400 (EDT)

> 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.

---

From: Gregory Stark <[email-masked]>
Date: Fri, 04 Apr 2008 20:56:27 +0100

"Greg Smith" <[email-masked]> 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.

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

---

From: Alvaro Herrera <[email-masked]>
Date: Fri, 4 Apr 2008 16:20:11 -0400

> 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.

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 4 Apr 2008 21:14:06 -0400 (EDT)

> 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.

---

From: Gregory Stark <[email-masked]>
Date: Sat, 05 Apr 2008 02:49:26 +0100

> 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.

---

From: Tom Lane <[email-masked]>
Date: Fri, 04 Apr 2008 22:19:47 -0400

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 4 Apr 2008 22:36:29 -0400 (EDT)

> 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.

---

From: Gregory Stark <[email-masked]>
Date: Sat, 05 Apr 2008 03:37:08 +0100

> 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.

---

From: Tom Lane <[email-masked]>
Date: Fri, 04 Apr 2008 22:37:17 -0400

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 4 Apr 2008 22:43:42 -0400 (EDT)

> The patch queue should be trafficking in URLs that do point into the

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.

---

From: "Joshua D. Drake" <[email-masked]>
Date: Fri, 4 Apr 2008 19:55:58 -0700

On Fri, 04 Apr 2008 22:37:17 -0400
Tom Lane <[email-masked]> wrote:

> > 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 [email-masked]
  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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Sat, 05 Apr 2008 01:11:43 -0300

> 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 . [email-masked]                              MSN . [email-masked]
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664

---

From: Tom Lane <[email-masked]>
Date: Sat, 05 Apr 2008 00:40:27 -0400

[ redirected to -www ]

> add either an X-header, or something in the body, that includes the Message-Id, 

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

---

From: Magnus Hagander <[email-masked]>
Date: Sat, 05 Apr 2008 09:32:45 +0200

> 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

---

From: Alvaro Herrera <[email-masked]>
Date: Sat, 5 Apr 2008 08:38:39 -0400

> 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.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 5 Apr 2008 08:42:22 -0400 (EDT)

> past; we're almost there.

And Alvaro has dealt with scalability.

---

From: "Marc G. Fournier" <[email-masked]>
Date: Sat, 05 Apr 2008 11:45:21 -0300

- --On Saturday, April 05, 2008 09:32:45 +0200 Magnus Hagander 
<[email-masked]> wrote:

> 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?

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 5 Apr 2008 11:09:24 -0400 (EDT)

Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 

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.

---

From: Tom Lane <[email-masked]>
Date: Sat, 05 Apr 2008 11:14:42 -0400

> 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

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 5 Apr 2008 11:22:00 -0400 (EDT)

> 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.

> because it doesn't get assigned until after the message is sent.

Right.

---

From: Alvaro Herrera <[email-masked]>
Date: Sat, 5 Apr 2008 13:25:15 -0400

> 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.

---

From: Alvaro Herrera <[email-masked]>
Date: Sat, 5 Apr 2008 16:49:19 -0400

> past; we're almost there.

Ok, we're one more step ahead -- things like
http://archives.postgresql.org/message-id/[email-masked]
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.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 5 Apr 2008 17:21:22 -0400 (EDT)

> as soon as I fix the remaining glitches.

OK, I updated my permanent URL references.

---

From: "Marc G. Fournier" <[email-masked]>
Date: Sat, 05 Apr 2008 19:43:59 -0300

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

- --

---

From: Alvaro Herrera <[email-masked]>
Date: Sat, 5 Apr 2008 19:26:17 -0400

> 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.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 5 Apr 2008 19:53:50 -0400 (EDT)

> as soon as I fix the remaining glitches.

FYI, this email URL is failing:

	http://archives.postgresql.org/message-id/[email-masked]

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=

---

From: Alvaro Herrera <[email-masked]>
Date: Sat, 5 Apr 2008 22:06:12 -0400

> 	http://archives.postgresql.org/message-id/[email-masked]

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

> 	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

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 5 Apr 2008 22:09:55 -0400 (EDT)

> 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.

---

From: "Marc G. Fournier" <[email-masked]>
Date: Sat, 05 Apr 2008 23:10:03 -0300

- --On Saturday, April 05, 2008 19:53:50 -0400 Bruce Momjian <[email-masked]> 
wrote:

>> http://archives.postgresql.org/message-id/[email-masked]
>> 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.
>>

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

- --

---

From: Alvaro Herrera <[email-masked]>
Date: Sat, 5 Apr 2008 22:22:00 -0400

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

That's because I just fixed it ;-)

---

From: "Marc G. Fournier" <[email-masked]>
Date: Sat, 05 Apr 2008 23:27:25 -0300

- --On Saturday, April 05, 2008 22:22:00 -0400 Alvaro Herrera 
<[email-masked]> wrote:

> Marc G. Fournier wrote:
>
>> - --On Saturday, April 05, 2008 19:53:50 -0400 Bruce Momjian
>> <[email-masked]>  wrote:
>>
>> > 	http://archives.postgresql.org/message-id/D9BA8B9B-A1CF-44E9-9F7A-B166875
>> > 	AEA [email-masked]
>>

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

- --

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 8 Apr 2008 08:41:49 -0400

> 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.

---

From: Gregory Stark <[email-masked]>
Date: Tue, 08 Apr 2008 14:11:30 +0100

> 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!

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 8 Apr 2008 09:34:14 -0400

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

[...]

> these attributes in the current format as sublist items under each major

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.)

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 8 Apr 2008 10:02:55 -0400 (EDT)

> spite of the fact that everyone else has started using them, seems a bit

I have offered to remove my web site pages.