You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2004/11/20 03:01:29 UTC
Re: [NOTICE] CVS to SVN migration complete
At 06:52 PM 11/19/2004, Justin Erenkrantz wrote:
>--On Saturday, November 20, 2004 1:49 AM +0100 André Malo <nd...@perlig.de> wrote:
>
>>Just a question:
>>Maybe I'm missing the info - is the httpd trunk supposed to work with the
>>apr 1.0.x branch or just the apr trunk?
>
>We're going to have to decide which APR branch/release httpd 2.1/2.2 should work with - and, we'll have to decide soon. Whichever we pick, we need to stick 2.2 to a *released* version of APR. At this point, without a compelling argument, I'd vote for 1.0.x. -- justin
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.
Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN
migration complete
Posted by Bill Stoddard <bi...@wstoddard.com>.
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." <wr...@rowe-clan.net> 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote:
>--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> 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
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to
SVN migration complete
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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 dev@apr.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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 dev@apr.
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
Posted by Joe Orton <jo...@redhat.com>.
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 dev@apr. 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 dev@apr.
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
Posted by Joe Orton <jo...@redhat.com>.
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 dev@apr. 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 dev@apr.
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
Posted by Allan Edwards <ak...@us.ibm.com>.
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
Posted by Allan Edwards <ak...@us.ibm.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, November 24, 2004 2:29 PM -0500 Cliff Woolley
<jw...@virginia.edu> 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, November 24, 2004 2:29 PM -0500 Cliff Woolley
<jw...@virginia.edu> 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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, November 24, 2004 2:20 PM -0500 Cliff Woolley
<jw...@virginia.edu> 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
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
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
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, November 24, 2004 2:20 PM -0500 Cliff Woolley
<jw...@virginia.edu> 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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Posted by Allan Edwards <ak...@us.ibm.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Allan Edwards <ak...@us.ibm.com>.
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
Posted by Bill Stoddard <bi...@wstoddard.com>.
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
Posted by Bill Stoddard <bi...@wstoddard.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote:
>--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> 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
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
Posted by Jim Jagielski <ji...@jaguNET.com>.
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.
2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration
complete
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> 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
2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration
complete
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, November 19, 2004 8:01 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> 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