Bug tracking

[Randy Terbush <ra...@zyzzyva.com>]

Ok, since this was a hot topic, let's put it to rest.

This was never a very popular topic in the past, so feel
free to move this off the list to private email. I would
really like to see some comments from Tony Sanders, Brian,
Paul and RobH at the very least. All other are welcome to
share comments as well.

The goal as I see it:
(and those who discussed this in Paris should confirm these)

* Installation of a bug tracking system that is

	o more automated than present
	o viewable via web interface
	o modifiable via web interface ???
	o viewable via email interface
	o modifiable via email interface

* Installation of a patch tracking system (same?)

	o mainly geared toward group members to help track submissions



* Software options
	o gnats
		(installed v3.2 - close to completion)
		I've never had warm fuzzies about gnats.
		I'd be interested in comments about the newer
		version that I have heard about. One snag that
		I hit when installing this was a desire to allow
		it to manage serveral different projects. Like
		'request' listed below, it would require separate
		installations for each managed project/list.

	o cvs web interface 
		Paul, FreeBSD has a very groovy CVS interface.
		Is this public domain?

	o request
		Nice trouble ticket mailing list manager.
		From my initial assessment, it would require
		a separate installation for each mailing list
		that it tracks. Is this true Tony?

	o using some database like mSQL or Postgres95
		I'm more enamored with this approach in light
		of the flexibility, however Email management
		would add another level of work that I'm not
		in a position to take on at the moment.

	o others???

Re: Bug tracking

[Tom Tromey <tr...@creche.cygnus.com>]

Randy> 	o gnats
Randy> 		(installed v3.2 - close to completion)
Randy> 		I've never had warm fuzzies about gnats.
Randy> 		I'd be interested in comments about the newer
Randy> 		version that I have heard about. One snag that
Randy> 		I hit when installing this was a desire to allow
Randy> 		it to manage serveral different projects. Like
Randy> 		'request' listed below, it would require separate
Randy> 		installations for each managed project/list.

I don't know anything about the other options.  But I do know some
things about GNATS.  We use it here at Cygnus (of course, since we
wrote it).

The newest Gnats is improved in many ways over the 3.2 release.  BTW
the newest one is available on ftp.cygnus.com.  Most notably it allows
all queries and edits to be done over the net.  It uses its own
protocol for this; it doesn't piggyback over email or the web.

Randy> 	o modifiable via email interface

I don't think this exists for Gnats.  You can do queries via email,
however.  Is "email" really the requirement?  Or is it just "remote"?
If the latter, then Gnats can do it.

I believe there are web interfaces to query/submit bugs, but I don't
know much about them.  There are also convenient Emacs modes to query,
submit, and edit bugs, for those of you who are Emacs junkies (like
me).

I don't know anything about installing Gnats to serve several
projects.  You'd have to write the maintainer (or look in the manual
-- maybe it has the info) to find out more here.

Gnats would probably work ok as a patch repository as well.  You could
just make a new "patch" category and store each patch as a PR.
Applying any patch, even from over the net, would be really easy:

	nquery-pr --full patch-id | patch

Tom
-- 
tromey@cygnus.com                 Member, League for Programming Freedom

Re: Bug tracking

[Brian Behlendorf <br...@organic.com>]

(it's catch-up-on-old-issues-and-maybe-do-some-hacking-day!)

On Wed, 15 May 1996 rasmus@madhaus.utcs.utoronto.ca wrote:
> I am perfectly willing to write the bulk of this.  Just a word of warning
> though.  I don't do Perl.  It would be written in C with all web interface
> code in PHP/FI running through the Apache mod_php module or through the
> FastCGI version of the PHP/FI parser.  

I'd be happy to set it up here on hyperreal, using fastCGI (since I don't 
have the spare memory needed for using mod_php), or you could set it up 
there on a machine of your own I suppose.  

The audience for this, from what I see, is not just us - it should be for
the user base as well, so that they can see what bugs in which versions
have been reported previously, what the cause is, what a short-term patch
might be and when a long-term fix might be released.  Right now we direct
people to USENET, or we have to rehash over and over the same response,
which is somewhat unsatisfactory.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  |  We're hiring!  http://www.organic.com/Home/Info/Jobs/

Re: Bug tracking

[ra...@madhaus.utcs.utoronto.ca]

>      o using some database like mSQL or Postgres95
>           I'm more enamored with this approach in light
>           of the flexibility, however Email management
>           would add another level of work that I'm not
>           in a position to take on at the moment.

I might be in a decent position to build something like this.  I have
recently written a simple mailing list management package which keeps
track of mail using mSQL.  And as you know, I also wrote PHP/FI which 
makes building a web interface to mSQL exceedingly simple.  It would
probably take me about a weekend to bang out something workable *if*
I got some input beforehand with a set of features and requirements
that it needs.

The way I see it:

  o You can submit items either via email or via a web interface.
    If submitted via e-mail, some magic tags must be present to
    denote various things such as OS, version, category, etc.

  o The items can be searched either via the web interface or via
    email.  It can either be a full-text search on the item 
    description, or it can be a category search on one or a combination
    of categories.  

  o Each item would be stored in an mSQL database.  Multiple projects
    or sub-projects could be easily handled by using a separate table
    for each.  The full text of the item description would be stored 
    as a separate file with only the filename stored in mSQL.  This
    allows us to use something like Glimpse to do proper full-text
    searching while limiting mSQL use to category searches and quick
    keyed lookups.

Components needed:

   o Email to mSQL interface

      This is 90% written.  The last 10 percent would be to add the various
      magic-tag parsing needed for the specific features

   o mSQL to Email interface

      Some code needs to be written that responds to email-based queries.
      It might also need to be able to send periodic updates, or send
      copies of all new additions to one or more maintainers for the
      various categories.

   o mSQL to Web interface

      I crank these out at a rate of about 10 screens per day.  This
      is a trivial thing.

   o List of requirements

      The most important part.

I am perfectly willing to write the bulk of this.  Just a word of warning
though.  I don't do Perl.  It would be written in C with all web interface
code in PHP/FI running through the Apache mod_php module or through the
FastCGI version of the PHP/FI parser.  

-Rasmus