Re: [vote] mod_ldap
Personally, I don't like httpd being a hostage of apr. If 2.4.x is such that using apr 2.x is precluded, so what? If apr 2.x becomes such a great thing, we create httpd 2.6.x.
Re: [vote] mod_ldap
On 07/07/2011 08:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2]) (binding both apr and mod_ldap to ldap libs) -1. OK for a hack, but not for a 2.4 release. Eat our own dogfood. Can we really request the usage of APR 2.0 during the lifetime of 2.4 and drop the possibility to use APR / APR-UTIL 1.x? APR 2.0 might contain changed API's such that existing 2.4 code and external modules code build for 2.4 does not run any longer. Wouldn't that violate our binary compatibility rules for the lifetime of a stable httpd version? Regards Rüdiger
Re: [vote] mod_ldap
On 13 Jul 2011, at 16:54, Ruediger Pluem wrote: On 07/07/2011 08:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2]) (binding both apr and mod_ldap to ldap libs) -1. OK for a hack, but not for a 2.4 release. Eat our own dogfood. Can we really request the usage of APR 2.0 during the lifetime of 2.4 and drop the possibility to use APR / APR-UTIL 1.x? APR 2.0 might contain changed API's such that existing 2.4 code and external modules code build for 2.4 does not run any longer. Wouldn't that violate our binary compatibility rules for the lifetime of a stable httpd version? I think we (including that vote) may have been at cross-purposes here. Subsequent discussion in various places leaves us with some plausible variants on that theme. I'd like to see 2.4 giving users the choice of APR version: 1.x or 2.0. I was voting against a (proposed) deliberate policy choice that would preclude using 2.0. I was not suggesting that we *require* 2.0 anytime in the foreseeable future! Having said that, it's been a while since I looked at the state of the build against different APR versions. Not been there since before LDAP blew up. -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: [vote] mod_ldap
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. 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. We are doomed to revisit this argument time and again if we avoid actually discussing the technical issues. Regards, Joe
Re: [vote] mod_ldap
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
Re: [vote] mod_ldap
On Tue, Jul 12, 2011 at 00:02, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... Which should be the combined revert of http://svn.apache.org/viewvc?view=revisionrevision=1143225 http://svn.apache.org/viewvc?view=revisionrevision=1143222 http://svn.apache.org/viewvc?view=revisionrevision=1143221 http://svn.apache.org/viewvc?view=revisionrevision=1141203 http://svn.apache.org/viewvc?view=revisionrevision=1141201 http://svn.apache.org/viewvc?view=revisionrevision=1140075 http://svn.apache.org/viewvc?view=revisionrevision=1140069 http://svn.apache.org/viewvc?view=revisionrevision=1130186 http://svn.apache.org/viewvc?view=revisionrevision=1131393 http://svn.apache.org/viewvc?view=revisionrevision=1129956 http://svn.apache.org/viewvc?view=revisionrevision=1129891 http://svn.apache.org/viewvc?view=revisionrevision=1129886 http://svn.apache.org/viewvc?view=revisionrevision=1129808 Sorry, I don't see applying a mega-revert. Either piecemeal or wholesale svn cp's from pre-1129808 seems more sensible. The later is more legible in svn, because re-applying the commits with proper attribution would be messy. 'svn cp' can be dangerous... you may wipe out other, unrelated changes. From a version control aspect, you also lose the information that the (above) revisions were reverse-merged (aka reverted). But I would simply state that is a pedantic detail, and the revert process should use whatever is easiest. If you go with 'svn cp', then just check the logs on the target files to ensure you don't lose unrelated changes. Cheers, -g
Re: [vote] mod_ldap
On 7/10/2011 5:34 PM, 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. So if I understand your statement, to examine a hypothetical case, it was entirely my choice to veto your request to deprecate mod_aspdotnet from the httpd project? (It was a suggestion I agreed with, but I do want to understand exactly your point here and it seems like a harmless example to discuss). This doesn't apply directly at httpd, but it would certainly be an interesting case to examine relative to the apr projects votes to drop a poorly supported and incomplete feature. One of the meta questions that comes out of this particularly lengthy thread is; what does any project do with code that would not obtain 3 +1's standing on its own? mod_aspdotnet had hit that point (no committer interest) and mod_ftp may very likely hit that point as well; mod_fcgid is just hanging on at this point with a small surplus. As such things become features of the meta-package (mod_fcgid is proposed for httpd trunk, so it's a good example) how is the desire for dozens of features by their individual authors balance with the fundamental consideration that all code should have three project members paying at least some oversight of it? If vetoes didn't purposefully exist to hang on to orphaned code by the choice of only a single champion, perhaps this general problem set needs to be reexamined? The voting rules seem largely a product of dealing with conflicting desires for adoption and evolution of code, but with coming up on 20 years of history, it is inevitable that httpd will face this issue again in the future.
Re: [vote] mod_ldap
On 7/12/2011 2:12 PM, Greg Stein wrote: On Tue, Jul 12, 2011 at 00:02, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... Which should be the combined revert of http://svn.apache.org/viewvc?view=revisionrevision=1143225 http://svn.apache.org/viewvc?view=revisionrevision=1143222 http://svn.apache.org/viewvc?view=revisionrevision=1143221 http://svn.apache.org/viewvc?view=revisionrevision=1141203 http://svn.apache.org/viewvc?view=revisionrevision=1141201 http://svn.apache.org/viewvc?view=revisionrevision=1140075 http://svn.apache.org/viewvc?view=revisionrevision=1140069 http://svn.apache.org/viewvc?view=revisionrevision=1130186 http://svn.apache.org/viewvc?view=revisionrevision=1131393 http://svn.apache.org/viewvc?view=revisionrevision=1129956 http://svn.apache.org/viewvc?view=revisionrevision=1129891 http://svn.apache.org/viewvc?view=revisionrevision=1129886 http://svn.apache.org/viewvc?view=revisionrevision=1129808 Sorry, I don't see applying a mega-revert. Either piecemeal or wholesale svn cp's from pre-1129808 seems more sensible. The later is more legible in svn, because re-applying the commits with proper attribution would be messy. 'svn cp' can be dangerous... you may wipe out other, unrelated changes. Absolutely, I understand that. Each specific unrelated change will be recommitted with all original attributions and svn references. The vast majority of commits are ldap changes. I will not be svn cp'ing the entire project, only targeted modules/ldap/ and specific include/ and build/ files. That's why I need reliable connectivity to apply this 'overwrite' back to the old state of svn, while preserving the changes to other parts of httpd/trunk/ From a version control aspect, you also lose the information that the (above) revisions were reverse-merged (aka reverted). But I would simply state that is a pedantic detail, and the revert process should use whatever is easiest. If you go with 'svn cp', then just check the logs on the target files to ensure you don't lose unrelated changes. +1, concur. Guenter et al, are the ldap changes more than 50% ldap changes, or fewer? I'd go with the path of least resistance on NWGNUxxx history.
Re: [vote] mod_ldap
On Monday 11 July 2011, William A. Rowe Jr. wrote: On 7/10/2011 5:34 PM, 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. I believe svn rm ... svn cp -r of the origin files to jump across the rejected patches is the most efficient and least confusing revert? Because of the other changes that we want to preserver, I think doing one big revert commit may be easier. The only complexity is to ensure configure.in/ or other peripheral changes are not lost. I have the cycles do this Tuesday, if not Monday. With a bit of git-foo, I have produced this: http://people.apache.org/~sf/revert_ldap.diff Which should be the combined revert of http://svn.apache.org/viewvc?view=revisionrevision=1143225 http://svn.apache.org/viewvc?view=revisionrevision=1143222 http://svn.apache.org/viewvc?view=revisionrevision=1143221 http://svn.apache.org/viewvc?view=revisionrevision=1141203 http://svn.apache.org/viewvc?view=revisionrevision=1141201 http://svn.apache.org/viewvc?view=revisionrevision=1140075 http://svn.apache.org/viewvc?view=revisionrevision=1140069 http://svn.apache.org/viewvc?view=revisionrevision=1130186 http://svn.apache.org/viewvc?view=revisionrevision=1131393 http://svn.apache.org/viewvc?view=revisionrevision=1129956 http://svn.apache.org/viewvc?view=revisionrevision=1129891 http://svn.apache.org/viewvc?view=revisionrevision=1129886 http://svn.apache.org/viewvc?view=revisionrevision=1129808 It builds for me with apr 1.x, but I haven't done any other checks or review. But maybe it is something you can build on. Especially r1142938 needs checking, I think I may have accidentally reverted some bits from that when resolving some conflicts. The concatenated original commits are at: http://people.apache.org/~sf/reverted_ldap_commits.txt And the separate reverts: http://people.apache.org/~sf/ldap_revert_commtis.txt
Re: [vote] mod_ldap
On 12.07.2011 00:35, Stefan Fritsch wrote: On Monday 11 July 2011, William A. Rowe Jr. wrote: On 7/10/2011 5:34 PM, Roy T. Fielding wrote: Especially r1142938 needs checking, I think I may have accidentally reverted some bits from that when resolving some conflicts. I can check and reapply where ncessary after the ldap revert. No problem. Regards, Rainer
Re: [vote] mod_ldap
On 7/11/2011 5:35 PM, Stefan Fritsch wrote: On Monday 11 July 2011, William A. Rowe Jr. wrote: On 7/10/2011 5:34 PM, 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. I believe svn rm ... svn cp -r of the origin files to jump across the rejected patches is the most efficient and least confusing revert? Because of the other changes that we want to preserver, I think doing one big revert commit may be easier. I will sandbox the state of trunk before committing, the files can always be svn cp'ed from sandbox to trunk when and if agreed upon. The only complexity is to ensure configure.in/ or other peripheral changes are not lost. I have the cycles do this Tuesday, if not Monday. With a bit of git-foo, I have produced this: http://people.apache.org/~sf/revert_ldap.diff Which should be the combined revert of http://svn.apache.org/viewvc?view=revisionrevision=1143225 http://svn.apache.org/viewvc?view=revisionrevision=1143222 http://svn.apache.org/viewvc?view=revisionrevision=1143221 http://svn.apache.org/viewvc?view=revisionrevision=1141203 http://svn.apache.org/viewvc?view=revisionrevision=1141201 http://svn.apache.org/viewvc?view=revisionrevision=1140075 http://svn.apache.org/viewvc?view=revisionrevision=1140069 http://svn.apache.org/viewvc?view=revisionrevision=1130186 http://svn.apache.org/viewvc?view=revisionrevision=1131393 http://svn.apache.org/viewvc?view=revisionrevision=1129956 http://svn.apache.org/viewvc?view=revisionrevision=1129891 http://svn.apache.org/viewvc?view=revisionrevision=1129886 http://svn.apache.org/viewvc?view=revisionrevision=1129808 Sorry, I don't see applying a mega-revert. Either piecemeal or wholesale svn cp's from pre-1129808 seems more sensible. The later is more legible in svn, because re-applying the commits with proper attribution would be messy.
Re: [vote] mod_ldap
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. Whatever it is we need to add to httpd in order to support compatibility with 2.2.x for some future version of APR, we can do so as specific fixes that solve a specific problem. If someone gets a brainstorm and comes up with a perfect LDAP API in the future, then the discussion can be revisited at that time. Roy
Re: [vote] mod_ldap
On 7/10/2011 5:34 PM, 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. I believe svn rm ... svn cp -r of the origin files to jump across the rejected patches is the most efficient and least confusing revert? The only complexity is to ensure configure.in/ or other peripheral changes are not lost. I have the cycles do this Tuesday, if not Monday.
Re: [vote] mod_ldap
On 07.07.2011 18:55, William A. Rowe Jr. wrote: Only presently available options are available as choices to end this now unproductive discussion [any heretofore unseen complete abstration of ldap cannot be considered with no patches offered]. This vote is limited to the scope of the httpd project and expresses a preference, there is no technical basis demonstrated to carry a veto. [X] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1
Re: [vote] mod_ldap
[ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1 (-0 at best on any of the others)
Re: [vote] mod_ldap
On 07 Jul 2011, at 6:55 PM, William A. Rowe Jr. wrote: Only presently available options are available as choices to end this now unproductive discussion [any heretofore unseen complete abstration of ldap cannot be considered with no patches offered]. This vote is limited to the scope of the httpd project and expresses a preference, there is no technical basis demonstrated to carry a veto. Five weeks ago you unilaterally chose the following option despite being warned at the time on dev@apr that it would be vetoed: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) Calling for a vote 5 weeks later in an attempt to legitimise your action does not get around the rules of veto, which are No veto can be overruled[1]. This vote is void. [1] http://httpd.apache.org/dev/guidelines.html [2] vote thread removing ldap from apr-2.x; http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3c4bd46614.6010...@rowe-clan.net%3E This statement is misleading, I ask that people follow this link to see for themselves. This vote thread called for Abandon apr_ldap_* API's to httpd 2.3 ldap, including required autoconf, not the removal of ldap from apr- v2.x. This issue was not brought to the attention of the dev@httpd list, nor was dev@httpd invited to vote on it, and therefore this vote too is void. Regards, Graham --
Re: [vote] mod_ldap
On Thu, Jul 7, 2011 at 12:55 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Only presently available options are available as choices to end this now unproductive discussion [any heretofore unseen complete abstration of ldap cannot be considered with no patches offered]. This vote is limited to the scope of the httpd project and expresses a preference, there is no technical basis demonstrated to carry a veto. [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) yes, unless I misunderstood option #3 [ ] Move ap_ldap API's to the core (binding both httpd and mod_ldap to ldap libs) no [ ] Move ap_ldap API's to yet another mod_ldaps[1] module (binding both mod_ldap and mod_ldaps to ldap libs) IIUC, the only benefit (and a great one) to yet another ldap shared library (whether mod_foo or in apr) is if there is a complete abstraction, such that only one shared library binds to libldap* and that one shared library can be switched out to switch client libraries and libldap* symbol use doesn't leak between different functional areas. Is there some other possibility? [ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2]) (binding both apr and mod_ldap to ldap libs) no [ ] Remove mod_authnz_ldap / mod_ldap from httpd 2.3 no [1] other name suggestions are welcome [2] vote thread removing ldap from apr-2.x; http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3c4bd46614.6010...@rowe-clan.net%3E http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%3caanlktinkzmdybxo2vggzloxpy72mh0orek-kuesgj...@mail.gmail.com%3E -- Born in Roswell... married an alien...
Re: [vote] mod_ldap
On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. [ ] Move ap_ldap API's to the core (binding both httpd and mod_ldap to ldap libs) Clear -1. [ ] Move ap_ldap API's to yet another mod_ldaps[1] module (binding both mod_ldap and mod_ldaps to ldap libs) -0. KISS. [ ] Revert to using apr_ldap (restricting mod_ldap to apr-util 1.x [2]) (binding both apr and mod_ldap to ldap libs) -1. OK for a hack, but not for a 2.4 release. Eat our own dogfood. [ ] Remove mod_authnz_ldap / mod_ldap from httpd 2.3 -1. Not an acceptable regression from 2.2. -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
Re: [vote] mod_ldap
On Jul 7, 2011, at 2:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. +1
Re: [vote] mod_ldap
On 07 Jul 2011, at 10:51 PM, Jim Jagielski wrote: On Jul 7, 2011, at 2:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. +1 +1. Regards, Graham --
Re: [vote] mod_ldap
On 7/7/2011 5:16 PM, Graham Leggett wrote: On 07 Jul 2011, at 10:51 PM, Jim Jagielski wrote: On Jul 7, 2011, at 2:44 PM, Nick Kew wrote: On 7 Jul 2011, at 17:55, William A. Rowe Jr. wrote: [ ] Retain ap_ldap API's in httpd 2.3 mod_ldap, as currently in trunk (binding mod_ldap to ldap libs) +1. But get it right: not a botch job just because there's pressure to release. Should really have been alpha rather than beta when this blew up, but too late to change that. +1 +1. +1 Since it's being pulled from APR, this is the most sane place to put it in order to maintain the functionality for httpd. -- -- Daniel Ruggeri
