Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Thu, 25 Nov 2004, Joe Orton wrote: > Or if it does, -1 veto on either bumping the APR major version or > creating a branch or making toast with jam before Allan submits a patch > for review on [EMAIL PROTECTED] Okay, well, that means that for progress to be made, some form of patch needs to get mailed in. Allan, go on and mail something in then. Joe's veto disappears at that point and THEN we can make a sandbox branch in the repository. Let's just not let this cause all action to be stopped. :) --Cliff
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, Nov 24, 2004 at 02:36:25PM -0500, Cliff Woolley wrote: > On Wed, 24 Nov 2004, Justin Erenkrantz wrote: > > > To be clear, I'm perfectly happy with merging to trunk in Allen's changes > > *once* completed and reviewed and moving trunk to 2.x if need be - but I > > Nevertheless, the question at hand is what action to take RIGHT NOW. The API changes are completely hypothetical at this point, so the only action to take "RIGHT NOW" is to "END THIS SILLY DISCUSSION" i.e. stop speculating about what to do once they are submitted and wait for them to be submitted to [EMAIL PROTECTED] This is common sense and I believe that doesn't require a vote. Or if it does, -1 veto on either bumping the APR major version or creating a branch or making toast with jam before Allan submits a patch for review on [EMAIL PROTECTED] joe p.s. STOP! Put that toaster down you in the corner there.
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
William A. Rowe, Jr. wrote: At 01:29 PM 11/24/2004, Cliff Woolley wrote: On Wed, 24 Nov 2004, Justin Erenkrantz wrote: I'm sick of all talk and no action. We tried this last year when we were "almost" ready to branch APR 1.0 and all action on that front ceased entirely for a YEAR. This time it's one or the other. I'll wait 24 hours at most to hear opinions. Whichever route gets the most support wins. So far we have: trunk remains 1.1, 64-bit is sandboxed: jwoolley, jerenkrantz wrowe: (conditional on committing to head once it's reviewed, and branch 1.1 if we want to keep 1.1 alive.) That is fine by me. I agree that the extent of the changes will probably be significant so at least starting with a sandbox branch may be judicious, at least until we get a feel for the extent of the changes, and working on a branch may actually help accelerate the work. Allan
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 01:29 PM 11/24/2004, Cliff Woolley wrote: >On Wed, 24 Nov 2004, Justin Erenkrantz wrote: > >I'm sick of all talk and no action. We tried this last year when we were >"almost" ready to branch APR 1.0 and all action on that front ceased >entirely for a YEAR. This time it's one or the other. I'll wait 24 hours >at most to hear opinions. Whichever route gets the most support wins. > >So far we have: > > trunk remains 1.1, 64-bit is sandboxed: > jwoolley, jerenkrantz wrowe: (conditional on committing to head once it's reviewed, and branch 1.1 if we want to keep 1.1 alive.) > trunk becomes 2.0: > rooneg > > >--Cliff
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 01:05 PM 11/24/2004, Cliff Woolley wrote: >On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote: > >> Allan - your last patches were to try to -wedge- the current >> API into httpd. Can you share the patch just to fix APR? >> Then we can start to comprehend scope. NO CASTS - just the >> correct declarations in the first place. > >Since this is obviously going to be big, don't you think it would be >better to just get going on a sandbox branch of APR so that we can work >iteratively instead of passing big patches back and forth? ++1
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Justin Erenkrantz wrote: > To be clear, I'm perfectly happy with merging to trunk in Allen's changes > *once* completed and reviewed and moving trunk to 2.x if need be - but I Nevertheless, the question at hand is what action to take RIGHT NOW. "Let's just wait for..." with no action attached is not acceptable to me in this case, because it's bitten us in the ass before. So I'm waiting for votes. :) --Cliff
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
--On Wednesday, November 24, 2004 2:29 PM -0500 Cliff Woolley <[EMAIL PROTECTED]> wrote: I'm sick of all talk and no action. We tried this last year when we were "almost" ready to branch APR 1.0 and all action on that front ceased entirely for a YEAR. This time it's one or the other. I'll wait 24 hours at most to hear opinions. Whichever route gets the most support wins. To be clear, I'm perfectly happy with merging to trunk in Allen's changes *once* completed and reviewed and moving trunk to 2.x if need be - but I want to be sure that we get the API perfect before we merge it into trunk. I expect that it's going to take a few iterations to get the API 64-bit clean and reviewed by everyone. So, I'd rather not disrupt everything else during the meantime. This is about as clear cut a reason for a branch as I know. =) -- justin
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Justin Erenkrantz wrote: > Oh, please don't. We have *no* idea what the changes are or whether we'll > even ultimately accept them. Please branch Allen's changes off in a > sandbox (cp trunk branches/64-bit-changes) - let him get a workable version > that we can then review, and then merge it in once we're done. But, these > changes are too drastic and unknown to do the development in trunk. -- I'm sick of all talk and no action. We tried this last year when we were "almost" ready to branch APR 1.0 and all action on that front ceased entirely for a YEAR. This time it's one or the other. I'll wait 24 hours at most to hear opinions. Whichever route gets the most support wins. So far we have: trunk remains 1.1, 64-bit is sandboxed: jwoolley, jerenkrantz trunk becomes 2.0: rooneg --Cliff
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
Cliff Woolley wrote: On Wed, 24 Nov 2004, Garrett Rooney wrote: I guess I'm just arguing for a single branch that's the target of the current development, as opposed to one 64 bit dev branch and one trunk which holds other changes, thus requiring us to either invest constant effort in merging changes from the trunk into the 64 bit branch or letting it get kind of stale and then having a mega-huge merge into the trunk at the end. The only question is whether we want to keep trunk as 1.1-dev or 2.0-dev. But I guess with SVN it's easy to branch 1.1 and 1.0 off of what's now the 1.0 branch (rename the 1.0 branch to 1.1 and branch a new 1.0 branch off of that, or whatever). Exactly. So sure, screw it. APR trunk is now 2.0-dev. Have fun. The only thing we need to be sure of is publicising this fact to our consumers. People are probably used to being able to check out trunk and get the 1.x API, so if we're planning on changing the API we need to make it clear that those people need to be using the 1.0.x branch. -garrett
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
--On Wednesday, November 24, 2004 2:20 PM -0500 Cliff Woolley <[EMAIL PROTECTED]> wrote: So sure, screw it. APR trunk is now 2.0-dev. Have fun. Oh, please don't. We have *no* idea what the changes are or whether we'll even ultimately accept them. Please branch Allen's changes off in a sandbox (cp trunk branches/64-bit-changes) - let him get a workable version that we can then review, and then merge it in once we're done. But, these changes are too drastic and unknown to do the development in trunk. -- justin
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Garrett Rooney wrote: > I guess I'm just arguing for a single branch that's the target of the > current development, as opposed to one 64 bit dev branch and one trunk > which holds other changes, thus requiring us to either invest constant > effort in merging changes from the trunk into the 64 bit branch or > letting it get kind of stale and then having a mega-huge merge into the > trunk at the end. The only question is whether we want to keep trunk as 1.1-dev or 2.0-dev. But I guess with SVN it's easy to branch 1.1 and 1.0 off of what's now the 1.0 branch (rename the 1.0 branch to 1.1 and branch a new 1.0 branch off of that, or whatever). So sure, screw it. APR trunk is now 2.0-dev. Have fun.
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
Cliff Woolley wrote: On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote: Allan - your last patches were to try to -wedge- the current API into httpd. Can you share the patch just to fix APR? Then we can start to comprehend scope. NO CASTS - just the correct declarations in the first place. Since this is obviously going to be big, don't you think it would be better to just get going on a sandbox branch of APR so that we can work iteratively instead of passing big patches back and forth? I'm all for using branches if there's going to be some kind of long-term breakage caused by the change, but if we're certain that APR 2.0 is going to include these changes for 64 bit support in the API then I'd much rather see it happen in the trunk, with iterations of the change happening there. Long lived branches should be avoided, IMO, if at all possible. Doing the development that will lead to 2.0 on the trunk doesn't keep us from merging changes back into the 1.0.x branch when appropriate. I guess I'm just arguing for a single branch that's the target of the current development, as opposed to one 64 bit dev branch and one trunk which holds other changes, thus requiring us to either invest constant effort in merging changes from the trunk into the 64 bit branch or letting it get kind of stale and then having a mega-huge merge into the trunk at the end. -garrett
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote: > Allan - your last patches were to try to -wedge- the current > API into httpd. Can you share the patch just to fix APR? > Then we can start to comprehend scope. NO CASTS - just the > correct declarations in the first place. Since this is obviously going to be big, don't you think it would be better to just get going on a sandbox branch of APR so that we can work iteratively instead of passing big patches back and forth?
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 12:29 PM 11/24/2004, Allan Edwards wrote: >If we can make good progress towards a stable 64 bit APR 2.0 then >moving httpd 2.1/2.2 to it could make sense. The question is >whether there is enough feature freeze pressure to say that >64 bit does not warrant the wait... Allan - your last patches were to try to -wedge- the current API into httpd. Can you share the patch just to fix APR? Then we can start to comprehend scope. NO CASTS - just the correct declarations in the first place. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Wed, 24 Nov 2004, Allan Edwards wrote: > First order of business now that we are on SVN is to focus on > the APR changes that are needed. It's not clear to me though, > now that we have an APR 1.0 branch, is the trunk open for > API-breaking changes or do we need a separate branch for that work? Just make yourself a branch in SVN of APR and do whatever you like. Branches are cheap and non-permanent in SVN. Once we merge it into the trunk, the trunk will likely have to become APR 2.0-dev. --Cliff
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
man, how did I get so far behind on my email... I'd like to see us get this into httpd 2.2 for the reasons previously outlined and think we need to get the work underway as quickly as possible to determine how extensive the changes are going to be and how fast progress can be made. First order of business now that we are on SVN is to focus on the APR changes that are needed. It's not clear to me though, now that we have an APR 1.0 branch, is the trunk open for API-breaking changes or do we need a separate branch for that work? If we can make good progress towards a stable 64 bit APR 2.0 then moving httpd 2.1/2.2 to it could make sense. The question is whether there is enough feature freeze pressure to say that 64 bit does not warrant the wait... I'd say let's see if we can make some progress first. Any help that can be offered on this endeavour will be greatly appreciated! Allan >Bill Stoddard wrote: William A. Rowe, Jr. wrote: 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. And that's precisely the reason we should attack the 64 bit problem for 2.2. This will give the 2.2 series a much longer life than if we push off the 64 bit work to 2.4. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote: > Yes - I understand that this means 1.x will never be used by > httpd. Version numbers are cheap. The APR project should > become used to this, if they are active, and httpd moves at > it's normal pace, it would be easy to go through APR 2.x, 3.x, > and land somewhere in version 4.x by the time httpd 2.4 or 3.0 > walks out the door. Do you understand how ridiculous that sounds?
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 11:08 AM 11/22/2004, Cliff Woolley wrote: >On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote: > >> Yes - I understand that this means 1.x will never be used by >> httpd. Version numbers are cheap. The APR project should >> become used to this, if they are active, and httpd moves at >> it's normal pace, it would be easy to go through APR 2.x, 3.x, >> and land somewhere in version 4.x by the time httpd 2.4 or 3.0 >> walks out the door. > >Do you understand how ridiculous that sounds? How so? Let's imagine the release -after- 2.2 takes another 12-18 months. Perhaps the event mpm gets plugged in, and it takes three months, alone, just to find all the gotchas of thread-jumping. In the meantime, apr is adopted by other projects. These coders offer up some solid functionality for their own applications, and the apr team agrees. Yes, I realize most of the time new functionality can be a minor bump of apr. Yes, I realize apr has not been all that active in the past 12 months. All I'm arguing is that apr shouldn't be addicted to some 1:1 correspondence of httpd and apr bumps. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 10:08 AM 11/22/2004, Bill Stoddard wrote: >William A. Rowe, Jr. wrote: > >>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. > >And that's precisely the reason we should attack the 64 bit problem for 2.2. >This will give the 2.2 series a much longer life than if we push off the 64 >bit work to 2.4. +1 - well said. By the way, Allen was out for the week of AC but returns this week, perhaps he can jump back into this conversation. Yes - I understand that this means 1.x will never be used by httpd. Version numbers are cheap. The APR project should become used to this, if they are active, and httpd moves at it's normal pace, it would be easy to go through APR 2.x, 3.x, and land somewhere in version 4.x by the time httpd 2.4 or 3.0 walks out the door. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
William A. Rowe, Jr. wrote: 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. And that's precisely the reason we should attack the 64 bit problem for 2.2. This will give the 2.2 series a much longer life than if we push off the 64 bit work to 2.4. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
William A. Rowe, Jr. wrote: At 11:03 PM 11/19/2004, Justin Erenkrantz wrote: --On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. I don't believe that Allen would be able to complete his changes in a reasonable timeframe. 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. -- I guess the ball is to Allen, then, but I'd also be happy to quickly whack at it. The concept is Simple(tm) and would be far less painful than actually fighting through all the ( cast )s of his later patches. Bill I'd personally prefer to see this done in 2.2 but reserving the right to change my mind ;-) Bill
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.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: 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
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: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote: >--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr." <[EMAIL >PROTECTED]> wrote: > >>I'll offer compelling argument. Allen offered patches, which >>Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, >>and told Allen to go back and fix APR. > >I don't believe that Allen would be able to complete his changes in a >reasonable timeframe. >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. -- I guess the ball is to Allen, then, but I'd also be happy to quickly whack at it. The concept is Simple(tm) and would be far less painful than actually fighting through all the ( cast )s of his later patches. Bill
2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. That is the right answer, branch APR 1.x, fix on svn trunk (2.0.0) and commit the right code in httpd-2.2 such that an allocation of memory is consistently size_t and an allocation of disk is consistently off_t, and none of which has anything to do with int or long. 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