apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject [RFC] Is removal of the LDAP feature from APR trunk veto-able?
Date Fri, 08 Jul 2011 19:43:54 GMT
Here's one attempt at approaching the question of features and
veto-ability.  This is of course just my
understanding^H^H^H^H^H^H^Hopinion.  (Purposefully omitted: APR's LDAP
feature had one user -- httpd -- and that one user now has the
necessary code, even if not all the build bits are working yet.)

The presence of most features in APR is highly subjective.  I.e.,
there's no technical requirement for APR that says it must or must not
have the LDAP or memcached or various other features.  Whether or not
it is present is not veto-able.  The group of developers must
collectively agree on the feature set.

The manner in which an APR feature is implemented has a handful of
technical characteristics which should be met.  Incompatibility with
the basic technical characteristics is veto-able.  Providing a feature
which uses a different memory management mechanism or different kind
of programming interface or a mixture of APR and non-APR programming
interfaces are examples of technical characteristics which are
objectively incorrect.

APR versioning rules place specific restrictions w.r.t. version
boundaries on removals of features which don't meet requirements or
additions of features which do.  Breaking any of the versioning rules
while adding or removing features is veto-able.

LDAP specifically:

Deficiencies in the LDAP interface were identified and not addressed
over a large period of time.  The group of developers sharing an
opinion made clear the required technical corrections which must be
made in order for the LDAP feature could remain for APR 2.0.  In fact
this was a compromise position, compared with the more extreme and
well supported position of removing it entirely instead of fixing it.
No APR developer besides Graham was aware of any progress on
correcting the deficiencies over that time.

The presence of LDAP in trunk without correction was veto-able.  The
removal of LDAP in trunk was not veto-able, as it merely was the
default resolution to satisifying the technical objections expressed
previously.  Importantly, removing it from trunk didn't prevent the
deficiencies from being corrected.  (But we can't go down this path
far without consideration of httpd actions, since httpd is the one
identified user.)

View raw message