httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: New scratch build, votes, etc....
Date Mon, 21 Aug 1995 09:52:53 GMT
   Date: Mon, 21 Aug 1995 03:07:54 -0700
   From: Cliff Skolnick <cliff@organic.com>

   +1 on bringing back the patch database, please....

I'd prefer to hold off on this until we have a good theory of what
it's for, and we're sure there isn't some lighter-weight way of
accomplishing the same goals.

Paul's immediate problem, for instance, is solved as easily by putting
the reason for the patch in the same file as the patch itself; doing
this would be at least as convenient for Paul (and for everyone else),
since you wouldn't have to cross-reference the patch itself with a
description stored somewhere else.  In fact, as I recall, we wound up
putting descriptions in the patch files themselves in *addition* to
the ones in the patch db for exactly this reason, and when a patch was
updated, the description in the patch file tended to get updated as
well, while the patch db went stale.

Likewise, classifying patches as bugfix, performance enhancement, or
extension (or cleanup --- a category we missed the last time around)
can be accomplished by imposing a naming convention on the files in
the patch directory.  In fact, given these conventions, it wouldn't
be hard to come up with a script which produces the same view of the
patch directories as the current patch-db front ends.

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.  Also, attempts to use the patch db as a
discussion forum never really worked out (email is just so much more
convenient, particularly with the sorry state of forms-based web
browsers as authoring environments --- besides which, I have enough
trouble keeping up with the mailing list without periodically
wandering over the patch db too to see if anything has changed).

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.  

Let's give it some thought, OK?

rst

Mime
View raw message