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
