apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r822263 - /apr/apr-util/branches/1.4.x/CHANGES
Date Tue, 13 Oct 2009 12:22:44 GMT
Jeff Trawick wrote:

> My understanding: Each of these deleted entries thus far is a minor
> implementation detail related to the new apr_crypto feature.  As the
> feature was never released, they do not fix a problem for the users of
> our library.  OTOH, any of these if tied to a particular user symptom
> could be interesting in the change log for a bug fix release, such as
> 1.4.1.

Now that I have some time to draft a proper reply.

The argument that "the feature was never released" becomes moot the
moment the code is released, and that will happen when we ship APR
v1.4.0 (or APR v2.0.0).

At that point, end users are going to want to know what's changed
between the last release and this one. And in the case of APR v2.0.0,
people are *really* going to want to know what has changed.

More specifically, people are going to want to know exactly how that
change got there, and that feature morphed over time to become what it
is now.

What you're arguing for is a "dumbed down" version of CHANGES, where
only a general announcement of a feature is included, but the core
details of how the feature got there are erased. And I'm firmly opposed
to that.

CHANGES isn't a marketing brochure, it's the thing that will show up in
google searches when end users are trying to debug a problem. And we can
fully expect problems to found when APR v2.0.0 is released, and people
to want to fix them.

There is a further, deeper reason why I oppose these changes to CHANGES
- the changes documented were committed 18 months ago. Without having
recent memory to go by, we are arbitrarily chopping out sections of our
history based in whether an entry looks "important" or not. We are
changing our historical record, and that is a really bad idea.

We have no idea what information might be vital to an end user to solve
a particular problem they have. An innocuous looking change could be the
cause of a bug. And no, end users of the library aren't going to be
checking out apr from svn to try and find the history.

We certainly should not be making end user's lives more difficult for
the sake of saving a few bytes.

On this basis, my -1 stands. Please revert the CHANGES (so to speak).


View raw message