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:10:52 GMT
On Thu, Jun 2, 2011 at 10:09 AM, Jeff Trawick <trawick@gmail.com> wrote:
> 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

(since httpd is working on a solution that doesn't rely on APR)

> 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.
>



-- 
Born in Roswell... married an alien...

Mime
View raw message