APR 1.4 status (and backport)

[Jim Jagielski]

With the hope for the httpd project to start pushing for a 2.4
release, it has a dependency on apr 1.4 (actually 2.0, but I'm
getting to that). Now that we have a pretty stable 1.3.x branch,
I'd like us to put some effort into a 1.4.0 release. With that
in mind, I'm also looking at backporting some 2.0 features to
1.4.0, esp the apr_pollcb_create_ex() (et.al.) stuff.

Comments?

[Graham Leggett]

Jim Jagielski wrote:

> With the hope for the httpd project to start pushing for a 2.4
> release, it has a dependency on apr 1.4 (actually 2.0, but I'm
> getting to that). Now that we have a pretty stable 1.3.x branch,
> I'd like us to put some effort into a 1.4.0 release. With that
> in mind, I'm also looking at backporting some 2.0 features to
> 1.4.0, esp the apr_pollcb_create_ex() (et.al.) stuff.

+1.

Regards,
Graham
--

[William A. Rowe Jr.]

Jim Jagielski wrote:
> With the hope for the httpd project to start pushing for a 2.4
> release, it has a dependency on apr 1.4 (actually 2.0, but I'm
> getting to that). Now that we have a pretty stable 1.3.x branch,
> I'd like us to put some effort into a 1.4.0 release. With that
> in mind, I'm also looking at backporting some 2.0 features to
> 1.4.0, esp the apr_pollcb_create_ex() (et.al.) stuff.
>
> Comments?

 * any particular feature you work to copy from 2.0 to 1.4 without
   breaking 1.x.x binary ABI sounds terrific.

 * including those backports, is 1.4.0 ready, or do we need to revert
   API's which are not sufficiently thought out?  The apr_crypto interfaces
   were rejected at 1.3.0, and it would be time to reopen that discussion.
   I'm pretty sure there haven't been enough eyeballs attending to this.

 * a larger question, is 2.0.0 ready?  Are there additional API improvements
   required to call it baked?  Does it fix enough awkward bugs in the static
   1.x.x API's to suggest that users move over already?  If 2.0.0 is ready,
   I can see wisdom in not pushing out a 1.4 at all.

If you didn't have a particular timetable, what if we used Tuesday hackathon
at ApacheCon to really push out a 2.0.0 or 1.4.0, resolving the last of the
open complaints f2f.  In the meantime, figure out what isn't suitable for
either 1.4.0 or 2.0.0, move whatever features you like to 1.4.0, and really
polish the build schema changes for 2.0.0, ensuring that it builds correctly
under the classic (deprecated) schemas or scons.

Other thoughts about 1.4.0 or 2.0.0?

Bill

[Graham Leggett]

William A. Rowe, Jr. wrote:

>  * including those backports, is 1.4.0 ready, or do we need to revert
>    API's which are not sufficiently thought out?  The apr_crypto interfaces
>    were rejected at 1.3.0, and it would be time to reopen that discussion.

The apr_crypto interfaces were rejected at v1.3.0, completely thrown out
and rewritten from scratch specifically addressing the original issues
with v1.3.0.

The reasons for the original v1.3.0 objections have been gone for a very
long time.

>  * a larger question, is 2.0.0 ready?  Are there additional API improvements
>    required to call it baked?  Does it fix enough awkward bugs in the static
>    1.x.x API's to suggest that users move over already?  If 2.0.0 is ready,
>    I can see wisdom in not pushing out a 1.4 at all.

The LDAP issue in v2.0 needs fixing, and that needs to be done properly,
not rushed for the benefit of getting httpd out the door.

Whatever mistakes we make in v2.0 will have to wait till v3.0 to be fixed.

Regards,
Graham
--

[Jeff Trawick]

On Fri, Oct 2, 2009 at 12:52 PM, William A. Rowe, Jr. <wrowe@...> wrote:

Jim Jagielski wrote:
> With the hope for the httpd project to start pushing for a 2.4
> release, it has a dependency on apr 1.4 (actually 2.0, but I'm
> getting to that). Now that we have a pretty stable 1.3.x branch,
> I'd like us to put some effort into a 1.4.0 release. With that
> in mind, I'm also looking at backporting some 2.0 features to
> 1.4.0, esp the apr_pollcb_create_ex() (et.al.) stuff.
>
> Comments?

 * any particular feature you work to copy from 2.0 to 1.4 without
  breaking 1.x.x binary ABI sounds terrific.

 * including those backports, is 1.4.0 ready, or do we need to revert
  API's which are not sufficiently thought out?  The apr_crypto interfaces
  were rejected at 1.3.0, and it would be time to reopen that discussion.
  I'm pretty sure there haven't been enough eyeballs attending to this.

no clue here; I'd just point out that crypto's use by mod_session_ is the only thing in httpd trunk that absolutely requires a new APR release (the simple MPM dependency isn't that big a deal)

 * a larger question, is 2.0.0 ready?  Are there additional API improvements
  required to call it baked?  Does it fix enough awkward bugs in the static
  1.x.x API's to suggest that users move over already?  If 2.0.0 is ready,
  I can see wisdom in not pushing out a 1.4 at all.

I think a number of the issues in trunk's STATUS file under the heading "Interface Changes Postponed for APR 2.0:" should be considered.  (<httpd>no joy here digging into that before there's a branch for httpd 2.4.</httpd>)

Something else prior to APR 2.0 is resolving the LDAP interfaces or tossing.
Related: Don't use OpenLDAP's non-threadsafe libldap.so if building thread-safe APR.  (Hopefully we already do that for other libraries, such as MySQL's.)

[Paul Querna-6]

On Fri, Oct 2, 2009 at 9:52 AM, William A. Rowe, Jr.
<wrowe@...> wrote:

> Jim Jagielski wrote:
>> With the hope for the httpd project to start pushing for a 2.4
>> release, it has a dependency on apr 1.4 (actually 2.0, but I'm
>> getting to that). Now that we have a pretty stable 1.3.x branch,
>> I'd like us to put some effort into a 1.4.0 release. With that
>> in mind, I'm also looking at backporting some 2.0 features to
>> 1.4.0, esp the apr_pollcb_create_ex() (et.al.) stuff.
>>
>> Comments?
>
>  * any particular feature you work to copy from 2.0 to 1.4 without
>   breaking 1.x.x binary ABI sounds terrific.
>
>  * including those backports, is 1.4.0 ready, or do we need to revert
>   API's which are not sufficiently thought out?  The apr_crypto interfaces
>   were rejected at 1.3.0, and it would be time to reopen that discussion.
>   I'm pretty sure there haven't been enough eyeballs attending to this.
>
>  * a larger question, is 2.0.0 ready?  Are there additional API improvements
>   required to call it baked?  Does it fix enough awkward bugs in the static
>   1.x.x API's to suggest that users move over already?  If 2.0.0 is ready,
>   I can see wisdom in not pushing out a 1.4 at all.
>
> If you didn't have a particular timetable, what if we used Tuesday hackathon
> at ApacheCon to really push out a 2.0.0 or 1.4.0, resolving the last of the
> open complaints f2f.  In the meantime, figure out what isn't suitable for
> either 1.4.0 or 2.0.0, move whatever features you like to 1.4.0, and really
> polish the build schema changes for 2.0.0, ensuring that it builds correctly
> under the classic (deprecated) schemas or scons.
>
> Other thoughts about 1.4.0 or 2.0.0?

Do it way before apachecon IMO.  Wait until apachecon to _talk_ about
it, we would be lucky to ship this year.

I'd like to at an absolute minimum have SCons working as the default
build on win32, and a viable choice on *nix, but ENOTIME with
everything else I've got going on this fall.

-Paul

[William A. Rowe Jr.]

Paul Querna wrote:

> On Fri, Oct 2, 2009 at 9:52 AM, William A. Rowe, Jr.
>>
>> If you didn't have a particular timetable, what if we used Tuesday hackathon
>> at ApacheCon to really push out a 2.0.0 or 1.4.0, resolving the last of the
>> open complaints f2f.  In the meantime, figure out what isn't suitable for
>> either 1.4.0 or 2.0.0, move whatever features you like to 1.4.0, and really
>> polish the build schema changes for 2.0.0, ensuring that it builds correctly
>> under the classic (deprecated) schemas or scons.
>>
>> Other thoughts about 1.4.0 or 2.0.0?
>
> Do it way before apachecon IMO.  Wait until apachecon to _talk_ about
> it, we would be lucky to ship this year.

That's what I meant, use apachecon to talk through all the places we get stuck
in disagreement, close the open issues and tag something before or at the
conference :)

> I'd like to at an absolute minimum have SCons working as the default
> build on win32, and a viable choice on *nix, but ENOTIME with
> everything else I've got going on this fall.

Those would be noble goals.  We'll see, I have it set up here, but like you I have
pretty minimal time between now and then.  I'm actually more keen to fix the mingw
autoconf flavor and ensure it is inline with win32 build today, and then ensure that
scons produces the same result.

[Arfrever Frehtes Taifersar Arahesis-2]

2009-10-02 20:31:07 Paul Querna napisał(a):

> On Fri, Oct 2, 2009 at 9:52 AM, William A. Rowe, Jr.
> <wrowe@...> wrote:
> > Jim Jagielski wrote:
> >> With the hope for the httpd project to start pushing for a 2.4
> >> release, it has a dependency on apr 1.4 (actually 2.0, but I'm
> >> getting to that). Now that we have a pretty stable 1.3.x branch,
> >> I'd like us to put some effort into a 1.4.0 release. With that
> >> in mind, I'm also looking at backporting some 2.0 features to
> >> 1.4.0, esp the apr_pollcb_create_ex() (et.al.) stuff.
> >>
> >> Comments?
> >
> >  * any particular feature you work to copy from 2.0 to 1.4 without
> >   breaking 1.x.x binary ABI sounds terrific.
> >
> >  * including those backports, is 1.4.0 ready, or do we need to revert
> >   API's which are not sufficiently thought out?  The apr_crypto interfaces
> >   were rejected at 1.3.0, and it would be time to reopen that discussion.
> >   I'm pretty sure there haven't been enough eyeballs attending to this.
> >
> >  * a larger question, is 2.0.0 ready?  Are there additional API improvements
> >   required to call it baked?  Does it fix enough awkward bugs in the static
> >   1.x.x API's to suggest that users move over already?  If 2.0.0 is ready,
> >   I can see wisdom in not pushing out a 1.4 at all.
> >
> > If you didn't have a particular timetable, what if we used Tuesday hackathon
> > at ApacheCon to really push out a 2.0.0 or 1.4.0, resolving the last of the
> > open complaints f2f.  In the meantime, figure out what isn't suitable for
> > either 1.4.0 or 2.0.0, move whatever features you like to 1.4.0, and really
> > polish the build schema changes for 2.0.0, ensuring that it builds correctly
> > under the classic (deprecated) schemas or scons.
> >
> > Other thoughts about 1.4.0 or 2.0.0?
>
> Do it way before apachecon IMO.  Wait until apachecon to _talk_ about
> it, we would be lucky to ship this year.
>
> I'd like to at an absolute minimum have SCons working as the default
> build on win32, and a viable choice on *nix

AFAIK SCons still doesn't work with the newest versions of Python.

--
Arfrever Frehtes Taifersar Arahesis

[William A. Rowe Jr.]

Graham Leggett wrote:

> William A. Rowe, Jr. wrote:
>
>>  * including those backports, is 1.4.0 ready, or do we need to revert
>>    API's which are not sufficiently thought out?  The apr_crypto interfaces
>>    were rejected at 1.3.0, and it would be time to reopen that discussion.
>
> The apr_crypto interfaces were rejected at v1.3.0, completely thrown out
> and rewritten from scratch specifically addressing the original issues
> with v1.3.0.
>
> The reasons for the original v1.3.0 objections have been gone for a very
> long time.

Agreed, and which is entirely my point; that code review passed, and the new code
hadn't actually been sufficiently reviewed.  Just pointing this out to encourage
people to thoroughly review the new API.

>>  * a larger question, is 2.0.0 ready?  Are there additional API improvements
>>    required to call it baked?  Does it fix enough awkward bugs in the static
>>    1.x.x API's to suggest that users move over already?  If 2.0.0 is ready,
>>    I can see wisdom in not pushing out a 1.4 at all.
>
> The LDAP issue in v2.0 needs fixing, and that needs to be done properly,
> not rushed for the benefit of getting httpd out the door.

Correct, so as we previously agreed, apr_ldap would be dropped from 2.0 if the
project wishes to move ahead.

> Whatever mistakes we make in v2.0 will have to wait till v3.0 to be fixed.

Agreed.

[Paul Querna-6]

On Fri, Oct 2, 2009 at 12:15 PM, Arfrever Frehtes Taifersar Arahesis
<arfrever.fta@...> wrote:
> 2009-10-02 20:31:07 Paul Querna napisał(a):
>> I'd like to at an absolute minimum have SCons working as the default
>> build on win32, and a viable choice on *nix
>
> AFAIK SCons still doesn't work with the newest versions of Python.

please be more specific, AFAIK, it works with all version of Python 2.x.

[Branko Čibej-2]

Paul Querna wrote:

> On Fri, Oct 2, 2009 at 12:15 PM, Arfrever Frehtes Taifersar Arahesis
> <arfrever.fta@...> wrote:
>  
>> 2009-10-02 20:31:07 Paul Querna napisał(a):
>>    
>>> I'd like to at an absolute minimum have SCons working as the default
>>> build on win32, and a viable choice on *nix
>>>      
>> AFAIK SCons still doesn't work with the newest versions of Python.
>>    
>
> please be more specific, AFAIK, it works with all version of Python 2.x.
>  

He probably means 3.0, which is used by afficionados but practically
nowhere else that I'm aware of. Not because there's anything wrong with
it, but there are a few unnecessary incompatibilities with 2.x (x < 6)
that effectively mean you can't have code that will run with both
generations of Python.

-- Brane