On 30 Mar 2010, at 3:34 AM, William A. Rowe Jr. wrote:
In what universe does the suggestion that path wildcards must
correspond
to at least one existing path diverge from the allowance that the
path(s)
need not contain one existing file? Two separate issues, one veto.
In your universe, you were arguing for this very thing:
"The gist of my objection is this illegitimate behavior;
Include conf/extra/*.duh
Include conf/extra/*/doh.conf
Include conf/empty/*
Include conf/*/whoops.conf
The last one (based on an existing conf/empty directive) fails,
alerting the admin
to the fact that they made a typo, which is good.
The others all fail-to-fail with this logic [based on the absence of
any matching
directories in the extra/ folder]. That's unacceptable."
It was a perfectly valid objection, based on the principle of least
surprise. Then when it was discovered that options 1 and 3 currently
pass today and have done for a long time, you changed your mind and
decided that only options 2 and 4 should fail, and that it was
suddenly ok to be inconsistent, contradicting yourself. Please make up
your mind.
I'm sorry you don't support my -1, but am done with your handwaving
about
whether the the veto is valid, or not. It is, and your
protestations don't
invalidate it.
Of course my protestations don't invalidate it, your inconsistent
technical justification invalidates it.
In theory, vetos are really cheap. They take zero effort to make, and
all they take to enforce are to to engage in a Monty Python style yes-
it-is-no-it-isn't argument until the other side gets fed up and
withdraws their contribution. The person with the veto wins, the
project loses the contribution.
In practice, vetos are very very expensive.
They discourage end users from contributing to the project, because
why should they bother spending their free time and effort when there
is a very real risk that someone will arbitrarily object and then
instead of agreeing to disagree, will happily obstruct progress using
a veto on the issue to the detriment of end users.
They discourage reviewers from reviewing backports, because why should
they go to the effort of picking through patches, applying them,
compiling code, running test suites and code and editing
documentation, and then finally to promote the patch, only to have
somebody eventually wake up and yank it out again, forcing everyone to
start the process all over again.
Vetos should be used *very* sparingly, and as an absolute last resort
to a problem, in recognition of the cost associated with them. It
should be far more common for members of a project to simply agree to
disagree and let consensus decide than it is for people to veto
anything.
Then they are welcome to use a patched version of httpd; this is the
advantage of open source.
Months and months of work by various ASF members convincing people in
this particular organisation that it is a good idea to pass their
changes upstream to the original project instead of hiding their code
in silos, and now they're told "you can just do what you've been doing
all along, keep your changes to yourself". Thanks for the help Bill.
Anyone can use whatever code they like whether
they agree with the 'released' version, or not. There is a solution
on
the table which could satisfy everyone, allowing a missing explicit
file,
or file pattern, or directory pattern to match nothing - while
making no
change in 2.2 to the Include behavior of allowing file patterns to not
match once the directory pattern has matched.
No, there isn't a solution on the table, I should know, all the
solutions we're discussing were written by, tested by, and documented
by me.
Now there is. Following my own advice I withdraw my veto over the
inconsistent Include behaviour that you want as it is better for end
users for us to agree to disagree. I've documented this behaviour
clearly for end users, and provided both an "Include optional path"
and "Include strict path" option for those users who require
consistent behaviour one way or the other.
Your objection is now resolved in r929318.
Regards,
Graham
--
