On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: > On 2/29/2012 6:25 PM, Roy T. Fielding wrote: >> On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: >>> >>> Let's take Roy's position on the attached vote discussion, it's relevant. >>> These new modules are certainly additions/deletions to httpd. >> >> Yes, but they are modules. Hence, their mere existence in our tree >> is not a technical reason to exclude them. We have a modular architecture >> so that people who don't want a module don't have to build it. In fact, >> it was exactly this type of argument in 1995 that caused rst to focus >> on creating a modular architecture. > > Ok, so to clarify, you are reversing your answer to Joe? The LDAP changes > were a change to a module. Not an httpd-wide API, just a module. So you > are saying that your comment to Joe, "The API was moved to *this* project > and all of the names were changed. It is, effectively, a new public API > for this project." was a misinformed statement (as it moved the ldap code > into mod_ldap and not into the core API). That veto was unjustified? > > Or rather, had we not exported a single symbol, then the veto was unjustified?
I don't remember the details, but it was presented by you as a new API. It was described by you as the addition of new LDAP libraries to httpd. And it was most certainly a change to the existing code in mod_ldap. Had it been presented as a new module with a new name and optional configuration, I would have said new modules only need one committer to maintain and a majority vote to decide if there is any objections. Quite frankly, I don't care either way for either change. What I care about is continual use of procedural bullshit to justify interference with other people scratching their own itches. If you don't like the module, then don't use it. If it has security holes or licensing issues, then those are grounds for a veto. If you don't like Grahams's attitude, that's too frigging bad -- find another way to vent your frustration or try to resolve it via the PMC, but don't mix it with a technical vote. >> If there were dependencies or license conditions brought in that somehow >> harmed the server without the module being active, then that would be a >> technical objection. > > There was no such case for the ldap change, so you are saying that specific > veto was unjustified, right? Anyways, all of this is distraction, let's > drill in further to your analysis; > >> Traditionally, we have allowed any module that has at least one willing >> volunteer committer to maintain it. And I agree with Jim, none of the >> subprojects have been as successful as just placing the code in the >> main tree. > > Allowed it by... voting to accept it, right? I accept that all of my > colleagues have different rationals for their +/- votes. Right now, just > about 3% of the committee are willing to entertain these module additions > to httpd trunk and 1.5% are against adding these to trunk. I chalk this > up to burnout, 2.4 was very complex to release and people know their +1 > votes are commitments and alter the httpd tarball for better or worse. If a vote is required (i.e., anyone objects), then it is a majority vote with minimal quorum (three +1s), as usual. > If there was a vote to add this module to core, that would be lovely, we > could vote on it. Sadly, minfrin offered no such vote, and whatever your > conclusion on the 'better course' - it was not voted on, and you hadn't > expressed a vote to adopt it in either case. I submit that there was confusion and the right thing to do would be to ask politely for the confusion to be resolved by an actual vote. It would help if you were not being an ass about it and randomly accusing people of nefarious behavior just because they don't give a damn about this particular difference of opinion. And it isn't Graham's responsibility to run the vote. >> I have no idea why mod_fcgi is in a subproject. mod_ftp is there >> because it isn't an HTTP server. mod_aspdotnet had all sorts of >> licensing issues that I never quite figured out. > > Nonsequitor, if we want to launch into a discussion of subprojects vs. > modules, that's great. That wasn't the conversation minfrin started, > and that's why I have a VETO on the commit. Correct the mis-execution > by conforming to the vote he held, or correct the vote instead. I've > VETOED a commit which is something other than what was voted on because > the project did not consent to his action. You are confused. You don't need to veto a non-event -- just conduct the vote properly and be done. > If there are two other committers who will vote with Jim for this > project to accept one or more of these modules into trunk (rather than > subproject), and someone will finish the ip-clearance, I'm great with > that. If none of that happens I will revert this mess. Fine with me, if you stop blathering about it and conduct the vote properly. You know how to conduct a vote. >> I see no reason not to commit mod_firehose, though I haven't had a >> chance to look at the code myself. > > mod_firehose is already [erroniously] committed without ip-clearance. > Only Jim agrees with minfrin that it belongs in trunk. If YOU want to > vote for it to be in trunk, do that. So far, it was accepted by this > project only as an additional subproject. > > Only you and Jim are defending this addition without ip-clearance. > Perhaps you are signing up to do that ip-clearance, since it doesn't > seem to be coming from the committer. IP clearance for an existing committer is BULLSHIT. I already cleared that with Legal when I was chair of this project. > I've voted against mod_policy and mod_combine until this mess is resolved. > With sufficient +1's I would have withdrawn all objections, but right now > I smell a code dump, and see nobody but Jim disagreeing with me. > >> Nor am I willing to respect a veto war based on the impact of past vetos. > > No, it's not a veto war. Only Jim has volunteered to maintain this code > (or agreed to help minfrin do so). Right now minfrin blocks correcting > mod_ldap, insists it's his project to finish his way, which hurts this > project. So his assurance that he should "my intention is to continue to > develop and support this" rings hollow. That is the ONLY relationship > to the other veto I had quoted your opinion on, other than to point out > that vetos are legitimate. Any assurance that he should be a sole > maintainer of not one but three+ more httpd module additions seems foolish. That is your opinion. It counts as a -1 (non veto). >> Now, if you'll excuse me, I have at least two other walls to bang >> my head on today ... > > Enjoy, I could certainly be wasting my time on better things as well. Equally painful, not better. > Unfortunately httpd got to its pre-2.4 state because there are so few > committers who are actually reviewing one another's contributions. > Throwing gunk into trunk doesn't help prevent it from happening again. Not throwing gunk into trunk is worse. > Perhaps the threat of releasing 2.6 / 3.0 this coming November might > keep trunk from atrophying into a similar state, once again? Why wait until November? ....Roy
