Thread: Link to bug webpage
If anyone was concerned about our bug database being visible and giving the impression we don't fix any bugs, see this URL: http://www.isthisthingon.org/nisca/postgres.html Not only does it show the problems he had with PostgreSQL, he uses our bug list as an example of how PostgreSQL isn't advancing or interested in fixing bug. We better remove that web page soon: http://www.ca.postgresql.org/bugs/bugs.php?2 -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Thus spake Bruce Momjian > If anyone was concerned about our bug database being visible and giving > the impression we don't fix any bugs, see this URL: > > http://www.isthisthingon.org/nisca/postgres.html Jeez, Louise. Talk about a blaming the tools because you don't know anything about database design. I mean, his biggest complaint is that PostgreSQL makes it hard (not impossible as he implies) to change the schema. Perhaps that is because it was written by GOOD database designers who don't have to change their schema every other week and so that issue hasn't been a squeaky wheel. I can't believe that anyone important is listening to this guy. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
> >We better remove that web page soon: > > http://www.ca.postgresql.org/bugs/bugs.php?2 > Do we have any pages to alter the status of bugs, or assign them? There are a number of bugs in the list that I know are fixed. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On Tue, 21 Aug 2001, Bruce Momjian wrote: > If anyone was concerned about our bug database being visible and giving > the impression we don't fix any bugs, see this URL: > > http://www.isthisthingon.org/nisca/postgres.html > > Not only does it show the problems he had with PostgreSQL, he uses our > bug list as an example of how PostgreSQL isn't advancing or interested > in fixing bug. > > We better remove that web page soon: > > http://www.ca.postgresql.org/bugs/bugs.php?2 I removed the link to the page a few days ago. I guess I should disable it as well. Woulda been a whole lot easier if the database was just updated periodically. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Tue, 21 Aug 2001, Philip Warner wrote: > > > >We better remove that web page soon: > > > > http://www.ca.postgresql.org/bugs/bugs.php?2 > > > > Do we have any pages to alter the status of bugs, or assign them? There are > a number of bugs in the list that I know are fixed. Yes but noone was interested in it. It's still there but you're really the first to show interest in about a year. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
At 08:32 21/08/01 -0400, Vince Vielhaber wrote: > >Yes but noone was interested in it. It's still there but you're really >the first to show interest in about a year. > That's good (and depressing); where are they? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On Tue, 21 Aug 2001, Bruce Momjian wrote: > If anyone was concerned about our bug database being visible and giving > the impression we don't fix any bugs, see this URL: > > http://www.isthisthingon.org/nisca/postgres.html > > Not only does it show the problems he had with PostgreSQL, he uses our > bug list as an example of how PostgreSQL isn't advancing or interested > in fixing bug. > > We better remove that web page soon: > > http://www.ca.postgresql.org/bugs/bugs.php?2 > > Ok the functionality as well as the menu item are gone. You do realize it's going to give the impression that we're trying to hide something, don't you? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
At 08:22 21/08/01 -0400, Vince Vielhaber wrote: > >I removed the link to the page a few days ago. I guess I should disable >it as well. Woulda been a whole lot easier if the database was just >updated periodically. > I don't think this is a good solution. We really do need a list of bugs. We probably need to list status and the releases they apply to. I don't think anybody but the most naieve (or biased) users expect software to be bug free, and the number of bugs grows with the complexity of the components. The fact we have a lot of bugs is to be expected. The fact that we don't mark them as fixed is just sloppy. Please reinstate the page, and allow some facility to edit them. I will try to work through them *slowly* to verify they are reproducible/not reproducible in 7.1.3 and in the current CVS, then mark them as fixed in the appropriate release. Hopefully other people will do the same with bugs they know about. Does this seem reasonable? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
> > > Ok the functionality as well as the menu item are gone. You do realize > > > it's going to give the impression that we're trying to hide something, > > > don't you? > > > > Uh, what choices do we have? Do we want to update that database, seeing > > as only a small percentage of bug reports come in through that > > interface? > > There are over 400 in the database. If that's a small percentage then > so be it, but it's still over 400 bugs that appear to have been ignored. > Having a place to look up possible problems and seeing if there was a > solution seems to be a plus to me, but if you don't want it it doesn't > bother me either way. The lookups are currently disabled, ball's in > your court. It's up to the group to decide. If we have a database of bugs, I think it has to be complete. I think a partial list is worse than no list at all. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 21 Aug 2001, Bruce Momjian wrote: > > On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > > > If anyone was concerned about our bug database being visible and giving > > > the impression we don't fix any bugs, see this URL: > > > > > > http://www.isthisthingon.org/nisca/postgres.html > > > > > > Not only does it show the problems he had with PostgreSQL, he uses our > > > bug list as an example of how PostgreSQL isn't advancing or interested > > > in fixing bug. > > > > > > We better remove that web page soon: > > > > > > http://www.ca.postgresql.org/bugs/bugs.php?2 > > > > > > > > > > Ok the functionality as well as the menu item are gone. You do realize > > it's going to give the impression that we're trying to hide something, > > don't you? > > Uh, what choices do we have? Do we want to update that database, seeing > as only a small percentage of bug reports come in through that > interface? There are over 400 in the database. If that's a small percentage then so be it, but it's still over 400 bugs that appear to have been ignored. Having a place to look up possible problems and seeing if there was a solution seems to be a plus to me, but if you don't want it it doesn't bother me either way. The lookups are currently disabled, ball's in your court. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > If anyone was concerned about our bug database being visible and giving > > the impression we don't fix any bugs, see this URL: > > > > http://www.isthisthingon.org/nisca/postgres.html > > > > Not only does it show the problems he had with PostgreSQL, he uses our > > bug list as an example of how PostgreSQL isn't advancing or interested > > in fixing bug. > > > > We better remove that web page soon: > > > > http://www.ca.postgresql.org/bugs/bugs.php?2 > > > > > > Ok the functionality as well as the menu item are gone. You do realize > it's going to give the impression that we're trying to hide something, > don't you? Uh, what choices do we have? Do we want to update that database, seeing as only a small percentage of bug reports come in through that interface? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
We could install the Postgres version of Bugzilla. Yes, there's a version that runs on Postgres rather than MySQL. That way we don't have to maintain the bug system. > Ok the functionality as well as the menu item are gone. You do realize > it's going to give the impression that we're trying to hide something, > don't you? > > Vince. Cheers, Colin
> > > >It's up to the group to decide. If we have a database of bugs, I think > >it has to be complete. I think a partial list is worse than no list at > >all. > > > > I disagree. Unless you are omniscient, we will only ever have a partial list. > > Perhaps more importantly, the more common ones will be in the list, because > the more often it's reported, the more likely someone will use the bug > tool. If we develop a culture that says 'if it's on the bug list, it will > get looked at', then more people will report bugs via the correct channels > etc. That is the real question. Do we want to rely more heavily on a bug database rather than the email lists? I haven't heard many say they want that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 21 Aug 2001, Colin 't Hart wrote: > We could install the Postgres version of Bugzilla. > Yes, there's a version that runs on Postgres rather than MySQL. > That way we don't have to maintain the bug system. And how does it know when bugs are fixed? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> > Yes, but we have to add items that don't come in through the database, > > and mark them as done/duplicates if we want it to be useful. > > Not necessarily. If someone discovers one that's not in the database > they'll add it. If it's already fixed it'll get closed out but will > still be in the database. It's not intended to be a todo/isdone list > or a development history reference. We have a TODO list and CVS for > that stuff. How do you communicate that to people looking at the content? Do you put in big letters at the top, "This list is not complete." The fact an items is missing from the list (new bug) is just as important as an item appearing on the list. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> >It's up to the group to decide. If we have a database of bugs, I think >it has to be complete. I think a partial list is worse than no list at >all. > I disagree. Unless you are omniscient, we will only ever have a partial list. Perhaps more importantly, the more common ones will be in the list, because the more often it's reported, the more likely someone will use the bug tool. If we develop a culture that says 'if it's on the bug list, it will get looked at', then more people will report bugs via the correct channels etc. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > > > >It's up to the group to decide. If we have a database of bugs, I think > > >it has to be complete. I think a partial list is worse than no list at > > >all. > > > > > > > I disagree. Unless you are omniscient, we will only ever have a partial list. > > > > Perhaps more importantly, the more common ones will be in the list, because > > the more often it's reported, the more likely someone will use the bug > > tool. If we develop a culture that says 'if it's on the bug list, it will > > get looked at', then more people will report bugs via the correct channels > > etc. > > That is the real question. Do we want to rely more heavily on a bug > database rather than the email lists? I haven't heard many say they > want that. The database keeps track of it. When someone uses the bugtool to report a bug it's mailed to the bugs list. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> > That is the real question. Do we want to rely more heavily on a bug > > database rather than the email lists? I haven't heard many say they > > want that. > > The database keeps track of it. When someone uses the bugtool to > report a bug it's mailed to the bugs list. Yes, but we have to add items that don't come in through the database, and mark them as done/duplicates if we want it to be useful. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Philip Warner <pjw@rhyme.com.au> writes: > Please reinstate the page, and allow some facility to edit them. I will try > to work through them *slowly* to verify they are reproducible/not > reproducible in 7.1.3 and in the current CVS, then mark them as fixed in > the appropriate release. Hopefully other people will do the same with bugs > they know about. I think you are wasting your time, unless you can get the community as a whole to buy into the notion that it's a profitable use of our time to try to maintain this bug database. Personally I won't spend any time on it, because it has exactly the same flaws that made our previous experiment in bug-tracking go down in flames: it's incomplete (doesn't track bugs reported via the mailing lists) and at the same time too complete (tracks everything sent in via that web form, which includes a lot of non-bugs). Vince, if I were you I'd just make the page point to the pgsql-bugs archives (http://www.ca.postgresql.org/mhonarc/pgsql-bugs/), which at least gives people the right impression about activity. regards, tom lane
On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > That is the real question. Do we want to rely more heavily on a bug > > > database rather than the email lists? I haven't heard many say they > > > want that. > > > > The database keeps track of it. When someone uses the bugtool to > > report a bug it's mailed to the bugs list. > > Yes, but we have to add items that don't come in through the database, > and mark them as done/duplicates if we want it to be useful. Not necessarily. If someone discovers one that's not in the database they'll add it. If it's already fixed it'll get closed out but will still be in the database. It's not intended to be a todo/isdone list or a development history reference. We have a TODO list and CVS for that stuff. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Philip Warner wrote: > I don't think this is a good solution. We really do need a list of bugs. We > probably need to list status and the releases they apply to. Bugzilla can do this -- it has the concept of a Milestone and a Version. > I don't think anybody but the most naieve (or biased) users expect software > to be bug free, and the number of bugs grows with the complexity of the > components. The fact we have a lot of bugs is to be expected. The fact that > we don't mark them as fixed is just sloppy. Bugzilla makes it fairly painless to mark a bug as fixed. > Please reinstate the page, and allow some facility to edit them. I will try > to work through them *slowly* to verify they are reproducible/not > reproducible in 7.1.3 and in the current CVS, then mark them as fixed in > the appropriate release. Hopefully other people will do the same with bugs > they know about. > > Does this seem reasonable? If we install Bugzilla (running on Postgres, not MySQL, obviously) we save ourselves the hassle of maintaining the bug system, and we can showcase that Postgres *can* be to back a web-based system :-) Cheers, Colin
> > Can someone point me to a bug that is _not_ on the TODO list? If not, > > what does a complete bug database do for us except list reported bugs > > and possible workarounds. > > Do you actually expect someone to go thru the 400+ items in the database > and compare them to the TODO list? Seems to me that's something the > maintainer of the TODO list would be doing. Can you point me to the form > that gets something on the TODO list that the average user can use? Can > you guarantee every bug will end up on the TODO list? Can you point me > to the place on the TODO list when a user can look at to see if a bug has > been fixed or even reported? I was just asking. If I have been missing stuff, I can see more value to a bug database. > You're making more of an issue with all of this than there is. The TODO > list has a purpose, as does CVS, as do the mailing lists, as does the > regression database, as does the bugs database, as do the interactive > docs, ... OK, what value does a bug database have over a TODO list? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > We could try going the other way, attaching URL's to the TODO items so > > people can get more information about an existing bug. > > That might be worth doing, but I think it's mostly orthogonal to the > question of a bug database. The set of problems that are (still) on the > TODO list is just a small fraction of the set of bugs that someone might > look in a bug database for --- anything that's already fixed in current > sources is probably not going to be on TODO, if it ever got there at > all (which easily-fixed problems do not). That is a good point. I remove items after we make a release, and we don't record quickly fixed items. I wonder if I should keep the HISTORY file updated more frequently so people can see what has been fixed from the previous release. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > > > Yes, but we have to add items that don't come in through the database, > > > > and mark them as done/duplicates if we want it to be useful. > > > > > > Not necessarily. If someone discovers one that's not in the database > > > they'll add it. If it's already fixed it'll get closed out but will > > > still be in the database. It's not intended to be a todo/isdone list > > > or a development history reference. We have a TODO list and CVS for > > > that stuff. > > > > How do you communicate that to people looking at the content? Do you > > put in big letters at the top, "This list is not complete." The fact an > > items is missing from the list (new bug) is just as important as an item > > appearing on the list. > > Huh? A list of bugs is only as complete as those submitting to it ... its > no more, or less, complete then a mailing list *shrug* Not really. The bug database only gets submissions from the web form, as far as I know. It doesn't get direct postings to the bugs list, and even then, lots of bugs aren't reported on the bugs list. If we open it up to all lists, it becomes identical to our mailing list archives. The comment above was saying showing some bugs is better than nothing, meaning do you show the list even if you know it isn't being maintained or updated. I think that is worse than not showing it at all. Now, if it was updated with all bugs as they come in, and updated as completed, that would be nice, but it is a lot of work and I am not sure if it is worth doing. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
How about we trial it, but with the understanding that bugs we fix will be marked as such? After all, every bug is given an ID, so whomever fixes the bug with that ID should also mark it off. Looking at the present situation, it seems we began a good idea, but never really followed through with it. Maybe it's time to. Philip seems to be volunteering for taking care of what's presently in there, can we also ask those [HACKERS] who commit fixes to mark them off? + Justin Bruce Momjian wrote: > > > > > > >It's up to the group to decide. If we have a database of bugs, I think > > >it has to be complete. I think a partial list is worse than no list at > > >all. > > > > > > > I disagree. Unless you are omniscient, we will only ever have a partial list. > > > > Perhaps more importantly, the more common ones will be in the list, because > > the more often it's reported, the more likely someone will use the bug > > tool. If we develop a culture that says 'if it's on the bug list, it will > > get looked at', then more people will report bugs via the correct channels > > etc. > > That is the real question. Do we want to rely more heavily on a bug > database rather than the email lists? I haven't heard many say they > want that. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Tue, 21 Aug 2001, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > >> That is the real question. Do we want to rely more heavily on a bug > >> database rather than the email lists? I haven't heard many say they > >> want that. > > > The database keeps track of it. When someone uses the bugtool to > > report a bug it's mailed to the bugs list. > > But the problem is the lack of feedback the other way. In my mind, > and I think in the minds of the rest of the developers, the pgsql-bugs > list is where bug discussions happen. That's not something I have any > interest in trying to change. Thus, I see little point in trying to > maintain a bug database that's separate from the pgsql-bugs archives. > > I still think a link to a searchable pgsql-bugs archive could replace > this bug database very easily. Some of the discussions could go on for weeks. Are you saying that wading thru a few hundred posts to find out what a solution was is better than a quick searchable summary? Personally I don't care if the bugs form, database, or any of that gets used. But if anyone expects to get meaningful bug reports you better plan on coming up with something alot easier than a mailing list you have to subscribe to (or wait till approved) for your info. You need to ask yourself how many bugs wouldn't be reported if it was harder to report them. PostgreSQL is gaining in the number of users, it's gonna get a whole lot worse before it gets any better. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
A web-based interface allows people to submit bug reports they might otherwise not be able to report. Not everyone is able/willing to sign-up to a mailing list, nor have newsfeed access. The one we have (had) allows the reporting, but has the flaw of not showing when something has been done about a bug. That could be fixed by either not keeping a history, or marking their status's as closed when done. At a minimum, I reckon we should have the web interface there, even if it just pipes the report to the mailing list and doesn't keep a history at all. + Justin Bruce Momjian wrote: > > > > Yes, but we have to add items that don't come in through the database, > > > and mark them as done/duplicates if we want it to be useful. > > > > Not necessarily. If someone discovers one that's not in the database > > they'll add it. If it's already fixed it'll get closed out but will > > still be in the database. It's not intended to be a todo/isdone list > > or a development history reference. We have a TODO list and CVS for > > that stuff. > > How do you communicate that to people looking at the content? Do you > put in big letters at the top, "This list is not complete." The fact an > items is missing from the list (new bug) is just as important as an item > appearing on the list. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
MySQL has to first add some features in order to have some bugs, don't they? :-) Some people crack me up in their opinions.. If it took him 6 hours to figure out "int8" then I'm not really interested in anything else he has to say... Lord... -Mitch ----- Original Message ----- From: "Bruce Momjian" <pgman@candle.pha.pa.us> To: "PostgreSQL-development" <pgsql-hackers@postgresql.org> Sent: Tuesday, August 21, 2001 7:05 AM Subject: [HACKERS] Link to bug webpage > If anyone was concerned about our bug database being visible and giving > the impression we don't fix any bugs, see this URL: > > http://www.isthisthingon.org/nisca/postgres.html > > Not only does it show the problems he had with PostgreSQL, he uses our > bug list as an example of how PostgreSQL isn't advancing or interested > in fixing bug. > > We better remove that web page soon: > > http://www.ca.postgresql.org/bugs/bugs.php?2 > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
On Tue, 21 Aug 2001, Bruce Momjian wrote: > > How about we trial it, but with the understanding that bugs we fix will > > be marked as such? > > > > After all, every bug is given an ID, so whomever fixes the bug with that > > ID should also mark it off. > > > > Looking at the present situation, it seems we began a good idea, but > > never really followed through with it. Maybe it's time to. > > > > Philip seems to be volunteering for taking care of what's presently in > > there, can we also ask those [HACKERS] who commit fixes to mark them > > off? > > Can someone point me to a bug that is _not_ on the TODO list? If not, > what does a complete bug database do for us except list reported bugs > and possible workarounds. Do you actually expect someone to go thru the 400+ items in the database and compare them to the TODO list? Seems to me that's something the maintainer of the TODO list would be doing. Can you point me to the form that gets something on the TODO list that the average user can use? Can you guarantee every bug will end up on the TODO list? Can you point me to the place on the TODO list when a user can look at to see if a bug has been fixed or even reported? You're making more of an issue with all of this than there is. The TODO list has a purpose, as does CVS, as do the mailing lists, as does the regression database, as does the bugs database, as do the interactive docs, ... Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
>> That is the real question. Do we want to rely more heavily on a bug
>> database rather than the email lists? I haven't heard many say they
>> want that.
> The database keeps track of it. When someone uses the bugtool to
> report a bug it's mailed to the bugs list.
But the problem is the lack of feedback the other way. In my mind,
and I think in the minds of the rest of the developers, the pgsql-bugs
list is where bug discussions happen. That's not something I have any
interest in trying to change. Thus, I see little point in trying to
maintain a bug database that's separate from the pgsql-bugs archives.
I still think a link to a searchable pgsql-bugs archive could replace
this bug database very easily.
regards, tom lane
Bruce Momjian writes: > OK, what value does a bug database have over a TODO list? The former is a database, the latter is a flat-text file. The former is mult-user, the latter is single-user. You figure out the rest. ;-) Seriously, IMHO a real bug database would be useful. A number of solutions for this are available, including the one Vince developed. But I will refuse to participate in a bug database that ordinary users have write access to. The sort of stuff that comes in over the bug list and through whatever else just isn't filtered enough. But in an organization that claims to be professional, when users report an actual problem they expect to be able to track this problem. I keep track of the problems that seem important to me myself, because I have no other place to put this information. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> How about we trial it, but with the understanding that bugs we fix will > be marked as such? > > After all, every bug is given an ID, so whomever fixes the bug with that > ID should also mark it off. > > Looking at the present situation, it seems we began a good idea, but > never really followed through with it. Maybe it's time to. > > Philip seems to be volunteering for taking care of what's presently in > there, can we also ask those [HACKERS] who commit fixes to mark them > off? Can someone point me to a bug that is _not_ on the TODO list? If not, what does a complete bug database do for us except list reported bugs and possible workarounds. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
----- Original Message ----- From: Bruce Momjian <pgman@candle.pha.pa.us> Sent: Tuesday, August 21, 2001 8:48 AM > > On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > > > > > > Not only does it show the problems he had with PostgreSQL, he uses our > > > bug list as an example of how PostgreSQL isn't advancing or interested > > > in fixing bug. > > > > > > We better remove that web page soon: > > > > > > http://www.ca.postgresql.org/bugs/bugs.php?2 > > > > > > > Ok the functionality as well as the menu item are gone. You do realize > > it's going to give the impression that we're trying to hide something, > > don't you? > > Uh, what choices do we have? Do we want to update that database, seeing > as only a small percentage of bug reports come in through that > interface? Maybe a better solution for the short run would be return the page where it was, and but links to the pgsql-bugs and pgsql-hackers archives with some sort of exmplanatory saying that "this is a *complete* (it must be complete of course) list of bugs, which are being extensively discussed in the these lists and fixed. Please, visit/search these mail archives for most up-to-date information blah blah blah" One can invent some appropriate wording, I guess. But this atleast will show people that there's work acually going on, and on daily basis. And also a good idea to have "Last updated" time stamp on the page too... so it doesn't seem to be forgotten for ages.. S.
On Tue, 21 Aug 2001, Lamar Owen wrote: > On Tuesday 21 August 2001 11:11, Bruce Momjian wrote: > > OK, what value does a bug database have over a TODO list? > > The TODO list isn't just a list of bugs that need fixing. > > A bug database is just that -- a list of bugs in existing features. While > Requests of Enhancements certainly can be accomodated through a bug database, > that isn't its primary function. > > Bugzilla, while clunky for some things, does have some great benefits, > including the ability to discuss that bug in context; attach patches, logs, > stack traces, or whatnot; mark the bug's status; assign the bug to someone; > as well as many other features. > > The TODO list as well as the mailing lists, while both great for what they > do, make it all too easy to loose a bug's context, being that both lists are > flat-files trying to track relational things. :-) > > Red Hat makes mission-critical use of bugzilla running on Oracle. See > bugzilla.redhat.com. And ask the Red Hat people on these lists their > opinions of bugzilla. What who thinks of what has actually become irrelevant. The following is clear: o No tool will replace the mailing listso The mailing lists are where discussion will be heldo Many/most maintainers haveno desire to update bug reports Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> Some of the discussions could go on for weeks. Are you saying that
> wading thru a few hundred posts to find out what a solution was is
> better than a quick searchable summary?
Given a threaded index, you aren't wading through "a few hundred posts".
Agreed, a nice canned database entry might be easier to look at, but
who's going to expend the time to maintain the database? Unless someone
actively takes responsibility for keeping the DB up to date, it'll be
junk. So far I heard Philip say he'd be willing to check over some
fraction of the existing entries, but I don't hear anyone wanting to
take it on as a long-term commitment.
> You need to ask yourself how many bugs wouldn't be reported if it
> was harder to report them.
Who said anything about making it harder to report them? The webform
feeding into pgsql-bugs is just fine with me. Seems to me the
discussion here is about how we keep track of the results of pgsql-bugs
activity.
regards, tom lane
On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > Yes, but we have to add items that don't come in through the database, > > > and mark them as done/duplicates if we want it to be useful. > > > > Not necessarily. If someone discovers one that's not in the database > > they'll add it. If it's already fixed it'll get closed out but will > > still be in the database. It's not intended to be a todo/isdone list > > or a development history reference. We have a TODO list and CVS for > > that stuff. > > How do you communicate that to people looking at the content? Actually right now I'm just trying to communicate that to you. > Do you > put in big letters at the top, "This list is not complete." The fact an > items is missing from the list (new bug) is just as important as an item > appearing on the list. In any situation the list not being complete should be more than obvious. The important part here that seems to be slipping away is that noone is updating it when things are fixed (sans Phillip). Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> > > Do you actually expect someone to go thru the 400+ items in the database > > > and compare them to the TODO list? Seems to me that's something the > > > maintainer of the TODO list would be doing. Can you point me to the form > > > that gets something on the TODO list that the average user can use? Can > > > you guarantee every bug will end up on the TODO list? Can you point me > > > to the place on the TODO list when a user can look at to see if a bug has > > > been fixed or even reported? > > > > I was just asking. If I have been missing stuff, I can see more value > > to a bug database. > > > > > You're making more of an issue with all of this than there is. The TODO > > > list has a purpose, as does CVS, as do the mailing lists, as does the > > > regression database, as does the bugs database, as do the interactive > > > docs, ... > > > > OK, what value does a bug database have over a TODO list? > > History. Searchability. Doesn't include features to be addeed. Yea, they would be nice. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > Can someone point me to a bug that is _not_ on the TODO list? If not, > > > what does a complete bug database do for us except list reported bugs > > > and possible workarounds. > > > > Do you actually expect someone to go thru the 400+ items in the database > > and compare them to the TODO list? Seems to me that's something the > > maintainer of the TODO list would be doing. Can you point me to the form > > that gets something on the TODO list that the average user can use? Can > > you guarantee every bug will end up on the TODO list? Can you point me > > to the place on the TODO list when a user can look at to see if a bug has > > been fixed or even reported? > > I was just asking. If I have been missing stuff, I can see more value > to a bug database. > > > You're making more of an issue with all of this than there is. The TODO > > list has a purpose, as does CVS, as do the mailing lists, as does the > > regression database, as does the bugs database, as do the interactive > > docs, ... > > OK, what value does a bug database have over a TODO list? History. Searchability. Doesn't include features to be addeed. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Tue, 21 Aug 2001, Bruce Momjian wrote: > > > Yes, but we have to add items that don't come in through the database, > > > and mark them as done/duplicates if we want it to be useful. > > > > Not necessarily. If someone discovers one that's not in the database > > they'll add it. If it's already fixed it'll get closed out but will > > still be in the database. It's not intended to be a todo/isdone list > > or a development history reference. We have a TODO list and CVS for > > that stuff. > > How do you communicate that to people looking at the content? Do you > put in big letters at the top, "This list is not complete." The fact an > items is missing from the list (new bug) is just as important as an item > appearing on the list. Huh? A list of bugs is only as complete as those submitting to it ... its no more, or less, complete then a mailing list *shrug*
> Vince Vielhaber <vev@michvhf.com> writes: > > Some of the discussions could go on for weeks. Are you saying that > > wading thru a few hundred posts to find out what a solution was is > > better than a quick searchable summary? > > Given a threaded index, you aren't wading through "a few hundred posts". > Agreed, a nice canned database entry might be easier to look at, but > who's going to expend the time to maintain the database? Unless someone > actively takes responsibility for keeping the DB up to date, it'll be > junk. So far I heard Philip say he'd be willing to check over some > fraction of the existing entries, but I don't hear anyone wanting to > take it on as a long-term commitment. We could try going the other way, attaching URL's to the TODO items so people can get more information about an existing bug. We already have that for TODO.detail but we could certainly expand on that. In fact, it may be interesting to load the TODO list into a database and start attaching emails to individual items. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, Aug 21, 2001 at 09:51:29AM -0400, Bruce Momjian wrote: > > > > > >It's up to the group to decide. If we have a database of bugs, I think > > >it has to be complete. I think a partial list is worse than no list at > > >all. > > > > > > > I disagree. Unless you are omniscient, we will only ever have a partial list. > > > > Perhaps more importantly, the more common ones will be in the list, because > > the more often it's reported, the more likely someone will use the bug > > tool. If we develop a culture that says 'if it's on the bug list, it will > > get looked at', then more people will report bugs via the correct channels > > etc. > > That is the real question. Do we want to rely more heavily on a bug > database rather than the email lists? I haven't heard many say they > want that. > I think this is related to the discussions about what to do with extensions, etc. The project is outgrowing its infrastructure. A bug database is one of those things that is hard to justify and maintain when all the developers can keep up with all the mailing lists, but that hasn't been true for a while, now. The _need_ for a bug database was recognized, but there wasn't enough interest for someone to take on the maintenance. As new developers have come in and taken over things like the JDBC driver, and the ODBC driver, no one has the entire state of the code in their head anymore. And, I think the project has reached critical mass: attracting new developers is not a big problem - other projects are taking PostgreSQL up as their base, without any selling from the core developers. Perhaps trying again (either with the existing system, or the PostgreSQL based Bugzilla) is the right answer. Personally, I think a bug database that coordinates with the email archives is the best of both worlds. That way, discussion about a bug, and it's state all get archived in the same location, without a lot of extra bother on the parts of the developers, just make sure to CC: the bug system. Call for volunteers who wish to be involved in the maintenence, open up the system, and put it on the list of TODO for release: 'check status and usefulness of current bug reporting system' so it gets looked at again at regular, appropriate intervals. Ross
On Tuesday 21 August 2001 11:59, Vince Vielhaber wrote: > On Tue, 21 Aug 2001, Lamar Owen wrote: > > Red Hat makes mission-critical use of bugzilla running on Oracle. See > > bugzilla.redhat.com. And ask the Red Hat people on these lists their > > opinions of bugzilla. > What who thinks of what has actually become irrelevant. Not really. I like to see what works for other projects before passing judgment -- and bugzilla and bug trackers of like bent are working very well for other projects. Red Hat is just one of the largest such 'projects.' >The following > is clear: > o No tool will replace the mailing lists > o The mailing lists are where discussion will be held > o Many/most maintainers have no desire to update bug reports Ok, having been involved in a project that has both an active mailing list AND a bug tracker, I can comment on this. I am not interested in finding a mailing list _replacement_. I am, however, interested in finding a augmentative solution that does well what mailing lists do not do well. Mailing lists do many things well, but they do not do the business of bugtracking well. Particularly as the size and scope of the project goes up. Bug trackers do not do the thing of discussion well. They do, however, do the thing of bug status reporting _very_ well. They also do the thing of relating bugs to OS versions, releases, and libraries much easier than with a list. Reference the '7.1.2-3' patch bug sent last week. Much was said that was not at all related to the real problem -- Windows 98. While the new fts mailing list search is VERY nice, mailing list bug reports and the discussion that follows may or may not help someone down the road. IOW, just how useful are our [BUGS] archives from two years ago? Just how useful are any of our archives, for that matter? I have found them useful on occassion -- but those occassions are rather rare and usually are just to remember what _I_ said about something. Or to see what Tom Lane's first post was. Or to see how long somebody has been with the project. Etc. I don't want to see the searchable archives go away, of course -- but I am questioning how useful they are to _non-developers_. A dynamic tracker would show bugs that were fixed at various versions. It would also make the project seem more responsive to those not on the lists --the vast majority of our users likely don't even know these lists are as useful as they are. I had used PostgreSQL for two years before I found out that the mailling lists are where _it's_ happening. I was _amazed_ at these lists and their contents. And I ran a Usenet site ten years ago, at that. Maybe that was the source of my amazement, OTOH. I've been through news.groups wars, news.admin wars, etc. There weren't any real 'wars' here --and that was _different_. JMHO, of course. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> We could try going the other way, attaching URL's to the TODO items so
> people can get more information about an existing bug.
That might be worth doing, but I think it's mostly orthogonal to the
question of a bug database. The set of problems that are (still) on the
TODO list is just a small fraction of the set of bugs that someone might
look in a bug database for --- anything that's already fixed in current
sources is probably not going to be on TODO, if it ever got there at
all (which easily-fixed problems do not).
regards, tom lane
> Justin Clift <justin@postgresql.org> writes: > > After all, every bug is given an ID, so whomever fixes the bug with that > > ID should also mark it off. > > Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs > doesn't show any such thing. > > This isn't going to happen unless there's some fairly convenient > mechanism to make it happen *in the context of responding to email > on the pgsql-bugs list*. At the very least, the webform should add > a link to an appropriate status-update page to the mail that it forwards > to the list. That would be pretty cool, using the mailing list archives as an _answer_ to the bug report. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tuesday 21 August 2001 11:11, Bruce Momjian wrote: > OK, what value does a bug database have over a TODO list? The TODO list isn't just a list of bugs that need fixing. A bug database is just that -- a list of bugs in existing features. While Requests of Enhancements certainly can be accomodated through a bug database, that isn't its primary function. Bugzilla, while clunky for some things, does have some great benefits, including the ability to discuss that bug in context; attach patches, logs, stack traces, or whatnot; mark the bug's status; assign the bug to someone; as well as many other features. The TODO list as well as the mailing lists, while both great for what they do, make it all too easy to loose a bug's context, being that both lists are flat-files trying to track relational things. :-) Red Hat makes mission-critical use of bugzilla running on Oracle. See bugzilla.redhat.com. And ask the Red Hat people on these lists their opinions of bugzilla. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, what value does a bug database have over a TODO list?
A TODO list is forward-looking. Many of the entries in a bug database
would be backward-looking (already fixed). We shouldn't try to make
either one serve the purpose of the other.
regards, tom lane
Justin Clift <justin@postgresql.org> writes:
> After all, every bug is given an ID, so whomever fixes the bug with that
> ID should also mark it off.
Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs
doesn't show any such thing.
This isn't going to happen unless there's some fairly convenient
mechanism to make it happen *in the context of responding to email
on the pgsql-bugs list*. At the very least, the webform should add
a link to an appropriate status-update page to the mail that it forwards
to the list.
regards, tom lane
I know I am not on the kernel team, but I have been a software developer for almost 20 years. ;-) A bug database is a useful tool IF it has been setup to be so. If it is a bare bones repository for bug reports it will not work. People won't use it. A "good" bug database, i.e. one which will be used, must be administered, and that administration must be easier than dealing with the various items separately. Also, there should be "approved" severity numbers, and a difference between "entered" and "confirmed" bugs, especially if you allow external access to the database. For what it is worth, a "good" bug database, which is used and reliable, would do much for PostgreSQL's reputation in the commercial IT space. The danger is that a bad or unused bug database would probably do more harm than not having one. Bruce Momjian wrote: > If anyone was concerned about our bug database being visible and giving > the impression we don't fix any bugs, see this URL: > > http://www.isthisthingon.org/nisca/postgres.html > > Not only does it show the problems he had with PostgreSQL, he uses our > bug list as an example of how PostgreSQL isn't advancing or interested > in fixing bug. > > We better remove that web page soon: > > http://www.ca.postgresql.org/bugs/bugs.php?2 > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html
> On Tue, 21 Aug 2001, Lamar Owen wrote: [...] > > What who thinks of what has actually become irrelevant. The following > is clear: > > o No tool will replace the mailing lists > o The mailing lists are where discussion will be held > o Many/most maintainers have no desire to update bug reports disadvantages of a mailinglist: - easy problems are solved by 10 people in 5 minutes, hard ones often by none - not clear who is the "owner" of a problem OK so what we need is an enhaced mailinglist with a web interface. I've used wreq (http://www.math.duke.edu/~yu/wreq/) in the past for something similar. Features: - web and mail interface - each problem gets an assigned owner - status of entered items is clear - not much extra work in comparison to a mailinglist. - outstanding bugs stay visible until closed (instead of forgotten) It may not be ideal for this kind of thing, but it is a start. Has anyone suggestions for a better tool? Reinoud
"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> The project is outgrowing its infrastructure.
Perhaps so. I think what's *really* needed here is someone who is
willing to take responsibility for maintaining a bug database, ie,
removing cruft (non-bug messages), making sure that old bugs are
marked closed when a developer forgets to do it, etc etc. It doesn't
matter what automatic systems we have in place unless a human is
willing to take responsibility for quality control. But given a
volunteer, a bug database could be a really nice thing to have.
If we're getting as big as all that, a volunteer or three to do this
shouldn't be impossible to come by.
> I think a bug database that coordinates with the email archives is the
> best of both worlds. That way, discussion about a bug, and it's state
> all get archived in the same location, without a lot of extra bother on
> the parts of the developers, just make sure to CC: the bug system.
I like that idea a lot: just cc: to some bug-input address to add or
update the collected mail for any one bug.
Peter remarked that he wouldn't use a bug database unless it has some
input filtering to remove all the non-bug issues that currently clutter
the pgsql-bug archives. I tend to agree with him. A possible way to
handle that is to set up bug-input like a closed mailing list: only
accept mail from designated people (developers and people nominated to
help run the bug database). So, a bug database entry would start life
when some one of these people replies to an emailed bug report
confirming that there is a bug, or forwards the verified report to
bug-input, or whatever.
It'd still need a maintainer, but something like this would fit
comfortably into our existing habits, which a pure web-based system
won't.
So: any volunteers to set this up and help run it?
regards, tom lane
On Tuesday 21 August 2001 11:06, Mitch Vincent wrote: > Some people crack me up in their opinions.. If it took him 6 hours to > figure out "int8" then I'm not really interested in anything else he has to > say... Lord... Hmmm... Let's look at the guy's bulleted list. The first item he can't stand is that you can't add a column after any arbitrary column, that it goes at the end. Well, this is really clueless, as you order the columns when you SELECT or when the application presents the data. The second item, however, has some real meat in it. Don't tell me that I should have a correct design before writing any application code. Any programmer knows that the user's needs change over time -- and the database should be able to keep up without any problems. I have myself ran into PostgreSQL's ALTER-hostile environment. I'm patient, however, as I need the featureset. Our ALTER needs real muscle. Some things are already on our TODO list to fix this, though -- and this guy should have checked that. But maybe he didn't find our TODO list. And 7.1 is much better than 7.0.3, the version he looked at. That third item, about int8. Can a clueless newbie who's heard that PostgreSQL is so great, knowing NOTHING about it, find things reasonably well in the docs? Only clueless newbies should answer that question -- I, nor any developer, qualify to answer that question. The fourth item looks like whining, IMHO. The problem he describes is merely annoying to him -- yet it's bulleted. Sounds like a MySQL partisan who's upset that PostgreSQL is better at many things and is trying to justify not supporting PostgreSQL out of personal bias. However, if it weren't too difficult to support index creation at table creation time, why NOT allow that? Do we just not _want_ to do it? I didn't see it in my read of TODO. Of course, the guy didn't ask on the lists to have it put in TODO. But how would he know to ask to have something put in TODO? Our development process is very simple, but is also rather opaque to outsiders. Maybe that's a good thing; maybe that's bad. Should we let just any user know that if they want a feature, they need to ask to have it placed on TODO? Or are people really not reading the docs? (Experienced admins know the answer to THATquestion.....) Our documentation is, however, much better now than when I started. Kudos to Thomas and all the rest that have contributed. I also like the direction techdocs.postgresql.org is going. The last worthwhile item on this guy's list is changing ownership of a database. Well, I haven't yet had to do this: can we do this easily? Just because someone is clueless and even obnoxious in their comments doesn't automatically disqualify what they say from validity. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Has anyone thought of using Bugzilla? (It is MySQL based, of course) but it might answer the bug database issues. (If you guys want a bug database) RedHat has a version which can use Oracle, but it seems there is a file: ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz that my be interesting.
On Tuesday 21 August 2001 12:47, Bruce Momjian wrote: > > Justin Clift <justin@postgresql.org> writes: > > > After all, every bug is given an ID, so whomever fixes the bug with > > > that ID should also mark it off. > That would be pretty cool, using the mailing list archives as an > _answer_ to the bug report. X-PostgreSQL-bug-ID: anyone? Or leave the bug ID number in the subject? Then the replies can be properly inserted into the database as belonging to an ID. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> > > I disagree. Unless you are omniscient, we will only ever have a partial > > > list. > but there wasn't enough interest for someone to take on > the maintenance. We need someone willing to be a kibo. Or is that too arcane a reference? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Vince Vielhaber wrote: > > What who thinks of what has actually become irrelevant. The following > is clear: > > o No tool will replace the mailing lists > o The mailing lists are where discussion will be held > o Many/most maintainers have no desire to update bug reports If anyone is interested, I am willing to undertake to be the link between the bugs mailing list and a bugs database. This should allow developers to continue to deal with the mailing list, just CCing a special e-mail address whenever a bug was fixed. I would then take care of finding the appropriate bug(s) in the database and marking them as fixed. There are two large, well-used bugs databases that I am aware of with somewhat different strengths:- The Debian Bug Tracking System- Bugzilla there are a gazillion others, of course, but let's just consider those two for the moment. In some ways the Debian bug tracking system is a closer fit to the way PostgreSQL currently works, since it drives into a mailing list, bug submission is via e-mail and bug control is via e-mail as well. Bugzilla is probably a closer fit in reality, since it is more focused around bugs for a single application. If Bugzilla were installed I'm sure some functionality could be added into it along the lines of the Debian BTS too. Regards, Andrew. -- _____________________________________________________________________ Andrew McMillan, e-mail: Andrew @ catalyst .net . nz Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64(21)635-694, Fax:+64(4)499-5596, Office: +64(4)499-2267xtn709
Lamar Owen <lamar.owen@wgcr.org> writes: > Let's look at the guy's bulleted list. > The first item he can't stand is that you can't add a column after any > arbitrary column, that it goes at the end. Well, this is really > clueless, as you order the columns when you SELECT or when the > application presents the data. Well, I can see some value in it --- but not enough to justify the implementation pain. It certainly is pretty weak as a leadoff gripe. > The second item, however, has some real meat in it. Agreed, we need better ALTER capability. As you say, it's on the TODO list. > That third item, about int8. Can a clueless newbie who's heard that > PostgreSQL is so great, knowing NOTHING about it, find things > reasonably well in the docs? He apparently didn't get as far as looking at Table 3-1, on the first page of the user's guide chapter on datatypes. Still, improving the docs is an ever-important task. > However, if it weren't too > difficult to support index creation at table creation time, why NOT allow > that? Do we just not _want_ to do it? We do support it, for UNIQUE indexes (see UNIQUE and PRIMARY KEY constraints). As for why not plain indexes too, the main answer is that UNIQUE constraints are SQL92 and any syntax to create indexes otherwise is not. Of course a CREATE INDEX command is not to be found in SQL92 either, but on the whole I agree with you; this is hard to read as anything except MySQL's-way-is-the-only-way partisanship. There hasn't been a lot of talk recently about adopting MySQL-isms, at least not anywhere near as much as about adopting Oracle-isms. I'd tend to treat either sort of proposal with suspicion, but we ought to be open to the idea if we are interested in attracting users of other DBMSs. Real question is, who out there is excited enough about this point to do the work? > Of course, the guy didn't ask on the lists to have it put in TODO. But how > would he know to ask to have something put in TODO? I see no evidence that this guy wants to learn about or contribute to Postgres development at all; he's just looking for things to rag on. (And not even doing very well at that --- I could name ten worse problems than these without taking a breath...) The TODO list is mentioned prominently on the website, for example. > The last worthwhile item on this guy's list is changing ownership of a > database. Well, I haven't yet had to do this: can we do this easily? It could be better. See recent "Multiple Servers" thread over in pg-admin, notably http://fts.postgresql.org/db/mw/msg.html?mid=1031042 (which the FTS server seems not to have linked into the thread for some reason) regards, tom lane
On Tue, 21 Aug 2001, Lamar Owen wrote: > > > > I disagree. Unless you are omniscient, we will only ever have a partial > > > > list. > > but there wasn't enough interest for someone to take on > > the maintenance. > > We need someone willing to be a kibo. Or is that too arcane a reference? Gotta admit, I haven't heard that in a while. But I think I'm nearing a solution. Stay tuned. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Bruce Momjian writes: > Can someone point me to a bug that is _not_ on the TODO list? Just looking through pgsql-bugs of the last two weeks, the following all look reasonable. http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00084.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00078.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00089.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00086.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00042.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00036.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00035.html http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00012.html At least a couple of them I would want to have recorded somewhere. > If not, what does a complete bug database do for us except list > reported bugs and possible workarounds. history, searchability -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> I see no evidence that this guy wants to learn about or contribute to > Postgres development at all; he's just looking for things to rag on. > (And not even doing very well at that --- I could name ten worse > problems than these without taking a breath...) The TODO list is > mentioned prominently on the website, for example. Seeing as it was written about 7.0.X, and it took >1 year for anyone to even mention it here, meaning no one else is reading it either. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian writes: > > > Can someone point me to a bug that is _not_ on the TODO list? > > Just looking through pgsql-bugs of the last two weeks, the following all > look reasonable. > > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00084.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00078.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00089.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00086.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00042.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00036.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00035.html > http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00012.html Yes, these are all valid bugs that the TODO list didn't capture. Good point. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > > > > I disagree. Unless you are omniscient, we will only ever have a partial > > > > > list. > > > but there wasn't enough interest for someone to take on > > > the maintenance. > > > > We need someone willing to be a kibo. Or is that too arcane a reference? > > Gotta admit, I haven't heard that in a while. But I think I'm nearing > a solution. Stay tuned. > I don't know what a kibo is, but I would be willing to put in some time helping maintaing a bug reporting system. One of the helpful things with bugzilla setup with some other big projects is that the bug gets assigned to a developer and the bug submitter gets emailed updates any time there is a status change. I agree that a bug database is not a replacement for the mailing lists, but I do think it could serve the project well if it is done correctly. I think most uses look for a bugzilla type bug reporting tool these days.
mlw wrote: > Has anyone thought of using Bugzilla? (It is MySQL based, of course) but it > might answer the bug database issues. (If you guys want a bug database) Bug tracking software that doesn't use transactions and referential integrity in a multiuser environment? Soundslike a bug by design to me, which are known not to be traceable by software. So the system might trace it's ownbugs while never catching the biggies ... Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck wrote: > > mlw wrote: > > Has anyone thought of using Bugzilla? (It is MySQL based, of course) but it > > might answer the bug database issues. (If you guys want a bug database) > > Bug tracking software that doesn't use transactions and > referential integrity in a multiuser environment? Sounds like > a bug by design to me, which are known not to be traceable by > software. So the system might trace it's own bugs while never > catching the biggies ... > RedHat has ported bugzilla to postgres, which I alluded too, but maybe I should be a bit more explicit. ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz (They have also ported it to Oracle.) Like I said before, a "good" i.e. used, up to date, and complete, bug database/tracking system impresses many people that make IT decisions. (but it better be good.) Something like Bugzilla, or PVCS Tracker, or what ever, may need to be the next stage in PostgreSQL's evolution from a university project to a full professional solution. -- 5-4-3-2-1 Thunderbirds are GO! ------------------------ http://www.mohawksoft.com
Jan Wieck said: > > Has anyone thought of using Bugzilla? (It is MySQL based, of course) but it > > might answer the bug database issues. (If you guys want a bug database) > > Bug tracking software that doesn't use transactions and > referential integrity in a multiuser environment? Sounds like > a bug by design to me, which are known not to be traceable by > software. So the system might trace it's own bugs while never > catching the biggies ... I agree, of course. That's why we'd use a Postgres port of Bugzilla: http://groups.google.com/groups?hl=en&safe=off&th=9efb66b03a69b9fd,1 and available at ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz Cheers, Colin
Matthew T. O'Connor volunteered: > I don't know what a kibo is, but I would be willing to put in some time > helping maintaing a bug reporting system. One of the helpful things with > bugzilla setup with some other big projects is that the bug gets assigned to > a developer and the bug submitter gets emailed updates any time there is a > status change. I have some experience in setting up Bugzilla, although we currently run it on MySQL, but we are looking to move it off MySQL and probably onto Postgres anyway. I'd also volunteer to help admin a Bugzilla setup. Do we have a third person? Cheers, Colin
On Tuesday 21 August 2001 17:51, Vince Vielhaber wrote: > On Tue, 21 Aug 2001, Lamar Owen wrote: > > > > > I disagree. Unless you are omniscient, > > We need someone willing to be a kibo. Or is that too arcane a reference? > Gotta admit, I haven't heard that in a while. Egads! An Internet where people don't remember Kibo.... Vince remembers, as does Marc,more than likely. But I got several emails asking 'What is a kibo'. Wow. James 'Kibo' Parry is, well, infamous in Usenet circles (or at least he used to be). Mention 'kibo' in a newsgroup posting (this used to work years ago), and 'Kibo' would reply. With 100MB of news per day, Kibo replied (in a sanctimonious way, as if he were a god or something) to almost every single mention of the name 'kibo'. I was halfway expecting a reply via the newsgroup gateway, but kibo must have been asleep. Or the 100GB of news per day has overwhelmed his bandwidth.... :-) And the most oddball newsgroups would get replied to. People began putting the string 'kibo' into their .sig's, prompting message after message. Kibo appeared to be omniscient -- thus the reference to kibo. There was actually a time where _every_ new posting with the word 'kibo' in it was replied to. In reality, kibo was driven by an intelligent regex running on a backbone server (and, at the time, Software Tool and Die _was_ a backbone server). All news postings referencing kibo were either auto-replied to, or Kibo himself would reply. A 'cult' of kibology developed, wondering what criteria would prompt personal replies from Kibo (at this point, the capital K was being used....). See www.kibo.com for all the flippant details. :-) Or ask kibo himself at kibo@world.std.com. Wow, now I _know_ I've been on Usenet too long.... But we DO need someone willing to be a postgresql-kibo. I could think of no better example of the completeness and attention to detail that was any better than that, that I thought people here could relate to. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> Egads! An Internet where people don't remember Kibo...
Yup, I do. I think he gave up years ago, though.
I useta be a small-time kibozer myself --- back in the early days of
JPEG, when a lot of people didn't really understand the format, I had
a little perl script that trolled a hundred or so likely newsgroups
for references to JPEG. And I followed up where appropriate. Didn't
have an automatic responder though, and I never tried to scan the whole
feed.
regards, tom lane organizer, Independent JPEG Group
Honestly I wasn't aware postgres had any bugs... tongue in cheek. What I mean is PG works very nicely for me and I haven't had any problems with it, so that means "no bugs". Yes there are bugs and things to be solved, but from my perspective it is already a pretty darn good piece of software. -d Philip Warner wrote: >At 08:32 21/08/01 -0400, Vince Vielhaber wrote: > >>Yes but noone was interested in it. It's still there but you're really >>the first to show interest in about a year. >> > >That's good (and depressing); where are they? >
I vote for pgsql bugzilla. If I have a bug to report I'll file it. I file plenty of moz bugs and aid in resolving them. -d Bruce Momjian wrote: >>There are over 400 in the database. If that's a small percentage then >>so be it, but it's still over 400 bugs that appear to have been ignored. >>Having a place to look up possible problems and seeing if there was a >>solution seems to be a plus to me, but if you don't want it it doesn't >>bother me either way. The lookups are currently disabled, ball's in >>your court. >> > >It's up to the group to decide. If we have a database of bugs, I think >it has to be complete. I think a partial list is worse than no list at >all. >
Bruce Momjian wrote: >>>That is the real question. Do we want to rely more heavily on a bug >>>database rather than the email lists? I haven't heard many say they >>>want that. >>> I'd very much like a bugzilla because I can do research on bugs past or present now as well as know the status of them. Right now if I had a bug I would have to dig through web page after web page or use wget and grep. -d
Serguei Mokhov wrote: >Maybe a better solution for the short run would be >return the page where it was, and but links to the pgsql-bugs and >pgsql-hackers archives with some sort of exmplanatory saying that "this is >a *complete* (it must be complete of course) list of bugs, which are >being extensively discussed in the these lists and fixed. Please, visit/search >these mail archives for most up-to-date information blah blah blah" One can >invent some appropriate wording, I guess. But this atleast will show people >that there's work acually going on, and on daily basis. And also a good idea >to have "Last updated" time stamp on the page too... so it doesn't seem >to be forgotten for ages.. > The archives are a 'flat' database of bugs which require a lot of work for a researcher to figure out if a bug is already documented and what the status is. It is also not 100% accurate as not all bugs get reported there. -d
Bruce Momjian wrote: >OK, what value does a bug database have over a TODO list? > history of a bug, entire discussion about that bug on the same page with hyperlinked patches and other attachments. ability of everyone to add to the bug documentation without submitting it to the TODO maintainer. categorization and "it works on X", "it's broken if Y" etc I really could go on and on. -d
Tom Lane wrote: >Given a threaded index, you aren't wading through "a few hundred posts". >Agreed, a nice canned database entry might be easier to look at, but >who's going to expend the time to maintain the database? Unless someone >actively takes responsibility for keeping the DB up to date, it'll be >junk. So far I heard Philip say he'd be willing to check over some >fraction of the existing entries, but I don't hear anyone wanting to >take it on as a long-term commitment. > I've often had a hard time searching for results in email archives because the datum used for indexing changes. Different people change the subject line etc. You can't index by date a fair bit of the time because there will be lapses in the discussion. One of the better things about using a bugzilla [e.g.] is that it becomes a community responsibility, not a single person or small group. Anyone can now update the 'TODO' list. -d
Bruce Momjian wrote: >How do you communicate that to people looking at the content? Do you >put in big letters at the top, "This list is not complete." The fact an >items is missing from the list (new bug) is just as important as an item >appearing on the list. > How do you distinguish that from what we have now? I can't look at my pgsql email box and see how many and of what. A bugzilla is a more accurate representation of bugs and future features for the group. -d
David Ford wrote: > > Bruce Momjian wrote: > > >>>That is the real question. Do we want to rely more heavily on a bug > >>>database rather than the email lists? I haven't heard many say they > >>>want that. > >>> > > I'd very much like a bugzilla because I can do research on bugs past or > present now as well as know the status of them. Right now if I had a > bug I would have to dig through web page after web page or use wget and > grep. Using bugzilla seems the best option for me too. No need to roll our own bug tracking system when we could spend the same effort on making Bugzilla/PostgreSQL work better. --------------- Hannu
Tom Lane wrote: >Peter remarked that he wouldn't use a bug database unless it has some >input filtering to remove all the non-bug issues that currently clutter >the pgsql-bug archives. I tend to agree with him. A possible way to >handle that is to set up bug-input like a closed mailing list: only >accept mail from designated people (developers and people nominated to >help run the bug database). So, a bug database entry would start life >when some one of these people replies to an emailed bug report >confirming that there is a bug, or forwards the verified report to >bug-input, or whatever. > Here I respectfully disagree. If I have to wait on 'approval' to submit a bug or carry on a discussion about it, most of the time I'm going to silently drop it and find some other way to make my project work. I like Mozilla's bugzilla because I can instantly and with very little effort classify all sorts of things and describe my bug. Then along comes a person who can assign it to someone, confirm it, mark it up as clueless user, or whatever is needed. Everyone associated with this bug # gets a copy of every transaction that happens to this bug. You can easily cc this into the pgsql-bugs. A lot of projects grow and develop little things like 'it works for all of us so it's not a bug', I run into that now and then in an obscure issue...libtool comes to mind...and -nobody- has information on it except 4 other webpages in this universe where 1 person reports the problem, two people say the 1st person is shouldn't be using gcc 2.96 and the fourth person has a fix which meant gcc wasn't at fault in the first place. You can't have a really effective 100% bug database without allowing everyone to add to it. If I had to submit to mozilla "tables are one pixel off starting about Aug 21st" and get approval before it went in, I'd likely say screw it and simply make my tables one pixel bigger. As it is, I post the bug and 20 minutes later due to the magic of bugzilla, the right person put the fix in. I don't have to adapt my tables. :) -d
Tom Lane wrote: >>The last worthwhile item on this guy's list is changing ownership of a >>database. Well, I haven't yet had to do this: can we do this easily? >> >It could be better. See recent "Multiple Servers" thread over in >pg-admin, notably >http://fts.postgresql.org/db/mw/msg.html?mid=1031042 >(which the FTS server seems not to have linked into the thread for some >reason) > Here is where the Indexing by date/thread.... fails. If I were searching for changing ownership, how would I even begin to consider "Multiple Servers" in my searches? A bug db here would have been perfect. -d
David Ford wrote: > > Tom Lane wrote: > > >Peter remarked that he wouldn't use a bug database unless it has some > >input filtering to remove all the non-bug issues that currently clutter > >the pgsql-bug archives. So the first thing to decide is the purpose of the bug database, do we want to have a) a marketing tool to show that we are bugfree and all bugs are fixed fast (at lest this is what started this thread :) or b) a convenient place to look up all open issues - here bugzilla would be graet. We have been using bugzilla with good results for our own projects (mainly Amphora http://www.amphora.ee/eng/ - a quite large groupware product based on Zope, PostgreSQL and other freeware technologies). So if it does suit both a smaller-than-PGSQL group of programmers/testers/users like us and a huge group like mozilla it should also suit a medium-sized group like postgreSQL. ----------- Hannu
One other aspect of bugzilla that I have not yet seen mentioned on this thread is the ability to vote for a particular feature or bug. I have often seen people on this asking "Is this an important feature to the users?". With voting, you can easily see what users think would be an important thing to fix. -rocco
fwiw, the PHP group uses a pretty simple PHP/MySQL-based bug tracking system that consists of something like 3 or 4 PHP pages, two tables in MySQL and has some pretty decent features. It wouldn't be much of problem difficult to port it to PostgreSQL (which I might be doing soon, anyways, 'cause I want a bug database myself). Check it out: http://www.php.net/bugs J mlw wrote: > Has anyone thought of using Bugzilla? (It is MySQL based, of course) but > it might answer the bug database issues. (If you guys want a bug database) > > RedHat has a version which can use Oracle, but it seems there is a file: > ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz that my be interesting. > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl
*whimper* I've been out of town for a week, and will not be able to
catch up with ~2000 email messages. So I can't even get to the end of
this thread. But I must agree that PostgreSQL development is pushing the
limits of what a person can keep up with.
> I am not interested in finding a mailing list _replacement_. I am, however,
> interested in finding a augmentative solution that does well what mailing
> lists do not do well.
The fundamental problem with bug tracking has been that the available
tools do not fit with our obviously successful mailing-list centered
development process. I certainly would consider it a distraction to
consult that tool to be able to participate in development.
I *could* see some combination of bug tracker, volunteer maintainers,
and our beta release cycle as a mechanism for having us all participate
in clearing those reported bugs and non-bugs.
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
> The fundamental problem with bug tracking has been that the available
> tools do not fit with our obviously successful mailing-list centered
> development process. I certainly would consider it a distraction to
> consult that tool to be able to participate in development.
As usual, Thomas cuts to the heart of the matter ...
The above is an accurate statement of the problem from a developer point
of view. ISTM that what we're missing is a window into the process for
people who are not following the mailing lists. While we have archives,
searching the archives is not a great answer for a number of reasons
(most notably that there's no mechanism to ensure that closure of a bug
is recorded in the same thread(s) that report it).
The trick for a bug database will be to provide a more coherent view
without being a drag on our proven development process.
regards, tom lane
On Tue, 28 Aug 2001, Tom Lane wrote: > Thomas Lockhart <lockhart@fourpalms.org> writes: > > The fundamental problem with bug tracking has been that the available > > tools do not fit with our obviously successful mailing-list centered > > development process. I certainly would consider it a distraction to > > consult that tool to be able to participate in development. > > As usual, Thomas cuts to the heart of the matter ... > > The above is an accurate statement of the problem from a developer point > of view. ISTM that what we're missing is a window into the process for > people who are not following the mailing lists. While we have archives, > searching the archives is not a great answer for a number of reasons > (most notably that there's no mechanism to ensure that closure of a bug > is recorded in the same thread(s) that report it). > > The trick for a bug database will be to provide a more coherent view > without being a drag on our proven development process. We're already working on it, lets not get this thread started again. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================