Обсуждение: partial dump of patch queue to wiki
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@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'sPostgreSQL 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@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 >
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 festo getting them into a wiki in a way that is fast/efficiento updatingthe 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
Dave Page wrote: > 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. 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@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 4:55 PM, Bruce Momjian <bruce@momjian.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@gregsmith.com http://www.gregsmith.com Baltimore, MD
"Greg Smith" <gsmith@gregsmith.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@gregsmith.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@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: > 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@enterprisedb.com> writes:
> "Bruce Momjian" <bruce@momjian.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@enterprisedb.com> writes: > > "Bruce Momjian" <bruce@momjian.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.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@momjian.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@momjian.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@sss.pgh.pa.us> wrote: > Bruce Momjian <bruce@momjian.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@lists.commandprompt.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 addmerge, 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 havea 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@enterprisedb.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@hub.org MSN . scrappy@hub.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-----
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@commandprompt.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 patchesget 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 otherwisegetting 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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +