Re: Technical reasons for -1 votes (?)
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? 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. As Jim points out, The fact is that once a project lives under the main tree, it's part of our shared project is dead to right. Jim alone is voting with minfrin to support these living in that shared tree, and only I vote that we don't, at this time, until there are more committers who are willing to share Jim's position. 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 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. 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. 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. 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. Now, if you'll excuse me, I have at least two other
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012 12:20 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... 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. I support Jim. +1
Re: Technical reasons for -1 votes (?)
On 2/29/2012 6:25 PM, Roy T. Fielding wrote: 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. Which explains mod_macro how, exactly?
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: 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. Which explains mod_macro how, exactly? At this point, my head exploded Scanners-like...
Re: Technical reasons for -1 votes (?)
On 3/1/2012 1:58 PM, Jim Jagielski wrote: On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: 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. Which explains mod_macro how, exactly? At this point, my head exploded Scanners-like... Funny, mine had exploded at the dis-congruity of; mod_ftp is there because it isn't an HTTP server. which is apropos of what? This isn't an ajp or scgi or fastcgi server either, it's an http server, which means we should pull out those interfaces?
Re: Technical reasons for -1 votes (?)
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
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 12:28 PM, William A. Rowe Jr. wrote: On 3/1/2012 1:58 PM, Jim Jagielski wrote: On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: 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. Which explains mod_macro how, exactly? At this point, my head exploded Scanners-like... Funny, mine had exploded at the dis-congruity of; mod_ftp is there because it isn't an HTTP server. which is apropos of what? It is a different product. If it were changed so that it could be meaningfully documented as part of the HTTP server, then I'd suggest it be moved to trunk too. This isn't an ajp or scgi or fastcgi server either, it's an http server, which means we should pull out those interfaces? Those are all gateway interfaces *used* by an HTTP server to communicate with a backend. If we had a better way to ship modular code, like CPAN or gem, they wouldn't be part of our core product. But we don't, so they are (or should be). Roy
Re: Technical reasons for -1 votes (?)
On 3/1/2012 4:17 PM, Roy T. Fielding wrote: On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: 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. Roy, I'm sorry. Obviously I miscommunicated. It was a former API. The proposal was to fold that behavior into a single self-contained module. I will present this in the coming month in a manner that conforms to your understanding of a module vs. an API, such that no individual can veto it, and the dozen+ of us can vote for it and be forever rid of the garbage former-API constraint, ignoring those crazy voices from the wilderness. If a vote is required (i.e., anyone objects), then it is a majority vote with minimal quorum (three +1s), as usual. That's the page I started on, thanks for confirming! These modules did NOT have majorities for inclusion in trunk. Tonight, one finally does. I never believed I had a veto, only 1 vote against blind implied consent. 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. Ah, but you see, that's the rub. There WAS a vote. A proposal was made by Graham, a vote was held by Graham, and a DIFFERENT course of action was followed by Graham. Amazingly, Graham ran the successful vote, for an altogether different outcome. That is what is objectionable; if there is anything in the past months demonstrates psychotic behavior, it is not my objections to what had transpired, but what actually transpired. Quoting the private list, where there is to be no development discussion (so ergo these comments cannot be confidential); On 12/8/2011 7:40 AM, Graham Leggett wrote: On 08 Dec 2011, at 3:30 PM, William A. Rowe Jr. wrote: But I think we are saying the same thing... I just wanted to be sure this was understood as [poll] Potential Adoption of... and not something actually adopted as in your message subject. The word proposal means exactly that, and I haven't seen any misunderstanding so far from anybody. at which point, the entire discussion went sideways once Graham adopted the input of private@ development discussion into his next actions. As the Chief Agent and Advocate against dev discussions happening in private off of the dev list, I'm relying on you personally to ensure this doesn't reoccur.
Technical reasons for -1 votes (?)
On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd. It is crystal clear that a veto is valid. It is incumbent upon the coder who makes a proposal to overcome objections. In this previous vote, some dozen developers failed to make that case to Graham, and his veto stood. Now Graham comes to the project with three modules and a hope that this isn't a code dump, my intention is to continue to develop and support this moving forward, and hopefully expand the community around them. He said the same thing about completing the LDAP abstraction half a decade ago or more. Attempts to route around his failure were unsuccessful because of his obstructionism. We are at a design impass with the community blocked on some handwave and a commitment to redesign an api someday, but likely never. Nothing can be allowed in core on some hope of expanding a community. Either there is collaboration and the code belongs at httpd, or there is not collaboration and the code does not. There are sandboxes and there are subprojects to begin that justification. Graham was offered that resolution which HE originally proposed, and for two months, has refused to act or acknowledge the demand that he revert his misfiled contribution. My veto to all three modules stands. If three committers with track records of collaboration (meaning most everyone else here) step up with +1 votes that includes their commitment to review and maintain one of these modules, seek the software license grant, and to file the ip-clearance with general@incubator, I'm willing to relax my veto on creating that subproject. But not into a core module until the subproject is successful. ---BeginMessage--- On Jul 12, 2011, at 8:20 AM, Joe Orton wrote: On Sun, Jul 10, 2011 at 03:34:10PM -0700, Roy T. Fielding wrote: Regardless of anyone else's opinion, the addition or deletion of a new API to our product is a technical change that can be vetoed. Likewise, the API being an incomplete abstraction that isn't needed in httpd is a valid technical reason to veto it even if it had once been in apr-util. Other than the convoluted history of this particular argument, I don't see any reason for further frustration. Revert the commit. Yet again: if the objection is to extending the exported mod_ldap API, that objection can be resolved without wholesale revert; most of the stuff added does not need to be exposed in the API, it was just done for consistency. The objection can only be resolved by convincing the person who has objected to change *their* opinion or by removing the thing being objected to. The time for convincing has expired -- let's move on. I do not understand using incomplete abstraction as motivation for veto, because mod_ldap's API was already an incomplete abstraction. If this was OK before, it is not reason for veto now. The API was moved to *this* project and all of the names were changed. It is, effectively, a new public API for this project. We are doomed to revisit this argument time and again if we avoid actually discussing the technical issues. The whole point of having a set of voting guidelines is to avoid having a discussion about process which is colored by the particular issue being discussed and to avoid having discussions about technical issues which become poisoned because of perceived unfairness in the way people's opinions are being respected. Remove the process issue first and then the technical issues can be resolved one at a time as technical issues. Roy ---End Message---
Re: Technical reasons for -1 votes (?)
Wow... As far as I can tell, we have *never* been so tight arsed with anything else: not mod_proxy_html, mod_sed, mod_rewrite, mod_dumpio, mod_substitute, (add your favorite one here)... And especially not with someone who's been a PMC member for as long as Graham has (~10yrs). I reiterate my +1s for accepting the code and stress that my preference is right in the main tree. On Feb 29, 2012, at 12:42 PM, William A. Rowe Jr. wrote: On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd. It is crystal clear that a veto is valid. It is incumbent upon the coder who makes a proposal to overcome objections. In this previous vote, some dozen developers failed to make that case to Graham, and his veto stood. Now Graham comes to the project with three modules and a hope that this isn't a code dump, my intention is to continue to develop and support this moving forward, and hopefully expand the community around them. He said the same thing about completing the LDAP abstraction half a decade ago or more. Attempts to route around his failure were unsuccessful because of his obstructionism. We are at a design impass with the community blocked on some handwave and a commitment to redesign an api someday, but likely never. Nothing can be allowed in core on some hope of expanding a community. Either there is collaboration and the code belongs at httpd, or there is not collaboration and the code does not. There are sandboxes and there are subprojects to begin that justification. Graham was offered that resolution which HE originally proposed, and for two months, has refused to act or acknowledge the demand that he revert his misfiled contribution. My veto to all three modules stands. If three committers with track records of collaboration (meaning most everyone else here) step up with +1 votes that includes their commitment to review and maintain one of these modules, seek the software license grant, and to file the ip-clearance with general@incubator, I'm willing to relax my veto on creating that subproject. But not into a core module until the subproject is successful. Attached Message.eml
Re: Technical reasons for -1 votes (?)
On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: On 2/29/2012 8:59 AM, André Malo wrote: On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote: I withdraw this vote, reverting my position to -1, until collaboration and respect for options and insights of fellow committers as well as project decisions and votes can be consistently demonstrated. I always thought, you'd have to provide technical reasons for -1 votes (?). 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. 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. 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. 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. I see no reason not to commit mod_firehose, though I haven't had a chance to look at the code myself. Nor am I willing to respect a veto war based on the impact of past vetos. Now, if you'll excuse me, I have at least two other walls to bang my head on today ... Roy
