Message-Id: <199508211454.HAA04607@bauhaus.organic.com>
To: new-httpd@hyperreal.com
Subject: Re: New scratch build, votes, etc.... 
In-reply-to: Your message of "Mon, 21 Aug 1995 09:52:53 EDT."
             <9508211352.AA07864@volterra>
Date: Mon, 21 Aug 1995 07:54:38 -0700
From: Cliff Skolnick <cliff@organic.com>
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


On Mon, 21 Aug 1995 09:52:53 EDT, rst@ai.mit.edu (Robert S. Thau) wrote:
 
} And between those two things, I think that's all that I ever got out
} of the patch db.  I can't recall needing information about a patch
} beyond type, description, and name of submitter; that information was
} often incorrect in any case.
 
} Of course, conventions like the ones I'm suggesting as alternatives to
} a patch db require cooperation on everybody's part to work --- but so
} does *any* mechanism that anyone might propose, including the patch db
} itself.  


I think we just need some standards.  One important thing we also need
to track is conflicting patches, but that is easy enough to put in the file.
I do indeed like your idea of bulding the database around the patch files
themselves to keep all the data in one place.  Most excellent suggestion.

One nice thing about the issueing of numbers was it was simple to refer to
a table of all the bugs.  Longs names can be misleading, what if
a bug filed as blech.solaris.foo ends up not being only on solaris?
Now your identifier changes or is left misleading.

How about:

	* Bug id issued via a web form

	* Submitter uploads the file to bug.<id #>

	* All data and a patch (if it exists) is in the one file

	* Create a cgi to print a sumery of the bugs in the file
	  close to what we had before.

	* Perhaps even another cgi that I can cut and paste to
	  email for votes?

Simple, and should solve problems.

Cliff