Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates
 64.233.182.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=lE5MDxhJSuT2UqLWxoCtJQdpYl1UFrKXDwzyf17FTr0DOfeco55I4En+7u9aRFI4mrqWYI4eUjfJvuaPwO1k+ZOjnbyg684I6kaz8WxniIk6ptfc9cBntAtqOfISkLFQK789tyD99G2m0DLjKxfaAMcuC7PpUxPv41npVBKYpyc=
Message-ID: <cc67648e0708171112kdcd5bbakce6ed9e493569735@mail.gmail.com>
Date: Fri, 17 Aug 2007 14:12:01 -0400
From: "Jeff Trawick" <trawick@gmail.com>
To: dev@httpd.apache.org
Subject: Re: svn commit: r567091 - in /httpd/httpd/trunk: CHANGES
 modules/ldap/util_ldap.c
In-Reply-To: <BB2C9A47-BE9D-48D5-A2F2-617997F640F8@jaguNET.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070817173313.321BB1A981A@eris.apache.org>
	 <200708171740.l7HHebC4051920@devsys.jaguNET.com>
	 <1404e5910708171046t75d9355cy42dc6a313179ec9e@mail.gmail.com>
	 <BB2C9A47-BE9D-48D5-A2F2-617997F640F8@jaguNET.com>

On 8/17/07, Jim Jagielski <jim@jagunet.com> wrote:
>
> On Aug 17, 2007, at 1:46 PM, Eric Covener wrote:
>
> > On 8/17/07, Jim Jagielski <jim@jagunet.com> wrote:
> >> Does this change really require a CHANGES entry??
> >>
> >> covener@apache.org wrote:
> >>>
> >>> Author: covener
> >>> Date: Fri Aug 17 10:33:11 2007
> >>> New Revision: 567091
> >>>
> >>> URL: http://svn.apache.org/viewvc?view=rev&rev=567091
> >>> Log:
> >>> AFAICT, LDAP_CACHE_LOCK was a no-op when virtualhosts were used
> >
> > I can expand or remove it; there's crash/hang potential (observed) as
> > the cache code goes into shared memory.
> >
>
> How about creating a PR about it and then closing it out.
> That way it's a documented bug that is closed; if it
> affects people, the PR will provide insight into what
> was wrong and what was fixed, and the CHANGES entry
> can be adjusted to reflect the PR number.

I'm confused.  Visually it doesn't look like Lotus Notes where I'm
reading this, but the message better fits &employer; corporate
standards.  (And yes, in that other world I'd want a formal external
description of the problem with nice text for customers and support to
use to know exactly what conditions they need the fix and what is
changed and so on).  That's very expensive, and also something that
hasn't been done in the past when a developer has a fix to commit.