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)
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)
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)
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)
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)
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)
Gregory Stark wrote: > Josh Berkus 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)
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)
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)
Josh Berkus 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)
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)
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)
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)
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 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)
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)
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 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)
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 @bugs.debian.org. You can close a bug by mailing [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)
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)
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)
"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)
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)
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)
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 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)
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)
> > 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)
> 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)
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)
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)
> > 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)
> 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. If we ask to take all complains, questions and bugs through a "bugtracker", then it's not a bugtracker. It's more of an "anything goes tracker", that usually ends up being a web based forum (with mail links) without all the features that makes a web based forum at all usable. (And I still think mailinglists are a lot more usable then a web based forum that *does* have a lot of functionality) This is what IMHO you see with a *lot* of OSS projects that use bugzilla or whatever. A bazillion bugs that aren't bugs but discussions or questions etc. Can't speak about the debian example, haven't checked theirs out. We already have our mailinglist archives dealing with this. I really can't see why we'd want to duplicate that and archive things in one more place. > Or: > > b) a private bug database only used by -hackers to track > known outstanding bugs and patches. 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) As a user/admin/whatever, just listing all bugs affecting an installation ("8.0 branch after 8.0.4" for example) so I can evaluate if I need to upgrade is a *very good* thing to be able to do. I realise this adds a bit of overhead for the people doing commits, but it should be possible to integrate that to a point where the overhead is minimized. And it would be a big win. As a -hacker, not needing to keep my own "mailbox format" or "textfile format" bugtracker, and being able to easily find something that would list all communications about a certain bug (*with* links to the archives, where the actual information would still be) would definitly be a win. Tom seems to be able to remember everything in his head and whip out the old commit messages in no time, but I certainly can't ;-) > 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. IMHO, that's the best solution. Except the email discussion lives just fine in the archives, and should be linked back into the tracker if possible instead of copied there. There's also the possibility of c) just using a "bugtracker style interface" as a presentation method over whatever we have now. All our mails go into the archives. If we make sure that all mails about a certain bug are flagged with that bug id (easy enough if it's submitted through the bugs form, I'm sure there can be some voodoo done in majordomo to have it send actual posts to the lists through a script that would do a similar thing), then a tool could fairly easy crawl the archives and pick up all emails related to that bug, and present them separatly. Then if we can convince the committers to always include the bug id when a commit is done for a bug, we'd have the commit messages in the tracker as well... You'd still need someone to fill out metadata like "versions affected" if we want that, but the effort on the "main developers" would pretty much just be to remember to keep the bug id around. //Magnus ---(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)
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)
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)
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
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)
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 <[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)
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)
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 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)
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)
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 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 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)
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)
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)
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: 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)
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)
"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)
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)
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)
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)
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)
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)
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)
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)
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
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
The long-lost pg_upgrade (was:Re: [HACKERS] 8.2 features status)
On Friday 04 August 2006 02:20, Josh Berkus wrote: > 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 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 http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-Original Message- From: "Marc G. Fournier" <[EMAIL PROTECTED]> To: "Dave Page" Cc: "Jim C. Nasby" <[EMAIL PROTECTED]>; "Bruce Momjian" <[EMAIL PROTECTED]>; "Josh Berkus" ; "Christopher Browne" <[EMAIL PROTECTED]>; "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
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
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 ... > 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. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.2 features status
On Wed, 9 Aug 2006, Dave Page wrote: Marc was setting up developer.postgresql.org as a developers wiki btw... Dunno what happened to that. Marc? Two words: House Hunting ... I have to download the stuff from pgFoundry tomorrow night, already have the database server running locally ... will post something to -www as soon as I have something up and running ... 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 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
Robert Treat wrote: On Wednesday 09 August 2006 12:12, Bruce Momjian wrote: 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. Yea, that would be interesting, like a pending TODO item list. 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? 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) On that note, one nice feature of the current setup, is that the only place you need to look is the TODO, which then (hopefully) points you to a detail or url for more info. To have to check the TODO *and* the wiki is just one more thing to forget IMHO. Cheers Mark ---(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 Wednesday 09 August 2006 12:12, Bruce Momjian wrote: > > 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. > > Yea, that would be interesting, like a pending TODO item list. 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? -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL ---(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 Wed, Aug 09, 2006 at 01:56:42PM -0700, Neil Conway wrote: > On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote: > > Well, either people post the changes publically or I trust a few people. > > I don't trust everyone or the TODO becomes a dumping ground, which I am > > afraid might happen with a wiki that anyone can update. > > I think that's preventable, especially if we require logins to edit the > wiki: while people are free to add content, others can clean up new > content and remove dubious additions. Besides, I think the TODO list is > speculative by nature: there are plenty of vague or half-baked ideas on > the current TODO list, for example. > > For those who haven't seen it, I think the GCC Wiki is a good model: > > http://gcc.gnu.org/wiki > > Personally I'd like to see us move toward maintaining the TODO list and > similar developer-oriented information primarily on a wiki. Another possibility for "questionabl" TODO items is to allow users to vote on them. Bugzilla (just as an example) allows users to vote on bugs, but they're only given a limited number of votes, so they have to decide what's most important to them. There's also the idea of "TODO purgatory" that I mentioned earlier. The issue I'm thinking of here is that there are things that would be very beneficial for users to have but that much of -hackers won't care about. Right now, we don't do a very good job of identifying those things (IMHO). -- 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: [HACKERS] 8.2 features status
On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote: > Well, either people post the changes publically or I trust a few people. > I don't trust everyone or the TODO becomes a dumping ground, which I am > afraid might happen with a wiki that anyone can update. I think that's preventable, especially if we require logins to edit the wiki: while people are free to add content, others can clean up new content and remove dubious additions. Besides, I think the TODO list is speculative by nature: there are plenty of vague or half-baked ideas on the current TODO list, for example. For those who haven't seen it, I think the GCC Wiki is a good model: http://gcc.gnu.org/wiki Personally I'd like to see us move toward maintaining the TODO list and similar developer-oriented information primarily on a wiki. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
Andrew Hammond wrote: I am actually hoping that jabber.postgresql.org would help that in the long run. Jabber's ok, but why not go with SILC instead? Because everything supports jabber, I only know of SILC and gaim that support SILC :). Also Jabber is pretty much an accepted standard at this point and if we ever decide to open the server it would be nice to talk to gmail etc... Sincerely, Joshua D. Drake ---(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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.2 features status
Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: 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. IIRC the problem with that patch was basically that the guy had failed to search all of the source code for references to the struct he wanted to modify. This isn't really the fault of the TODO list. It could be (probably already is) a hint in the developer's FAQ ... but I can't see putting that sort of generic how-to-develop-a-good-patch kind of info into every TODO item. I entirely assumed that your references were correct. It was just the only example that I could think up off the top of my head. I was more trying to display a good use of possible dependecies. SIncerely, Joshua D. Drake regards, tom lane ---(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 -- === 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
> I am actually hoping that jabber.postgresql.org would help that in the > long run. Jabber's ok, but why not go with SILC instead? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.2 features status
-Original Message- From: "Jim C. Nasby" <[EMAIL PROTECTED]> To: "Bruce Momjian" <[EMAIL PROTECTED]> Cc: "Josh Berkus" ; "Christopher Browne" <[EMAIL PROTECTED]>; "pgsql-hackers@postgresql.org" Sent: 09/08/06 17:00 Subject: Re: [HACKERS] 8.2 features status > One possibility: have a 'holding area' (perhaps on a Wiki) Marc was setting up developer.postgresql.org as a developers wiki btw... Dunno what happened to that. Marc? /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > 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. IIRC the problem with that patch was basically that the guy had failed to search all of the source code for references to the struct he wanted to modify. This isn't really the fault of the TODO list. It could be (probably already is) a hint in the developer's FAQ ... but I can't see putting that sort of generic how-to-develop-a-good-patch kind of info into every TODO item. regards, tom lane ---(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
OK, so what do you want to do? Oh, sure makes us deliver on our arguments. How very un open source of you :).. Let me get with andrew and I will post back and actual solidified idea. Andrew and I are tabling this until I get back from LinuxWorld. We will be discussing potential ideas to present via email during that week. Joshua D. Drake 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