apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Date Thu, 02 Jun 2011 14:09:38 GMT
On Thu, Jun 2, 2011 at 7:10 AM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 02 Jun 2011, at 1:19 AM, William A. Rowe Jr. wrote:
>
>> On 6/1/2011 5:37 PM, Graham Leggett wrote:
>>>
>>> I see a vote, and no on-list discussion that preceded it. Not only that,
>>> I see a vote on
>>> the dev@apr list proposing an as yet unheard of solution that concerns a
>>> completely
>>> separate project, with no discussion having happened on either project.
>>> This is not how a
>>> project at the ASF works.
>>
>> Quit whining, of course this is how an ASF project works; there was a
>> discussion,
>> it ate up a good part of the list bandwidth, with discussion and
>> suggestions of
>> how to fix, and no fix forthcoming, and a conclusive decision on list;
>>
>>
>> http://mail-archives.apache.org/mod_mbox/apr-dev/200903.mbox/%3C5c902b9e0903240326r3222ac90k15dcb7f34d2d1587@mail.gmail.com%3E
>>
>> Justin had brought this to the list from a f2f hackathon for a decision as
>> this
>> blocked 2.0 in 2009(!).
>
> "So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util". Another example of discussions taken and
> decisions made off list.
>
> This is not how an ASF project works, and wearing my PMC member's hat, I
> consider this continued practice a risk to this project.
>
>> but you had years to set aside time, and couldn't be bothered.
>
> I am thoroughly disgusted by this remark.
>
> I have spent weeks and weeks of my time on my dime solving RFC violations in
> mod_cache that were contributed to us in 2003, in addition to a huge amount
> of other work on fixing the mod_cache API in time for the imminent release
> of httpd v2.4, and this is simply more important right now. A further
> enormous time sink was resolving your issues you demanded fixed in the
> apr_crypto API, which you carried on complaining about even after the work
> was completed - you'd hadn't even noticed the work had been done.
>
> The Apache Way is community over code, a community working together makes
> for high quality code that is safe to build upon. When one member of a
> community starts behaving abusively towards other members of the community,
> the code suffers. Again, wearing my PMC member's hat, this has got to stop.
>
>>  (In the
>> interim, I had to set aside time to make the merge to mod_ldap - that is
>> how the ASF works, [s]he who does the work makes the decisions.)
>
> I have already declared my intention to veto any attempt to dump this code
> in httpd. Our end users and vendors deserve to be treated better than this.
>
> Regards,
> Graham

There's a lot of extraneous information here which is not related to
removing LDAP from APR 2.0-dev.

What are the critical facts?

LDAP support in APR 2.0:

* there was [almost] no support for preserving the status quo; those
that spoke up wanted either to make it a full API or drop it
** more wanted to drop it
** Graham offered to do the work to make it a full API

* AFAIK we did not resolve the fact that more people spoke up for
removal than for making it a full API ("tentative compromise"?)

* nobody got around to either removing it or making it a full API for
a long time afterwards, for the same multitude of reasons that other
things do not get done

* wrowe finally got around to take action, which was to yank it
** I dunno if that was preceded by a notice, which would have been
"nice"  (no, I haven't spent much time in my inbox :( )

Any dispute so far?

What is veto-able?  Nothing, AFAICT.  There's no technical issue.

Separately, the current state of the code matches the group think when
this was discussed before.  If the group think changes, it can come
right back in, in a state that matches the group think.

Where are users left?

httpd users aren't expected to be left out, but that's not our problem here.

What is the set of APR users which depend on the moderate help
provided by apr-util 1.x for dealing with multiple LDAP toolkit?  I
don't know.  I doubt that many users are impacted, and the moderate
level of assistance provided by apr-util wasn't the normal APR
experience anyway.  Those users didn't step up to help at any rate.

Mime
View raw message