From dev-return-24299-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Jul 8 19:44:24 2011 Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2A63A65BA for ; Fri, 8 Jul 2011 19:44:24 +0000 (UTC) Received: (qmail 91815 invoked by uid 500); 8 Jul 2011 19:44:23 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 91712 invoked by uid 500); 8 Jul 2011 19:44:22 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 91697 invoked by uid 99); 8 Jul 2011 19:44:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jul 2011 19:44:22 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.214.50 as permitted sender) Received: from [209.85.214.50] (HELO mail-bw0-f50.google.com) (209.85.214.50) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jul 2011 19:44:14 +0000 Received: by bwb11 with SMTP id 11so2529389bwb.37 for ; Fri, 08 Jul 2011 12:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=lKXQptgxyMLWQ2PCZnXnuA+k12wEe0yYkGtOetXM9us=; b=q8db0Kk8v9FRbvhXlYU3kK7z52gn0yJwVlFI8LXu5utbyGcgMjsV7owfoWRZqmdF3y qc/0ramOrDKJgZ7vC15WDSNO8Xbz4DnOTbScl4lcUiUKFXhLa+HBS3oCmpI8OWl6S//B B3B4LYKrs57reOoPykzOu574dNQMADw8FF8nI= MIME-Version: 1.0 Received: by 10.204.24.68 with SMTP id u4mr1537584bkb.12.1310154234478; Fri, 08 Jul 2011 12:43:54 -0700 (PDT) Received: by 10.204.113.133 with HTTP; Fri, 8 Jul 2011 12:43:54 -0700 (PDT) Date: Fri, 8 Jul 2011 15:43:54 -0400 Message-ID: Subject: [RFC] Is removal of the LDAP feature from APR trunk veto-able? From: Jeff Trawick To: dev@apr.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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.)