Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Aug 17, 2006, at 3:40 PM, Alvaro Herrera wrote: The searching capabilities in debbugs are, well, non-existent, which is a real problem in my mind. Well, we can set up our own indexing, like Oleg and Teodor have done in http://www.pgsql.ru/ That seems like quite a hack for something that should be built-in... it also severely limits searchability. For example, it's very important to be able to do things like ignore closed bugs when you're searching. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On 8/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote: Alvaro Herrera wrote: Have you tried to use debbugs? If you can find up-to-date source code for debbugs, we might continue that line of thought. http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html ( bzr get http://bugs.debian.org/debbugs-source/mainline/ ) The searching capabilities in debbugs are, well, non-existent, which is a real problem in my mind. As its mail based, it delegates searching to mail archive search tools. -- marko ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Marko Kreen wrote: On 8/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote: Alvaro Herrera wrote: Have you tried to use debbugs? If you can find up-to-date source code for debbugs, we might continue that line of thought. http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html ( bzr get http://bugs.debian.org/debbugs-source/mainline/ ) The searching capabilities in debbugs are, well, non-existent, which is a real problem in my mind. As its mail based, it delegates searching to mail archive search tools. Why are we even dabating a system when it has been reported that the authors believe it is completely unsuitable for use by the PostgreSQL project? cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Andrew, Why are we even dabating a system when it has been reported that the authors believe it is completely unsuitable for use by the PostgreSQL project? Not *completely*. More that it would take a couple dozen hours of work to make it good for us, and the resulting version then couldn't be synched with the Debian version. Mind you, it would take an equal amount of time to add an e-mail-comment interface to Bugzilla, but BZ would then probably accept the patch. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Josh Berkus josh@agliodbs.com writes: On the other hand, a lot of my personal dislike of BugZilla seems to be based on being forced to use old versions. A lot of the stuff I hate about it has been fixed in the current version. Does that include it being basically a web-only interface? I'm listed on various mozilla bugs and occasionally get notifications of updates but I can't reply to those notifications and I'm not about to fire up a browser and log in and search for the bug just to add comments. I expect if you set up a web-based interface it won't be a matter of people digging in heels so much as just being indifferent to it. And like most projects the bugs will just accumulate and not get feedback. Incidentally, does it also fix the issue with the database schema where the entire set of comments is stored in a single field of a single record and so when two people comment on a bug at the same time one stomps on the others changes? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
I expect if you set up a web-based interface it won't be a matter of people digging in heels so much as just being indifferent to it. And like most projects the bugs will just accumulate and not get feedback. And which projects would these be? Oddly enough it might surprise you that the web has really matured. All kinds of people use it now. You should really check it out. ;) Sincerely, Joshua D. Drake Incidentally, does it also fix the issue with the database schema where the entire set of comments is stored in a single field of a single record and so when two people comment on a bug at the same time one stomps on the others changes? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Gregory Stark [EMAIL PROTECTED] writes: I'm listed on various mozilla bugs and occasionally get notifications of updates but I can't reply to those notifications and I'm not about to fire up a browser and log in and search for the bug just to add comments. It's really not that painful: every email bugzilla sends includes the URL of the bug page. It's one click to visit the page, assuming your mail and web tools are well enough integrated that you can readily visit a URL given in text email. (If not, consider joining the 21st century ;-)) I think actually the weak spot of bugzilla for our purposes will be the problem of transferring original email reports into BZ entries. The volunteer(s) who do that work are probably going to want a tool better adapted to that purpose than the standard BZ bug entry page ... but we'll likely want to do some customization work on our BZ anyway, so I don't see that as a fatal objection. The bottom line here is that there will not be any tool that is perfect for our purposes out-of-the-box. Well, it's all open source, we can scratch our own itch. What we need more than any specific tool is a commitment from someone to put effort into adapting the tool to our needs. (Given that reality, the quality of the tool's existing source code needs to figure strongly in our decision. If BZ is still as ugly as Josh remembers it being, that'd be a strike against it.) regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Gregory Stark wrote: Josh Berkus josh@agliodbs.com writes: On the other hand, a lot of my personal dislike of BugZilla seems to be based on being forced to use old versions. A lot of the stuff I hate about it has been fixed in the current version. Does that include it being basically a web-only interface? I'm listed on various mozilla bugs and occasionally get notifications of updates but I can't reply to those notifications and I'm not about to fire up a browser and log in and search for the bug just to add comments. I expect if you set up a web-based interface it won't be a matter of people digging in heels so much as just being indifferent to it. And like most projects the bugs will just accumulate and not get feedback. Yea, I'm planning on ignoring the bug tracker until we decide I can stop doing what I do already. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: I'm listed on various mozilla bugs and occasionally get notifications of updates but I can't reply to those notifications and I'm not about to fire up a browser and log in and search for the bug just to add comments. It's really not that painful: every email bugzilla sends includes the URL of the bug page. It's one click to visit the page, assuming your mail and web tools are well enough integrated that you can readily visit a URL given in text email. (If not, consider joining the 21st century ;-)) I think actually the weak spot of bugzilla for our purposes will be the problem of transferring original email reports into BZ entries. The volunteer(s) who do that work are probably going to want a tool better adapted to that purpose than the standard BZ bug entry page ... but we'll likely want to do some customization work on our BZ anyway, so I don't see that as a fatal objection. The bottom line here is that there will not be any tool that is perfect for our purposes out-of-the-box. Well, it's all open source, we can scratch our own itch. What we need more than any specific tool is a commitment from someone to put effort into adapting the tool to our needs. (Given that reality, the quality of the tool's existing source code needs to figure strongly in our decision. If BZ is still as ugly as Josh remembers it being, that'd be a strike against it.) It is a heck of a lot better then it was. For example, presentation logic is largely factored out and handed off to TT templates. Personally I'd like to see the SQL factored out too, but Bugzilla is hardly unique in having SQL littered across the code. Honestly, this is not your father's bugzilla. BTW, Josh's memory is of the 1.x series. The 2.x series is now at 2.22. The code has move a very long way. There are also tools for email interaction, although they might need to be beefed up for the likes of some 20th century dwellers :-) I will check about Greg's complaint about race conditions in updating comments. My initial impression is that this is no longer so, but I will get a definite answer. We certainly have enough perl-heads on our community that we can surely make it do what we want with little difficulty. Oh, it can also import some XML too. The DTD is in the source. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
I wrote: I will check about Greg's complaint about race conditions in updating comments. My initial impression is that this is no longer so, but I will get a definite answer. My impression was correct. Each comment on a bug gets its own row, marked by bug-id, commenter-id and timestamp. BTW, there are undoubtedly some infelicities in the schema, but it's not too bad, and the way the bugzilla code works there is no danger of one underlying DB platform getting out of synch, as they are all generated from a single abstract schema. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Thu, Aug 17, 2006 at 08:20:22PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Have you tried to use debbugs? I agree with Greg Stark that it's a better fit for our current procedure, while enabling better traceability. The principal strike against debbugs seems to be that the source code is not readily available and/or isn't updated regularly. If we could get current sources we'd probably end up maintaining our own fork ... OTOH, given all the enthusiasm being expressed in this thread, somebody would volunteer to do that no? Well, actually, you can get the currently running source whenever you like: http://bugs.debian.org/debbugs-source/ I got that from one of the bugs listed against debbugs: http://bugs.debian.org/222077 The problem is that there is no recently packaged version that one can just quickly install somewhere. Other than that not-small problem, I agree that debbugs seems like an excellent fit to our existing habits. Yeah, debbugs is a really good fit here, like for Debian, because of the overwhelming prevalence of email correspondence compared to any other kind of communication. If we all used forums ofcourse, debbugs would suck :) Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Have you tried to use debbugs? I agree with Greg Stark that it's a better fit for our current procedure, while enabling better traceability. The principal strike against debbugs seems to be that the source code is not readily available and/or isn't updated regularly. If we could get current sources we'd probably end up maintaining our own fork ... OTOH, given all the enthusiasm being expressed in this thread, somebody would volunteer to do that no? Other than that not-small problem, I agree that debbugs seems like an excellent fit to our existing habits. Well, the enthusiasm was for use, not for maintaining a fork :-) I had a brief look at the code (literally less than 5 minutes). The good news is that it is admirably small. A fork isn't a bad idea, though, especially as a pgfoundry project. I can think of several excellent candidates for such a project (no names, no pack drill) ;-) I should mention that it's a perl app. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
All, I chatted some with some of the Debian folks who maintain Debbugs. They thought it would take a significant amount of work to adapt it to PostgreSQL, in addition to the obvious needs to improve the web interface. RT has some significant short comings for our project such as not having good support for tying bugs to versions etc. As people have pointed out, it's a Request Tracker, not necessarily a Bug Tracker. On the other hand, a lot of my personal dislike of BugZilla seems to be based on being forced to use old versions. A lot of the stuff I hate about it has been fixed in the current version. So, the question is whether any of our biggest bug-fixers would dig in their heels and scream No! if we gave BugZilla a try. Comments? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
So, the question is whether any of our biggest bug-fixers would dig in their heels and scream No! if we gave BugZilla a try. Comments? I could have this setup this weekend should we vote YES :) Joshua D. Drake ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Let me add that most entries that illict a quick patch or TODO item do not come in through the bugs list, but are rather problems people post to ther lists, or are the result of discussions. --- Gregory Stark wrote: Andrew Dunstan [EMAIL PROTECTED] writes: What we are talking about here is bug triage. Really? We have a problem with too many bug reports and need a tool to help triage them? That's the first I've heard of that. Think about what tasks you do now and what tool would make it easier. Don't try to invent problems to solve. The Debian system would be basically zero operational change. pgsql-bugs would continue to exist exactly as it does now except it would go through debbugs. Any message there would open a bug report. Anyone responding to say that's not a bug would just include the magic phrase to close the bug report too. Anyone responding with questions or data would just respond as normal. The net result would be exactly as it is now except that there would be a tool to view what bugs are still open and look at all the data accumulated on that bug. And you could look back at old bugs to see what version they were fixed in and what the bug looked like to see if it matched the problem a user is having. In short, it's just a tool to solve a problem we actually have (having a convenient archive of data about current and past bugs) without inventing problems to solve with extra process that we aren't already doing anyways. RT can be set up similarly but I'm not sure how much work it would take to make it as seamless. Debbugs has the advantage of working that way pretty much out of the box. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Greg, In short, it's just a tool to solve a problem we actually have (having a convenient archive of data about current and past bugs) without inventing problems to solve with extra process that we aren't already doing anyways. RT can be set up similarly but I'm not sure how much work it would take to make it as seamless. Debbugs has the advantage of working that way pretty much out of the box. Debbugs would be good too. I'll quiz the Debian folks here at the conference about what issues there are with the system. FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to open source it for us. ;-) --Josh Berkus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Josh Berkus schrieb: Greg, In short, it's just a tool to solve a problem we actually have (having a convenient archive of data about current and past bugs) without inventing problems to solve with extra process that we aren't already doing anyways. RT can be set up similarly but I'm not sure how much work it would take to make it as seamless. Debbugs has the advantage of working that way pretty much out of the box. Debbugs would be good too. I'll quiz the Debian folks here at the conference about what issues there are with the system. FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to open source it for us. ;-) What is wrong with for example trac? (trac.edgewall.com) which actually runs on postgres just fine... Regards Tino ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
I'm not sure I follow this, since currently anyone can email the bugs list or use the bugs - email form from the website. Are you looking to increase the barrier for bug reporting? Any garbage (ie. spam) is generally filtered before it hits the -bugs list itself Spam: Yes. Non-bug-reports: Absolutely not. The majority of things on -bugs are *not* bug reports, from what I can tell... //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Thu, Aug 17, 2006 at 06:48:54PM +0200, Magnus Hagander wrote: This, however, I would find very useful - both as a -hacker and as a user. The point is that only confirmed things should be in there, so only confirmed things should be returned on searches and whatevr. (private not as in not visible to the public, but private as in write-controlled) I've yet to see a bug tracker that doesn't make it trivial to identify bugs that were marked as invalid (ie: not a real bug). The only difference is that you actually have to mark them as such. Given the fairly low volume of non-bugs that come in through the web form, I don't think marking them will be a big issue (and as I mentioned previously, it's something that doesn't have to be done by anyone who's a committer). In fact, having such a system would probably save committers time, because they could look only at bugs that had been confirmed as valid by someone else. Right now, every time a non-bug gets filed dozens of people end up reading the report before they hit delete. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Magnus Hagander wrote: I'm not sure I follow this, since currently anyone can email the bugs list or use the bugs - email form from the website. Are you looking to increase the barrier for bug reporting? Any garbage (ie. spam) is generally filtered before it hits the -bugs list itself Spam: Yes. Non-bug-reports: Absolutely not. The majority of things on -bugs are *not* bug reports, from what I can tell... And many bugs appear on other lists, so again, it isn't just that the bugs list isn't just bugs, but that bugs appear elsewhere. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
These days I doubt there's anyone around the project who refuses to use a web browser at all. However, I still personally find it much more convenient to read and respond to mailing-list postings than to have to go and visit random web pages to find out if there's something I need to know about. So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Doesn't bugzilla insist on sending you the complete bug every time? Or am I confusing it with the gforge/pgfoundry trackers? If so, then it's a really bad idea, IMHO, since it sends new copies out all the time... Now the other side of the coin is that people are used to being able to email problem reports to pgsql-bugs, and that's not going to stop anytime soon. If you don't mind having a bug tracker that is clueless about some fair-size fraction of what is going on, then you can set up a system that is impervious to email input. Just don't expect people to trust it very far. Whatever system is used (if one is), there definitly needs to be some people looking over what comes in on the mailinglists (or on IRC, for that matter) and pipe it off to the tracker in case it's not already there. Unless we want to force everybody to use *just* a web interface (which would be a horrible idea, btw), we won't get 100% coverage. (btw, istm that people email at least as many bugs directly to -hackers, or to -general or whatever, because the end user *does not know* when it's a bug from when it's a misconfiguration, or misunderstanding of the issue or whatnot) //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
This, however, I would find very useful - both as a -hacker and as a user. The point is that only confirmed things should be in there, so only confirmed things should be returned on searches and whatevr. (private not as in not visible to the public, but private as in write-controlled) I've yet to see a bug tracker that doesn't make it trivial to identify bugs that were marked as invalid (ie: not a real bug). The only difference is that you actually have to mark them as such. Given the fairly low volume of non-bugs that come in through the web form, I don't think marking them will be a big issue (and as I mentioned previously, it's something that doesn't have to be done by anyone who's a committer). In fact, having such a system would probably save committers time, because they could look only at bugs that had been confirmed as valid by someone else. Right now, every time a non-bug gets filed dozens of people end up reading the report before they hit delete. Well, if it's invalid, it shouldn't be in there. But I guess you could just go ahead and delete it at that point - but it's work that someone has to do. But when I look at a lot of OSS projects out there, I see hundreds (if not thousands or tens of thousands for large projects) of bugs that are just dangling. That likely aren't bugs, but they are listed as such. Could definitly be that it's just that the system isn't maintained properly, but if so many others have failed, there's definitly a nontrivial risk that we would fail as well. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Wed, Aug 16, 2006 at 06:52:21AM +0200, Peter Eisentraut wrote: Tom Lane wrote: that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Bugzilla is good in that you need to sign up to report anything (or at least it can be configured that way, not sure), which might reduce the amount of noise. The other systems that have been mentioned have by design little or no barrier of entry, which doesn't seem to be what we want. We put an anti-spam solution w/quarantine in front of our RT E-mail instance (DSPAM) and it is very effective at keeping the cruft out of the tracking system. You can also do basic processing on incoming messages to weed out the non-bugs. We put them in a General start queue and then move them to other working queues when they meet whatever threshold you set. The General queue could also automatically timeout/close tickets that stay in the queue for a certain period of time. Ken ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Wed, Aug 16, 2006 at 01:22:43PM +0900, Michael Glaesemann wrote: On Aug 16, 2006, at 12:29 , Tom Lane wrote: So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Setting aside the email in, how would people feel about Atom or RSS feeds as an alternative for alerts of activity in the system? Michael Glaesemann grzm seespotcode net RT has an RSS output. A particular set of criteria can be used to populate it on an individual basis. Ken ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
RT has an E-mail interface. That was one of our considerations when we used it to replace our aging trouble ticket system. What does the interface need to do? RT's is pretty flexible. Ken On Tue, Aug 15, 2006 at 04:59:46PM -0500, Jim C. Nasby wrote: On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: RT is easy to setup/configure/use and works well with PostgreSQL as the backend. CPAN uses it for their bug tracker. Was there a list of features and requirements? I don't know if we ever came up with one, but I know that the big deal killer for a bug tracker is that a lot of hackers don't want to be forced to use a web interface instead of email. So basically, to be accepted, a bug tracker would have to have an effective email interface; one that allowed for updates to an issue coming in via email. Sadly, I don't think such an animal exists. Ken On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: On Fri, 11 Aug 2006, Alvaro Herrera wrote: I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. I will install anything, and everything, if you can get some sort of concensus on which one to try / go with ... so far, all discussions have ended with nobody coming close to agreeing to anything :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Thu, Aug 17, 2006 at 07:00:21PM +0200, Magnus Hagander wrote: These days I doubt there's anyone around the project who refuses to use a web browser at all. However, I still personally find it much more convenient to read and respond to mailing-list postings than to have to go and visit random web pages to find out if there's something I need to know about. So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Doesn't bugzilla insist on sending you the complete bug every time? Or am I confusing it with the gforge/pgfoundry trackers? If so, then it's a really bad idea, IMHO, since it sends new copies out all the time... No. In fact, it's one of the few that doesn't do that. I agree that sending the whole bug is a really dumb idea. Now the other side of the coin is that people are used to being able to email problem reports to pgsql-bugs, and that's not going to stop anytime soon. If you don't mind having a bug tracker that is clueless about some fair-size fraction of what is going on, then you can set up a system that is impervious to email input. Just don't expect people to trust it very far. Whatever system is used (if one is), there definitly needs to be some people looking over what comes in on the mailinglists (or on IRC, for that matter) and pipe it off to the tracker in case it's not already there. Unless we want to force everybody to use *just* a web interface (which would be a horrible idea, btw), we won't get 100% coverage. (btw, istm that people email at least as many bugs directly to -hackers, or to -general or whatever, because the end user *does not know* when it's a bug from when it's a misconfiguration, or misunderstanding of the issue or whatnot) Yes, there will have to be cross-checking. However, in practice, I've found that users will enter the bug themselves if you send them a reply asking them to, so I don't think it should pose too much additional burden. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote: I've yet to see a bug tracker that doesn't make it trivial to identify bugs that were marked as invalid (ie: not a real bug). The only difference is that you actually have to mark Well, if it's invalid, it shouldn't be in there. But I guess you could just go ahead and delete it at that point - but it's work that someone has to do. But when I look at a lot of OSS projects out there, I see hundreds (if not thousands or tens of thousands for large projects) of bugs that are just dangling. That likely aren't bugs, but they are listed as such. Could definitly be that it's just that the system isn't maintained properly, but if so many others have failed, there's definitly a nontrivial risk that we would fail as well. I always see people getting bent out-of-shape about bug trackers that contain a lot of invalid bug reports and I never understand why. Most of the ones I've seen hide those by default, so it's not like you really have to deal with them. And having them still exist is useful... for example, if you keep seeing the same thing come up over and over you know there's probably an issue of some kind (ie: documentation). Plus, if users are encouraged to search for the bug they found before reporting it and *that* search by default includes invalid bugs then it's more likely that the user will find the question (and answer) themselves. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Magnus Hagander [EMAIL PROTECTED] writes: ... Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Doesn't bugzilla insist on sending you the complete bug every time? Nope, it just sends the changes/additions. Other than the lack of a direct email input method, I find BZ quite usable. Josh was just complaining that its source code is a mess (dunno, haven't looked) but other than that I think it's a definite possibility, just because so many people are already familiar with it. Whatever system is used (if one is), there definitly needs to be some people looking over what comes in on the mailinglists (or on IRC, for that matter) and pipe it off to the tracker in case it's not already there. Sure; we'd need a few volunteers handling that, no matter what software we pick. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Jim C. Nasby wrote: On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote: I've yet to see a bug tracker that doesn't make it trivial to identify bugs that were marked as invalid (ie: not a real bug). The only difference is that you actually have to mark Well, if it's invalid, it shouldn't be in there. But I guess you could just go ahead and delete it at that point - but it's work that someone has to do. But when I look at a lot of OSS projects out there, I see hundreds (if not thousands or tens of thousands for large projects) of bugs that are just dangling. That likely aren't bugs, but they are listed as such. Could definitly be that it's just that the system isn't maintained properly, but if so many others have failed, there's definitly a nontrivial risk that we would fail as well. I always see people getting bent out-of-shape about bug trackers that contain a lot of invalid bug reports and I never understand why. Most of the ones I've seen hide those by default, so it's not like you really have to deal with them. And having them still exist is useful... for example, if you keep seeing the same thing come up over and over you know there's probably an issue of some kind (ie: documentation). Plus, if users are encouraged to search for the bug they found before reporting it and *that* search by default includes invalid bugs then it's more likely that the user will find the question (and answer) themselves. If the crud isn't handled some way then the system isn't nearly as much use to you. That's why I believe some sort of process for keeping the bug tracking system reasonably clean is necessary. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Tom Lane wrote: Doesn't bugzilla insist on sending you the complete bug every time? Nope, it just sends the changes/additions. Other than the lack of a direct email input method, I find BZ quite usable. Josh was just complaining that its source code is a mess (dunno, haven't looked) but other than that I think it's a definite possibility, just because so many people are already familiar with it. One other point about BZ - several community members (including me) put in some effort to make the trunk version run on postgres, which it now does, and quite well. So our using it would be a nice return compliment. The source code might well be a mess, but for the most part it can just be treated as a black box. Whatever system is used (if one is), there definitly needs to be some people looking over what comes in on the mailinglists (or on IRC, for that matter) and pipe it off to the tracker in case it's not already there. Sure; we'd need a few volunteers handling that, no matter what software we pick. You betcha. I'm glad we agree about that. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: ... Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Doesn't bugzilla insist on sending you the complete bug every time? Nope, it just sends the changes/additions. Other than the lack of a direct email input method, I find BZ quite usable. Josh was just complaining that its source code is a mess (dunno, haven't looked) but other than that I think it's a definite possibility, just because so many people are already familiar with it. Have you tried to use debbugs? I agree with Greg Stark that it's a better fit for our current procedure, while enabling better traceability. For an example, see http://bugs.debian.org. There are three links there pointing to pages on how to use the system. Entering a bug number shows detail; for example try entering 330514 which is a PostgreSQL bug. You can add more detail to a bug by mailing bug-number@bugs.debian.org. You can close a bug by mailing bug-number[EMAIL PROTECTED] You can of course clone bugs, retarget to a different package, merge bugs, etc. It's controllable by email -- in fact, I think email is the only controlling interface. You can get reports using the web frontend. You can get an mbox via HTTP for a particular bug, which you can later open with your email client if you like. (And respond to it, etc). We would have to determine what constitutes a package (probably one for each contrib module, one for each interface, one for the backend, etc; or we could have separate package for optimizer, rewriter, transaction system, one for each access method, etc), what tags there are, what versions, etc. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Alvaro Herrera wrote: Have you tried to use debbugs? If you can find up-to-date source code for debbugs, we might continue that line of thought. The searching capabilities in debbugs are, well, non-existent, which is a real problem in my mind. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Peter Eisentraut wrote: Alvaro Herrera wrote: Have you tried to use debbugs? If you can find up-to-date source code for debbugs, we might continue that line of thought. Josh Berkus said he'd try to talk to the Debian people at LinuxWorld -- let's see if something materializes from there. The searching capabilities in debbugs are, well, non-existent, which is a real problem in my mind. Well, we can set up our own indexing, like Oleg and Teodor have done in http://www.pgsql.ru/ -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Alvaro Herrera [EMAIL PROTECTED] writes: Have you tried to use debbugs? I agree with Greg Stark that it's a better fit for our current procedure, while enabling better traceability. The principal strike against debbugs seems to be that the source code is not readily available and/or isn't updated regularly. If we could get current sources we'd probably end up maintaining our own fork ... OTOH, given all the enthusiasm being expressed in this thread, somebody would volunteer to do that no? Other than that not-small problem, I agree that debbugs seems like an excellent fit to our existing habits. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: I'm not sure I follow this, since currently anyone can email the bugs list or use the bugs - email form from the website. Are you looking to increase the barrier for bug reporting? Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most are confused or misdirected users. I don't want to raise that barrier. But I want a higher barrier before something is recorded in the bug tracking system. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Wednesday 16 August 2006 00:52, Peter Eisentraut wrote:
Tom Lane wrote:
that the bug tracker would have to have a reasonable output email
capability, but I'd not necessarily insist on being able to input
to it by mail. Red Hat's present bugzilla system could be described
that way --- and while I can't say I'm in love with it, I can deal
with it.
Bugzilla is good in that you need to sign up to report anything (or at
least it can be configured that way, not sure), which might reduce the
amount of noise. The other systems that have been mentioned have by
design little or no barrier of entry, which doesn't seem to be what we
want.
I'm not sure I follow this, since currently anyone can email the bugs list or
use the bugs - email form from the website. Are you looking to increase the
barrier for bug reporting?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote: Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: I'm not sure I follow this, since currently anyone can email the bugs list or use the bugs - email form from the website. Are you looking to increase the barrier for bug reporting? Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most are confused or misdirected users. I don't want to raise that barrier. But I want a higher barrier before something is recorded in the bug tracking system. Well, you need to get some agreement on what the bug tracker is for. Is it: a) a front-end to deal with complaints and bugs people have. Is it something you expect end users to look at? This is how Debian uses its bug-tracker, to make sure issues people bring up don't get lost. You can always close the bug if it isn't a real bug. Or: b) a private bug database only used by -hackers to track known outstanding bugs and patches. If you want the latter, the approach would be to keep pgsql-bugs and when a real issue comes up, bounce it to the bug tracker. Any subsequent email discussion should then get logged in the bug report. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Martijn van Oosterhout wrote: On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote: Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: I'm not sure I follow this, since currently anyone can email the bugs list or use the bugs - email form from the website. Are you looking to increase the barrier for bug reporting? Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most are confused or misdirected users. I don't want to raise that barrier. But I want a higher barrier before something is recorded in the bug tracking system. Well, you need to get some agreement on what the bug tracker is for. Is it: a) a front-end to deal with complaints and bugs people have. Is it something you expect end users to look at? This is how Debian uses its bug-tracker, to make sure issues people bring up don't get lost. You can always close the bug if it isn't a real bug. Or: b) a private bug database only used by -hackers to track known outstanding bugs and patches. If you want the latter, the approach would be to keep pgsql-bugs and when a real issue comes up, bounce it to the bug tracker. Any subsequent email discussion should then get logged in the bug report. Have a nice day, What we are talking about here is bug triage. Weeding out misreports, duplicates etc. is a prime part of this function. It is essential to the health of any functioning bug tracking system. All it takes is resources. Is it worth it? Yes, IMNSHO, but it's a judgement call. One sensible way to do this would be to have a group of suitably qualified volunteers who could perform this function on a roster basis, for, say, a week or a two at a time. That way we could the load off key personnel like Tom (I am in favor of anything which would reduce the demands we place on Tom ;-) ) cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Wed, Aug 16, 2006 at 09:14:47AM -0400, Andrew Dunstan wrote: What we are talking about here is bug triage. Weeding out misreports, duplicates etc. is a prime part of this function. It is essential to the health of any functioning bug tracking system. All it takes is resources. Is it worth it? Yes, IMNSHO, but it's a judgement call. One sensible way to do this would be to have a group of suitably qualified volunteers who could perform this function on a roster basis, for, say, a week or a two at a time. That way we could the load off key personnel like Tom (I am in favor of anything which would reduce the demands we place on Tom ;-) ) Actually, I'd bet we don't need to put such a formal system in place. I suspect that we'll have users actually looking at the incomming bugs and commenting if they're not valid. As we notice folks who are doing a good job of that, we can give them the privleges to mark bugs as invalid. In the meantime, I'd be glad to help out with 'weeding' incomming bug reports. Depending on the bug tracking system, you can even just let people do this ad-hoc... bugzilla (for example) has an unconfirmed status for new bugs; it would just take people looking at all unconfirmed bugs and marking them appropriately. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote: Tom, These days I doubt there's anyone around the project who refuses to use a web browser at all. However, I still personally find it much more convenient to read and respond to mailing-list postings than to have to go and visit random web pages to find out if there's something I need to know about. So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Actually, if that's the only objection it's solved. RT will now allow you to create, comment on, modify, and close bugs by e-mail. And the RT team would be thrilled to have us using it, in theory enough to provide some setup help. There's one thing that RT doesn't do by e-mail (can't remember offhand) but that's a TODO for them so it should be fixed soon. So, if the only real requirement for a bug tracker is that we can handle it 100% by e-mail, and integrate it with the pgsql-bugs list, that is possible. Does Trac have similar capability? Reason I'm asking is that I think *eventually* it would be very useful to have trac's ability to link bugs, version control, wiki, etc. all together. I know it'll probably be quite some time before that happens, but I'm sure that if we go with RT it'll never happen. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Jim C. Nasby wrote: On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote: Tom, These days I doubt there's anyone around the project who refuses to use a web browser at all. However, I still personally find it much more convenient to read and respond to mailing-list postings than to have to go and visit random web pages to find out if there's something I need to know about. So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Actually, if that's the only objection it's solved. RT will now allow you to create, comment on, modify, and close bugs by e-mail. And the RT team would be thrilled to have us using it, in theory enough to provide some setup help. There's one thing that RT doesn't do by e-mail (can't remember offhand) but that's a TODO for them so it should be fixed soon. So, if the only real requirement for a bug tracker is that we can handle it 100% by e-mail, and integrate it with the pgsql-bugs list, that is possible. Does Trac have similar capability? Reason I'm asking is that I think *eventually* it would be very useful to have trac's ability to link bugs, version control, wiki, etc. all together. I know it'll probably be quite some time before that happens, but I'm sure that if we go with RT it'll never happen. guys, just a sobering refrain from the troll audience -- establishing trac/subversion, as a formal mechanism within postgesql circles, would go a long way toward showing the real world out there that postgresql is professionalizing (I know) and systematizing, etc.ad infinitum. Let everyone identify bugs (keeps novices busy), the more the merrier! New classes of semi-programmers will arise, lets call them buggers, and bugger watchers, unless they know English very well, pretty soon, the system will get used by real programmers, because in the long run, it saves time, and gets results. And folks, lets learn from the goofs of the Freebsd crowd, and maybe even from the Torvalds gang. Michael -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Wed, 16 Aug 2006, Robert Treat wrote: I'm not sure I follow this, since currently anyone can email the bugs list or use the bugs - email form from the website. Are you looking to increase the barrier for bug reporting? Any garbage (ie. spam) is generally filtered before it hits the -bugs list itself Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Andrew Dunstan [EMAIL PROTECTED] writes: What we are talking about here is bug triage. Really? We have a problem with too many bug reports and need a tool to help triage them? That's the first I've heard of that. Think about what tasks you do now and what tool would make it easier. Don't try to invent problems to solve. The Debian system would be basically zero operational change. pgsql-bugs would continue to exist exactly as it does now except it would go through debbugs. Any message there would open a bug report. Anyone responding to say that's not a bug would just include the magic phrase to close the bug report too. Anyone responding with questions or data would just respond as normal. The net result would be exactly as it is now except that there would be a tool to view what bugs are still open and look at all the data accumulated on that bug. And you could look back at old bugs to see what version they were fixed in and what the bug looked like to see if it matched the problem a user is having. In short, it's just a tool to solve a problem we actually have (having a convenient archive of data about current and past bugs) without inventing problems to solve with extra process that we aren't already doing anyways. RT can be set up similarly but I'm not sure how much work it would take to make it as seamless. Debbugs has the advantage of working that way pretty much out of the box. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Gregory Stark wrote: The Debian system would be basically zero operational change. pgsql-bugs would continue to exist exactly as it does now except it would go through debbugs. Debbugs is fine and all, but they don't seem to publish their code on a regular basis. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Andrew Dunstan wrote: What we are talking about here is bug triage. I think we are actually talking about bug *tracking*. One sensible way to do this would be to have a group of suitably qualified volunteers who could perform this function on a roster basis, for, say, a week or a two at a time. Organising a roster, a rotating roster at that, is probably the single most difficult thing you can do in this group. :-) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Martijn van Oosterhout wrote: If you want the latter, the approach would be to keep pgsql-bugs and when a real issue comes up, bounce it to the bug tracker. Any subsequent email discussion should then get logged in the bug report. That's what I want. I don't want the bug tracking system to be the primary frontend to users off the street. Because quite frankly most users are too confused to know what a real bug is. That doesn't mean that I want a closed BTS, but a system that requires sign up and user accounts (like Bugzilla) imposes the right barrier to random abuse in my mind. Note that RT stands for Request Tracker, which on its face is a different thing, namely a system to do tracking of requests by users off the street. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Fri, 11 Aug 2006, Alvaro Herrera wrote: I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. I will install anything, and everything, if you can get some sort of concensus on which one to try / go with ... so far, all discussions have ended with nobody coming close to agreeing to anything :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Marc G. Fournier wrote: On Fri, 11 Aug 2006, Alvaro Herrera wrote: I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. I will install anything, and everything, if you can get some sort of concensus on which one to try / go with ... so far, all discussions have ended with nobody coming close to agreeing to anything :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster quite frankly, I think this group needs the same kind of consensus found in Torvalds kernel group. Is anyone denying their approach gets better results!? No flatline there. JMUASFANPWWMR! -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
RT is easy to setup/configure/use and works well with PostgreSQL as the backend. CPAN uses it for their bug tracker. Was there a list of features and requirements? Ken On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: On Fri, 11 Aug 2006, Alvaro Herrera wrote: I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. I will install anything, and everything, if you can get some sort of concensus on which one to try / go with ... so far, all discussions have ended with nobody coming close to agreeing to anything :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: RT is easy to setup/configure/use and works well with PostgreSQL as the backend. CPAN uses it for their bug tracker. Was there a list of features and requirements? I don't know if we ever came up with one, but I know that the big deal killer for a bug tracker is that a lot of hackers don't want to be forced to use a web interface instead of email. So basically, to be accepted, a bug tracker would have to have an effective email interface; one that allowed for updates to an issue coming in via email. Sadly, I don't think such an animal exists. Ken On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: On Fri, 11 Aug 2006, Alvaro Herrera wrote: I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. I will install anything, and everything, if you can get some sort of concensus on which one to try / go with ... so far, all discussions have ended with nobody coming close to agreeing to anything :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Tue, 15 Aug 2006, Jim C. Nasby wrote: On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: RT is easy to setup/configure/use and works well with PostgreSQL as the backend. CPAN uses it for their bug tracker. Was there a list of features and requirements? I don't know if we ever came up with one, but I know that the big deal killer for a bug tracker is that a lot of hackers don't want to be forced to use a web interface instead of email. So basically, to be accepted, a bug tracker would have to have an effective email interface; one that allowed for updates to an issue coming in via email. Sadly, I don't think such an animal exists. GnATs :) Ken On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: On Fri, 11 Aug 2006, Alvaro Herrera wrote: I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. I will install anything, and everything, if you can get some sort of concensus on which one to try / go with ... so far, all discussions have ended with nobody coming close to agreeing to anything :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Jim C. Nasby wrote: On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: RT is easy to setup/configure/use and works well with PostgreSQL as the backend. CPAN uses it for their bug tracker. Was there a list of features and requirements? I don't know if we ever came up with one, but I know that the big deal killer for a bug tracker is that a lot of hackers don't want to be forced to use a web interface instead of email. So basically, to be accepted, a bug tracker would have to have an effective email interface; one that allowed for updates to an issue coming in via email. Sadly, I don't think such an animal exists. We have three candidates already -- debbugs, RT and Gnats. The first has the advantage that was written by hackers, for hackers, so it doesn't have any of the insane for end users stuff which annoys so many people around here ;-) (On the other hand it does have some web stuff for generating reports, etc). I haven't used RT much, and I don't know Gnats at all, but I kinda like (the little I have played with) debbugs. Apparently it's rather easy to set up: http://www.benham.net/debbugs/ -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
I've used and use RT. It is web based for admin, but all the transactions are E-Mail based. http://www.bestpractical.com I can also make a test queue on my instance if someone wants to play. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
We have three candidates already -- debbugs, RT and Gnats. The first has the advantage that was written by hackers, for hackers, so it doesn't have any of the insane for end users stuff which annoys so many people around here ;-) (On the other hand it does have some web stuff for generating reports, etc). Kill me now if I have to use GNATS :) Have you ever tried submitting a bug to the FreeBSD project? *shudder* That said, I'll live :) I have recently totally falling in love with Trac and its complete subversion integration. I'm not sure it supports PostgreSQL, and converting to subversion is probably a little too hardcore at the moment :) Chris ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Christopher Kings-Lynne wrote: We have three candidates already -- debbugs, RT and Gnats. The first has the advantage that was written by hackers, for hackers, so it doesn't have any of the insane for end users stuff which annoys so many people around here ;-) (On the other hand it does have some web stuff for generating reports, etc). Kill me now if I have to use GNATS :) Have you ever tried submitting a bug to the FreeBSD project? *shudder* That said, I'll live :) I have recently totally falling in love with Trac and its complete subversion integration. I'm not sure it supports PostgreSQL, and converting to subversion is probably a little too hardcore at the moment :) Chris ---(end of broadcast)--- TIP 6: explain analyze is your friend CVS users just rot away or are subverted. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Jim C. Nasby [EMAIL PROTECTED] writes: I don't know if we ever came up with one, but I know that the big deal killer for a bug tracker is that a lot of hackers don't want to be forced to use a web interface instead of email. So basically, to be accepted, a bug tracker would have to have an effective email interface; one that allowed for updates to an issue coming in via email. Sadly, I don't think such an animal exists. That was the position that several of us took five-or-six years ago when the issue first came up ;-) These days I doubt there's anyone around the project who refuses to use a web browser at all. However, I still personally find it much more convenient to read and respond to mailing-list postings than to have to go and visit random web pages to find out if there's something I need to know about. So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Now the other side of the coin is that people are used to being able to email problem reports to pgsql-bugs, and that's not going to stop anytime soon. If you don't mind having a bug tracker that is clueless about some fair-size fraction of what is going on, then you can set up a system that is impervious to email input. Just don't expect people to trust it very far. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
On Aug 16, 2006, at 12:29 , Tom Lane wrote: So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Setting aside the email in, how would people feel about Atom or RSS feeds as an alternative for alerts of activity in the system? Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Tom Lane wrote: that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Bugzilla is good in that you need to sign up to report anything (or at least it can be configured that way, not sure), which might reduce the amount of noise. The other systems that have been mentioned have by design little or no barrier of entry, which doesn't seem to be what we want. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)
Tom, These days I doubt there's anyone around the project who refuses to use a web browser at all. However, I still personally find it much more convenient to read and respond to mailing-list postings than to have to go and visit random web pages to find out if there's something I need to know about. So my current take on this would be that the bug tracker would have to have a reasonable output email capability, but I'd not necessarily insist on being able to input to it by mail. Red Hat's present bugzilla system could be described that way --- and while I can't say I'm in love with it, I can deal with it. Actually, if that's the only objection it's solved. RT will now allow you to create, comment on, modify, and close bugs by e-mail. And the RT team would be thrilled to have us using it, in theory enough to provide some setup help. There's one thing that RT doesn't do by e-mail (can't remember offhand) but that's a TODO for them so it should be fixed soon. So, if the only real requirement for a bug tracker is that we can handle it 100% by e-mail, and integrate it with the pgsql-bugs list, that is possible. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On Fri, Aug 11, 2006 at 05:27:46PM -0400, Alvaro Herrera wrote: Does that rails thing also have a bug tracker that integrates with mailing lists? IIRC the show-stopper on a bug tracker was finding one that allowed people to still use mailing lists. AFAIU the showstopper was that people wanted to be able to _control_ the bugtracker using email only, i.e. not forcing you to open a web browser to do stuff like adding comments or attachments to a bug, or closing, etc. The only bugtracker I know that allows that is debbugs, which a nice system IMHO, but I'm sure people have differing opinions about that... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
The long-lost pg_upgrade (was:Re: [HACKERS] 8.2 features status)
On Friday 04 August 2006 02:20, Josh Berkus wrote: grin Aren't I, the marketing geek, supposed to be the one whining about this? [snip] * In-place upgrades (pg_upgrade) BTW, I may get Sun to contribute an engineer for this; will get you posted. Long time no post. This statement really caught my attention; bravo if true upgrading can happen, and someone can be put on it and do it right. As Tom said, a little farther down the thread, we have talked over this many times. I specifically remember, oh, about a dozen times I personally have 'gadflied' this issue. As one who now has a, let's see: [EMAIL PROTECTED] ~]# du /var/lib/pgsql/data -s 16668528/var/lib/pgsql/data [EMAIL PROTECTED] ~]# Yes, a 16GB inventory database, with in-database large object images. Anyway, as one who does not look forward to migrating this the old-fashioned way (I can just imagine how fas^H^H^Hslow a restore of all those large objects is going to be; backup is slow enough (about 50 minutes on this Xeon 2.4GHz box)), in place upgrade would cut this considerably; the database is not a complex one, just a largish one. It's, let's see, only holding a little less than 5,000 items with associated lo images (due to many factors, this is handled through ODBC from Microsoft Access; it is a kludge, and a big one, but it works very smoothly from the users' points of view, where item images are literally 'dragged and dropped' from the digital camera straight to the database). So, anyway, looking forward to seeing some progress in this department... :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote: I think it is a combination of the two. A wiki could be used to discuss ideas for todos, it could be used to describe TODOs in actual detail, it could used (in conjunction with Trac) to be able to document dependecies for todos... etc. A wiki for *discussion*? I thought email was for that. A wiki is nice to work toghether on a document (in some circumstances). -- __ Nothing is as subjective as reality Reinoud van Leeuwen[EMAIL PROTECTED] http://www.xs4all.nl/~reinoud __ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Reinoud van Leeuwen wrote: On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote: I think it is a combination of the two. A wiki could be used to discuss ideas for todos, it could be used to describe TODOs in actual detail, it could used (in conjunction with Trac) to be able to document dependecies for todos... etc. A wiki for *discussion*? I thought email was for that. A wiki is nice to work toghether on a document (in some circumstances). I dont he meant that. A wiki is a good place to summarize an email discussion, not to actually hold a discussion on the wiki (I have seen it done though .. and its not pretty). regards, Lukas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Neil Conway napsal(a): However, is there a reason to use Trac beyond the fact that it is already setup? ISTM we only need a wiki, and don't need the other features of Trac, such as the bug tracker. I do not agree. How you determine what release fixes the bug now? We have web page and mailing list for bug reporting but there is not any relation between bug, patch and release(s). I think bug tracking is necessary if we want move forward. Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Alvaro Herrera wrote: Jim Nasby wrote: First, +1 on Josh B.'s point about trying out Trac, since it's already up and running. Josh D., can you just turn that on? (BTW, is trac linked off http://commandprompt.com anywhere? I had to google to find it yesterday...) I just noticed that the code repository on that Trac is broken in more ways than I had realized. For starters it doesn't seem to have the 8.1 branch or tags (apparently it's out of date). It doesn't? http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql What are you looking at Alvaro? Exactly that URL, but this wasn't there when I looked. Maybe it was being regenerated at that time? But I don't know why you are ignoring my comments that it's broken. For an example, go here: http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src Note that the DEVELOPERS file shows a revision 5684, message Typo fix. Click on that 5684. It'll show you two items, revs 23689 and 5684. First problem, where did that 23689 come from? It wasn't there in the parent dir. Now open that changeset (click on the [23689]). Look at the list of files -- it only has errcodes.sgml in it. No DEVELOPERS, which is the file we want to track! Furthermore, it doesn't show any diff at all. I have looked at it before and I've found these kinds of problems all over the place. If you mark follow copies in the box at the right and then click Update, more broken revisions will appear. It's impossible to actually follow the history of a file, because all the entries are bogus. I don't know what on earth is going on but I surely won't waste my time checking that repo again since it seems pretty useless. Doesn't Trac have a CVS plugin? No, like the rest of the world, Trac has moved on from CVS ;) There are still a lot of projects using CVS. We happen to be one of them. It's pretty damn useful to be able to use the Trac facilities to mark tickets as fixed in revision such-and-such, which allows us to track more carefully the bugs fixed and the features added. But if the repo is useless, then the rest of Trac loses a lot of its usefulness as well. And to be clear, I would only expect that this would be used as a reference, that is all. The ability to link from the wiki directly to a source file or changeset could be useful. Precisely my point. But if the reference doesn't work, then it's just a plain Wiki like any other. I wouldn't want to waste my time on that. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql What are you looking at Alvaro? Exactly that URL, but this wasn't there when I looked. Maybe it was being regenerated at that time? Yeah it gets regenerated every 4 hours or so. But I don't know why you are ignoring my comments that it's broken. For an example, go here: http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src No one is ignoring you. Note that the DEVELOPERS file shows a revision 5684, message Typo fix. Click on that 5684. It'll show you two items, revs 23689 and 5684. First problem, where did that 23689 come from? It wasn't there in the parent dir. Now open that changeset (click on the [23689]). Look at the list of files -- it only has errcodes.sgml in it. No DEVELOPERS, which is the file we want to track! Furthermore, it doesn't show any diff at all. O.k. So it isn't perfect. It isn't like I expected to be. However many people find it useful, myself included. I don't know what on earth is going on but I surely won't waste my time checking that repo again since it seems pretty useless. O.k., I am not sure who put oil in your pudding, but nobody is asking you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually what *you* should be using. I would expect that if the SVN/Trac repo were determined to be used it would be used as an entry point and that explicit instructions would also be made that the authoritative source of the code is the CVSWeb repository. Doesn't Trac have a CVS plugin? No, like the rest of the world, Trac has moved on from CVS ;) There are still a lot of projects using CVS. We happen to be one of them. Unfortunately that is true. It's pretty damn useful to be able to use the Trac facilities to mark tickets as fixed in revision such-and-such, which allows us to track more carefully the bugs fixed and the features added. But if the repo is useless, then the rest of Trac loses a lot of its usefulness as well. O.k. but no one is suggesting that we use Trac as a bug tracker, or at least I wasn't. All I was suggesting was the ability to help viewing of specific files as listed dependencies. Precisely my point. But if the reference doesn't work, then it's just a plain Wiki like any other. I wouldn't want to waste my time on that. I just threw the trac out there because it was already setup. I don't care if anyone uses it or not. Nor am I suggesting that it *should* be used. Lastly if you review this thread you would see that Andrew and I had already decided to wait until after Linux World to actually propose something. It may be Trac it may be something else. For example, I am also looking at Launchpad. There is also something very similar to trac that is built on ruby on rails that also integrates with mailing lists. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
I do not agree. How you determine what release fixes the bug now? We have web page and mailing list for bug reporting but there is not any relation between bug, patch and release(s). I think bug tracking is necessary if we want move forward. You can completely forget the idea of having an actual bug tracking system. It has been beaten to death over the years. The developers have very specific requirements that no bug tracker currently adheres to. If you are in the mood for a long, never ending soap opera on the topic I suggest you review the archives :) Sincerely, Joshua D. Drake Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Lastly if you review this thread you would see that Andrew and I had already decided to wait until after Linux World to actually propose something. It is perhaps not surprising, but most of the discussion has been focused on technologies (mailing lists, wikis, bugtrackers, trac, SCM systems, etc.). My view is that these things are at best enablers of good process, but they should not define the processes used. I am trying to spend what little time I can devote to this topic to thinking about the issues I see in human rather than technological terms. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql What are you looking at Alvaro? Exactly that URL, but this wasn't there when I looked. Maybe it was being regenerated at that time? Yeah it gets regenerated every 4 hours or so. Suggestion -- have it create the new copy in a separate directory and when it's complete, rename the new one to the original name. That way the update is atomic and users don't get to see an incomplete repo. I don't know what on earth is going on but I surely won't waste my time checking that repo again since it seems pretty useless. O.k., I am not sure who put oil in your pudding, but nobody is asking you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually what *you* should be using. Actually I'd *like* to use something better than CVSWeb, because you know what? It sucks and I'd love to have something better. I'd also like to have a decent bugtracker as well. If both repo and bugtracker are integrated it could be very useful. We almost have that with Trac but since it doesn't work, it's so close as to instill hope but because of the bugs it's useless so it brings frustration instead, which is much worse than if it didn't do either. It's pretty damn useful to be able to use the Trac facilities to mark tickets as fixed in revision such-and-such, which allows us to track more carefully the bugs fixed and the features added. But if the repo is useless, then the rest of Trac loses a lot of its usefulness as well. O.k. but no one is suggesting that we use Trac as a bug tracker, or at least I wasn't. All I was suggesting was the ability to help viewing of specific files as listed dependencies. I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. Those who don't want to use it can choose not to use it, or they can eventually find that yeah, maybe it's a good idea after all. If no one does anything, nothing will happen. I think the devel version of Trac contains some stuff to be able to handle multiple SCMs. I know there's a Monotone plugin for it at least. Maybe somebody has already written a CVS plugin as well -- I'll have a look. It may be Trac it may be something else. For example, I am also looking at Launchpad. There is also something very similar to trac that is built on ruby on rails that also integrates with mailing lists. Launchpad is proprietary. I don't know about the RoR tool you mention, it may be worth having a look at. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
Alvaro Herrera wrote: O.k. but no one is suggesting that we use Trac as a bug tracker, or at least I wasn't. All I was suggesting was the ability to help viewing of specific files as listed dependencies. I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. Those who don't want to use it can choose not to use it, or they can eventually find that yeah, maybe it's a good idea after all. If no one does anything, nothing will happen. Agreed. Seems enough people are interested that even if I don't think it will work, it is worth a try. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Actually I'd *like* to use something better than CVSWeb, because you know what? It sucks and I'd love to have something better. I'd also I am not opposed to actually using taylor or something to do the conversion instead. I just couldn't get it to work. I think the devel version of Trac contains some stuff to be able to handle multiple SCMs. I know there's a Monotone plugin for it at least. Maybe somebody has already written a CVS plugin as well -- I'll have a look. Well that would make life ALOT easier. Launchpad is proprietary. I don't know about the RoR tool you mention, it may be worth having a look at. Launchpad is supposedly releasing their source 10/2006 I believe. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote: I just threw the trac out there because it was already setup. I don't care if anyone uses it or not. Nor am I suggesting that it *should* be used. Lastly if you review this thread you would see that Andrew and I had already decided to wait until after Linux World to actually propose something. It may be Trac it may be something else. For example, I am also looking at Launchpad. There is also something very similar to trac that is built on ruby on rails that also integrates with mailing lists. Does that rails thing also have a bug tracker that integrates with mailing lists? IIRC the show-stopper on a bug tracker was finding one that allowed people to still use mailing lists. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Jim C. Nasby wrote: On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote: I just threw the trac out there because it was already setup. I don't care if anyone uses it or not. Nor am I suggesting that it *should* be used. Lastly if you review this thread you would see that Andrew and I had already decided to wait until after Linux World to actually propose something. It may be Trac it may be something else. For example, I am also looking at Launchpad. There is also something very similar to trac that is built on ruby on rails that also integrates with mailing lists. Does that rails thing also have a bug tracker that integrates with mailing lists? IIRC the show-stopper on a bug tracker was finding one that allowed people to still use mailing lists. AFAIU the showstopper was that people wanted to be able to _control_ the bugtracker using email only, i.e. not forcing you to open a web browser to do stuff like adding comments or attachments to a bug, or closing, etc. I'm not sure what you have in mind about integration between the mailing lists and the bugtracker, because nothing else I can think of makes much sense. I'm always happy to be illuminated :-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Tom Lane wrote: Yeah, the main problem I have with TODO-on-a-wiki is the question of quality control. I've been heard to complain that the TODO list consists of everything Bruce thinks is a good idea, but for the most part things don't get onto TODO without some rough consensus on the mailing lists --- at least about the nature of the problem, if not the exact shape of the solution. I'm worried about a wiki having pages that have not been peer-reviewed at all. In some respects that wouldn't matter, but what of our hypothetical newbie developer coming along and taking entries at face value? If you don't know the project well enough to recognize bogus entries, you could still end up wasting your time on silly ideas that will get rejected once seen by a wider audience. To bring up PHP again: http://oss.backendmedia.com/PhP52 This is the todo list for the upcoming 5.2.0 release that is currently in RC1. Most of the todo items in PHP do not need much detail, so this list does not carry much more information than Bruce's list. The wiki has support for ACL's, so I have given various trusted people direct access. Some developers however rely on me for updating the items. As you can see there is a confirmed (as in the release manager has oked the todo) and an under discussion as well as a future 5.x release section. We already have a separate todo list for php 6. A todo list that illustrates the ability to attach more information for a given todo item is my PEAR::MDB2 list in the same wiki: http://oss.backendmedia.com/MDB2/ToDo regards, Lukas ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
-Original Message- From: Marc G. Fournier [EMAIL PROTECTED] To: Dave Page dpage@vale-housing.co.uk Cc: Jim C. Nasby [EMAIL PROTECTED]; Bruce Momjian [EMAIL PROTECTED]; Josh Berkus josh@agliodbs.com; Christopher Browne [EMAIL PROTECTED]; pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org Sent: 10/08/06 05:30 Subject: RE: [HACKERS] 8.2 features status Two words: House Hunting ... Yeuch. Toronto? ... will post something to -www as soon as I have something up and running ... Ok, cool. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Marc, ... will post something to -www as soon as I have something up and running ... Given that JD is already pulling something into a Trac instance, why don't we just try using that? It has both an issue tracker and a wiki, and it's up and running now. When we have a firmer idea what we want, we may move to different software, but why spend extra effort now? -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
On 8/9/06, Bruce Momjian [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. Why not as long as we have someone who can actually make approved todos versus wishlist type stuff. So you want a wish-list wiki? Great idea, I can link to it from the TODO list. Is that all people want? just jumping in here but have you considered doing the todo list on a wiki? fwiw, i find the todo list links to be pretty neat and helpful. even for non-developers its a good way to get the feel about whats going on with certain features so they can plan strategies around them. merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
First, +1 on Josh B.'s point about trying out Trac, since it's already up and running. Josh D., can you just turn that on? (BTW, is trac linked off http://commandprompt.com anywhere? I had to google to find it yesterday...) On Aug 9, 2006, at 11:34 PM, Tom Lane wrote: Mark Kirkwood [EMAIL PROTECTED] writes: Robert Treat wrote: Wouldn't a thread reply saying something like Bruce, can we add this as a TODO with the following wording: blah blah blah likely suffice? That's pretty much how it's done now ... Robert missed the point I was making... there is value in keeping track of ideas that may not have enough consensus to be a valid TODO yet, but could still be useful. Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't see why that is hard or onerous). Plus it is seen by a wide audience, some of whom might not be tracking any wiki (very likely if there end up being several wiki's) Yeah, the main problem I have with TODO-on-a-wiki is the question of quality control. I've been heard to complain that the TODO list consists of everything Bruce thinks is a good idea, but for the most part things don't get onto TODO without some rough consensus on the mailing lists --- at least about the nature of the problem, if not the exact shape of the solution. I'm worried about a wiki having pages that have not been peer-reviewed at all. In some respects that wouldn't matter, but what of our hypothetical newbie developer coming along and taking entries at face value? If you don't know the project well enough to recognize bogus entries, you could still end up wasting your time on silly ideas that will get rejected once seen by a wider audience. Agreed... there needs to be enough consensus and 'critical mass' before something becomes an official TODO. Because of that, we shouldn't allow anyone to edit the TODO wiki (though I do think we shouldn't put the entire responsibility on Bruce). A nice thing about a wiki is it makes it easy for people to collectively work on a use-case and design for a TODO item. One thing that could come out of this is the expectation that TODO items that aren't inherently obvious (however you define that) must come with X amount of documentation (use cases, design, what-have-you). This isn't something that should replace discussion on the mailing lists, but I think that being able to point to a wiki page with the finalized info about a TODO item is a lot better than pointing at list archives that are spread all over. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Jim Nasby wrote: First, +1 on Josh B.'s point about trying out Trac, since it's already up and running. Josh D., can you just turn that on? (BTW, is trac linked off http://commandprompt.com anywhere? I had to google to find it yesterday...) I just noticed that the code repository on that Trac is broken in more ways than I had realized. For starters it doesn't seem to have the 8.1 branch or tags (apparently it's out of date). Doesn't Trac have a CVS plugin? It will just cause confusion to have a SVN repo that doesn't reflect reality -- which it wouldn't even if it weren't broken. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Alvaro Herrera wrote: Jim Nasby wrote: First, +1 on Josh B.'s point about trying out Trac, since it's already up and running. Josh D., can you just turn that on? (BTW, is trac linked off http://commandprompt.com anywhere? I had to google to find it yesterday...) I just noticed that the code repository on that Trac is broken in more ways than I had realized. For starters it doesn't seem to have the 8.1 branch or tags (apparently it's out of date). It doesn't? http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql What are you looking at Alvaro? Doesn't Trac have a CVS plugin? No, like the rest of the world, Trac has moved on from CVS ;) It will just cause confusion to have a SVN repo that doesn't reflect reality Well sure... but again... what are you looking at, because it looks fine to me? And to be clear, I would only expect that this would be used as a reference, that is all. The ability to link from the wiki directly to a source file or changeset could be useful. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.2 features status
Alvaro Herrera wrote: Jim Nasby wrote: First, +1 on Josh B.'s point about trying out Trac, since it's already up and running. Josh D., can you just turn that on? (BTW, is trac linked off http://commandprompt.com anywhere? I had to google to find it yesterday...) Oh and answer Jim's question. No isn't linked of www.cmd... why? I have no idea ;) It should be on our /community page. I just noticed that the code repository on that Trac is broken in more ways than I had realized. For starters it doesn't seem to have the 8.1 branch or tags (apparently it's out of date). Doesn't Trac have a CVS plugin? It will just cause confusion to have a SVN repo that doesn't reflect reality -- which it wouldn't even if it weren't broken. -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote: No, like the rest of the world, Trac has moved on from CVS ;) There is CVSTrac (www.cvstrac.org), which actually predates Trac. However, is there a reason to use Trac beyond the fact that it is already setup? ISTM we only need a wiki, and don't need the other features of Trac, such as the bug tracker. -Neil ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Neil Conway wrote: On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote: No, like the rest of the world, Trac has moved on from CVS ;) There is CVSTrac (www.cvstrac.org), which actually predates Trac. However, is there a reason to use Trac beyond the fact that it is already setup? ISTM we only need a wiki, and don't need the other features of Trac, such as the bug tracker. Well that is certainly the question but the bug tracker could easily turn into a todo list as well. It is a very powerful tool that is relatively flexible. Joshua D. Drake -Neil ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Merlin Moncure wrote: On 8/9/06, Bruce Momjian [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. Why not as long as we have someone who can actually make approved todos versus wishlist type stuff. So you want a wish-list wiki? Great idea, I can link to it from the TODO list. Is that all people want? just jumping in here but have you considered doing the todo list on a wiki? fwiw, i find the todo list links to be pretty neat and helpful. even for non-developers its a good way to get the feel about whats going on with certain features so they can plan strategies around them. I don't see what a wiki would do for the TODO list except make it take longer for me to update. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Jim Nasby wrote: First, +1 on Josh B.'s point about trying out Trac, since it's already up and running. Josh D., can you just turn that on? (BTW, is trac linked off http://commandprompt.com anywhere? I had to google to find it yesterday...) On Aug 9, 2006, at 11:34 PM, Tom Lane wrote: Mark Kirkwood [EMAIL PROTECTED] writes: Robert Treat wrote: Wouldn't a thread reply saying something like Bruce, can we add this as a TODO with the following wording: blah blah blah likely suffice? That's pretty much how it's done now ... Robert missed the point I was making... there is value in keeping track of ideas that may not have enough consensus to be a valid TODO yet, but could still be useful. It seems some people like the authoritative TODO list, and others want a TODO wiki that they can add stuff to without having to get community buy-in. I have trouble seeing how the wiki doesn't just end up being a blog of ideas, but I see no harm in it as long as it is clear the items haven't passed community review. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
It seems some people like the authoritative TODO list, and others want a TODO wiki that they can add stuff to without having to get community buy-in. I have trouble seeing how the wiki doesn't just end up being a blog of ideas, but I see no harm in it as long as it is clear the items haven't passed community review. I think it is a combination of the two. A wiki could be used to discuss ideas for todos, it could be used to describe TODOs in actual detail, it could used (in conjunction with Trac) to be able to document dependecies for todos... etc. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: It seems some people like the authoritative TODO list, and others want a TODO wiki that they can add stuff to without having to get community buy-in. I have trouble seeing how the wiki doesn't just end up being a blog of ideas, but I see no harm in it as long as it is clear the items haven't passed community review. I think it is a combination of the two. A wiki could be used to discuss ideas for todos, it could be used to describe TODOs in actual detail, it could used (in conjunction with Trac) to be able to document dependecies for todos... etc. But what is it likely to do? I don't think much, but if we can shut it down if we decide it isn't of value (unlike gborg which can't be shut down), I think it is fine to try. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.2 features status
Quoth [EMAIL PROTECTED] (Joshua D. Drake): Josh Berkus wrote: Bruce, What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X I would bet, right about here we loose a whole lot of would be contributors. Just the the questions I had about two todos this year was enough basically give up on doing any work on them. So I'm to take it that if nobody had *ever* pestered you about those items, you would have been certain (or significantly more likely) to get them done in time for 8.2? I don't see this being a huge force for evil... If people are so easily discouraged that any attempt to account for what has been promised will lead to its loss, then it seems to me that they shouldn't have promised anything in the first place. It's not a matter of having to send in weekly status reports; I would think that pestering about status more than once every other month is more than could be done. And in terms of the community contract for taking on TODO items, it does not strike me as unreasonable to be expected to report back on status once every couple months. That's not a heavy bureaucratic burden. -- output = (cbbrowne @ linuxfinances.info) http://linuxfinances.info/info/wp.html Rules of the Evil Overlord #223. I will install a fire extinguisher in every room -- three, if the room contains vital equipment or volatile chemicals. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Christopher Browne wrote: Quoth [EMAIL PROTECTED] (Joshua D. Drake): Josh Berkus wrote: Bruce, What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X I would bet, right about here we loose a whole lot of would be contributors. Just the the questions I had about two todos this year was enough basically give up on doing any work on them. So I'm to take it that if nobody had *ever* pestered you about those items, you would have been certain (or significantly more likely) to get them done in time for 8.2? I think you are misreading my comment. I said: I would bet, right about here we loose a whole lot of would be contributors. Just the the questions I had about two todos this year was enough basically give up on doing any work on them. Which was a positive reinforcement to: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks Is anyone working on X? B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply yes, someone is but I don't remember who, search the archives for keyword X My point was, I was going to work on some todos before feature freeze. I asked about two specific todos. One of them was badly worded and one of them did not represent (except in the smallest of ways) what it actually was. The first one I bailed out of because it was entirely too much for me to do in terms of expertise. The second one turned into a huge debate about not only what the todo was, but how it was to be implemented and it turned out the todo was all about pg_dump. Here is that todo: %Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef() I was under the impression that I would be writing some C or SQL functions to create some useful tidbits. It took a couple of days just to get enough information to find out I was wrong. I was then going to think about possibly sponsoring the todo instead as it was out of my realm. I decided to forget about it after waiting for everyone to figure out what they wanted. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
There's a LOT of unnecessary overhead in that process: having a simple web app that lists who claimed what todo and when, any status updates if they've voluntarily provided them, and links to archive discussions, we could reduce the above to a 3-step process making it vastly easier for new hackers to get started. A developers' wiki with links into the list archives would be great. My thoughts exactly... -- Korry Douglas [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] 8.2 features status
Joshua D. Drake [EMAIL PROTECTED] writes: My point was, I was going to work on some todos before feature freeze. I asked about two specific todos. One of them was badly worded and one of them did not represent (except in the smallest of ways) what it actually was. Well, it's certainly the case that some of the TODO items are vaguely defined (because part of the TODO item is to figure out what to do) and many of them are too complicated to explain well in one sentence. But surely that's a different complaint from what's being discussed in this thread? What this story does do for me is reinforce the notion that it's critical for newbie developers to work in the open, getting feedback from the lists at an early stage about what they are doing. If you go off in a corner and develop a patch for a TODO item, you risk having it rejected because you misunderstood what the TODO item was about. Maybe the connection is that while thinking about processes, we need to take into account the need to encourage people to get early feedback about what they are considering doing. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: My point was, I was going to work on some todos before feature freeze. I asked about two specific todos. One of them was badly worded and one of them did not represent (except in the smallest of ways) what it actually was. Well, it's certainly the case that some of the TODO items are vaguely defined (because part of the TODO item is to figure out what to do) and many of them are too complicated to explain well in one sentence. But surely that's a different complaint from what's being discussed in this thread? I have started adding URLs to the TODO items, which helps. What this story does do for me is reinforce the notion that it's critical for newbie developers to work in the open, getting feedback from the lists at an early stage about what they are doing. If you go off in a corner and develop a patch for a TODO item, you risk having it rejected because you misunderstood what the TODO item was about. Right, and the TODO items change over time as the system improves in other ways. Maybe the connection is that while thinking about processes, we need to take into account the need to encourage people to get early feedback about what they are considering doing. We say that clearly in the developer's FAQ, but it seems it is not enough. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
What this story does do for me is reinforce the notion that it's critical for newbie developers to work in the open, getting feedback from the lists at an early stage about what they are doing. If you go off in a corner and develop a patch for a TODO item, you risk having it rejected because you misunderstood what the TODO item was about. I 100% agree with this. Newbie developers should be in the open and it kind of lends itself to my Mentors idea that I mentioned previously. The problem I see is that even if they are in the open we make it fairly difficult to get the information they need to get started. Maybe the connection is that while thinking about processes, we need to take into account the need to encourage people to get early feedback about what they are considering doing. Agreed. Sincerely, Joshua D. Drake regards, tom lane -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Maybe the connection is that while thinking about processes, we need to take into account the need to encourage people to get early feedback about what they are considering doing. We say that clearly in the developer's FAQ, but it seems it is not enough. I just read the developer's FAQ, and just so were all honest I never had before. :). The developers FAQ is actually quite useful, and helpful except for this one part: Outstanding features are detailed in the TODO list. This is located in doc/TODO in the source distribution or at http://www.postgresql.org/docs/faqs.TODO.html. You can learn more about these features by consulting the archives, the SQL standards and the recommend texts (see 1.10). No one wants to consult the archives. Nor do I believe they should have to. I want a link, directly off the TODO line item that states specific references on one page of what is requested. This is where the wiki comes in. It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. Tom's comments although valid (as usual :)) were that the person missed a bunch of stuff having to do with the planner. Some of us may think... well of course that is obvious... Well either the Sun guy was just lazy, or it isn't obvious. I prefer to think it is not obvious. From Bruce's perspective this actually doesn't add too much to the workload. Generate the link, possibly paste some archive urls into the wiki and then someone can come behind and clean up. Of course, who is the clean up guy is always a question. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Joshua D. Drake wrote: Maybe the connection is that while thinking about processes, we need to take into account the need to encourage people to get early feedback about what they are considering doing. We say that clearly in the developer's FAQ, but it seems it is not enough. I just read the developer's FAQ, and just so were all honest I never had before. :). The developers FAQ is actually quite useful, and helpful except for this one part: Outstanding features are detailed in the TODO list. This is located in doc/TODO in the source distribution or at http://www.postgresql.org/docs/faqs.TODO.html. You can learn more about these features by consulting the archives, the SQL standards and the recommend texts (see 1.10). No one wants to consult the archives. Nor do I believe they should have to. I want a link, directly off the TODO line item that states specific references on one page of what is requested. This is where the wiki comes in. We now have URLs on the TODO list to the archives, and the next FAQ item is: H3 id=item1.41.4) What do I do after choosing an item to work on?/H3 PSend an email to pgsql-hackers with a proposal for what you want to do (assuming your contribution is not trivial). Working in so it is clear what we want people to do. It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. Tom's comments although valid (as usual :)) were that the person missed a bunch of stuff having to do with the planner. Some of us may think... well of course that is obvious... Well either the Sun guy was just lazy, or it isn't obvious. I prefer to think it is not obvious. From Bruce's perspective this actually doesn't add too much to the workload. Generate the link, possibly paste some archive urls into the wiki and then someone can come behind and clean up. I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? I think the big conclusion we made long ago is that We are never going to have enough detail anywhere that someone is going to be able to work on an item without asking the community. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: From Bruce's perspective this actually doesn't add too much to the workload. Generate the link, possibly paste some archive urls into the wiki and then someone can come behind and clean up. Or better yet, if editing the TODO is more accessible then we're not dependent on one person to maintain it. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
We now have URLs on the TODO list to the archives, and the next FAQ item is: H3 id=item1.41.4) What do I do after choosing an item to work on?/H3 PSend an email to pgsql-hackers with a proposal for what you want to do (assuming your contribution is not trivial). Working in so it is clear what we want people to do. what we want my be part of the problem :) It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? Do you want a todo list with 4 paragraphs (minimum) for each todo item? I think the big conclusion we made long ago is that We are never going to have enough detail anywhere that someone is going to be able to work on an item without asking the community. I don't think anyone is expecting that. I think that what we are expecting is that they can ask knowledgeable questions. Would you prefer: Hi, I am a C developer, PostgreSQL Rocks... I want to implement Enums.. Or: Hi, I am a C developer, PostgreSQL Rocks... I would like to take the Enums todo. Here are my specific questions regarding your feature requirements at URL --- Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
Jim C. Nasby wrote: On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: From Bruce's perspective this actually doesn't add too much to the workload. Generate the link, possibly paste some archive urls into the wiki and then someone can come behind and clean up. Or better yet, if editing the TODO is more accessible then we're not dependent on one person to maintain it. To be fair, Bruce has offered to allow that to happen even on his home machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. It may not be a web interface that people could log into but it is entirely possible to contribute back with it. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 8.2 features status
On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote: bruce wrote: bruce wrote: OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. Let me add that anyone who has CVS commit access or wants to submit TODO patches can keep the TODO updated in this way. I can also give someone ssh access to my server with the ability to modify only the TODO list. I've never submitted patches for the TODO because it seems pretty silly to go through that much work just to add one line to a file, but being able to change it directly would be a good compromise. I'd be happy to help. Something else that bugs me about the current TODO process is there's a lot of ideas that get brought up but never make it on there. Certainly a lot of them aren't worth putting on there, but there's plenty of items that get left on the floor. It would be nice if there was a better way to deal with these ideas. One possibility: have a 'holding area' (perhaps on a Wiki) where users could add use-cases for these ideas. If there's 'enough demand' (however one defines that), they get promoted to the TODO. Note that this is something geared towards users... things that are obviously useful to -hackers tend to get on the list. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
Bruce Momjian wrote: I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? You can update a wiki instantly. Unless you are a committer, updating the TODO list involves sending in a patch. It should be added that the idea that the TODO list has much authority has been decried in the past. I think the big conclusion we made long ago is that We are never going to have enough detail anywhere that someone is going to be able to work on an item without asking the community. Wikis take a tiny bit of getting used to. But they are extremely useful - they can be used like a kind of online notebook. I find it much easier to make progress notes, reminders, etc in a wiki than in a notebook that I forget to take with me half the time. And they are thus also a great place to record progress. Until you have used this, it seems strange. After you start it doesn't ;-) cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
