Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 209.85.214.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=WdHpqjGYioufihyLNyHLk+8ZU+IAk9YsFKEkl4qeGOT45c9FdnmSnr0Uul4FbuUHbg
         EaOSy4tkoVmJmMe+zSxC01N4ZEspG2K5YNF6oZgbVAnlKdJVI9QvGVv/YiiLHOcxHj9N
         x9SHpbQzRbnP9CYU90dTaccAiMYNb/Uq5fSQY=
MIME-Version: 1.0
In-Reply-To: <06420815-80CD-4C94-946E-703B200650CD@sharp.fm>
References: <20110529145931.60F722388901@eris.apache.org>
	<38C960CC-8BA2-4609-8564-5D64AE7F2925@sharp.fm>
	<4DE4FC69.90803@rowe-clan.net>
	<186558C0-B164-4899-85C7-6A71474D647E@sharp.fm>
	<4DE537E5.5050208@rowe-clan.net>
	<6EE4576E-8BA3-4DAB-89C4-CF2EE2408DDA@sharp.fm>
	<4DE6C90A.9030302@rowe-clan.net>
	<06420815-80CD-4C94-946E-703B200650CD@sharp.fm>
Date: Thu, 2 Jun 2011 10:09:38 -0400
Message-ID: <BANLkTinY8NogH8=o-QUff7sS69zPokp_sA@mail.gmail.com>
Subject: Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4
 build/apu-ldap.m4 configure.in
From: Jeff Trawick <trawick@gmail.com>
To: APR Developer List <dev@apr.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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/%3C5c902b9e=
0903240326r3222ac90k15dcb7f34d2d1587@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 amou=
nt
> of other work on fixing the mod_cache API in time for the imminent releas=
e
> 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 wor=
k
> 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 communit=
y,
> the code suffers. Again, wearing my PMC member's hat, this has got to sto=
p.
>
>> =A0(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 cod=
e
> in httpd. Our end users and vendors deserve to be treated better than thi=
s.
>
> 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.