bugs - lets call an exterminator!

Vince Vielhaber <vev@michvhf.com> writes:

Now some history.. Over the last couple of years we've tried a
number (5 I think) of bug tracking packages. Either Marc or me
or both have had to learn it, install it, get it going and the
result has been the same - the maintainers don't want to update
it, it's a pain in the ass to administrator, set up, etc.

The current bugtool.

After a bunch of these failures I asked for input on what was
needed in a tool. Web input interface, ability to track the
bug report, email notification to the bug list, email notification
to the reporter of the bug.

FTR, we're using bugzilla for this and it works great. We're working
on porting it PostgreSQL.

ftp://people.redhat.com/dkl/ should contain a recent state

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Tue, 21 Aug 2001, Vince Vielhaber wrote:

In the seemingly hundreds of thousands of messages on the bug database
topic I think I've come up with the following..

Solution..

Is implementing yet another bugtool going to be the solution?
Probably not. Do I want to go for number six? No.

The current tool has a form - we keep it.
The current tool mails to the bugs list - we keep it.

You are correct on implementing another bug reporting tool - why re-invent
the wheel? Why not use the bugzilla project for bug tracking? I do
believe it has a postgresql backend by now and if it doesn't - I am sure
it will soon or would be trivial to make a backend and contribute it back.
This tool has been popularized by Mozilla and RedHat ... saying that I am
sure the couple of RedHat employees on the list wouldn't mind giving a
hand with setup and what not (though they will have to speak for
themselves on this issues).

--
//========================================================\\
|| D. Hageman <dhageman@dracken.com> ||
\\========================================================//

At 20:08 21/08/01 -0400, Vince Vielhaber wrote:

In the seemingly hundreds of thousands of messages on the bug database
topic I think I've come up with the following..

Your first pass needs to have a simple mail and web based ssystem for
developers to at least close bugs. The CC idea is probably fine. You might
even want to put an X-header in the mail message, then for each bugs list
message automatically generate a footer with a web link to close the bug,
or some such - a bit like the TIPs we get all the time. This way, a
developer can go to any message relating to the bug, click on the link &
close it. This should also send off a message to the list etc.

Also, to make the jobs of the volunteers easier, it would be good for each
bug details page sho show a list of bugs mailing list trafic relating to
the bug, sorted by inverse date order (or, better, sub-threads). Then we
can look in the most recent two or three to check the status...

----------------------------------------------------------------
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 |/

Vince Vielhaber <vev@michvhf.com> writes:

Needs

easy reporting of bugs - sent to bugs list
easy lookup of previous bugs
summary of fix or workaround
detail of fix or work around
little to no intervention of
developers
ability of developer to add
comments

That should sum it up.

Check.

We've had a couple of volunteers to keep the database up to date.
Is it enough? I dunno, if I were to guess I'd have to look at
previous experience and say probably not.

AFAIR, we had *zero* people paying any attention to the state of the
bug database up to now. A couple of people ought to make a big
difference.

Is implementing yet another bugtool going to be the solution?
Probably not. Do I want to go for number six? No.

If you're the man maintaining it then I'm certainly not going to tell
you how to do your job. OTOH --- it does seem like a lot of people
like Bugzilla. Might be worth at least a cursory look.

Here's what I propose.

The current tool has a form - we keep it.
The current tool mails to the bugs list - we keep it.

Those are both fine. How do we get feedback in the other direction,
ie mailing lists to bug database? That's the $64 question in my mind
at the moment.

regards, tom lane

I think it'd be not so difficult to extend our mailware
(fts.postgresql.org) to handle bug-list. Actually,
mailware has much more features, it's already has search/read,
track features. Adding post is trivial. Developers (who actually
fix a bugs) usually read mailing lists and reply's to BUG, which
should be automatically go to corresponding bug-thread.

Oleg
On Tue, 21 Aug 2001, Tom Lane wrote:

Vince Vielhaber <vev@michvhf.com> writes:

Needs

easy reporting of bugs - sent to bugs list
easy lookup of previous bugs
summary of fix or workaround
detail of fix or work around
little to no intervention of
developers
ability of developer to add
comments

That should sum it up.

Check.

We've had a couple of volunteers to keep the database up to date.
Is it enough? I dunno, if I were to guess I'd have to look at
previous experience and say probably not.

AFAIR, we had *zero* people paying any attention to the state of the
bug database up to now. A couple of people ought to make a big
difference.

Is implementing yet another bugtool going to be the solution?
Probably not. Do I want to go for number six? No.

If you're the man maintaining it then I'm certainly not going to tell
you how to do your job. OTOH --- it does seem like a lot of people
like Bugzilla. Might be worth at least a cursory look.

Here's what I propose.

The current tool has a form - we keep it.
The current tool mails to the bugs list - we keep it.

Those are both fine. How do we get feedback in the other direction,
ie mailing lists to bug database? That's the $64 question in my mind
at the moment.

regards, tom lane

---------------------------(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

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

On Tue, 21 Aug 2001, D. Hageman wrote:

On Tue, 21 Aug 2001, Vince Vielhaber wrote:

In the seemingly hundreds of thousands of messages on the bug database
topic I think I've come up with the following..

Solution..

Is implementing yet another bugtool going to be the solution?
Probably not. Do I want to go for number six? No.

The current tool has a form - we keep it.
The current tool mails to the bugs list - we keep it.

You are correct on implementing another bug reporting tool - why re-invent
the wheel? Why not use the bugzilla project for bug tracking? I do
believe it has a postgresql backend by now and if it doesn't - I am sure
it will soon or would be trivial to make a backend and contribute it back.
This tool has been popularized by Mozilla and RedHat ... saying that I am
sure the couple of RedHat employees on the list wouldn't mind giving a
hand with setup and what not (though they will have to speak for
themselves on this issues).

Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us
that would make me want to learn it and install it? BTW, the current
wheel was invented a year ago 'cuze nothing really fit what we needed.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

Vince asks:

Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us
that would make me want to learn it and install it? BTW, the current
wheel was invented a year ago 'cuze nothing really fit what we needed.

The reasons I would choose Bugzilla:

1. It's *not* written by us so (in theory) we don't have to waste time
developing yet another bug tracking solution.

2. It sends email to people involved with a bug whenever the detail
associated with that bug is modified. This includes the reporter, who
often will feedback that it now works, at which time the fixer or the
reporter can mark the bug as fixed.

3. It complains when a NEW bug hasn't been looked at for /n/ days --
this means that any not-a-bug's will be closed, while any that are
really bugs will be accepted.

4. Good query facilities, if a little complex to use.

5. I think Bugzilla's concepts of products, components and versions fit
the way we work.
I envisage that 'Postgres', 'Interfaces', 'Languages' might be products
that we would have.
Within 'Postgres' we would have the various subsystems that make up the
core.
Within 'Interfaces' we would have 'JDBC', 'ODBC' etc.
Within 'Languages' we would have 'PL/pgSQL' etc.

Arguments accepted.

There are other tools the Mozilla project uses that we could also use:

Tinderbox -- continuous automated builds, including subsequent regression
tests
(useful for seeing who broke CVS).
Bonsai -- CVS integration for Bugzilla

Cheers,

Colin

On Thu, 23 Aug 2001, Colin 't Hart wrote:

Vince asks:

Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us
that would make me want to learn it and install it? BTW, the current
wheel was invented a year ago 'cuze nothing really fit what we needed.

The reasons I would choose Bugzilla:

1. It's *not* written by us so (in theory) we don't have to waste time
developing yet another bug tracking solution.

What we have is already developed and refining it isn't a problem.

2. It sends email to people involved with a bug whenever the detail
associated with that bug is modified. This includes the reporter, who
often will feedback that it now works, at which time the fixer or the
reporter can mark the bug as fixed.

What we have already does this, but noone was using it.

3. It complains when a NEW bug hasn't been looked at for /n/ days --
this means that any not-a-bug's will be closed, while any that are
really bugs will be accepted.

This would piss off the developers.

4. Good query facilities, if a little complex to use.

Please elaborate.

5. I think Bugzilla's concepts of products, components and versions fit
the way we work.
I envisage that 'Postgres', 'Interfaces', 'Languages' might be products
that we would have.
Within 'Postgres' we would have the various subsystems that make up the
core.
Within 'Interfaces' we would have 'JDBC', 'ODBC' etc.
Within 'Languages' we would have 'PL/pgSQL' etc.

I can see a little benefit to this, but for the most part the same
people that are working on the core pieces of PostgreSQL are also
working on the interfaces and languages.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

Vince Vielhaber <vev@michvhf.com> writes:

On Thu, 23 Aug 2001, Colin 't Hart wrote:

5. I think Bugzilla's concepts of products, components and versions fit
the way we work.
I envisage that 'Postgres', 'Interfaces', 'Languages' might be products
that we would have.
Within 'Postgres' we would have the various subsystems that make up the
core.
Within 'Interfaces' we would have 'JDBC', 'ODBC' etc.
Within 'Languages' we would have 'PL/pgSQL' etc.

I can see a little benefit to this, but for the most part the same
people that are working on the core pieces of PostgreSQL are also
working on the interfaces and languages.

I would argue against subdividing a bug database at all. I don't think
the project is large enough to require it (we are in no danger of
becoming the size of Mozilla anytime soon). But more importantly,
subdivision introduces the risk of misclassification of a bug --- and
in my experience the initial reporter of a bug *very* frequently
misidentifies where the problem is. So unless additional effort is
expended to reclassify bugs (is that even possible in Bugzilla?), the
classification will degenerate to the point of being a hindrance rather
than a help in locating things. Overall I just don't see that much
benefit from a classification system.

regards, tom lane

Tom Lane wrote:

it does seem like a lot of people
like Bugzilla. Might be worth at least a cursory look.

We do use Bugzilla and I believe is a very good tool, which should fit
nicely with the open development style of PostgreSQL community. New
version is due in a few weeks and it's been already noted that a
PostgreSQL backend is almost ready. The Bugzilla community is growing
fast, BTW.

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750

"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925

Vince Vielhaber wrote:

Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us
that would make me want to learn it and install it? BTW, the current
wheel was invented a year ago 'cuze nothing really fit what we needed.

I believe the greatest advantage for the PostgreSQL is that a Bugzilla
installation would allow end-users as well as developers to check if a
bug has already been reported, look for existing bugs, submit patches,
add comments, see progress in development. This is very similar to the
open-development style of the core development team.

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-2-755750

"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925

Tom Lane wrote:

Vince Vielhaber <vev@michvhf.com> writes:

On Thu, 23 Aug 2001, Colin 't Hart wrote:

5. I think Bugzilla's concepts of products, components and versions fit
the way we work.
I envisage that 'Postgres', 'Interfaces', 'Languages' might be products
that we would have.
Within 'Postgres' we would have the various subsystems that make up the
core.
Within 'Interfaces' we would have 'JDBC', 'ODBC' etc.
Within 'Languages' we would have 'PL/pgSQL' etc.

I can see a little benefit to this, but for the most part the same
people that are working on the core pieces of PostgreSQL are also
working on the interfaces and languages.

I would argue against subdividing a bug database at all. I don't think
the project is large enough to require it (we are in no danger of
becoming the size of Mozilla anytime soon). But more importantly,
subdivision introduces the risk of misclassification of a bug --- and
in my experience the initial reporter of a bug *very* frequently
misidentifies where the problem is. So unless additional effort is
expended to reclassify bugs (is that even possible in Bugzilla?), the
classification will degenerate to the point of being a hindrance rather
than a help in locating things. Overall I just don't see that much
benefit from a classification system.

Bugzilla does provide for the reclassification bugs. I have
misidentified where bugs were in Mozilla and have had them reclassified
into different areas/components of that project.