Mailing List Archive

In reply to Robert S. Thau who said
>
> Given that Roy and I have just dumped a whole buncha new patches on
> hyperreal, it seems a bit rushed to start a vote now. In the meantime,
> since I have the thing lying around anyway and it may prove useful to
> people, I've snapshotted my current working sources (which include
> everything except Rob H.'s ScriptAlias patch (it has mine) and Roy's
> license patch --- in particular, it has Brian's install and README
> patches).

Can we have a better mechanism for storing bugs and their *causes*.
I'm going to grab the latest set of sources sometime soon (today
or tomorrow) and with all the patches going in it would be handy
if I knew what to actually try to verify the problem doesn't exist
on FreeBSD.

That's a bit hard if I don't remember what the procedure is that
manifests the bug in the first place.


--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)

In reply to Robert S. Thau who said
>
> Given that Roy and I have just dumped a whole buncha new patches on
> hyperreal, it seems a bit rushed to start a vote now. In the meantime,
> since I have the thing lying around anyway and it may prove useful to
> people, I've snapshotted my current working sources (which include
> everything except Rob H.'s ScriptAlias patch (it has mine) and Roy's
> license patch --- in particular, it has Brian's install and README
> patches).

Can we have a better mechanism for storing bugs and their *causes*.
I'm going to grab the latest set of sources sometime soon (today
or tomorrow) and with all the patches going in it would be handy
if I knew what to actually try to verify the problem doesn't exist
on FreeBSD.

That's a bit hard if I don't remember what the procedure is that
manifests the bug in the first place.


--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)

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

Cliff

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

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

Thinking...... conclussion - let's have the patch database back.


rob

From: Paul Richards <paul@netcraft.co.uk>
Date: Mon, 21 Aug 1995 10:54:33 +0100 (BST)

Can we have a better mechanism for storing bugs and their *causes*.
I'm going to grab the latest set of sources sometime soon (today
or tomorrow) and with all the patches going in it would be handy
if I knew what to actually try to verify the problem doesn't exist
on FreeBSD.

That's a bit hard if I don't remember what the procedure is that
manifests the bug in the first place.

The easiest way to do this is probably to put a description of the
problem in the patch file itself (some, but not all of the patches
currently on hyperreal have these --- 'patch' is smart enough to skip
over them to get to the actual patch). As a stopgap, here's the
latest version of the list I'm keeping...

* patch10.access_cleanup --- clarify init code and nuke bogus compiler warning
in mod_access.c [Florent Guillaume]
* patch10.config-cleanup --- Corrects several directives in sample srm.conf
--- includes corrections to directory indexing icon-related directives
(using unknown.gif rather than unknown.xbm as the DefaultIcon, doing
icons for encodings right, and turning on AddEncoding by default).
[Roy Fielding]
* patch10.dir_cmd_tab --- Correct descriptions of args to AddIcon and AddAlt
in command table [James Cloos]
* patch10.dir_index --- Don't reset DirectoryIndex to 'index.html' when
other directory options are set in a .htaccess file. [Robert Thau]
* install.diff --- mention contributed modules directory
* readme.diff --- ditto.
patch10.license --- fix English in the license language...
* patch10.log-noaccess --- Log access failures due to symlink checks
or invalid client address [Fielding, Thau]
* patch10.scripta-rst --- Fix ScriptAlias by moving ScriptAlias handling to
mod_alias.c, merging it almost completely with handling of Alias, and
adding a 'notes' field to the request_rec which allows the CGI module
to discover whether the Alias module has put this request through
ScriptAlias (which it needs to know for back-combatibility, as the old
NCSA code did not check Options ExecCGI in ScriptAliased directories).
[Robert Thau]
* patch10.solaris-loop --- Don't loop for buggy CGI on Solaris [Cliff Skolnick]
* patch10.symlinks --- make FollowSymlinks and SymlinksIfOwnerMatch check
the file being requested itself, in addition to the directories leading
up to it. [Robert Thau]
* patch10.symlinks-again --- make FollowSymLinks deal correctly with systems
where lstat of "/path/to/some/link/" follows the link. [Thau, Fielding]

From: Paul Richards <paul@netcraft.co.uk>
Date: Mon, 21 Aug 1995 10:54:33 +0100 (BST)

Can we have a better mechanism for storing bugs and their *causes*.
I'm going to grab the latest set of sources sometime soon (today
or tomorrow) and with all the patches going in it would be handy
if I knew what to actually try to verify the problem doesn't exist
on FreeBSD.

That's a bit hard if I don't remember what the procedure is that
manifests the bug in the first place.

The easiest way to do this is probably to put a description of the
problem in the patch file itself (some, but not all of the patches
currently on hyperreal have these --- 'patch' is smart enough to skip
over them to get to the actual patch). As a stopgap, here's the
latest version of the list I'm keeping...

* patch10.access_cleanup --- clarify init code and nuke bogus compiler warning
in mod_access.c [Florent Guillaume]
* patch10.config-cleanup --- Corrects several directives in sample srm.conf
--- includes corrections to directory indexing icon-related directives
(using unknown.gif rather than unknown.xbm as the DefaultIcon, doing
icons for encodings right, and turning on AddEncoding by default).
[Roy Fielding]
* patch10.dir_cmd_tab --- Correct descriptions of args to AddIcon and AddAlt
in command table [James Cloos]
* patch10.dir_index --- Don't reset DirectoryIndex to 'index.html' when
other directory options are set in a .htaccess file. [Robert Thau]
* install.diff --- mention contributed modules directory
* readme.diff --- ditto.
patch10.license --- fix English in the license language...
* patch10.log-noaccess --- Log access failures due to symlink checks
or invalid client address [Fielding, Thau]
* patch10.scripta-rst --- Fix ScriptAlias by moving ScriptAlias handling to
mod_alias.c, merging it almost completely with handling of Alias, and
adding a 'notes' field to the request_rec which allows the CGI module
to discover whether the Alias module has put this request through
ScriptAlias (which it needs to know for back-combatibility, as the old
NCSA code did not check Options ExecCGI in ScriptAliased directories).
[Robert Thau]
* patch10.solaris-loop --- Don't loop for buggy CGI on Solaris [Cliff Skolnick]
* patch10.symlinks --- make FollowSymlinks and SymlinksIfOwnerMatch check
the file being requested itself, in addition to the directories leading
up to it. [Robert Thau]
* patch10.symlinks-again --- make FollowSymLinks deal correctly with systems
where lstat of "/path/to/some/link/" follows the link. [Thau, Fielding]

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

Cliff suggests...

* 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?

I'd like a meaningful name, and a one-character category code in the
filename in addition to the number; also, I'd like a command to run on
hyperreal to get a bug id (so I don't have to fire up Netscrape; it
probably isn't running already, since I do all my server debugging
with telnet).

If neither of these is any big deal, we may have reduced this to a
SMOP.

rst

David wrote,

> . It's already clear that 'uninteresting'
> bug reports fall through the cracks in the mailling list; nobody is interested
> in fixing them, so they are forgotten.

Yup, very true.

Many of the mailed patches just get deleted on sight too, I don't have
the energy to run my own personal mail-based patch database.


We used to be able to assign ids to ideas as well as existing patches.
Can we retain this option. It's useful to be able to make a permanent
record of ideas which are still evolving.


On a related topic, has anyone looked into a way to merge an existing
C cgi program into Apache as a module ? Is there are recommended way to
do this ?

InternalScriptAlias anyone ?


rob

Date: Mon, 21 Aug 95 18:28 BST
From: drtr@ast.cam.ac.uk (David Robinson)

Even more importantly, is prevents the assignment a bug-id to a
problem _before the patch has been written_. It's already clear
that 'uninteresting' bug reports fall through the cracks in the
mailling list; nobody is interested in fixing them, so they are
forgotten.

Hmmm... with my proposal, you could try to accomodate this with a
"patch file" that has just a description, and no patch. This leaves
the case of multiple fixes to the same bug --- if they all have the
bug-id as a prefix, though, it doesn't seem terribly hard to make the
web front-end grok that B97-sprays-ketchup, B97-use-mustard-instead,
and B97-ditch-condiments are all associated with the same problem and
display them appropriately.

To this end, I've updated the patch-db software to enable it to list
patches by type, so that one can display unresolved problems.

Two final comments:
1. Any solution that requires interactive use of hyperreal is unacceptable to
me.
2. For any solution that uses cgi scripts on hyperreal, the scripts can
be run directly by hyperreal users (albeit with some output post-processing,
probably).

That's what I had in mind --- running the same program, which would
act by CGI conventions if invoked that way, and do something sensible
if run interactively.

Actually, something which might be even easier on users would be a
mail robot interface... the idea would be to have a mail alias, say,
bugtraq@mail.apache.org, which would take directions on the subject
line as to what would do with the body... e.g.

Subject: NEWBUG --- Apache 1.1.21 sprays ketchup on Foonix kitchencomputers

...would assign a new bug ID (and forward that and the info to the
main list, diddling the headers appropriately), while (assuming a bug
ID of 97 for this problem)

Subject: Re: B97 --- patch: ditch condiments

would note further work. (The point of having this be a separate
alias, rather than having the robot monitor the main list, is that,
IMHO, some active action should be required to affect the db, lest the
robot get confused about notes that aren't *really* meant as
directions to it).

This holds at least the prospect of any easy way of keeping things
from falling between the cracks --- forward a copy to bugtraq and it
will be remembered...

rst

Cliff wrote:
>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.

I don't agree. It is bugs or enhancement ideas that should be given
ids, _not_ particular patches. I think it is unnecessarily restrictive to tie
a bug number to reference a particular patch. With bugs and patches as
distinct objects, one can have have several (competing) patches for a single
bug-id, e.g.
B01232-drtr-fix and B01232-rst-fix.

Even more importantly, is prevents the assignment a bug-id to a problem
_before the patch has been written_. It's already clear that 'uninteresting'
bug reports fall through the cracks in the mailling list; nobody is interested
in fixing them, so they are forgotten.

To this end, I've updated the patch-db software to enable it to list
patches by type, so that one can display unresolved problems.

Two final comments:
1. Any solution that requires interactive use of hyperreal is unacceptable to
me.
2. For any solution that uses cgi scripts on hyperreal, the scripts can
be run directly by hyperreal users (albeit with some output post-processing,
probably).

David.