Re: getting patches organized

[Diego Novillo <dnovillo at cygnus dot com>]

On Thu, 16 Dec 1999, Jeffrey A Law wrote:

> Diego -- can you forward that initial summary you sent to the Cygnus GCC team
> to the Jim & the GDB folks.
> 
Sure. I will also be putting this information and the replies I
got in Faq-o-matic.


-----------------------------------------------------------------------------
From dnovillo@cygnus.com Thu Dec 16 10:35:22 1999
Date: Fri, 3 Dec 1999 20:58:46 -0700 (MST)
From: Diego Novillo <dnovillo@cygnus.com>
To: gcc-local@cygnus.com
Bcc: Diego Novillo <dnovillo@cygnus.com>
Subject: RFD: Patch tracking systems


I've been browsing the web looking for patch tracking systems. I
found none. However, as Jeff mentioned last Tuesday, we could use
some of the existing bug tracking systems. It actually is a
similar problem.

I used the following (personal) criteria when evaluating the
different options:

* It should be free (not necessarily gratis) and come with source.
* It should work via e-mail.
* It should be actively maintained.
* It should work on any flavor of Unix.
* It should have all the reasonable features:
	- Query interface for finding patches
	- Assign different attributes/categories to each case
	- Case states to keep track of what's happening to the
	  patch.

Perhaps the most important factor from my point of view is the
e-mail interface. I do not want to open netscape or some silly
window to upload a file. E-mail is ubiquitous and simple to use.

Here's a few that caught my eye:


---------------------
99r1 Patch submission
---------------------

Most of us have used it. This is the web interface for submitting
patches to 99r1. I don't particularly like it because it needs
too many indirections to get the patch submitted. You have to
bring up netscape, upload your files to a special directory in
SV and fill in the form.

Jeff was working on a version that would simplify the patch
uploading step but I still think it might be easier to use
something that's email based.


--------
Bugzilla
--------

Another web-based tool. It's a bunch of perl scripts that use
MySQL to store the cases. I downloaded the sources and I wasn't
very impressed. Documentation is lacking and it doesn't seem to
be too integrated. From their README:

"This is not very well packaged code.  It's not packaged at all.
Don't come here expecting something you plop in a directory,
twiddle a few things, and you're off and using it.  Work has to
be done to get there.  We'd like to get there, but it wasn't
clear when that would be, and so we decided to let people see it
first."

They claim to be working on an email interface but it still
doesn't work. There's also a gnats2bz conversion script in the
contrib directory in case we ever wanted to migrate from PRMS to
Bugzilla.

The impression I got is that they started from something specific
to Mozilla and they're trying to make it more generic, but they
still have a long way to go.



--------------------------
Debian Bug Tracking System
--------------------------

This one looks promising. More integrated and generic. These are
the main features that they put up on their home page:

* All input and manipulation of reports is done by email;
  developers do not need on-line web access or accounts on the
  host system. 

* Outstanding, recently closed and other listings of reports are
  made available via a webserver, and by an email request bot. 

* Each report has a separate email address for submission of additional
  information. 

* WWW listings of bugs can be mirrored by email or HTTP. 

* Core functions do not require CGI scripts. 

It's used by several open projects out there and seems to be
actively maintained.



--------------------
GNU GNATS (aka PRMS)
--------------------

Not much to say about this one. You have used it before. I have
never used it but it does seem very flexible. It's got all sorts
of interfaces: email, web, tk. 

The documentation is very complete and best of all, it's being
developed in-house. We might as well take advantage of this. If
we have problems with the tool we can always walk down the hall
and beat them over the head to fix it.

Some of the features:

* E-mail interface for submitting patches.
* Uses a file system based database 
* Each problem identified by a unique key 
* Querying possible 
* Can maintain audit trail of all activities concerning a specific problem 
* GUI interfaces (via tkgnats and gnatsweb) 


---------
JitterBug
---------

JitterBug was originally developed for managing the samba bug
reports but they have made it available under the GPL. It is
mainly web based but it does have e-mail functionality.

[ I ripped this from their web page ]

JitterBug operates by receiving bug reports via email or a web
form. Authenticated users can then reply to the message, move it
between different categories or add notes to it.

Some of the features of JitterBug include

* Fully web based. The whole system is a single C program running as
  a CGI script.
* HTML 3.2 compliant so it is usable from virtually any browser. No
  frames, Java or gratuitous graphics.
* Uses your web servers built-in authentication
* Built in SMTP mail client for sending replies and notifications
* Each user can request email notification of changes to messages or
  directories
* FAQ editing/creation built into the mail composing page
* Tracking of replies and followups
* Search and message selection controls
* Each user can set personal preferences for colors, screen layout
  and personal details (like email address and signature)
* Easily customizable
* Doesn't require a database backend. All messages are kept as
  separate files
* Users can add arbitrary notes to each message
* An audit trail is kept for each message showing who did what and
  when.


----
Wreq
----

This is mainly a sysadmin tool for handling user requests. It
uses both e-mail and web interfaces. I guess we could use it but
it does not seem to be fully functional yet. I wouldn't bother
with this one.




There were others but they cost money or they're more primitive.
My impression is that we can do with one of these. My personal
preferences are: GNATS -> Debian -> JitterBug. 

To make a more informed decision we should first get a consensus
on how we want to use the system. We then try to map what we want
into one of these systems and see which one we like better.

How I see us using this:

1- Patches should include basically the same information we use
   now plus a couple more fields:

   * Category.
	This would be used to select who gets the patch
	initially. For this we use the categories and reviewers
	that we've been discussing lately.

   * Branch/release.
   	
   * Description of the problem.

   * ChangeLog

   * Patch

   There are other fields but they should be mostly automatic
   (who, when, etc)


2- We send the patch to some local address (say gcc-patches). The
   patch gets automatically copied to the reviewers, and maybe
   gcc-local so that everyone gets a chance to see it.


3- All the e-mail discussion about the patch is automatically
   appended to the case (provided that people keep CCing
   gcc-patches).


4- The case is closed when some reviewer approves it.

5- People can query cases using the GUI interface.


I would like to start playing with GNATS and/or Debian. I will
need to setup a gcc-patches account in SV. Although for the time
being I can set it up locally and take it from there.

Suggestions? Comments?

Thanks.