svn commit: r105933 - httpd/mod_aspdotnet/trunk
Author: wrowe Date: Fri Nov 19 20:15:52 2004 New Revision: 105933 Modified: httpd/mod_aspdotnet/trunk/README.txt Log: Remove the blank line to test that mod_aspdotnet now notifies [EMAIL PROTECTED] Modified: httpd/mod_aspdotnet/trunk/README.txt == --- httpd/mod_aspdotnet/trunk/README.txt(original) +++ httpd/mod_aspdotnet/trunk/README.txtFri Nov 19 20:15:52 2004 @@ -2,7 +2,6 @@ --- - Build Notes ---
svn commit: r105925 - in httpd/mod_aspdotnet: branches tags
Author: wrowe Date: Fri Nov 19 19:08:35 2004 New Revision: 105925 Added: httpd/mod_aspdotnet/branches/ httpd/mod_aspdotnet/tags/ Log: Create new tags and branches structure
Re: 2.1.1 tarballs posted...
--On Saturday, November 20, 2004 1:49 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Back up. Nothing is a release, not even an alpha, without 3 +1's. Until it's voted as a release, even as alpha, it's simply a tarball. Nobody can declare any release without 3 +1's and it's been that way for about 7 years. No. That's not the case with unstable versions (version numbers are cheap). We operated under these rules - immediately going to alpha at RM's discretion - until we went to GA for 2.0. I swear I'm not making these rules up. I'm fine if you want to propose new rules, but releasing as alpha immediately after a tarball/tag is created *is* what we did before... -- justin
Re: 2.1.1 tarballs posted...
--On Saturday, November 20, 2004 2:35 AM -0500 Cliff Woolley [EMAIL PROTECTED] wrote: Consensus at the conference was that the branch point corresponds to the 2.1.x release upon which we declare feature freeze for the 2.2 branch. My concern with this is that if we're waiting for one small feature (say, 'group hooks'), we now have to deal with all sorts of churn in the trunk because we're waiting for that feature to land to branch. That is less than optimal, IMHO. I'd rather branch sooner than later so that we don't have to deal with stabilizing the branch with all sorts of unwanted changes later. -- justin
Re: CVS to SVN conversion
On Fri, Nov 19, 2004 at 10:41:38AM -0500, Jim Jagielski wrote: I would like to publicly THANK Sander and Justin for their tireless (well, not literally tireless, because they worked so long that they were *very* tired) work in doing the conversion! I think during AC2004 everyone settled their beer scores, but Sander and Justin *definitely* are once again in the I owe you category :) I want to second that too. The difference it makes to be able to svn diff and svn st without sending packets round the world a few times is just immense, it really makes the development process more enjoyable. Thank you thank you thank you! joe
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: I don't believe that Allen would be able to complete his changes in a reasonable timeframe. I'm tired of holding things up for a 'major' rewrite that'll come any day now (TM). Sorry. I'd be willing to give him a week or two to make the changes everywhere he needs to, but even then it'd be hard for all of us to review such a major change. I'm in favor of releasing httpd 2.1 as 2.2 almost as-is with some relatively minor things thrown in (say the config re-org changes and the group hooks). However, trying to fix the 64-bit issues in a 2.2 (and with an APR 2.0) at this late state would make it really hard for our module writers to adopt 2.2 in a timely manner. So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. For module writers it's not a big deal, but for commercial 3rd party modules it might be. Simply because they would need to produce yet another version of their modules for httpd. Recall how long it took for some 1.3 modules to be ported to 2.0? With 2.2 they will now need to port to 2.2, which obviously is trivially easier than going from 1.3-2.0. But there will be delay. If we then produce another 2.x which isn't binary compatible, then it's another process and the module list will start looking quite crowded: 1.3 2.0 2.2 (non-64) 2.x (64) That's a lot of modules for companies to worry about. No, I don't have the answer but we should be prepared for the uptake of 2.2 to be less than we hope or imagine. This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. We've been operating on a pull me scenario, and it's worked, but it's been hardly optimal. Maybe some sort of push mechanism would be useful. Even if it's just a blurb on the site that Apache 2.2 will be released soon, here is the new API (which is frozen), if you plan to have your Apache modules ready for 2.2 when released, please grab this tarball and test. In many, many ways the success of httpd depends on the availability of its modules.
Re: svn error: unknown node kind
* André Malo [EMAIL PROTECTED] wrote: While running my script to adjust the docs revision references, I'm getting an error, while retrieving a property: svn propget cvs2svn:cvs-rev -r 103423 \ https://svn.apache.org/repos/asf/httpd/httpd/trunk/manual/mod/mod_authz_default.xml Never mind, it's the wrong URL :-( nd -- Solides und umfangreiches Buch -- aus einer Rezension http://pub.perlig.de/books.html#apache2
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. It does - that's the rub. And, for 2.2, this was always the plan. For module writers it's not a big deal, but for commercial 3rd party modules it might be. Simply because they would need to produce yet another version of their modules for httpd. They will. Implicit in the '2.0 isn't a moving target' comes the correlary '2.1-dev is a moving target, and once we get it right, it will be 2.2 and quit shifting the API beneath you.' Recall how long it took for some 1.3 modules to be ported to 2.0? With 2.2 they will now need to port to 2.2, which obviously is trivially easier than going from 1.3-2.0. Yes - though there will be api changes as well. We obviously need to move beyond APR 0.9 - either to 1.x or (if we have to fix the API) to 2.x. But there will be delay. If we then produce another 2.x which isn't binary compatible, then it's another process and the module list will start looking quite crowded [...] That's a lot of modules for companies to worry about. We might, or it might be too drastic (event mpm's which allow requests to jump threads.) If they are too radical for 2.4 or 2.6 expectations, then 3.0 comes along. I'd hope no faster than 6-18 mos per minor bump because you are right - it creates a burden for module authors. No, I don't have the answer but we should be prepared for the uptake of 2.2 to be less than we hope or imagine. Of course. This is true of most projects, Major bump is quite slow (initially), minor is a noticeable delay, and subver should be quick if we keep it painless. This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. We've been operating on a pull me scenario, and it's worked, but it's been hardly optimal. Maybe some sort of push mechanism would be useful. Even if it's just a blurb on the site that Apache 2.2 will be released soon, here is the new API (which is frozen), if you plan to have your Apache modules ready for 2.2 when released, please grab this tarball and test. I'm 100% with you - we should loudly scream The alpha is here! Tell module authors this is it - if we can make your life easier, now is the moment we will break ABI in order to do so! Of course, snooze you lose, if there is something you needed, it will just wait until 2.3-dev for us to begin work after the feature/api freeze 2.2. Bill
mod_cgid, unix socket, ScriptSock directive
The ScriptSock directive must be used when there are two instances of the server with same ServerRoot. If it is omitted, symptoms may include . wrong credentials for CGIs . CGIs stop working for one server when other server is terminated It should be easy to avoid this configuration requirement by appending parent pid to the name of the unix socket which is used *when user didn't specify ScriptSock*, though there is slight migration concern in case administrator relies on name of unix socket for other reason (e.g., to use its existence as knowledge that mod_cgid is ready for business). It should be easy to catch such a misconfiguration by adding the parent pid to the CGI request sent over the Unix socket, and fail the request (and log appropriate message) if parent pid is wrong. Any concerns with adding parent pid to name of the unix socket used by mod_cgid? If the default unix socket name is changed, then chance of misconfiguration goes way down, so there is not much benefit to adding the server-instance check as part of every CGI request.
Re: RFC for a Perchild-like-MPM
On Fri, 19 Nov 2004 17:42:20 +, Ivan Ristic [EMAIL PROTECTED] wrote: Leif W wrote: which was last released as version 2.4.2 on 2003-11-24. Does it still work with Apache httpd 2.0.x? Works fine with httpd 2.0.x in my tests (mod_fastcgi 2.4.2, I didn't try the more recent snapshot). I have the impression that many people feel FastCGI is dead because there isn't much activity on the web site. But it seems to me the authors have just made the protocol (and the Apache module) do what they wanted it to do. 2.4.2 works for me as well. I have the impression that it just works for a number of people, such that a lot of development activity is not necessary.
End of Life Policy
So, we are nearing a new stable branch. For the first time in a long time we will have a no-longer-developed-but-stable-branch in wide use. (2.0.x) I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. Thoughts? -Paul Querna
Re: End of Life Policy
If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. Remember Jim's comments - many users will be 'stuck' on 2.0 for some time into the future while their vendors are preparing their 2.2 builds of add-in modules. Bill At 12:32 PM 11/20/2004, Paul Querna wrote: So, we are nearing a new stable branch. For the first time in a long time we will have a no-longer-developed-but-stable-branch in wide use. (2.0.x) I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. Thoughts? -Paul Querna
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 08:23 AM 11/20/2004, Jim Jagielski wrote: This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. The other alternative is a 'fixed' subset of the httpd API that we simply don't touch. At least so it's APR compat if not ABI compat. That also means leaving httpd n.x releases on apr m.x releases. But mod_isapi already builds on all platforms if you are looking for a stable plug-in api ;-) Bill
Re: End of Life Policy
William A. Rowe, Jr. wrote: If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. That is how I would want to leave it. The problem is, this does not set *any* expectations for how long we will provide these fixes. It does not help an Apache User who maintains any number of servers with httpd-2.0.x. I want the policy to provide an insight for these users -- so they know how long they have to start an upgrade cycle within their environment. Remember Jim's comments - many users will be 'stuck' on 2.0 for some time into the future while their vendors are preparing their 2.2 builds of add-in modules. Yes, but if we set a 10 month end of official support policy, it will also encourage these vendors. If in 8 months, 2.2 turns out to be a major dud, we can reconsider this policy. These are all example time lines, but I believe we need some sort of initial minimum supported policy, as a service to our users. -Paul
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 12:37 PM 11/20/2004, William A. Rowe, Jr. wrote: The other alternative is a 'fixed' subset of the httpd API that we simply don't touch. At least so it's APR compat if not ABI compat. s/APR compat/API compat/
Re: 2.1.1 tarballs posted...
Since this is alpha level, should the server signature contain -alpha so that users don't get this confused with an actual release? Once I build binaries for NetWare, the only thing that will indicate that this is an alpha is the name of the .zip file. It would be less confusing if the binaries also showed that it is an alpha. Index: ap_release.h === --- ap_release.h(revision 105990) +++ ap_release.h(working copy) @@ -36,7 +36,7 @@ #define AP_SERVER_MAJORVERSION_NUMBER 2 #define AP_SERVER_MINORVERSION_NUMBER 1 #define AP_SERVER_PATCHLEVEL_NUMBER 1 -#define AP_SERVER_ADD_STRING +#define AP_SERVER_ADD_STRING -alpha /* keep old macros as well */ #define AP_SERVER_MAJORVERSION APR_STRINGIFY(AP_SERVER_MAJORVERSION_NUMBER) Brad [EMAIL PROTECTED] Friday, November 19, 2004 11:14:19 PM http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin
Re: End of Life Policy
On Sat, 20 Nov 2004 11:45:31 -0700, Paul Querna [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. That is how I would want to leave it. The problem is, this does not set *any* expectations for how long we will provide these fixes. The PMC would have to be willing to specifically forbid maintenance of 2.0 in order to determine such a date. There are more than 3 httpd developers who promise their own customers that their 2.0-based servers will be supported for some years to come with no migration steps required to get critical fixes, and it will be only natural for those folks to want to share any such fixes with the rest of the world.
Re: 2.1.1 tarballs posted...
The netware build is not copying the charset.conv file to the /conf directory during the make install stage. I just committed a patch for NWgnumakefile. Brad [EMAIL PROTECTED] Friday, November 19, 2004 11:14:19 PM http://httpd.apache.org/dev/dist/ Grab the 2.1.1 tarballs while they're fresh. Please start testing these releases - they should have the intent of becoming the beginning of the 2.2.x series modulo all of the cleanup work we'll have to do after we branch. For now, 2.1.1 includes APR/APR-util 1.0.1 - we can adjust this later, if need be. 2.1.1 is currently at alpha level - if we get enough +1s (i.e. 3 or more), it can then be promoted to beta. -- justin
Re: End of Life Policy
Jeff Trawick wrote: On Sat, 20 Nov 2004 11:45:31 -0700, Paul Querna [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. That is how I would want to leave it. The problem is, this does not set *any* expectations for how long we will provide these fixes. The PMC would have to be willing to specifically forbid maintenance of 2.0 in order to determine such a date. No, I do not want to make it forbidden. Rather, I would like a set date where we do not provide _any_ implied support as the HTTPd project. If people continue back porting changes, thats great, but I would like a time line to help support our users. It is not fair to them to leave the branch with an indeterminate status. There are more than 3 httpd developers who promise their own customers that their 2.0-based servers will be supported for some years to come with no migration steps required to get critical fixes, and it will be only natural for those folks to want to share any such fixes with the rest of the world.
Re: End of Life Policy
Paul Querna, Saturday, November 20, 2004 13:32 I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Support 2.0 for the lesser of: *) Until the next stable release after 2.2 (2.4 or 3.0) *) 12-24 months from 2.2 release Rationale: Don't stop supporting 2.0 until 2.2 is widely used. Getting usage statistics is tricky, with people disabling server version string. Have a poll? ;-) Widely used should be quantifiable, the definition is debatable and the timeframe may not be predictable. Say over 50%, like 2/3 of the combined users of 2.0 and 2.2 use 2.2, 1/3 use 2.0. Or 75/25. Or shall we still include 1.3? ;-) Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. I use a distribution, but I prefer tarballs to package hell for things like Apache. The distributions may patch something as quickly, but on an older version. It can take some months or even years before the package uses the newer version which may have a non-security bugfix. Anything less than a year seems like pulling the rug out from under people. Why stop supporting the software before it even gets widely adopted? How long since 2.0 came out, and there are people still stuck with 1.3, due to valid concerns. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. Maybe it can be done with communication through the available channels (web, mail, tarballs)? We strongly urge you to migrate those old 2.0.x or (ack) 1.3.x modules to 2.2.x within the first ( 6 M 24 ) months after the 2.2.x release! Maybe put a timed nag message at the end of the ./configure script: alert people of the support window, advise them to upgrade modules. Not necessarily explicitly dropping security backports, which makes it look like the developers drop the ball, but turning it around on the user, to let them know that it's them who chose to drop the ball. 24 months is a *** eternity though... :p Leif
[SVN] Branches for apr[-util|-iconv] 0.9.x moved
apr/apr/branches/ APR_0_9_BRANCH - 0.9.x apr/apr-util/branches/ APU_0_9_BRANCH - 0.9.x apr/apr-iconv/branches/ API_0_9_BRANCH - 0.9.x All changed... you need to... cd into your local checkout directories, and switch them. cd /path-to-local/apr-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr/branches/0.9.x cd /path-to-local/apr-util-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x cd /path-to-local/apr-iconv-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr-iconv/branches/0.9.x and you will jump right up with us. apr/apr/branches/ APR/ unlabeled/ - these are duds - delete them? apr/apr-iconv/branches/ API_1_0_BRANCH ICONV - these are dead - rm them? All gone. Bill
httpd-2.1 and apr-?
Greetings All, Just trying to get building back together after the change to SVN and find I now get: Linking Release/aprlib.nlm ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved Errors caused tool to abort. make[1]: *** [Release/aprlib.nlm] Error 1 make: *** [srclib\apr] Error 2 In the previous setup, 2.1 came with it's own APR APR-UTIL hooked onto the .\srclib directory, but no such convenience now... what version of APR/APR-UTIL should I be using with 2.1 CVS ...er trunk? TIA, Norm
Re: httpd-2.1 and apr-?
I believe APR-Trunk is broken on Netware as noted in my r105905 commit message. (This commit split APR Pollset into multiple files). If you want something that works now, APR-1.0.1 should work for Netware. Otherwise, you need to add poll/unix/select.c to the Netware build. NormW wrote: Greetings All, Just trying to get building back together after the change to SVN and find I now get: Linking Release/aprlib.nlm ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved Errors caused tool to abort. make[1]: *** [Release/aprlib.nlm] Error 1 make: *** [srclib\apr] Error 2 In the previous setup, 2.1 came with it's own APR APR-UTIL hooked onto the .\srclib directory, but no such convenience now... what version of APR/APR-UTIL should I be using with 2.1 CVS ...er trunk? TIA, Norm
Re: httpd-2.1 and apr-?
Paul Querna wrote: I believe APR-Trunk is broken on Netware as noted in my r105905 commit message. (This commit split APR Pollset into multiple files). If you want something that works now, APR-1.0.1 should work for Netware. Otherwise, you need to add poll/unix/select.c to the Netware build. NormW wrote: Greetings All, Just trying to get building back together after the change to SVN and find I now get: Linking Release/aprlib.nlm ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved ### mwldnlm Linker Error: # Exported symbol '[EMAIL PROTECTED]' cannot be resolved Errors caused tool to abort. make[1]: *** [Release/aprlib.nlm] Error 1 make: *** [srclib\apr] Error 2 In the previous setup, 2.1 came with it's own APR APR-UTIL hooked onto the .\srclib directory, but no such convenience now... what version of APR/APR-UTIL should I be using with 2.1 CVS ...er trunk? TIA, Norm . Good afternoon Paul, First off thanks for the reply, and hope your weekend is being better used. I got to looking at this newfangled svn (after taking ages to get the hang of CVS, even if there was still a touch of magic to it), and found there was an apr 1.0 branch, so got that down and was able to get passed the original problem However... my NetWare building wants to complain about: Compiling modules/http/http_request.c ### mwccnlm Compiler: #File: modules\http\http_request.c # # 219: apr_bucket *e = apr_bucket_flush_create(c-bucket_alloc); # Error: ^^ # expression syntax error From a little experience with CodeWarrior (their name choice, not mine), normally CW doesn't like symbols getting a 'first-time' appearence in the middle of a function with structure prefixes, and by defining 'e' at the start of the function apr_bucket *e; and just using e = apr_bucket_flush_create(...' at line 219 then it all glues together without issue. Some where between the last CVS update to http_request.c and what is currently in httpd-2.1 /trunk, the check_pipeline_flush() routine was updated and the 'update' broke CW... Someone care to put some BlueTack on this please? Regards, and thanks for the quick reply. Norm
Re: httpd-2.1 and apr-?
However... my NetWare building wants to complain about: Compiling modules/http/http_request.c ### mwccnlm Compiler: #File: modules\http\http_request.c # # 219: apr_bucket *e = apr_bucket_flush_create(c-bucket_alloc); # Error: ^^ # expression syntax error From a little experience with CodeWarrior (their name choice, not mine), normally CW doesn't like symbols getting a 'first-time' appearence in the middle of a function with structure prefixes, and by defining 'e' at the start of the function apr_bucket *e; and just using e = apr_bucket_flush_create(...' at line 219 then it all glues together without issue. I just committed r106072 that should fix this. I am not 100% sure it is fixed, since I don't have the correct compilers to test this. -Paul Querna
Re: httpd-2.1 and apr-?
Paul Querna wrote: However... my NetWare building wants to complain about: Compiling modules/http/http_request.c ### mwccnlm Compiler: #File: modules\http\http_request.c # # 219: apr_bucket *e = apr_bucket_flush_create(c-bucket_alloc); # Error: ^^ # expression syntax error From a little experience with CodeWarrior (their name choice, not mine), normally CW doesn't like symbols getting a 'first-time' appearence in the middle of a function with structure prefixes, and by defining 'e' at the start of the function apr_bucket *e; and just using e = apr_bucket_flush_create(...' at line 219 then it all glues together without issue. I just committed r106072 that should fix this. I am not 100% sure it is fixed, since I don't have the correct compilers to test this. -Paul Querna . Good afternoon Paul, Hope everyone else is as happy as the CW is now. Thanks for the quick fix... long live 2.2... Regards, Norm
