partial dump of patch queue to wiki

"Alvaro Herrera" <alvherre@commandprompt.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

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@commandprompt.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.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@momjian.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@mail.gmail.com.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@mail.gmail.com.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Alvaro Herrera <alvherre@commandprompt.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@commandprompt.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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce@momjian.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@gregsmith.com http://www.gregsmith.com Baltimore, MD

Greg Smith <gsmith@gregsmith.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@momjian.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@momjian.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@momjian.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@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.

Aidan Van Dyk <aidan@highrise.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