On 31 Mar 2010, at 2:33 AM, William A. Rowe Jr. wrote:
On 2.2 branch, we are hamstrung by the stable shipping behavior, you
are
right that we cann only fail 2 and 4.
On trunk, all of these can fail by default, unless a permissive
directive
is used to indicate the config author believes they know what they are
doing, and accepts the consequences of chasing down their own typos if
things just 'don't happen' when they change the mis-directed config.
No Bill, this is not how things are done.
You have just argued above for a brand new feature - a change to the
behaviour of wildcard support in httpd. Ordinarily, one would propose
this new feature on this list as a single issue and ask the rest of us
for comments. Or you might have even patched trunk, and used that as a
basis for the discussion over whether such a change was warranted. You
would have provided evidence of problems encountered by people making
typos by pointing out threads on the user's mailing list, you could
have even just told us "I help lots of people who make these typos,
and they really need to be helped" and we would have believed you.
But you didn't do that. You took an entirely unrelated feature, the
extension of wildcard support to directories in addition to files, a
feature that had been explicitly approved by three people as per the
long standing voting rules of this project, and you vetoed it, on the
basis that somebody else's work didn't have your unrelated change
built into it. Did you propose or discuss your unrelated change on the
list beforehand? No. Did you respect the opinions of the three people
who were happy with this change? No. Did you provide any evidence that
your feature was even necessary? No. Did you provide your own patch,
implementing the change you wanted? No. You went straight for the
veto, do not pass go, not not collect 200 pounds. You were so
confident in your veto that you didn't even stop to check if your veto
had hit the list (it hadn't, thanks to dodgy mail clients).
Seriously, this kind of thing has got to stop.
Yes, we've all seen vetoes thrown around without any explanation,
without
the author willing to revisit, refine and reclarify the objection,
in light
of additional information. You and I did refine and reclarify this
veto,
many times, in the process. In the end, we were able to refine a
solution
without having to go to the extreme of a F2F powwow. That's a
positive.
No Bill, I refined the solution. I provided the patch, I provided the
documentation, and I provided most of my saturday, a lot of my sunday,
and my whole monday night and tuesday night trying to make sure that a
problem that has negatively affected a large number of people stayed
solved. You provided the whip, and undid most of the work by backing
out an approved backport, that was pretty much it.
And yes, the project is more than willing to lose contributions
which are
not thought out; we do so frequently if the bugzilla
'PatchAvailable' tag
is a measure of which patches are 'interesting'. The difference is
the
disagreement between an arbitrary contributor v.s. a committer.
No, we lose patches because of limited time from limited committers.
Do not underestimate or try to downplay the importance of a patch from
an arbitrary contributer. They've spent their own time and effort
formulating the patch, contributing it to us, justifying its
inclusion, and our license obliges nobody to do that.
Encourage arbitrary contributers by respecting the work they put in
and they become regular contributers, and then they become committers,
and then members.
Your definition of progress isn't necessarily my definition, or
Paul's or
Jim's or Ruediger's. Each committer is here looking at the code
from their
own perspective, and I hold the greatest respect for the committers
who
clearly are looking out for the interests of several groups of users
at
once, not the committers who might be here to advance only their own
agenda.
In other words, TMTOWTDI, most of the time, and collaboration means
moving
forwards to let as many improvements in that don't disrupt other
groups of
users or developers.
I honestly couldn't care in the slightest which committer has
contributed what, or what their agenda is, all I care about is whether
a contribution adds value to the project on a case by case basis, and
whether the lives of webmasters and end users are made more pleasant
as a result.
I have the greatest respect for the committers who have stuck around
and do actual work, and that includes you Bill, and is why we're
having this discussion.
Currently it is my agenda to take the inhouse experience of one of the
world's biggest media organisations whose average daily traffic
pattern would be described as a "distributed denial of service attack"
by everyone else, and share that experience with other users of the
httpd server. It also happens to be the agenda of a number of other
ASF members working for the same organisation.
Given the number of people who want to build "fast" webservers these
days, I am focusing on making sure there are still "reliable"
webservers available in the market, of which httpd is arguably still
the best example to date.
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.
You presume that all changes are suitable as-is?
No, I presume that changes will be suitably peer reviewed by other
members of this project, commented on and changed as appropriate, and
if proposed for backport agreed upon by at least three of the
project's members, in the way that is has always been, or at least how
it's been during the decade-and-a-bit I've been contributing patches
to this project. I do not presume that changes will be stomped on and
killed through misuse of the veto mechanism.
Include strict path is an improvement in 2.2, yes, although one that
will go
away in trunk (since all Include statements should find some file to
Include,
unless the clever/attentive adminstrator tags them 'optional'). I
suspect
that an IncludeOptional directive is more efficient, I'm happy to
offer the
patch to your patch after I svn revert my local code changes. The
cost of
another hashed directive is less expensive than parsing for multiple
args.
Either is as easy as the other, I implemented both in the last few
days. And I don't mind whatever feature you put in, as long as I and
everyone else has the option to switch it off.
Regards,
Graham
--
