On 3/30/2010 5:17 PM, Graham Leggett wrote: > 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.
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. >> 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. Trunk may be inconsistent with 2.2 branch, it frequently is. > 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. 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. 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. > 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. 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. > 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. And considering the raw volume of code I review at a glance and in depth, I certainly don't use them often, in fact the entire project doesn't use them often. The previous veto I saw was Lars' objection to allowing the ServerString to misrepresent Apache 'out off the box'. (Nobody objects to the user modifying the code and relabeling the program, of course). >> 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. You presume that all changes are suitable as-is? Horsepucky. The point to offering patches back is a convenience factor, of course. But the real reason to offer patches upstream is to improve them. Apache software is not about accepting all of the submissions offered, it is about collaborating to improve on the best of those submissions. Everyone wants to see their changes in 2.2.next, but that is unrealistic. It's enough that their changes hit trunk, to see the light of day in the next major release. The trick to manage users expectations is to deliver that next major version more than once every five years. >> 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. 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.
