Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Thu, Jul 9, 2009 at 2:20 PM, Robert Haasrobertmh...@gmail.com wrote: On Jul 9, 2009, at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: We're now about a week away from the start of the July 2009 commitfest, and we need to make a decision about whether to start using http://commitfest.postgresql.org to manage it, or punt to the next commitfest and continue to use the wiki for July. While reorganizing my bookmarks for this I realized that there is a fairly significant bit of functionality that's entirely missing from the new app. With the wiki page, you could conveniently see what had been done lately by examining the page history. I don't see any equivalent capability in the new app. I find this fairly significant, as evidenced by the fact that I'd gone so far as to set up a bookmark for the history view. I'm not particularly wedded to the wiki page history in terms of what it looks like or how it functions, but I do feel a need to know what other people have done recently I'll fix this. Give me a couple days; my Internet access here at the family vacation spot is not compatible with git push. OK, this is a little bit quick-and-dirty, and I'm sure I'll get some, ah, gentle suggestions for improvement, but I've added an activity log to the app. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Jul 9, 2009, at 12:35 PM, Brendan Jurd wrote: We don't AFAIK collect data about these events. However, we could have certain actions trigger the creation of an automated comment (e.g., Status changed to Committed by petere) and let the aforementioned comment view suffice for a history. Our main system at work does that; any kind of status is stored as a raw, text note. It sucks. It makes trying to query for specific kinds of events difficult, and it wastes a bunch of space. It's a lot better to record machine-readable information for machine- created events. If you want to present it all as one, I suggest a union view that turns the machine-understood data into a human- understandable text format. -- Decibel!, aka Jim C. Nasby, Database Architect deci...@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
I think we might be better off just leaving the closed commitfests up on the wiki, and putting a notice on the app saying commitfests prior to July 2009 can be found at wiki.postgresql.org. +1. That's why we're switching technogies at the beginning of a dev cycle. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd dire...@gmail.com writes: We're now about a week away from the start of the July 2009 commitfest, and we need to make a decision about whether to start using http://commitfest.postgresql.org to manage it, or punt to the next commitfest and continue to use the wiki for July. While reorganizing my bookmarks for this I realized that there is a fairly significant bit of functionality that's entirely missing from the new app. With the wiki page, you could conveniently see what had been done lately by examining the page history. I don't see any equivalent capability in the new app. I find this fairly significant, as evidenced by the fact that I'd gone so far as to set up a bookmark for the history view. I'm not particularly wedded to the wiki page history in terms of what it looks like or how it functions, but I do feel a need to know what other people have done recently. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Em Thu, 09 Jul 2009 14:16:41 -0300, Tom Lane t...@sss.pgh.pa.us escreveu: I'm not particularly wedded to the wiki page history in terms of what it looks like or how it functions, but I do feel a need to know what other people have done recently. May be the new app could have a page with a filterable table log with some important columns like who do what on where and when. This could help, maybe with a RSS in that (like in git). []s Dickson S. Guedes http://pgcon.postgresql.org.br http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/10 Tom Lane t...@sss.pgh.pa.us: While reorganizing my bookmarks for this I realized that there is a fairly significant bit of functionality that's entirely missing from the new app. With the wiki page, you could conveniently see what had been done lately by examining the page history. I don't see any equivalent capability in the new app. You're right, the app currently lacks a view for this. And while it would be pretty easy to add a page that just lists the most recent comments in descending creation order, that would not show things like * patches being committed/rejected/punted; * patches changed to a different subsection; * changes to a patch's short name; * edits to existing comments. We don't AFAIK collect data about these events. However, we could have certain actions trigger the creation of an automated comment (e.g., Status changed to Committed by petere) and let the aforementioned comment view suffice for a history. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Thu, Jul 09, 2009 at 02:35:04PM -0300, Dickson S. Guedes wrote: This could help, maybe with a RSS in that (like in git). +1 for the RSS feed, if only because I think it sounds neat :) -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
We don't AFAIK collect data about these events. However, we could have certain actions trigger the creation of an automated comment (e.g., Status changed to Committed by petere) and let the aforementioned comment view suffice for a history. Can you put in a simple event-recording trigger for all changes? We can dress it up for easy viewing later, but if the data isn't collected, it will be impossible to recreate. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Josh Berkus j...@agliodbs.com writes: We don't AFAIK collect data about these events. However, we could have certain actions trigger the creation of an automated comment (e.g., Status changed to Committed by petere) and let the aforementioned comment view suffice for a history. Can you put in a simple event-recording trigger for all changes? +1. Just add an event log table. I think we'll wish we had one later. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Jul 9, 2009, at 12:16 PM, Tom Lane t...@sss.pgh.pa.us wrote: Brendan Jurd dire...@gmail.com writes: We're now about a week away from the start of the July 2009 commitfest, and we need to make a decision about whether to start using http://commitfest.postgresql.org to manage it, or punt to the next commitfest and continue to use the wiki for July. While reorganizing my bookmarks for this I realized that there is a fairly significant bit of functionality that's entirely missing from the new app. With the wiki page, you could conveniently see what had been done lately by examining the page history. I don't see any equivalent capability in the new app. I find this fairly significant, as evidenced by the fact that I'd gone so far as to set up a bookmark for the history view. I'm not particularly wedded to the wiki page history in terms of what it looks like or how it functions, but I do feel a need to know what other people have done recently I'll fix this. Give me a couple days; my Internet access here at the family vacation spot is not compatible with git push. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/10 Josh Berkus j...@agliodbs.com: We don't AFAIK collect data about these events. However, we could have certain actions trigger the creation of an automated comment (e.g., Status changed to Committed by petere) and let the aforementioned comment view suffice for a history. Can you put in a simple event-recording trigger for all changes? We can dress it up for easy viewing later, but if the data isn't collected, it will be impossible to recreate. I could, but a db trigger would have no awareness of which user made the change. That would make the information substantially less useful IMO. I've got access to the database but I'm not in a position to make changes to the app frontend. I'm therefore inclined to wait the prophesied couple days for Robert's proper fix for this problem than dropping in a trigger which will only tell us part of the story. Bear in mind that CF activity over the past week has been in the realm of 0-4 changes per 24 hours, so it's not like we are talking about huge amounts of throughput here. Making up the bulk of those changes were new patches coming in (which involves adding a comment so the change is already tracked) and patches getting committed (which is stored in -hackers and version control anyway). Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd dire...@gmail.com writes: Bear in mind that CF activity over the past week has been in the realm of 0-4 changes per 24 hours, so it's not like we are talking about huge amounts of throughput here. Well, it'll be more once commitfest actually starts, but in any case it's not going to be enough to make a log table be a resource hog. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
robertmh...@gmail.com (Robert Haas) writes: I suspect both are true, but in the unlikely event that we decide on some massive change to the system, we can either run the DBs in parallel as Tom suggests, or dump out the older data in Wiki markup and post it on there. But I can't imagine what we'd want to do that would even make us consider such drastic steps. Your example would not be a difficult migration, for instance. We had an ancient version of Bugzilla in use for quite a while; it was *SO* vastly different from modern versions that it wasn't remotely plausible to port the data from the old instance to a new one. I went and ran wget to pull all the contents of the old instance, turning that into a series of static web pages. No longer updatable, but certainly browsable. Once a CommitFest is complete, I could easily see making a summary of it, as a series of static web pages. No need for a database anymore altogether ;-). -- select 'cbbrowne' || '@' || 'linuxfinances.info'; http://linuxdatabases.info/info/spreadsheets.html I'd give my right arm to be ambidextrous! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd escribió: Short answer: I could bring across the old commitfests but it would take a couple hours at best per commitfest and result in little bits of data loss here and there. I think we might be better off just leaving the closed commitfests up on the wiki, and putting a notice on the app saying commitfests prior to July 2009 can be found at wiki.postgresql.org. Agreed; if it requires manual work let's leave them in the wiki. -- Alvaro Herrerahttp://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
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Hi folks, We're now about a week away from the start of the July 2009 commitfest, and we need to make a decision about whether to start using http://commitfest.postgresql.org to manage it, or punt to the next commitfest and continue to use the wiki for July. Robert and I have been upgrading the app in response to the feedback so far, and personally I think the app is already a far superior tool to the wiki for managing a commitfest. I think we should use it for 2009-07. What we need in order to proceed is: a) a viable consensus from patch reviewers/committers to switch over, b) an email out to -hackers about the new app, c) updates to the wiki developer pages pointing to the new app, and d) decommissioning the wiki July CF. I can do b), c) and d) but I could use your help in obtaining a). If you think we should switch over, please say so. If you think the app needs some tweaking, please say so but let's switch over anyway and make those tweaks as we go. If you think the app is fundamentally less useful than the wiki, please say so and we'll work out whether we can resolve your objection in time for the start of the CF. Thanks in advance for your comments. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd dire...@gmail.com wrote: If you think the app is fundamentally less useful than the wiki, please say so and we'll work out whether we can resolve your objection in time for the start of the CF. It's been down for a while now. I don't know if this is causal, but the failure seemed to start when I went into the patch I submitted, and clicked on the link to edit a comment I added. At any rate, the reliability doesn't seem to match the wiki yet, which would seem to be a pretty fundamental thing to fix before switching. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd dire...@gmail.com wrote: If you think the app is fundamentally less useful than the wiki, please say so and we'll work out whether we can resolve your objection in time for the start of the CF. Oh, sure -- I post about it being down, and seconds after I hit send it comes up again. :-/ Do we know that cause? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/8 Kevin Grittner kevin.gritt...@wicourts.gov: Oh, sure -- I post about it being down, and seconds after I hit send it comes up again. :-/ Do we know that cause? Well, no, since I've never observed it being down and I really have no idea what you mean by that. Maybe you could describe the symptoms you observed? Was the webserver totally uncontactable, or was it an error in the web app itself? Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd dire...@gmail.com wrote: Maybe you could describe the symptoms you observed? Was the webserver totally uncontactable, or was it an error in the web app itself? When I clicked the link to edit the comment, it clocked until the browser timed out. So then I tried the URL for the main page, and it again clocked until the browser timed out. I then tried again on the main page, and it clocked for a minute, so I posted the message about it being down. Moments after I sent that, the page came up. If anyone else was hitting the site and it was working, perhaps the problem could have been elsewhere. (Our network or our Internet path to the site could have had some temporary issue.) -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote: We're now about a week away from the start of the July 2009 commitfest, and we need to make a decision about whether to start using http://commitfest.postgresql.org to manage it, or punt to the next commitfest and continue to use the wiki for July. I have the following concern: Likely, this tool and the overall process will evolve over time. To pick an example that may or may not be actually useful, in the future we might want to change from a fixed list of patch sections to a free list of tags, say. Then someone might alter the application backend, and we'd use that new version for the next commit fest at the time. What will that do to the data of old commit fests? With the wiki, the data of the old fests will pretty much stay what is was, unless we change the wiki templates in drastic ways, as I understand it. But if we did changes like the above, or more complicated things, perhaps, what will happen? Perhaps we simply don't care about the historical data. But if we do, we better have pretty high confidence that the current application will do for a while or is easily upgradable. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Peter Eisentraut pete...@gmx.net wrote: in the future we might want to change from a fixed list of patch sections to a free list of tags, say. Then someone might alter the application backend, and we'd use that new version for the next commit fest at the time. What will that do to the data of old commit fests? Certainly you see how trivial that conversion would be. If that were the worst case anyone could even imagine, it would be a pretty strong argument that the schema is more than good enough to proceed. Do you see anything fundamentally wrong with the structure in terms of long term goals? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Peter Eisentraut pete...@gmx.net writes: With the wiki, the data of the old fests will pretty much stay what is was, unless we change the wiki templates in drastic ways, as I understand it. But if we did changes like the above, or more complicated things, perhaps, what will happen? Perhaps we simply don't care about the historical data. But if we do, we better have pretty high confidence that the current application will do for a while or is easily upgradable. I'm not convinced that we care in the least about commitfests that are more than a fest or two back; especially since the mailing lists archive all the interesting underlying data. However, if we did, the answer doesn't seem that hard: keep the old database instance on-line for serving up the old data, and put a new one beside it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Jul 7, 2009, at 2:14 PM, Peter Eisentraut pete...@gmx.net wrote: On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote: We're now about a week away from the start of the July 2009 commitfest, and we need to make a decision about whether to start using http://commitfest.postgresql.org to manage it, or punt to the next commitfest and continue to use the wiki for July. I have the following concern: Likely, this tool and the overall process will evolve over time. To pick an example that may or may not be actually useful, in the future we might want to change from a fixed list of patch sections to a free list of tags, say. Then someone might alter the application backend, and we'd use that new version for the next commit fest at the time. What will that do to the data of old commit fests? I don't see this as being much of an obstacle. I have migrated data far more complex, and I venture to say that most of the rest of the regular posters in this forum have too. With the wiki, the data of the old fests will pretty much stay what is was, unless we change the wiki templates in drastic ways, as I understand it. But if we did changes like the above, or more complicated things, perhaps, what will happen? Perhaps we simply don't care about the historical data. But if we do, we better have pretty high confidence that the current application will do for a while or is easily upgradable. I suspect both are true, but in the unlikely event that we decide on some massive change to the system, we can either run the DBs in parallel as Tom suggests, or dump out the older data in Wiki markup and post it on there. But I can't imagine what we'd want to do that would even make us consider such drastic steps. Your example would not be a difficult migration, for instance. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Haas escribió: I suspect both are true, but in the unlikely event that we decide on some massive change to the system, we can either run the DBs in parallel as Tom suggests, or dump out the older data in Wiki markup and post it on there. But I can't imagine what we'd want to do that would even make us consider such drastic steps. Your example would not be a difficult migration, for instance. By the way, if the migration of the current commitfest was an automatic procedure, is there a chance that the old commitfests can be migrated as well? -- Alvaro Herrerahttp://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
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/8 Alvaro Herrera alvhe...@commandprompt.com:
By the way, if the migration of the current commitfest was an automatic
procedure, is there a chance that the old commitfests can be migrated as
well?
It wasn't really automatic as such. I used a few scripts that I saved
in case we needed to use them again, but there was also quite a bit of
manual massage of the data required in between those script runs.
There are a few minor incompatibilities, for example the wiki allows
you to put links to the mailing list archives anywhere in a review or
comment with {{messageLink}} but the app has the message-id as a
separate field. I like the way the data is laid out in the app
better, but it makes it difficult to migrate comments with multiple
{{messageLinks}} in them.
Short answer: I could bring across the old commitfests but it would
take a couple hours at best per commitfest and result in little bits
of data loss here and there. I think we might be better off just
leaving the closed commitfests up on the wiki, and putting a notice on
the app saying commitfests prior to July 2009 can be found at
wiki.postgresql.org.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/8 Peter Eisentraut pete...@gmx.net: I have the following concern: Likely, this tool and the overall process will evolve over time. To pick an example that may or may not be actually useful, in the future we might want to change from a fixed list of patch sections to a free list of tags, say. Then someone might alter the application backend, and we'd use that new version for the next commit fest at the time. What will that do to the data of old commit fests? Same thing that always happens when you make big-picture schema changes to an app ... you either migrate the data or you leave a historical instance in place. NB moving from topics to tags is *not* a big-picture change and wouldn't invalidate past data in the slightest. With the wiki, the data of the old fests will pretty much stay what is was, unless we change the wiki templates in drastic ways, as I understand it. Actually the wiki makes this more difficult. Changes to the templates are limited to adding new keyword arguments. If you want to, say, insert a new positional argument into one of the templates, you need to make a copy of all the affected templates and migrate all existing template calls to the historical copy. We had to do this once. It wasn't pleasant. So, even for minor changes to layout (like the tags thing you mentioned) result in having to leave a historical instance of the system in place. Whereas having the data in a relational database makes it far more likely that we can just migrate across small, incremental changes. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/3 Robert Haas robertmh...@gmail.com: The application stamps comments with the community login of the person who left them, but the import stamped them with names instead. This is actually of some significance, since the app will allow you to edit your own comments but not those of other people. We could probably fix this if someone can give us access to (or a dump of) the realname to username mappings from the community login DB. Nobody came forward with a mapping of real names to community logins, so I went ahead and did this the dumb, slow way (eyeballing the wiki history and manually creating a mapping for the names we have in the commitfest app so far). I've updated the patch comment creator field with the login names I was able to map, but there are a few contributors who either don't have a community login, or haven't used the wiki. In those cases I left the name as-is. You should now be able to edit comments that you created. If you think you should be able to edit a comment, but you can't because the login name is wrong, let me know and I'll fix it up. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Jul 3, 2009, at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. I think what you guys must be seeing is that the topics are not in quite the same order. As far as I can tell, the ordering of patches within topics is absolutely identical. No, what we're complaining about is the ordering of comments for a single patch. If you look at http://commitfest.postgresql.org/action/commitfest_view?id=2 in some cases there are Comments before the Patch itself, and in some cases after, but more often than not the original Patch is at the bottom. Oh, duh. I totally missed that. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Brendan Jurd dire...@gmail.com writes: Please let us know if you encounter any problems with withe app, or have suggestions for improvement. It looks like every patch and comment is timestamped ... but with yesterday (the time of data import, I suppose). This is much worse than useless. If you can't get the actual date, leave it off. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
I tried the New Patch Comment feature. It's absolutely horrid. I get a page showing a comment type button, one line for Message-ID, and one line for Content. No explanation of what those are, and no visibility any more of the patch I'm trying to comment on. I have no idea what I'm supposed to do here, and if I were trying to respond to someone else's comment, it would be nice to be able to see that comment. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? I'm not sure why you would think that it's not stable. It's not stable in the sense that it won't always be the open CommitFest, but it's certainly stable in the sense that it will always be the same CommitFest that it is now. It's actually MORE stable than the wiki, since the wiki doesn't permit you to change the name of the CommitFest without also changing the URL. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. You've asked to view a commitfest. The id of that commitfest is 2. What more do you want to know? If you're advocating for the use of wiki-style names, where the URL actually contains the name of the things that it points to, then you have incompatible requirements, because things can, do, and will continue to get renamed. If the URL is built around the name, then the URL will change when the name changes. If you want it to be stable, a non-natural key is your only option. And I frankly don't see what's wrong with that. We regularly deal in message-IDs or other links to the archives, which are certainly totally opaque. Fortunately, they're links. You can click on them, and then you see what they are. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 10:40 AM, Tom Lanet...@sss.pgh.pa.us wrote: I tried the New Patch Comment feature. It's absolutely horrid. I get a page showing a comment type button, one line for Message-ID, and one line for Content. No explanation of what those are, and no visibility any more of the patch I'm trying to comment on. I have no idea what I'm supposed to do here, and if I were trying to respond to someone else's comment, it would be nice to be able to see that comment. The message-ID is the (optional) ID of a message you'd like to link to. The comment is the text of your comment. If there's a legitimate reason for confusion here, I have no idea what it is. I agree that the comment box probably needs to be converted into a text area rather than a single line. But I also think that comments on the wiki should be kept short. If you have more than a few lines of text, there's a good chance you should be sending an email to -hackers and then linking to it. There are some projects that are managed using a discussion forum or a bug tracker and as far as I know you've always been opposed to that, as am I. So complaining that this system doesn't work that way seems disingenuous. Also, if you think this interface is inconvenient for leaving a comment, have you tried doing it on the wiki lately? Anyway, I'm sure there's room for improvement in this tool. I intend to make improvements. I still think it's already better than the wiki. Moving things to a different commitfest or a different section of the same commitfest (like, particularly relevant to you, the committed section) is takes me minutes on the wiki and seconds with this app. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Haas wrote: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? I'm not sure why you would think that it's not stable. It's not stable in the sense that it won't always be the open CommitFest, but it's certainly stable in the sense that it will always be the same CommitFest that it is now. It's actually MORE stable than the wiki, since the wiki doesn't permit you to change the name of the CommitFest without also changing the URL. We have redirects to the previous, open, and in-progress commitfests in the wiki (see http://wiki.postgresql.org/wiki/CommitFest). Those redirects are bookmarkable. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:40 AM, Tom Lanet...@sss.pgh.pa.us wrote: I tried the New Patch Comment feature. It's absolutely horrid. I get a page showing a comment type button, one line for Message-ID, and one line for Content. No explanation of what those are, and no visibility any more of the patch I'm trying to comment on. I have no idea what I'm supposed to do here, and if I were trying to respond to someone else's comment, it would be nice to be able to see that comment. The message-ID is the (optional) ID of a message you'd like to link to. The comment is the text of your comment. If there's a legitimate reason for confusion here, I have no idea what it is. It's not apparent that the message-ID is optional, nor what it is for really. And the fact that the boxes are the same size leaves one wondering what the comment is supposed to be too. The basic complaint is that the page assumes you already know what to do with it. Given the vast amount of white space left behind by the omission of any context information, it doesn't seem unreasonable to include a couple sentences of explanation. I agree that the comment box probably needs to be converted into a text area rather than a single line. But I also think that comments on the wiki should be kept short. If you have more than a few lines of text, there's a good chance you should be sending an email to -hackers and then linking to it. There are some projects that are managed using a discussion forum or a bug tracker and as far as I know you've always been opposed to that, as am I. So complaining that this system doesn't work that way seems disingenuous. Also, if you think this interface is inconvenient for leaving a comment, have you tried doing it on the wiki lately? I spent a large part of the last year leaving comments on the wiki. Yeah, it was a bit tedious to use wiki markup, but at least all the information you needed was a click away. (The wiki wasn't designed on the assumption that users already know how to use it.) And the context didn't all disappear from view the moment you wanted to add something. I still think it's already better than the wiki. Maybe to you, but right now I think the wiki is far more usable and far more flexible. It hasn't got arbitrary assumptions about what size comment people are allowed to leave, for example. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 11:46 AM, Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote: Robert Haas wrote: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: On suggestions for improvement: I need to be able to bookmark the commitfest summary list (whichever page is equivalent to the old wiki page). The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I can also imagine people wanting to refer to particular patch entries in email, but those URLs are no better. Could we pay some attention to using URLs that are stable and self-explanatory? I'm not sure why you would think that it's not stable. It's not stable in the sense that it won't always be the open CommitFest, but it's certainly stable in the sense that it will always be the same CommitFest that it is now. It's actually MORE stable than the wiki, since the wiki doesn't permit you to change the name of the CommitFest without also changing the URL. We have redirects to the previous, open, and in-progress commitfests in the wiki (see http://wiki.postgresql.org/wiki/CommitFest). Those redirects are bookmarkable. We can do the same thing here. It's a SMOP. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Friday 03 July 2009 11:50:29 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, 2009-07-03 at 14:06 -0400, Robert Treat wrote: On Friday 03 July 2009 11:50:29 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. O.k. I am probably blowing something out of the water here but do we need yet another domain? wiki.postgresql.org/commitfest/2009/07 (or www) Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 11:50 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. Backing up for a moment to ten thousand feet here, I posted a link to this web app on May 26th. I received several comments on it, all of them positive, including some constructive feedback from you which I took to heart. It is now July 1st, and I am trying very hard to get ready for the next CommitFest, which I have agreed to manage. So I need to determine whether there is some finite number of changes of manageable size that I can make to get this to a state where we can use it, or whether I should give up hope now and go back to the wiki. The latter outcome would be disappointing to me, but that's where we're going to end up if we can't actually boil this down to a specific list of changes to be made. I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. First of all, one of your arguments is that I might want to change them later. I can promise you that I won't want to do any such thing, or at the VERY least that the old URLs will always be supported. There would be a sort of perverse irony to me changing the application to use a different kind of key for the reason that Tom Lane is afraid that some day I might want to use a different kind of key. Secondly, if we are going to make a change, it would be nice to know what the use case is for the change and to have a set of requirements that are not mutually contradictory. It is not possible to both assign the URLs to the pages based on the names of the objects to which the refer (which are changeable) and to guarantee that the URLs will never change. So you can either have URL stability or you can have wiki-style names, but you can't have both, unless perhaps you include both the ID and the name in the link but make the name just decoration. I am frankly at a loss to why this is a big deal: if you bookmark the page, your browser will record the page title; if you use firefox, you can also find by page title in the address bar. And we've never had pages for individual patches before anyway, so why should it now be critical how those links are formatted? But if it is critical then please describe exactly how you think it should work. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 2:10 PM, Joshua D. Drakej...@commandprompt.com wrote: O.k. I am probably blowing something out of the water here but do we need yet another domain? Because it's installed on a different VM and I don't want to move it just to make the URL look different? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Treat wrote: On Friday 03 July 2009 11:50:29 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. I believe Tom wants details removed from the URL, so future implementation changes don't either a) break bookmarks because more stuff is needed in the URL or b) don't break bookmarks but be limited to existing sutff in the URL (ie. hacky work arounds). If that's the case, your best best is to use some kind of key, like 16 random bytes displayed in hex, that looks up the data. IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:00 PM, Andrew Chernowa...@esilo.com wrote: The current URL seems to be http://commitfest.postgresql.org/action/commitfest_view?id=2 which is both opaque as can be and not looking like it's intended to be stable over the long term. I'm not sure why you would think that it's not stable. Because it's exposing three or four details of your implementation, which you might wish to change later. I'm also not sure what you would think that it's not self-explanatory, since it looks pretty self explanatory to me. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. I believe Tom wants details removed from the URL, so future implementation changes don't either a) break bookmarks because more stuff is needed in the URL or b) don't break bookmarks but be limited to existing sutff in the URL (ie. hacky work arounds). If that's the case, your best best is to use some kind of key, like 16 random bytes displayed in hex, that looks up the data. I *am* using some kind of key. Specifically, in integer derived from a serial column. It's just as stable as 16 random bytes displayed in hex, but a lot shorter and easier to remember, if you're the sort of person who likes to remember URLs. :-) IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? Sorry, I'm not following this part. ...Robet -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Hi, Le 3 juil. 09 à 20:44, Robert Haas a écrit : - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. May I suggest something looking about like: http://commitfest.postgresql.org/current http://commitfest.postgresql.org/open http://commitfest.postgresql.org/in-progress http://commitfest.postgresql.org/previous With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. Your software seems to be better than a wiki, but its potential users are expressing needs and bikescheding. I think you'd better accept both kind of changes as long as it's not making your life much harder than you'd want. Frankly, what URL looks better: http://commitfest.postgresql.org/action/commitfest_view?id=2 http://commitfest.postgresql.org/2009/07 Oh, and while at it, I don't foresee that we would want the commitfest of july 2009 to change its name but not the semantic URL pointing to its management. Or if it's ever wanted, as has been said, have a look at Apache Rewrite Rules system, it's made for supporting content being moved. Something in the spirit of: RedirectPermanent /2009/07 /2009/08 While at it, I imagine that within a given commit fest, a single patch will have a stable shortname, or if it comes to change, we could accept that the URL too change: http://commitfest.postgresql.org/action/patch_view?id=71 http://commitfest.postgresql.org/2009/07/Synch_Rep http://commitfest.postgresql.org/current/Synch_Rep Now, rather than following the names with apache setup, maybe you could add something like some history tables tracking short name changes (maybe some ON UPDATE trigger would do), so that referring to an older name would send a HTTP 302 redirect to the new name URL? I'd like your work to be useful for all of us and appreciated to its real value, and those changes well seem like user interface improvements rather than basic structure or behavior questioning. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
I *am* using some kind of key. Specifically, in integer derived from a serial column. It's just as stable as 16 random bytes displayed in hex, but a lot shorter and easier to remember, if you're the sort of person who likes to remember URLs. :-) Wasn't aware of exately what you were doing. It sounded like multiple things were in the query_string. If its already a single key, than there is no need to use a different key. And no, I don't like remebering URLs ... thus all the fuss about breaking bookmarks ;-) It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? Sorry, I'm not following this part. Using a URL to encode when something occurred was being offered as a solution to know what commitfest it is. I'm not sure where your confusion is? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:08 PM, Dimitri Fontainedfonta...@hi-media.com wrote: Your software seems to be better than a wiki, but its potential users are expressing needs and bikescheding. I think you'd better accept both kind of changes as long as it's not making your life much harder than you'd want. Frankly, what URL looks better: http://commitfest.postgresql.org/action/commitfest_view?id=2 http://commitfest.postgresql.org/2009/07 We've definitely gotten to the harder than I'd want point at this point. Oh, and while at it, I don't foresee that we would want the commitfest of july 2009 to change its name but not the semantic URL pointing to its management. Or if it's ever wanted, as has been said, have a look at Apache Rewrite Rules system, it's made for supporting content being moved. Something in the spirit of: RedirectPermanent /2009/07 /2009/08 I humbly submit that it's insane to thing about editing httpd.conf every time somebody renames an object. The point here is to *reduce* the administrative burden of maintaining this thing. While at it, I imagine that within a given commit fest, a single patch will have a stable shortname, or if it comes to change, we could accept that the URL too change: http://commitfest.postgresql.org/action/patch_view?id=71 http://commitfest.postgresql.org/2009/07/Synch_Rep http://commitfest.postgresql.org/current/Synch_Rep Now, rather than following the names with apache setup, maybe you could add something like some history tables tracking short name changes (maybe some ON UPDATE trigger would do), so that referring to an older name would send a HTTP 302 redirect to the new name URL? So, the good thing about the current system is that the URL *doesn't* change and you *don't* need complicated bookkeeping to remember every URL you've ever assigned to the thing to get it. I am well aware that it's possible to design a system that does this, but what benefit do we get out of it? Making it possible to tell what a URL points to without clicking on it, for those occasions when you're stranded on a desert island with a URL and no Internet access? There's a subtle and pernicious danger of the system you're proposing, too. If we regularly change the URLs that refer to certain objects, but compensate for that by remembering the whole history of URLs that have ever referred to that object, then there will multiple URLs that refer to the same object, of which all but one will contain WRONG information about what that link points to. The http://commitfest.postgresql.org/2009/07/Sync_Rep link, for example, might imply to someone that the patch is in the 2009-07 commitfest, but in fact it may well have been moved to the 2009-11, 2010-01, or 2010-03 commitfest, or we might have finally come to our senses and realized that it ought to be called streaming rep and rename it. It's true that the current URLs, without some sort of accompanying text, do not tell you what they point to. But no information can often be better than disinformation. I'd like your work to be useful for all of us and appreciated to its real value, and those changes well seem like user interface improvements rather than basic structure or behavior questioning. I'd like that, too. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:15 PM, Andrew Chernowa...@esilo.com wrote: I *am* using some kind of key. Specifically, in integer derived from a serial column. It's just as stable as 16 random bytes displayed in hex, but a lot shorter and easier to remember, if you're the sort of person who likes to remember URLs. :-) Wasn't aware of exately what you were doing. It sounded like multiple things were in the query_string. If its already a single key, than there is no need to use a different key. And no, I don't like remebering URLs ... thus all the fuss about breaking bookmarks ;-) Right. The current system has exactly ZERO chance of breaking any bookmarks, and all of the proposed alternatives are much more likely to do so. It's impossible to know that this is commitfest 2009-07. commitfest.postgresql.org/2009/07 ? That, or any similar scheme, seems easily doable with a little apache rewrite magic and some programming. See my blog urls for one such example. IMHO, I don't see much gain to encoding the date into the url either. This is not a great way of telling the user when something occurred. A lookup is going to occur either way, so why not get all data at once using a single method? Sorry, I'm not following this part. Using a URL to encode when something occurred was being offered as a solution to know what commitfest it is. I'm not sure where your confusion is? The suggestion was to encode the start date of the CommitFest in the URL, instead of using a non-natural key. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: Backing up for a moment to ten thousand feet here, I posted a link to this web app on May 26th. I received several comments on it, all of them positive, including some constructive feedback from you which I took to heart. It is now July 1st, and I am trying very hard to get ready for the next CommitFest, which I have agreed to manage. So I need to determine whether there is some finite number of changes of manageable size that I can make to get this to a state where we can use it, or whether I should give up hope now and go back to the wiki. I think it's probably fixable, if you've got some time to put into it between now and the 15th. What's being griped about is user interface details, and it's not surprising that you as the author didn't see these things the same way a new user would. From what I've been able to see, the underlying functionality is mostly there, but it needs some usability/presentation tweaking. I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. Given your item 3 above, I think we can live with the URLs otherwise. One other thing I was noticing is that the items for a particular patch seem to be listed in reverse date order. Personally I find this strange and would prefer newest-at-the-bottom --- in particular, having the patch itself at the bottom doesn't seem especially usable. We might need to take a vote on that though, since I suppose some people like newest-at-the-top. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:27 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Backing up for a moment to ten thousand feet here, I posted a link to this web app on May 26th. I received several comments on it, all of them positive, including some constructive feedback from you which I took to heart. It is now July 1st, and I am trying very hard to get ready for the next CommitFest, which I have agreed to manage. So I need to determine whether there is some finite number of changes of manageable size that I can make to get this to a state where we can use it, or whether I should give up hope now and go back to the wiki. I think it's probably fixable, if you've got some time to put into it between now and the 15th. What's being griped about is user interface details, and it's not surprising that you as the author didn't see these things the same way a new user would. From what I've been able to see, the underlying functionality is mostly there, but it needs some usability/presentation tweaking. Thanks, that is really good news. I agree that the presentation and usability need some work and I'm trying to address those concerns as expediently as I can. Part of my angst is that I am going to have only sporadic Internet access for the next week, so what I can't get done today (while my wife wonders why I am doing a second job on a holiday for no money) probably isn't going to happen for a bit, and I would like to get cut over so that Brendan doesn't have to keep manually replicating changes between the systems. I will see if I can make the changes below happen today. I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. With respect to the issue of the page URLs, I'm very unconvinced of the value of making a change. Given your item 3 above, I think we can live with the URLs otherwise. /me feels like he has dodged a bullet. One other thing I was noticing is that the items for a particular patch seem to be listed in reverse date order. Personally I find this strange and would prefer newest-at-the-bottom --- in particular, having the patch itself at the bottom doesn't seem especially usable. We might need to take a vote on that though, since I suppose some people like newest-at-the-top. I think it IS newest at the bottom, and I agree that that is how it should be. 24 hours ago it was alpha by topic and then alpha by patch name, but now it is topic by sortorder, then topic by name, then patch by ascending ID number (which works out to newest at the bottom). I thought the other way would be OK, but after Brendan and I imported the data we both said that sucks, so it got changed last night around midnight Eastern +/- an hour. One of the things that I would like to add in the future is the ability to assign a patch a shortname. This would be useful for building command-line tools to interface with the system, e.g. download the sepgsql patch. The idea would be that these names would be stable, though of course it's hard to see how to guarantee that 100%. I am still trying to work out in my mind how best to set that up, though, so it's probably not going to happen right away unless someone else is prepared to do some of the legwork. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com wrote: I think it IS newest at the bottom, and I agree that that is how it should be. It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Kevin Grittner kevin.gritt...@wicourts.gov writes: Robert Haas robertmh...@gmail.com wrote: I think it IS newest at the bottom, and I agree that that is how it should be. It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Tom Lane t...@sss.pgh.pa.us wrote: Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Just for purposes of conversion, or as a long-term behavior? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Just for purposes of conversion, or as a long-term behavior? Well, right at the moment I was just thinking of the conversion problem, but it wouldn't be a horrible idea to make it a permanent behavior for entries that include a message reference. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 3:40 PM, Robert Haasrobertmh...@gmail.com wrote: I accept the need for and am willing to make the following changes: - Changing the patch comment field from type text to type textarea and integrating it into the patch view page to provide context. - Adding a note to the effect that the message ID is optional. - Adding stable links with mnemonic names for the open, in progress, and most recently closed commitfests. Done. Done. Done. You guys are harder to please than my boss. He doesn't quite know for sure which things are possible. :-) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Robert Haas robertmh...@gmail.com wrote: I think it IS newest at the bottom, and I agree that that is how it should be. It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. I think what you guys must be seeing is that the topics are not in quite the same order. As far as I can tell, the ordering of patches within topics is absolutely identical. If you see a counterexample, please point it out. If you want to fix the order of the topics, click on the CommitFest Topics link in the upper lefthand corner of the page and frobnicate the sort order. What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Brendan, is this something that you can work on? Or does anyone else have some time to put into it? And do we have to fix this before we can declare the new system live, or can we catch up after the fact? Because replicating changes from the old system to the new is a bit of a pain in the neck. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/4 Robert Haas robertmh...@gmail.com: On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: What are the chances that the date or timestamp of the corresponding wiki modification could be put onto the patch and comment lines? (One would hope that could be done with a script, rather than by hand) Currently, it seems that most or all of the entries are links to archived messages. Scraping the date from the underlying message would be the best thing. Brendan, is this something that you can work on? I will take a stab at it. I think Tom's suggestion of harvesting the time of the mail message from the archives could do the job. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 3, 2009 at 4:00 PM, Tom Lanet...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: It seems to be inconsistent. Probably because everything wound up with the same date, the order is probably more-or-less random. Yeah, I think that's what I'm seeing. I think what you guys must be seeing is that the topics are not in quite the same order. As far as I can tell, the ordering of patches within topics is absolutely identical. No, what we're complaining about is the ordering of comments for a single patch. If you look at http://commitfest.postgresql.org/action/commitfest_view?id=2 in some cases there are Comments before the Patch itself, and in some cases after, but more often than not the original Patch is at the bottom. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/4 Tom Lane t...@sss.pgh.pa.us: No, what we're complaining about is the ordering of comments for a single patch. Now moot, since I've successfully pulled the dates for all comments with a message-id from the archives, and updated the database accordingly. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/3 Robert Haas robertmh...@gmail.com: Also, we're currently missing the reviewer names due to limitations of the import script; Brendan is fixing this. Update: The reviewer names have now been populated. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
On Fri, Jul 3, 2009 at 12:34 AM, Brendan Jurddire...@gmail.com wrote: 2009/7/3 Robert Haas robertmh...@gmail.com: Also, we're currently missing the reviewer names due to limitations of the import script; Brendan is fixing this. Update: The reviewer names have now been populated. looks good... now, how can i mark a patch as being reviewed? or i have to told you in order to you mark it? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [pgsql-www] commitfest.postgresql.org
2009/7/3 Jaime Casanova jcasa...@systemguards.com.ec: On Fri, Jul 3, 2009 at 12:34 AM, Brendan Jurddire...@gmail.com wrote: 2009/7/3 Robert Haas robertmh...@gmail.com: Also, we're currently missing the reviewer names due to limitations of the import script; Brendan is fixing this. Update: The reviewer names have now been populated. looks good... now, how can i mark a patch as being reviewed? or i have to told you in order to you mark it? Until we have a solid consensus to switch to using the new app, please continue to make your changes on the wiki. I'll replicate the changes by hand as we go until switchover. If you'd like to make your changes on the app yourself and save me the trouble, please do! Just select the patch you're interested in, click edit patch on the upper right and change the status and/or reviewer fields as required. Please let us know if you encounter any problems with withe app, or have suggestions for improvement. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
