Having seen three +1 votes and no vetoes on the release of 0.8.10
(0.8.9 with David's two additional "show-stopper" patches), I've put a
0.8.10 build on hyperreal (httpd/dist) --- this is identical to the
former 0.8.10x except for the obvious one line in httpd.h, but it
would still be nice to know (as ever) that no essential bits fell out
in packing the thing. Assuming that's so, I'd be happy to move it to
the public distribution directory and update the pointers (and even
happier if someone else did that).
NB since people were only explicitly voting on the two patches named
above (AllowOverride bug and revised accept()-locking behavior), those
are the *only* patches on top of what was in 0.8.9 --- no other bug
fixes are included, even if I wrote the code myself.
By the group agreement that 0.8.9 was the last release to be built
without a formal, patch-by-patch vote on the contents, everything else
has to wait until that vote can be held. This raises the question of
timing...
Now, I'm planning to have a go this weekend at some of the .htaccess
related problems, and with wildcarded <Directory> entries. (Anyone
else who's looking into the wildcard stuff as well, see note below).
Since these are both frequently reported bugs, it seems to make sense
to put off the vote until fixes are available (or at least until we've
had a good shot at producing them) --- also, I would like a shot at
producing a cleaner fix to the Alias/ScriptAlias problem. What I'm
currently figuring on is making sure all the patches are available
Sunday, starting the vote Sunday evening, and building a release based
on the results sometime Tuesday.
(We have accumulated a bunch of useful-looking bug fixes past 0.8.9
already, but doing a vote *now* and adding the things above as soon as
they are available would mean two votes within 48 hours of each, which
is logistically infeasable. I suppose I could spin another release in
the meantime on the "rst's choice" system if we were still doing that,
pulling stuff which proves ill-advised later as I have in the past,
but given the rhetoric on procedural issues, I would rather not --- I
sincerely hope that the advocates of full votes will not now excoriate
me for delays which are simply inherent in the voting system which
they've been asking for, and which they've now got).
rst
PS --- Roy, on the wildcards issue --- if you read the directory_walk
code, you'll find two lines which look like wild cards will work if
you just uncomment them... and that may even be true. However,
uncommenting those lines is not clearly the right thing;
strcmp_match does *not* special case '/' characters, so those lines
will cause wildcards which match to match multiple times (in case
of subdirectories), and for their defaults to be merged multiple
times, an efficiency lose if nothing else.
The easiest fix is to revert to the way the NCSA code deals with
wildcards, which is to merge all of the matching wildcard entries
before doing the full directory walk and looking for exact matches...
(0.8.9 with David's two additional "show-stopper" patches), I've put a
0.8.10 build on hyperreal (httpd/dist) --- this is identical to the
former 0.8.10x except for the obvious one line in httpd.h, but it
would still be nice to know (as ever) that no essential bits fell out
in packing the thing. Assuming that's so, I'd be happy to move it to
the public distribution directory and update the pointers (and even
happier if someone else did that).
NB since people were only explicitly voting on the two patches named
above (AllowOverride bug and revised accept()-locking behavior), those
are the *only* patches on top of what was in 0.8.9 --- no other bug
fixes are included, even if I wrote the code myself.
By the group agreement that 0.8.9 was the last release to be built
without a formal, patch-by-patch vote on the contents, everything else
has to wait until that vote can be held. This raises the question of
timing...
Now, I'm planning to have a go this weekend at some of the .htaccess
related problems, and with wildcarded <Directory> entries. (Anyone
else who's looking into the wildcard stuff as well, see note below).
Since these are both frequently reported bugs, it seems to make sense
to put off the vote until fixes are available (or at least until we've
had a good shot at producing them) --- also, I would like a shot at
producing a cleaner fix to the Alias/ScriptAlias problem. What I'm
currently figuring on is making sure all the patches are available
Sunday, starting the vote Sunday evening, and building a release based
on the results sometime Tuesday.
(We have accumulated a bunch of useful-looking bug fixes past 0.8.9
already, but doing a vote *now* and adding the things above as soon as
they are available would mean two votes within 48 hours of each, which
is logistically infeasable. I suppose I could spin another release in
the meantime on the "rst's choice" system if we were still doing that,
pulling stuff which proves ill-advised later as I have in the past,
but given the rhetoric on procedural issues, I would rather not --- I
sincerely hope that the advocates of full votes will not now excoriate
me for delays which are simply inherent in the voting system which
they've been asking for, and which they've now got).
rst
PS --- Roy, on the wildcards issue --- if you read the directory_walk
code, you'll find two lines which look like wild cards will work if
you just uncomment them... and that may even be true. However,
uncommenting those lines is not clearly the right thing;
strcmp_match does *not* special case '/' characters, so those lines
will cause wildcards which match to match multiple times (in case
of subdirectories), and for their defaults to be merged multiple
times, an efficiency lose if nothing else.
The easiest fix is to revert to the way the NCSA code deals with
wildcards, which is to merge all of the matching wildcard entries
before doing the full directory walk and looking for exact matches...