httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: svn commit: r567091 - in /httpd/httpd/trunk: CHANGES modules/ldap/util_ldap.c
Date Fri, 17 Aug 2007 18:31:06 GMT

On Aug 17, 2007, at 2:12 PM, Jeff Trawick wrote:

> On 8/17/07, Jim Jagielski <> wrote:
>> On Aug 17, 2007, at 1:46 PM, Eric Covener wrote:
>>> On 8/17/07, Jim Jagielski <> wrote:
>>>> Does this change really require a CHANGES entry??
>>>> wrote:
>>>>> Author: covener
>>>>> Date: Fri Aug 17 10:33:11 2007
>>>>> New Revision: 567091
>>>>> URL:
>>>>> 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.

The issue is how does someone know if the fix in
CHANGES applies to them? As it is currently
written, they don't. There's no "background"
to the bug... In fact, it doesn't even "read"
*as* a bug. This needs to be changed. Either
a better bug description in CHANGES or else
put the bug description in Bugzilla and then
close it out.

View raw message