Mailing List Archive: Vote early, vote often...

Vote early, vote often...

Aug 22, 1995, 9:51 AM

Post #1 of 20 (1262 views)

Here's that ballot I was threatening to send around. It lists the current
patches, and my votes --- replace those with your own. FWIW, my 11x build
is a quick way of trying out all of these (except the license patch, which
doesn't affect the actual code any).

+1 patch10.access_cleanup --- clarify init code and nuke bogus warning
in mod_access.c [Florent Guillaume]
+1 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]
+1 patch10.dir_cmd_tab --- Correct descriptions of args to AddIcon and AddAlt
in command table [James Cloos]
+1 patch10.dir_index --- Don't reset DirectoryIndex to 'index.html' when
other directory options are set in a .htaccess file. [Robert Thau]
+1 install.diff --- mention "contributed modules" directory [Brian Behlendorf]
+1 patch10.dist-readme --- ditto [Brian Behlendorf]
+1 patch10.license --- fix English in the license language...
"for for" --> "for". [Roy Fielding]
+1 patch10.log-noaccess --- Log access failures due to symlink checks
or invalid client address [Fielding, Thau]
+1 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]
+1 patch10.solaris-loop --- Don't loop for buggy CGI on Solaris [Cliff Skolnick]
+1 patch10.symlinks --- make FollowSymlinks and SymlinksIfOwnerMatch check
the file being requested itself, in addition to the directories leading
up to it. [Robert Thau]
+1 patch10.symlinks-again --- make FollowSymLinks deal correctly with systems
where lstat of "/path/to/some/link/" follows the link. [Thau, Fielding]

(Rob H. said not to bother with his ScriptAlias patch, so, well... I haven't
bothered with it).

The vote closes in something like 24 hours from now.

rst

Re: Vote early, vote often... [ In reply to ]

randy at zyzzyva

Aug 22, 1995, 8:07 AM

Post #2 of 20 (1251 views)

Re: Vote early, vote often... [ In reply to ]

fielding at beach

Aug 22, 1995, 11:21 AM

Post #3 of 20 (1252 views)

>patch10.config-cleanup -1 Don't like AddIcon changes

What is that supposed to mean? The changes institute the default
icons and fix two bugs. Whether or not you like the default icons
is irrelevant to the patch.

.....Roy

Re: Vote early, vote often... [ In reply to ]

fielding at beach

Aug 22, 1995, 11:25 AM

Post #4 of 20 (1250 views)

+1 patch10.access_cleanup
+1 patch10.config-cleanup
+1 patch10.dir_cmd_tab
+1 patch10.dir_index
+1 install.diff
+1 patch10.dist-readme
+1 patch10.license
+1 patch10.log-noaccess
+1 patch10.scripta-rst
+1 patch10.solaris-loop
+1 patch10.symlinks
+1 patch10.symlinks-again

........Roy

Re: Vote early, vote often... [ In reply to ]

Aug 22, 1995, 1:39 PM

Post #5 of 20 (1250 views)

Date: Tue, 22 Aug 95 18:12 BST
From: drtr@ast.cam.ac.uk (David Robinson)

Comments on one veto:

patch10.wild-dirs -1 what about / in wildcards?

[Somewhat angered...] I thought the purpose of getting patches in a
couple of days before a vote was to give time for people to look the
patches over, and for objections like this to be aired. Why is this
the first I hear of it? At any rate, I'll pretend you had raised the
issue earlier, and respond...

To answer the question --- we're compatible. Doing anything else
would break peoples' setups --- I'm sure Roy isn't the only person who
is counting on "/*/public_html*" to match all UserDirs.

Even if you think this is a bug (and having looked at some more setups
than my own since I thought myself that slashes in wildcards were a
problem, I frankly disagree), you must surely accept that this is an
improvement on the status quo, in which wildcards are just hosed (a
bug which has been reported to use repeatedly, which has security
implications, and which we had better fix).

rst

Re: Vote early, vote often... [ In reply to ]

Aug 22, 1995, 6:12 PM

Post #6 of 20 (1252 views)

Apologies if you get this twice...

install.diff +1
patch10.access_cleanup +1
patch10.config-cleanup -1 Don't like AddIcon changes
patch10.dir-cmd-tab +1
patch10.dir-index +1
patch10.license +1
patch10.log-noaccess 0 Failed to patch
patch10.scripta-robh -1 very ugly
patch10.scripta-rst 0 ugly; couldn't it have the effect of a <directory>?
patch10.solaris-loop +1
patch10.symlinks +1
patch10.symlinks-again +1
patch10.wild-dirs -1 what about / in wildcards?
readme.diff +1

David.

Re: Vote early, vote often... [ In reply to ]

brian at organic

Aug 23, 1995, 12:32 AM

Post #7 of 20 (1254 views)

Well, I installed 11x on hyperreal, and all is still well, so I presume
it works as advertised :) I don't have the time/technical expertise to
detect errors in the patches by inspection, but if they fix what they are
supposed to fix, perfect.

+1 on all.

Brian

On Tue, 22 Aug 1995, Robert S. Thau wrote:
> Here's that ballot I was threatening to send around. It lists the current
> patches, and my votes --- replace those with your own. FWIW, my 11x build
> is a quick way of trying out all of these (except the license patch, which
> doesn't affect the actual code any).
>
> +1 patch10.access_cleanup --- clarify init code and nuke bogus warning
> in mod_access.c [Florent Guillaume]
> +1 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]
> +1 patch10.dir_cmd_tab --- Correct descriptions of args to AddIcon and AddAlt
> in command table [James Cloos]
> +1 patch10.dir_index --- Don't reset DirectoryIndex to 'index.html' when
> other directory options are set in a .htaccess file. [Robert Thau]
> +1 install.diff --- mention "contributed modules" directory [Brian Behlendorf]
> +1 patch10.dist-readme --- ditto [Brian Behlendorf]
> +1 patch10.license --- fix English in the license language...
> "for for" --> "for". [Roy Fielding]
> +1 patch10.log-noaccess --- Log access failures due to symlink checks
> or invalid client address [Fielding, Thau]
> +1 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]
> +1 patch10.solaris-loop --- Don't loop for buggy CGI on Solaris [Cliff Skolnick]
> +1 patch10.symlinks --- make FollowSymlinks and SymlinksIfOwnerMatch check
> the file being requested itself, in addition to the directories leading
> up to it. [Robert Thau]
> +1 patch10.symlinks-again --- make FollowSymLinks deal correctly with systems
> where lstat of "/path/to/some/link/" follows the link. [Thau, Fielding]
>
> (Rob H. said not to bother with his ScriptAlias patch, so, well... I haven't
> bothered with it).
>
>
> The vote closes in something like 24 hours from now.
>
> rst
>

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 8:53 AM

Post #8 of 20 (1254 views)

I agree with your comments about compatibility.

Does this mean you rescind the veto?

[. Hmmm... if I left wild-dirs off the ballot, we have a problem. I vote
+1 on the thing, and anyone who has used 11x has tried it out, and is
entitled to vote +1 as well... ]

rst

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 8:58 AM

Post #9 of 20 (1251 views)

My main concern is that we should fix the bugs in the directory indexing code
before deciding what should go in the srm.conf file.

Dave, this is asinine. What's in the srm.conf file right now is *broken*.
*Bogus*. *Kaput*. It just plain doesn't work. This has been reported to
us as a bug, more than once.

And you don't want it fixed because you think we should chnage something
else first?

rst

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 9:43 AM

Post #10 of 20 (1251 views)

David wrote,

> What happens now is:
> A single person sets the agenda by selecting patches for a new release.
> Everyone takes a copy of the preliminary version of the new release, and
> votes +1 on all the patches if they don't encounter any problems.

> Hence the occurence that there have been four +1 votes for a
> patch that cannot be successfully applied to 0.8.10!

> Am I not wasting my time here? Wouldn't it be more efficient to take this
> to its logical conclusion? i.e. simply chuck all the patches into a new
> internal release, drop any peer review of the changes, and hope that any
> problems come to light with subsequent testing.

> Of course, this would reinforce the bug-fixers syllogism:
> `This bug must be fixed. Here is a patch that fixes the bug.
> Therefore this patch must be applied.'

I agree entirely, hence my +0 on everything.

+1 on the old system. It worked.

David's caution is slowing things down, but that's a good thing IMO.

rob

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 10:25 AM

Post #11 of 20 (1253 views)

>Comments on one veto:
>
> patch10.wild-dirs -1 what about / in wildcards?
>
>[Somewhat angered...] I thought the purpose of getting patches in a
>couple of days before a vote was to give time for people to look the
>patches over, and for objections like this to be aired. Why is this
>the first I hear of it? At any rate, I'll pretend you had raised the
>issue earlier, and respond...

Given that the author didn't vote the patch, I assumed there was something
wrong with it, and for want of a better vote, I voted -1. 8-)

I agree with your comments about compatibility.

David.

Re: Vote early, vote often... [ In reply to ]

brian at organic

Aug 23, 1995, 10:33 AM

Post #12 of 20 (1253 views)

On Wed, 23 Aug 1995, David Robinson wrote:
> > My main concern is that we should fix the bugs in the directory indexing
> > code before deciding what should go in the srm.conf file.
>
> >Dave, this is asinine. What's in the srm.conf file right now is *broken*.
> >*Bogus*. *Kaput*. It just plain doesn't work. This has been reported to
> >us as a bug, more than once.
>
> How am I to know that? Am I expected to go back through all the mail to try
> and figure out what a patch is for?

If you vote on a patch, you are expected to have kept up with the
discussions regarding that patch and its implications, and have to one
degree or another tested it. If you didn't know the context of the
patch, you should not veto it.

Two mitigating factors in this flame. The archive of posts is currently
very lame (one big mail spool) and I will be fixing this soon to do
monthly archiving using hypermail. Also, I thought Rob's "you have 2 days
to vote on this" was a little rushed, or at least that was my fiance's
opinion last night when I explained why I came home an hour later than I
said I would :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Re: Vote early, vote often... [ In reply to ]

brian at organic

Aug 23, 1995, 10:49 AM

Post #13 of 20 (1253 views)

On Wed, 23 Aug 1995, David Robinson wrote:
> It seems to me that the voting rules have changed somewhat. What used to
> happen (and what only I am doing) was:
>
> people only voted on those patches that they had examined, applied and
> tested.

This is still true. As patches were coming out to 0.8.10 I applied many
of them. I also have spent a lot of time monitoring the comments made
about each patch and benefits/demerits.

> What happens now is:
> A single person sets the agenda by selecting patches for a new release.
> Everyone takes a copy of the preliminary version of the new release, and
> votes +1 on all the patches if they don't encounter any problems.

Well, a single person at *some* point has to marshall the troops and
focus them. That means setting cutoff dates and making decisions about
things - what other patches besides RobH's (which he withdrew) and
Randy's BSDI 1.1 (which made it after voting had begun) didn't make it
to the vote?

Now as to the process leading to my issuance of +1's - I grabbed 11x because,
yes, it was easier than applying the patches separately. I *trust* RobT to
apply them correctly and without adding small easter eggs of his own, etc. I
qualified my evaluations - while I don't understand the internals of Apache
well enough to foresee some conflicts that some patches cause, I know it well
enough to understand the flow of the debate. In every system one has to
trust particular individuals to do "the right thing" - even after the
vote there might be issues in getting all the patches to work together.
Dave, if you're interested in taking on the task of vote counter and
release engineer for the next couple of releases I bet Rob would be happy
to take a breather....

If you want to see a patch database back, well, you have your account on
hyperreal and can turn it back on anytime, revamped however you like...
would you like to take that on as your area of focus?

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 10:56 AM

Post #14 of 20 (1249 views)

Date: Wed, 23 Aug 95 14:50 BST
From: drtr@ast.cam.ac.uk (David Robinson)

How am I to know that? Am I expected to go back through all the
mail to try and figure out what a patch is for? On reading the
patch I see lots of (to me) pointless changes, followed by a few
sensible mods. Without any information to the contrary, I would
assume that all the changes in the patch have equal importance.

Roy's description of the patch is at the top fof the file --- it's
brief, but it's there. Since he repeated the same description even
in response to your specifically stated concern about AddIcon, it
certainly looks as if he doesn't think it requires elaboration. Why
do you believe he would have entered a more complete description into
the patch db?

rst

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 12:25 PM

Post #15 of 20 (1252 views)

Roy wrote:
>>patch10.config-cleanup -1 Don't like AddIcon changes
>
>What is that supposed to mean? The changes institute the default
>icons and fix two bugs. Whether or not you like the default icons
>is irrelevant to the patch.

Nothing to do with the icons themselves, but with the AddIcon, AddIconByType
and AddIconByEncoding changes to srm.conf.

My main concern is that we should fix the bugs in the directory indexing code
before deciding what should go in the srm.conf file.

I believe that the algorithm for resolving an icon should be as follows:
1. Find the content-type and encoding of the file in a manner identical
to the rest of Apache
2. If the object has a mime type matching an AddIconByType, then use that.
3. If the object has an extension matching an AddIcon, then use that.
4. Otherwise, if the object has an encoding matching AddIconByEncoding, then
use that.

The idea is that the icon reflects the type of the object returned.
Using an icon to show the encoding should be the lowest priority.

So I suggest that srm.conf should use AddIconByType where ever possible:
e.g. AddIconByType (TAR,/icons/tar.gif) application/x-tar
AddIconByType (DIR,/icons/dir.gif) httpd/unix-directory

David.

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 2:50 PM

Post #16 of 20 (1253 views)

> My main concern is that we should fix the bugs in the directory indexing
> code before deciding what should go in the srm.conf file.

>Dave, this is asinine. What's in the srm.conf file right now is *broken*.
>*Bogus*. *Kaput*. It just plain doesn't work. This has been reported to
>us as a bug, more than once.

How am I to know that? Am I expected to go back through all the mail to try
and figure out what a patch is for? On reading the patch I see lots of (to me)
pointless changes, followed by a few sensible mods. Without any information to
the contrary, I would assume that all the changes in the patch have equal
importance.

I would rather this patch didn't make the AddIcon changes, but if you assure
me that it is fixing a significant bug, then I'll change my vote to 0.

>And you don't want it fixed because you think we should chnage something
>else first?

That is a completely unwarranted conclusion. When did I say that I didn't
want the DefaultIcon bug fixed? My message was quite specific in restricting
my comments to the AddIcon changes.

(I am guessing that by *broken* you are referring to the DefaultIcon change,
but I don't actually know.)

+1 on bringing back a (the) patch log database.

David.

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 3:11 PM

Post #17 of 20 (1251 views)

> I agree with your comments about compatibility.
>
>Does this mean you rescind the veto?

When I've looked at the patch...

>[. Hmmm... if I left wild-dirs off the ballot, we have a problem. I vote
> +1 on the thing, and anyone who has used 11x has tried it out, and is
> entitled to vote +1 as well... ]

It seems to me that the voting rules have changed somewhat. What used to
happen (and what only I am doing) was:

people only voted on those patches that they had examined, applied and
tested.

What happens now is:
A single person sets the agenda by selecting patches for a new release.
Everyone takes a copy of the preliminary version of the new release, and
votes +1 on all the patches if they don't encounter any problems.

Hence the occurence that there have been four +1 votes for a patch that cannot
be successfully applied to 0.8.10!

Am I not wasting my time here? Wouldn't it be more efficient to take this
to its logical conclusion? i.e. simply chuck all the patches into a new
internal release, drop any peer review of the changes, and hope that any
problems come to light with subsequent testing.

Of course, this would reinforce the bug-fixers syllogism:
`This bug must be fixed. Here is a patch that fixes the bug.
Therefore this patch must be applied.'

(Not that this needs reinforcing on this list 8-) )

David.

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 4:12 PM

Post #18 of 20 (1250 views)

Rst wrote:
>Comments on one veto:
>
> patch10.wild-dirs -1 what about / in wildcards?
>
>
>To answer the question --- we're compatible. Doing anything else
>would break peoples' setups --- I'm sure Roy isn't the only person who
>is counting on "/*/public_html*" to match all UserDirs.

Actually, we're not compatible. NCSA applies wildcard entries before
non-wildcard ones, whereas the patch applies them in order. The NCSA
behaviour is slightly more useful, but I doubt anyone depends on it.

+1; should the difference is documented?

David.

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 4:32 PM

Post #19 of 20 (1256 views)

I wrote:
>Rst wrote:
>>Comments on one veto:
>>
>> patch10.wild-dirs -1 what about / in wildcards?
>>
>>
>>To answer the question --- we're compatible. Doing anything else
>>would break peoples' setups --- I'm sure Roy isn't the only person who
>>is counting on "/*/public_html*" to match all UserDirs.
>
>Actually, we're not compatible. NCSA applies wildcard entries before
>non-wildcard ones, whereas the patch applies them in order. The NCSA
>behaviour is slightly more useful, but I doubt anyone depends on it.
>
>+1; should the difference is documented?

More importantly, it should be documented that Apache treats all wildcard
Directory entries as though they end in a '*' (nearly).

e.g.
<Directory /foo/*/baz>

for NCSA matches /foo/wibble/baz but not /foo/wibble/baz/wombat,
whereas in Apache 0.8.10-patched both directories are matched.

David.

Re: Vote early, vote often... [ In reply to ]

Aug 23, 1995, 7:28 PM

Post #20 of 20 (1249 views)

Date: Wed, 23 Aug 1995 10:33:27 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>

Two mitigating factors in this flame. The archive of posts is currently
very lame (one big mail spool) and I will be fixing this soon to do
monthly archiving using hypermail. Also, I thought Rob's "you have 2 days
to vote on this" was a little rushed, or at least that was my fiance's
opinion last night when I explained why I came home an hour later than I
said I would :)

Sigh... I tried. The vote was announced on Friday for Sunday, then
postponed for a day and a half to give people more time to look things
over. Brian has suggested, in private email, that we have some time
for discussion after all the patches come in, followed by two days for
the vote --- personally, I think three days for the whole process is a
bit uncomfortable (half a week), but I could live with it. What do
people think?

rst