Limited connectivity
Just to let folks know, I won't be able to roll back our patches and sandbox them until I have something resembling stable connectivity, and it may be a day or two before that happens.
Re: [vote] mod_ldap
Bill, Am 13.07.2011 02:20, schrieb William A. Rowe Jr.: +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. I think the only part to be reverted is the copy of ap_ldap.hnw in ./build/NWGNUmakefile, everything else what I committed was to fix macro redefs on Win32 / NetWare -- if you revert the code to the state before your ldap modifications they should be gone; if some of these problems remain I can easily apply again, no prob ... Gün.
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. > wrote: >> ... >>> Which should be the combined revert of >>> >>> http://svn.apache.org/viewvc?view=revision&revision=1143225 >>> http://svn.apache.org/viewvc?view=revision&revision=1143222 >>> http://svn.apache.org/viewvc?view=revision&revision=1143221 >>> http://svn.apache.org/viewvc?view=revision&revision=1141203 >>> http://svn.apache.org/viewvc?view=revision&revision=1141201 >>> http://svn.apache.org/viewvc?view=revision&revision=1140075 >>> http://svn.apache.org/viewvc?view=revision&revision=1140069 >>> http://svn.apache.org/viewvc?view=revision&revision=1130186 >>> http://svn.apache.org/viewvc?view=revision&revision=1131393 >>> http://svn.apache.org/viewvc?view=revision&revision=1129956 >>> http://svn.apache.org/viewvc?view=revision&revision=1129891 >>> http://svn.apache.org/viewvc?view=revision&revision=1129886 >>> http://svn.apache.org/viewvc?view=revision&revision=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 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 Tue, Jul 12, 2011 at 00:02, William A. Rowe Jr. wrote: >... >> Which should be the combined revert of >> >> http://svn.apache.org/viewvc?view=revision&revision=1143225 >> http://svn.apache.org/viewvc?view=revision&revision=1143222 >> http://svn.apache.org/viewvc?view=revision&revision=1143221 >> http://svn.apache.org/viewvc?view=revision&revision=1141203 >> http://svn.apache.org/viewvc?view=revision&revision=1141201 >> http://svn.apache.org/viewvc?view=revision&revision=1140075 >> http://svn.apache.org/viewvc?view=revision&revision=1140069 >> http://svn.apache.org/viewvc?view=revision&revision=1130186 >> http://svn.apache.org/viewvc?view=revision&revision=1131393 >> http://svn.apache.org/viewvc?view=revision&revision=1129956 >> http://svn.apache.org/viewvc?view=revision&revision=1129891 >> http://svn.apache.org/viewvc?view=revision&revision=1129886 >> http://svn.apache.org/viewvc?view=revision&revision=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 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: svn commit: r1145647 - /httpd/httpd/trunk/modules/arch/win32/mod_win32.c
Am 12.07.2011 18:13, schrieb fua...@apache.org:
Author: fuankg
Date: Tue Jul 12 16:13:28 2011
New Revision: 1145647
URL: http://svn.apache.org/viewvc?rev=1145647&view=rev
Log:
Fixed some more env vars which make problems.
This fix is based on BZ 13029 / 34985, and includes
now the SSL_ and GEOIP_ vars; otherwise its impossible
to run CGIs when mod_ssl and/or mod_geoip are loaded
and those mods return UTF-8 chars in any var during a
request.
Modified:
httpd/httpd/trunk/modules/arch/win32/mod_win32.c
Modified: httpd/httpd/trunk/modules/arch/win32/mod_win32.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/arch/win32/mod_win32.c?rev=1145647&r1=1145646&r2=1145647&view=diff
==
--- httpd/httpd/trunk/modules/arch/win32/mod_win32.c (original)
+++ httpd/httpd/trunk/modules/arch/win32/mod_win32.c Tue Jul 12 16:13:28 2011
@@ -528,9 +528,10 @@ static apr_status_t ap_cgi_build_command
&& (strncmp(elts[i].key, "HTTP_", 5) == 0
|| strncmp(elts[i].key, "SERVER_", 7) == 0
|| strncmp(elts[i].key, "REQUEST_", 8) == 0
- || strcmp(elts[i].key, "QUERY_STRING") == 0
- || strcmp(elts[i].key, "PATH_INFO") == 0
- || strcmp(elts[i].key, "PATH_TRANSLATED") == 0)) {
+ || strncmp(elts[i].key, "PATH_", 5) == 0
+ || strncmp(elts[i].key, "SSL_", 4) == 0
+ || strncmp(elts[i].key, "GEOIP_", 6) == 0
+ || strcmp(elts[i].key, "QUERY_STRING") == 0)) {
prep_string((const char**)&elts[i].val, r->pool);
}
}
Just looked again at this, and instead of adding more and more vars to
this list we should probably do the opposite: just check for those where
we know for sure they will never hold UTF-8 chars like REMOTE_,
GATEWAY_INTERFACE, REQUEST_METHOD, SERVER_ADDR, SERVER_PORT,
SERVER_PROTOCOL, and fixup all others; otherwise this issue will pop up
again sooner or later with other 3rd-party mods like I faced now already
with mod_geoip ...
Comments?
Gün.
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
