This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 20 Aug 2000 00:33:00 +0200 (CEST)
Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)
Ross J. Reedstrom writes:
> Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be
> pretty simple: the #define is already there: UNSAFE_FLOATS. Define that,
> and the CheckFloat[48]Val functions just return true.
Show me a system where it doesn't work and we'll get it to work.
UNSAFE_FLOATS as it stands it probably not the most appropriate behaviour;
it intends to speed things up, not make things portable.
> > NULL and NaN are not quite the same thing imho. If we are allowing NaN
> > in columns, then it is *known* to be NaN.
>
> For the purposes of ordering, however, they are very similar.
Then we can also treat them similar, i.e. sort them all last or all first.
If you have NaN's in your data you wouldn't be interested in ordering
anyway.
> we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word
> for those three values), else elog().
"non-finite values"
Side note 2: The paper "How Java's floating point hurts everyone
everywhere" provides for good context reading.
Side note 3: Once you read that paper you will agree that using floating
point with Postgres is completely insane as long as the FE/BE protocol is
text-based.
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Don Baccus <dhogaza@pacifier.com>
Date: Sat, 19 Aug 2000 16:26:44 -0700
At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:
>(Side note: Folks, we need a real bug/issue-tracking system. We just
>discussed this a month ago ("How PostgreSQL's floating point hurts
>everyone everywhere"). If anyone's interested in porting Bugzilla or some
>other such system to PostgreSQL and putting it into use, let me know.)
OpenACS and arsDigita are using Ben Adida's software development manager,
which includes a ticket-tracking module. It's still under development,
but you can take a look at www.openacs.org/sdm to see how we're using
it.
It was developed for Postgres (which is what you see at the above URL)
then ported to Oracle (which is what you arsDigita does). aD has also
added some functionality which is supposed to be ported back to the
Postgres version.
Among other things it integrates with a todo list manager that maintains
individual todo lists for developers ... you're assigned a bug, it
ends up on your todo list.
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Vince Vielhaber <vev@michvhf.com>
Date: Sat, 19 Aug 2000 20:34:43 -0400 (EDT)
> On Sat, 19 Aug 2000, Don Baccus wrote:
>
> > At 12:33 AM 8/20/00 +0200, Peter Eisentraut wrote:
> > >(Side note: Folks, we need a real bug/issue-tracking system. We just
> > >discussed this a month ago ("How PostgreSQL's floating point hurts
> > >everyone everywhere"). If anyone's interested in porting Bugzilla or some
> > >other such system to PostgreSQL and putting it into use, let me know.)
> >
> > OpenACS and arsDigita are using Ben Adida's software development manager,
> > which includes a ticket-tracking module. It's still under development,
> > but you can take a look at www.openacs.org/sdm to see how we're using
> > it.
> >
> > It was developed for Postgres (which is what you see at the above URL)
> > then ported to Oracle (which is what you arsDigita does). aD has also
> > added some functionality which is supposed to be ported back to the
> > Postgres version.
> >
> > Among other things it integrates with a todo list manager that maintains
> > individual todo lists for developers ... you're assigned a bug, it
> > ends up on your todo list.
On Sat, 19 Aug 2000, The Hermit Hacker wrote:
>
> Ben has an account on Hub, and aolserver has been installed, so if you
> guys want to install and get this working, just tell me what else you need
> as far as software and/or configurations are concerned and "it shall be
> done" ...
http://www.postgresql.org/bugs/
I was about to implement it once before and the directory disappeared.
But anyway it's there.
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Don Baccus <dhogaza@pacifier.com>
Date: Sat, 19 Aug 2000 17:43:13 -0700
At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:
>
>http://www.postgresql.org/bugs/
>
>I was about to implement it once before and the directory disappeared.
>But anyway it's there.
Cool, I tried it and broke it on my second click ... any particular reason
to roll your own rather than use something that's already being used by
several other development projects and is under active development for
that reason? (i.e. the SDM)
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Sun, 20 Aug 2000 01:22:39 +0000
Don Baccus wrote:
>
> >(Side note: Folks, we need a real bug/issue-tracking system. We just
> >discussed this a month ago ("How PostgreSQL's floating point hurts
> >everyone everywhere"). If anyone's interested in porting Bugzilla or some
> >other such system to PostgreSQL and putting it into use, let me know.)
istm that it is *not* that easy. We tried (very briefly) a bug tracking
system. Whatever technical problems it had (which other tools may not),
the fundamental problem is that the mailing lists do a *great* job of
screening problem reports while also supporting and enhancing the
"Postgres culture", whereas a "bug report tool" eliminates that traffic
and requires one or a few people to pay attention to the bug list to
manage new and existing bug reports.
This has (or could have) a *huge* impact on the culture and tradition of
Postgres development, which imho is one of the most satisfying,
pleasant, and effective environments in open source development. So if
we try to do something with a bug tracking system, we will need to
figure out:
o how to retain a free and helpful discussion on the mailing lists, and
to not degrade into a "shut up and check the bug reports" response.
o how to filter or qualify bug reports so that developers don't spend
time having to do that.
All imho of course ;)
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Don Baccus <dhogaza@pacifier.com>
Date: Sat, 19 Aug 2000 18:28:54 -0700
At 01:22 AM 8/20/00 +0000, Thomas Lockhart wrote:
>istm that it is *not* that easy. We tried (very briefly) a bug tracking
>system. Whatever technical problems it had (which other tools may not),
>the fundamental problem is that the mailing lists do a *great* job of
>screening problem reports while also supporting and enhancing the
>"Postgres culture", whereas a "bug report tool" eliminates that traffic
>and requires one or a few people to pay attention to the bug list to
>manage new and existing bug reports.
In the SDM you can, of course, ask to be notified of various events
by e-mail. And there's a commenting facility so in essence a bug
report or feature request starts a conversation thread.
I don't recall saying that the SDM is simply a "bug report tool". There's
quite a bit more to it, and the goal is to INCREASE interactivity, not
decrease it.
>This has (or could have) a *huge* impact on the culture and tradition of
>Postgres development, which imho is one of the most satisfying,
>pleasant, and effective environments in open source development. So if
>we try to do something with a bug tracking system, we will need to
>figure out:
>
>o how to retain a free and helpful discussion on the mailing lists, and
>to not degrade into a "shut up and check the bug reports" response.
This is a social, not software, engineering issue.
>o how to filter or qualify bug reports so that developers don't spend
>time having to do that.
Developers don't have to filter or qualify bug reports e-mailed to the
bugs list today? Who's doing it, then, and why can't they continue doing
so if another tool is used to manage bug reports?
The SDM allows a little more granularity than the single e-mail list
aproach allows for. You can designate modules within a package. For
instance, psql might be a module with Peter assigned as an administrator,
and he might elect to get e-mail alerts whenever a bug is submitted to
for psql.
But he might not, for instance, be particularly interested in getting
e-mail alerts on (say) the JDBC driver.
There's a certain amount of delegation inherent in an approach like
this, and developers focused on narrow portions of the product (and
Peter came to mind because of psql, I'm not suggesting he only has
a narrow interest in the product) can arrange to only get nagged, if
you will, for stuff they've taken responsibility for.
My guess is that such a system probably isn't as cozy and useful for
developers, as you're implying.
I think it might well be more friendly for users, though. Certainly
the OpenACS and arsDigita communities - both fairly large though
not as long in the tooth as PG, I might add - seem to appreciate having
access to such a system.
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 20 Aug 2000 00:02:35 -0300 (ADT)
If Ben and gang are willing to work on the bug tracking system to get it
to fit what we want/need, it would give a good example of OpenACS and gang
for them to use ... we could just shot "wants" at them and they could
improve as we go along?
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Vince Vielhaber <vev@michvhf.com>
Date: Sat, 19 Aug 2000 22:52:52 -0400 (EDT)
On Sat, 19 Aug 2000, Don Baccus wrote:
> At 08:34 PM 8/19/00 -0400, Vince Vielhaber wrote:
> >
> >http://www.postgresql.org/bugs/
> >
> >I was about to implement it once before and the directory disappeared.
> >But anyway it's there.
>
> Cool, I tried it and broke it on my second click ... any particular reason
> to roll your own rather than use something that's already being used by
> several other development projects and is under active development for
> that reason? (i.e. the SDM)
Like I said, the dir disappeared before I could commit it, probably some
config stuff too. We tried a couple of already in use items and frankly
I got tired of learning a new package that noone used anyway. I figured
at least this one could be more of what we needed. It logs the problem
in the database and emails the bugs list (I may have the wrong list
addr in there too). The status can be changed, entries can be made as
to the status.
What did you do to break it and what broke?
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: Vince Vielhaber <vev@michvhf.com>
Date: Sat, 19 Aug 2000 23:20:08 -0400 (EDT)
On Sun, 20 Aug 2000, The Hermit Hacker wrote:
>
> If Ben and gang are willing to work on the bug tracking system to get it
> to fit what we want/need, it would give a good example of OpenACS and gang
> for them to use ... we could just shot "wants" at them and they could
> improve as we go along?
Fine by me, BUT I have no desire to learn how it works. If that's gonna
be the end result then rm -Rf is my preference. This'll be the third or
forth one so far, the others were pushed off the edge of the earth. Sorry
to be so harsh but no matter what the bug tool is I can't see it lasting
very long. This group has shown repeatedly that it's not as desired as
it appears to be.
===
Subject: Re: [HACKERS] Re: [GENERAL] +/- Inf for float8's
From: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 20 Aug 2000 00:07:21 -0300 (ADT)
On Sat, 19 Aug 2000, Don Baccus wrote:
> >o how to filter or qualify bug reports so that developers don't spend
> >time having to do that.
>
> Developers don't have to filter or qualify bug reports e-mailed to the
> bugs list today? Who's doing it, then, and why can't they continue
> doing so if another tool is used to manage bug reports?
the problem as I see it with any bug tracking tool is someone has to close
off those bugs when fixed ... right now, someone commits a bug fix, and
then fires off an email to the list stating its fixed ... with a bug
tracking system, then they have to go one more step, open up a web
browser, login to the system, find the bug report and close it ...
===
Subject: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 19 Aug 2000 23:22:00 -0400
FWIW, I agree with Thomas' comments: our last try at a bug-tracking
system was a spectacular failure, and rather than just trying again
with a technically better bug-tracker, we need to understand why we
failed before.
I think we do need to look for a better answer than what we have, but
I do not have any faith in "install system FOO and all your problems
will be solved".
My take is that
(a) a bug *tracking* system is not the same as a bug *reporting*
system. A tracking system will be useless if it gets cluttered
with non-bug reports, duplicate entries, etc. There must be a human
filter controlling what gets entered into the system.
(b) our previous try (with Keystone) was a failure in part because
it was not even effective as a bug reporting system: it did not
encourage people to fill in our standard "bug report form", with the
result that bug reports were seriously incomplete w.r.t. version
numbers, platforms, etc. This is a relatively simple technical
deficiency, not a social-engineering problem, but it does point up
the fact that one-size-fits-all solutions fit nobody.
(c) fill-in-the-web-form reporting systems suck. They make it
difficult to copy-and-paste query output, dump files, etc.
Also, the window for entering text is always either too small or too
large. Email with attachments is fundamentally superior.
(d) divorcing the bug reporting system from the existing mailing
list community is foolish, as Thomas pointed out. When a bug report
is a non-bug (user error, etc) or fixed in a later version or just
a duplicate, we tend to rely on the rest of the community to give
the reporter a helpful response. Funneling reports into a separate
system that is only read by a few key developers will lose.
I'm not sure what I want, but I know what I don't want...
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Philip Warner <pjw@rhyme.com.au>
Date: Sun, 20 Aug 2000 15:20:19 +1000
Perhaps this is foolhardy, but it might be worth making a list of
requirements, at least so we can tick moxes when considering any system...
>(a) a bug *tracking* system is not the same as a bug *reporting*
>system. A tracking system will be useless if it gets cluttered
>with non-bug reports, duplicate entries, etc. There must be a human
>filter controlling what gets entered into the system.
1. Human filtering of 'incoming' reports.
2. Separation of 'bug reports' from 'bugs'.
>(b) our previous try (with Keystone) was a failure in part because
>it was not even effective as a bug reporting system: it did not
>encourage people to fill in our standard "bug report form", with the
>result that bug reports were seriously incomplete w.r.t. version
>numbers, platforms, etc. This is a relatively simple technical
>deficiency, not a social-engineering problem, but it does point up
>the fact that one-size-fits-all solutions fit nobody.
3. Web and email submissions should do data verification and reject
incomplete reports (giving reasons).
>(c) fill-in-the-web-form reporting systems suck. They make it
>difficult to copy-and-paste query output, dump files, etc.
>Also, the window for entering text is always either too small or too
>large. Email with attachments is fundamentally superior.
[I disagree with the above (web *can* work), but...]
4. Must support email AND web submissions, or at least email submissions
and web reporting.
>(d) divorcing the bug reporting system from the existing mailing
>list community is foolish, as Thomas pointed out.
5. Must integrate with mailing lists.
And to add some of my own (suggested) requirements:
6. Require: name, email address, OS & version, PG version, short description.
7. Optional: compiler & version, long description, file attachments.
8. Creation of 'bug reports' is a public function. Creation of 'bug
entries' is a priv'd function.
9. Simple reporting - unprocessed bug reports, open bugs, bugs by module etc.
I have tried to keep this relatively simple in an effort to define what we
need to make it work in the current context. But I'm sure I've missed
things....
<YABRS>
As it happens, I have a Perl/PGSql based bug-tracking system that I give my
clients access to, which does about 80-90% of this, and I would be willing
to GPL it.
Before anybody asks, the reason I rolled my own was because
there weren't many that supported email and web submission,
and the ones that did, did not support PG easily. This
system also implements my prefferred model for bug reporting
which is to separate (to use my terminology) 'Incidents'
from 'Issues': an Incident is an event (or set of events)
that causes a user to make a report. An Issue is an
individual item that needs attention (usually a single
bug). Typically users send email (or web forms) and I create
one or more Issues. When two Incidents (bug reports) are
made about the same Issue, then the system allows the two to
be linked, so that when the Issue is fixed, all Incident
owners are notified etc.
The email integration does very little validation, and it is
*not* integrated with a mailing list (but it is on my ToDo
list). I had planned to do the following:
- When a message is received and the subject does not start with 'Re:' (or
'Aw:'!), submit it as a bug report. If the bug report code returns an
error, then reject it from the list. If the bug report works, then send it
on to Majordomo & Mhonarc.
- If the message starts with 'Re:' then just submit it to the list.
Let me know if anyone would be interested, and I can set up a sample
'product' for people to play with and then, if it is still worth pursuing,
make the code a little more presentable (and decrease it's reliance on my
own perl libraries).
Bear in mind that this is designed for an Apache/mod-perl environment, so
may not be acceptable to some people.
</YABRS>
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Peter Eisentraut <peter_e@gmx.net>
Date: Sun, 20 Aug 2000 11:18:28 +0200 (CEST)
Tom Lane writes:
> (a) a bug *tracking* system is not the same as a bug *reporting*
> system. A tracking system will be useless if it gets cluttered
> with non-bug reports, duplicate entries, etc. There must be a human
> filter controlling what gets entered into the system.
Letting any user submit bug reports directly into any such system is
certainly not going to work, we'd have "query does not use index" 5 times
a day. I consider the current *reporting* procedure pretty good; web forms
are overrated in my mind.
What I had in mind was more a databased incarnation of the TODO list. I
mean, who are we kidding, we are writing a database and maintain the list
of problems in flat text. The TODO list has already moved to the
TODO.detail extension, but we could take it a bit further.
I think currently too many issues get lost, or discussed over and over
again. Many developers maintain their own little lists. The TODO list
often cannot be deciphered by end users and hence does not get read.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: The Hermit Hacker <scrappy@hub.org>
Date: Sun, 20 Aug 2000 11:17:28 -0300 (ADT)
On Sun, 20 Aug 2000, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > (a) a bug *tracking* system is not the same as a bug *reporting*
> > system. A tracking system will be useless if it gets cluttered
> > with non-bug reports, duplicate entries, etc. There must be a human
> > filter controlling what gets entered into the system.
>
> Letting any user submit bug reports directly into any such system is
> certainly not going to work, we'd have "query does not use index" 5 times
> a day. I consider the current *reporting* procedure pretty good; web forms
> are overrated in my mind.
>
> What I had in mind was more a databased incarnation of the TODO list. I
> mean, who are we kidding, we are writing a database and maintain the list
> of problems in flat text. The TODO list has already moved to the
> TODO.detail extension, but we could take it a bit further.
>
> I think currently too many issues get lost, or discussed over and over
> again. Many developers maintain their own little lists. The TODO list
> often cannot be deciphered by end users and hence does not get read.
A TODO list that one can add comments to ...
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Wim Ceulemans <Wim.Ceulemans@nice.be>
Date: Sun, 20 Aug 2000 13:19:35 +0200
Peter Eisentraut wrote:
>
> Tom Lane writes:
>
> > (a) a bug *tracking* system is not the same as a bug *reporting*
> > system. A tracking system will be useless if it gets cluttered
> > with non-bug reports, duplicate entries, etc. There must be a human
> > filter controlling what gets entered into the system.
>
> Letting any user submit bug reports directly into any such system is
> certainly not going to work, we'd have "query does not use index" 5 times
> a day. I consider the current *reporting* procedure pretty good; web forms
> are overrated in my mind.
>
> What I had in mind was more a databased incarnation of the TODO list. I
> mean, who are we kidding, we are writing a database and maintain the list
> of problems in flat text. The TODO list has already moved to the
> TODO.detail extension, but we could take it a bit further.
>
I maintain my todo items for my projects in a postgres database. But
there are a lot of issues to consider there too:
- a table of projects (or topics)
- a table of todo items with synopsis, full description, ...
- a table of versions (item is planned to be solved in version, x.x.x,
actually solved in y.y.y)
- a table of developers
- assign table (projects -> developers, items -> developers)
- change type: bug,doc,rfe (request for enhancement),idc (internal
design change), ...
- change state (accepted, evaluated, fixed, rejected, incomplete,
committed, ...
- severity or priority of each item, project
- search functionality
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Ben Adida <ben@openforce.net>
Date: Sun, 20 Aug 2000 01:15:57 -0400
Tom Lane wrote:
> FWIW, I agree with Thomas' comments: our last try at a bug-tracking
> system was a spectacular failure, and rather than just trying again
> with a technically better bug-tracker, we need to understand why we
> failed before.
Okay, well then this is an interesting discussion: the
OpenACS project and my company (OpenForce) would very much
be interested in discussing what you guys think would be a
useful bug tracking system. What kind of features would it
need? Nothing is too fancy here, the idea is to have the
best possible system, one that focused developers like the
PG team would use.
Maybe we should take this offline? I'm happy to keep this
discussion going and hear everything you've got to say:
understanding what it would take to build a system you guys
would use is *very* important data.
-Ben
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Ned Lilly <ned@greatbridge.com>
Date: Sun, 20 Aug 2000 22:22:27 -0400
If you all don't mind, I think it'd be great to keep this
discussion on the list. As some of you know, Great Bridge
is working on its own project hosting site (including a
PG-backed bug tracking module). We're not quite ready to
pull back the curtain yet, but are getting close, and will
be actively soliciting input (and hacks) from the community.
The process of getting hacker requirements for such a system is a very
useful one, IMHO...
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Aug 2000 06:59:06 -0700
At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:
>If you all don't mind, I think it'd be great to keep this discussion on the
>list. As some of you know, Great Bridge is working on its own project
>hosting site (including a PG-backed bug tracking module). We're not quite
>ready to pull back the curtain yet, but are getting close, and will be
>actively soliciting input (and hacks) from the community.
So - again - why roll your own instead of build upon a base
which at least is already seeing some use, by some fairly
large organizations (arsDigita is larger and more deeply
funded than Great Bridge, making profits to boot, and I
won't even start talking about AOL)? arsDigita is putting
some developer effort into the SDM, so it's no longer just
Ben and whoever he can rope into helping out.
Couldn't you guys more profitably spend time, say, working
on outer joins rather than doing something like this?
The folks working on the SDM have a LOT more web/db
development experience than whoever's rolling your bug
tracking system.
I keep sniffing the odor of NIH ...
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Aug 2000 07:35:10 -0700
At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:
>>If you all don't mind, I think it'd be great to keep this discussion on the
>>list. As some of you know, Great Bridge is working on its own project
>>hosting site (including a PG-backed bug tracking module). We're not quite
>>ready to pull back the curtain yet, but are getting close, and will be
>>actively soliciting input (and hacks) from the community.
Another implication which missed me first time 'round is
that Great Bridge might be planning to have its own bug
reporting system, separate from that used by the development
community at large?
I hope not. There should be one central place for bug
reporting. If Great Bridge wants to run it, fine, also if
Great Bridge wants to be able to incorporate some sort of
prioritization system for those with paid support (or some
other discriminatory system) it is still probably better to
figure out a way to accomodate it rather than have two
separate bug reporting systems.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 21 Aug 2000 10:48:17 -0400 (EDT)
On Mon, 21 Aug 2000, Don Baccus wrote:
> At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:
> >If you all don't mind, I think it'd be great to keep this discussion on the
> >list. As some of you know, Great Bridge is working on its own project
> >hosting site (including a PG-backed bug tracking module). We're not quite
> >ready to pull back the curtain yet, but are getting close, and will be
> >actively soliciting input (and hacks) from the community.
>
> So - again - why roll your own instead of build upon a base which at least
> is already seeing some use, by some fairly large organizations (arsDigita
> is larger and more deeply funded than Great Bridge, making profits to boot,
> and I won't even start talking about AOL)? arsDigita is putting some
> developer
> effort into the SDM, so it's no longer just Ben and whoever he can rope into
> helping out.
>
> Couldn't you guys more profitably spend time, say, working on outer joins
> rather than doing something like this?
>
> The folks working on the SDM have a LOT more web/db development experience
> than whoever's rolling your bug tracking system.
>
> I keep sniffing the odor of NIH ...
Could it be possible that folks are shying away because of having
to install and learn an entire webserver and tools and then the
bug tracker on top of that?
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Ben Adida <ben@openforce.net>
Date: Mon, 21 Aug 2000 11:01:49 -0400
Vince Vielhaber wrote:
> Could it be possible that folks are shying away because of having
> to install and learn an entire webserver and tools and then the
> bug tracker on top of that?
And so the solution is to build a totally new system?
Coming from the Postgres team, this is relatively
surprising. Postgres is a great tool. I dropped Oracle and
learned Postgres because I thought it would eventually
become a better tool, and because it was already better in
many ways. It took time and effort to do so, but eventually
it was the right thing to do because I can now make full use
of a very powerful open-source database.
It seems to me that the whole point of Open-Source vs. Not
Invented Here is that you are *supposed* to go out and make
the effort necessary to learn new tools that can then become
extremely useful. If you accept the attitude of "it's not
Apache/mod-perl so I'm not using it," then it's time to stop
all criticism of those who use MySQL, Oracle, Windows,
etc... Those people are *used* to their technology, and the
only reason they refuse to switch is that they don't want to
spend time learning something new.
Just my 2 cents.... the useful tools are not always the ones
everyone is using.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 21 Aug 2000 11:12:51 -0400 (EDT)
On Mon, 21 Aug 2000, Ben Adida wrote:
> Vince Vielhaber wrote:
>
> > Could it be possible that folks are shying away because of having
> > to install and learn an entire webserver and tools and then the
> > bug tracker on top of that?
>
> And so the solution is to build a totally new system?
In some cases yes.
> Coming from the Postgres team, this is relatively surprising. Postgres is a great
> tool. I dropped Oracle and learned Postgres because I thought it would eventually
> become a better tool, and because it was already better in many ways. It took
> time and effort to do so, but eventually it was the right thing to do because I
> can now make full use of a very powerful open-source database.
I am *NOT* "the Postgres team". But have you listened to
what you & Don are suggesting that we, or for that matter
anyone else in need of a bug tracking system, do? You want
us to install the full blown arsDigita with all the bells
and whistles just for a bug tracker. That's like saying I
need a pickup truck to move a chair so I'm going to go out
and get a new FreightLiner with a 55' trailer to do the job.
> It seems to me that the whole point of Open-Source vs. Not Invented Here is that
> you are *supposed* to go out and make the effort necessary to learn new tools
> that can then become extremely useful. If you accept the attitude of "it's not
> Apache/mod-perl so I'm not using it," then it's time to stop all criticism of
> those who use MySQL, Oracle, Windows, etc... Those people are *used* to their
> technology, and the only reason they refuse to switch is that they don't want to
> spend time learning something new.
You missed the point. It's called overkill. You needed a full blown
database for your project. We need (although _want_ may be another story)
a bug tracker - not a new webserver.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Adam Haberlach <adam@newsnipple.com>
Date: Mon, 21 Aug 2000 10:28:18 -0700
On Mon, Aug 21, 2000 at 07:35:10AM -0700, Don Baccus wrote:
>
> >At 10:22 PM 8/20/00 -0400, Ned Lilly wrote:
> >>If you all don't mind, I think it'd be great to keep this discussion on the
> >>list. As some of you know, Great Bridge is working on its own project
> >>hosting site (including a PG-backed bug tracking module). We're not quite
> >>ready to pull back the curtain yet, but are getting close, and will be
> >>actively soliciting input (and hacks) from the community.
>
> Another implication which missed me first time 'round is that Great Bridge
> might be planning to have its own bug reporting system, separate from
> that used by the development community at large?
Cool your conspiracy theories. I'm not yet involved with either side
of this discussion, but before it runs out of control...
> I hope not. There should be one central place for bug reporting. If
> Great Bridge wants to run it, fine, also if Great Bridge wants to be able
> to incorporate some sort of prioritization system for those with paid
> support (or some other discriminatory system) it is still probably better
> to figure out a way to accomodate it rather than have two separate
> bug reporting systems.
The fact is that postgres already has a very good
system for keeping track of issues from report to fix to
verification. So far the main defect is the obvious one of
"People don't know the history unless they troll the message
archives or lurk". Everyone here is leery of "fixing" a
working system. Especially when it entails modifying the
working system to deal with a new issue database.
Bug Database/Issue Trackers can be done in two ways.
Someone can grab an off-the-shelf system like Bugzilla or
this ArsTechnica thing and then try to make the project
conform to it. So far, everyone I've talked to who has
touched Bugzilla has said that it sucks. I don't know
anything about this other proposed system but it will
probably require a lot of time to even get people to use it
regularly, much less use it well.
The other method is to create the system to match the
process in place. Since the postgres project is already
very well organized, I personally would like to see the
custom system, rather then make Bruce throw away his TODO
list and use someone else's idea of an issue tracking
system. It takes a lot more work--someone has to pay
attention to what is going on with the project and make sure
the database stays in sync, but in the long run, it is less
disruptive and smoother to integrate into an already working
project like this one.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Aug 2000 10:47:41 -0700
At 10:48 AM 8/21/00 -0400, Vince Vielhaber wrote:
>Could it be possible that folks are shying away because of having
>to install and learn an entire webserver and tools and then the
>bug tracker on top of that?
Learning to use AOLserver is going to be harder than writing a
bugtracker and associated tools from scratch? I find that hard to
believe.
If it's true, of course they could run Apache, since arsDigita
provides a module which implements the AOLserver API in Apache
for exactly this reason, thus making it possible to run the
toolkit (including the SDM) under Apache.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Aug 2000 11:34:45 -0700
At 10:28 AM 8/21/00 -0700, Adam Haberlach wrote:
>On Mon, Aug 21, 2000 at 07:35:10AM -0700, Don Baccus wrote:
>> Another implication which missed me first time 'round is that Great Bridge
>> might be planning to have its own bug reporting system, separate from
>> that used by the development community at large?
>
> Cool your conspiracy theories.
I'm making an observation, that's all. Cool your own wild theories, please.
>
>> I hope not. There should be one central place for bug reporting. If
>> Great Bridge wants to run it, fine, also if Great Bridge wants to be able
>> to incorporate some sort of prioritization system for those with paid
>> support (or some other discriminatory system) it is still probably better
>> to figure out a way to accomodate it rather than have two separate
>> bug reporting systems.
>
> The fact is that postgres already has a very good system for keeping
>track of issues from report to fix to verification.
<shrug> I didn't raise the subject, it was a core developer who started
this thread with a semi-rant about it being about time that the project
had decent bug tracking software.
So apparently not everyone in the community agrees with your
analysis. If there were consensus that the current system's
great then Great Bridge wouldn't be looking at implementing
something different, and Peter wouldn't be ranting that
something better is needed.
> So far the main defect
>is the obvious one of "People don't know the history unless they troll the
>message archives or lurk". Everyone here is leery of "fixing" a working
>system.
There seems to be some disagreement about how well it works.
Again, I didn't raise the issue, I simply responded with a
possible solution when one of the core developers raised it.
And I know that Great Bridge wants to do something web-based
- this isn't some fantasy I dreamed up when in a psychotic
state.
I'm only saying that if a different approach is to be taken,
why not build on something that exists, is under active
development, and is being driven by folks who are VERY open
to working with the project to make the tool fit the project
rather than vice-versa?
>Someone can grab an off-the-shelf system like Bugzilla or this ArsTechnica
arsDigita
>thing and then try to make the project conform to it.
Read above. Ben's already posted that he's eager for design
input. aD has already enhanced the thing based on their own
needs, and there's no reason why Great Bridge and the
Postgres crew can't do the same.
>I don't
>know anything about this other proposed system but it will probably require
>a lot of time to even get people to use it regularly, much less use it well.
Strange, OpenACS folk use it regularly and all we've done is
put a "report a bug" link on the home page.
I haven't heard so many arguments against change since the
VT100 started replacing the KSR 35!
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Aug 2000 11:00:44 -0700
At 11:12 AM 8/21/00 -0400, Vince Vielhaber wrote:
>I am *NOT* "the Postgres team". But have you listened to what you & Don
>are suggesting that we, or for that matter anyone else in need of a bug
>tracking system, do? You want us to install the full blown arsDigita with
>all the bells and whistles just for a bug tracker. That's like saying I
>need a pickup truck to move a chair so I'm going to go out and get a new
>FreightLiner with a 55' trailer to do the job.
A rather dubious analogy.
It takes me less than half a day to install AOLserver, Postgres and the
toolkit on a virgin system, including setting up user accounts, etc.
And ... you never know. Other parts of the toolkit might turn out to be
useful.
If not, just leave them turned off. Take a look at openacs.org - do you
find any traces of the e-commerce module there? The intranet company
management module? What do you see? You see the use of perhaps 10% of
the toolkit.
This is slightly different than hauling an 18-wheeler around. Software
and trucks bear little resemblence to each other, though Freightliner does
have its home here in Portland, OR.
And, of course, the SDM has a bit more functionality than a simple bugtracker,
which is just one piece. It will be gaining more functionality over time,
including increased integration with CVS (there is already some integration,
i.e. the ability to browse the tree).
>You missed the point. It's called overkill. You needed a full blown
>database for your project. We need (although _want_ may be another story)
>a bug tracker - not a new webserver.
Then run it under Apache.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Alfred Perlstein <bright@wintelcom.net>
Date: Mon, 21 Aug 2000 11:50:13 -0700
Don Baccus <dhogaza@pacifier.com> [000821 11:48] wrote:
> At 11:12 AM 8/21/00 -0400, Vince Vielhaber wrote:
>
> >You missed the point. It's called overkill. You needed a full blown
> >database for your project. We need (although _want_ may be another story)
> >a bug tracker - not a new webserver.
>
> Then run it under Apache.
Sorry to jump in without reading the entire thread, but has GNATS
(what the FreeBSD team uses) or Bugzilla come up as options?
GNATS is a bit crusty but works pretty ok for us.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 21 Aug 2000 14:54:12 -0400 (EDT)
On Mon, 21 Aug 2000, Don Baccus wrote:
> At 10:48 AM 8/21/00 -0400, Vince Vielhaber wrote:
>
> >Could it be possible that folks are shying away because of having
> >to install and learn an entire webserver and tools and then the
> >bug tracker on top of that?
>
> Learning to use AOLserver is going to be harder than writing a
> bugtracker and associated tools from scratch? I find that hard to
> believe.
Learning how to use it is only a tiny part of it. You still have to
migrate your website to it. It's not a drop in replacement. So
writing a bugtracker that will fit the environment vs learning a new
webserver & migrating your website & rebuilding or rewriting custom
apps ... For the average, busy admin, don't count too heavily on
the latter. They're more likely to stick with what they know and
trust regardless of how good something else is reported to be.
> If it's true, of course they could run Apache, since arsDigita
> provides a module which implements the AOLserver API in Apache
> for exactly this reason, thus making it possible to run the
> toolkit (including the SDM) under Apache.
First I heard of this, but I'd also have concerns of it's reliability.
It has to be real new. And if it fails it's not ars that looks bad,
it's the site that's running it. Remember the flack over udmsearch?
PostgreSQL was slammed over and over because udmsearch wasn't working
right.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Aug 2000 12:24:49 -0700
At 02:54 PM 8/21/00 -0400, Vince Vielhaber wrote:
>On Mon, 21 Aug 2000, Don Baccus wrote:
>> Learning to use AOLserver is going to be harder than writing a
>> bugtracker and associated tools from scratch? I find that hard to
>> believe.
>Learning how to use it is only a tiny part of it. You still have to
>migrate your website to it. It's not a drop in replacement. So
>writing a bugtracker that will fit the environment vs learning a new
>webserver & migrating your website & rebuilding or rewriting custom
>apps ... For the average, busy admin, don't count too heavily on
>the latter. They're more likely to stick with what they know and
>trust regardless of how good something else is reported to be.
So run the development portion of the site on a different server. Who
said anything about migrating the entire postgres site to AOLserver???
>> If it's true, of course they could run Apache, since arsDigita
>> provides a module which implements the AOLserver API in Apache
>> for exactly this reason, thus making it possible to run the
>> toolkit (including the SDM) under Apache.
>
>First I heard of this, but I'd also have concerns of it's reliability.
>It has to be real new.
Yep. Written by Robert Thau, one of the original eight core Apache
developers, under contract to aD.
>And if it fails it's not ars that looks bad,
>it's the site that's running it.
arsDigita gets on average greater than $500,000 to develop and deploy
a website.
If aD deploys one on Apache+mod_aolserver (they paid for the development
of this module) and it falls over, do you really believe aD won't look
bad?
Seeing as they'd very likely be sued, I think you're wrong.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Don Baccus <dhogaza@pacifier.com>
Date: Mon, 21 Aug 2000 12:36:12 -0700
At 04:34 PM 8/21/00 -0300, The Hermit Hacker wrote:
>Ummm, just stupid question here, but I already posted that AOLserver was
>installed and ready for you guys to implement this ... Ben already has an
>account to get in and do it ... instead of arguing about it, why not just
>do it? If nobody likes it/uses it, so be it ... its no skin off my
>back. But right now the arguments that are going back and forth seem to
>be sooooooo useless since they *seem* to involve technical issues that
>aren't issues ...
Well, this is a breath of fresh air ...
Hopefully Ben will have time soon to do so. Unfortunately (well, not from
my personal point of view!) I'm about to leave for five of the next six
weeks, four of those spent where the internet doesn't reach (where nothing
but BLM radio dispatch doesn't reach, to be more precise) so I'm not going
to be able to help.
Otherwise I'd just jump in.
Of course, putting it up will just make its shortcomings apparent, and
those who resist even the concept of change will ignore the fact that
Ben and I have both stated that modifying the SDM to fit the project
rather than modifying the project to fit the SDM and say, "see, this
doesn't fit our needs!" blah blah blah.
Just as the red herring you've mentioned has been raised.
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Joe Brenner <doom@kzsu.stanford.edu>
Date: Mon, 21 Aug 2000 12:40:19 -0700
Well, just to throw another piece of information into the
mix, there is a new bug-tracking system under development by
the folks at collab.net. They call it "scarab", and last I
talked to them that they thought it would be ready for
production use Real Soon Now:
http://scarab.tigris.org/
I guess they regard this as a replacement for bugzilla.
Some personal opinions:
(1) I would actually like to see bugzilla fixed rather than
replaced. The collab.net guys are into java servlets
because they're CS geeks who are down on perl. Me, I'm a
perl loyalist who thinks that Larry Wall is onto something
-- mathematical elegance may not be the right standard to
judge a computer language.
(2) And maybe it'd be nice if the "religous wars" could be
dropped in favor of pure objective technical decision
making, but i don't think they can be: the social and the
technical don't neatly split into two little piles. (A case
in point: the argument that using a mailing list for bug
control is somehow "warmer" or "more human" than a bug
database.)
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 21 Aug 2000 15:47:33 -0400 (EDT)
On Mon, 21 Aug 2000, Don Baccus wrote:
> At 02:58 PM 8/21/00 -0400, Vince Vielhaber wrote:
> >On Mon, 21 Aug 2000, Don Baccus wrote:
>
> >> It takes me less than half a day to install AOLserver, Postgres and the
> >> toolkit on a virgin system, including setting up user accounts, etc.
> >
> >How familiar are you with it as opposed to most others on the net?
>
> Ben has already offered to help out and has an account on hub. If I weren't
> leaving town for five of the next six or so weeks, I would too.
>
> Still, we have strangers to all three pieces installing everything in a
> weekend, usually with a bit of help. If you were to install it, you'd
> be familiar with Postgres which is about 1/3 of the confusion for newcomers.
>
> >You really don't get it do you?
>
> Yes, I do.
>
> > I'm not comparing software and trucks,
> >I'm comparing tools to do a job. Once you grasp that concept you'll be
> >able to catch on to what I'm talking about - until then I'm just wasting
> >my time.
>
> Do I detect a flame? Ohhh...
>
> It's a toolkit, Vincent. Once you grasp the notion that using a wrench
> out of your toolbox doesn't mean you have to use every tool in the
> toolbox you'll be able to grasp what I'm talking about.
Yet you insist on shoving the entire toolbox down our throats every time
there's a task to be done, Donnie.
> I answered your previous question plainly. If you're not capable of
> understanding the answer, don't answer with an invitation for a flamefest
> you have no chance of winning, OK?
When the day comes that you actually answer a question without telling
the world that openacs, arsdigita, aolserver or whatever you want to call
it is the answer and saviour to everything from world peace to who cares
what else, I'll believe you answered a "question plainly". But that's
not likely to ever happen. And since you think that anything I've said
so far has been a flame I doubt you'd know one if it slapped you with a
trout.
One more thing, Donnie... ***PLONK***
===
Subject: Re: Bug tracking (was Re: [HACKERS] +/- Inf for float8's)
From: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 21 Aug 2000 16:54:04 -0300 (ADT)
On Mon, 21 Aug 2000, Don Baccus wrote:
> At 04:34 PM 8/21/00 -0300, The Hermit Hacker wrote:
>
> >Ummm, just stupid question here, but I already posted that AOLserver was
> >installed and ready for you guys to implement this ... Ben already has an
> >account to get in and do it ... instead of arguing about it, why not just
> >do it? If nobody likes it/uses it, so be it ... its no skin off my
> >back. But right now the arguments that are going back and forth seem to
> >be sooooooo useless since they *seem* to involve technical issues that
> >aren't issues ...
>
> Well, this is a breath of fresh air ...
>
> Hopefully Ben will have time soon to do so. Unfortunately (well, not from
> my personal point of view!) I'm about to leave for five of the next six
> weeks, four of those spent where the internet doesn't reach (where nothing
> but BLM radio dispatch doesn't reach, to be more precise) so I'm not going
> to be able to help.
>
> Otherwise I'd just jump in.
>
> Of course, putting it up will just make its shortcomings apparent, and
> those who resist even the concept of change will ignore the fact that
> Ben and I have both stated that modifying the SDM to fit the project
> rather than modifying the project to fit the SDM and say, "see, this
> doesn't fit our needs!" blah blah blah.
>
> Just as the red herring you've mentioned has been raised.
Right now, you've thrown out "it can do this, it can do that" ... I've
put forth the resources so that you can prove that it will work, its in
your court now :)
===