On Tue, Oct 6, 2009 at 11:24 AM, Graham Leggett <email@example.com> wrote:
Jeff Trawick wrote:Right, there is nothing new about this philosophy at all, but I see no
> Generally: If it isn't useful info to library users, it doesn't go in
> CHANGES. We track CHANGES based on releases, not based on Subversion
> commits, so a further refinement is that entries should be useful info
> for library users who download a release from us, not for those who svn
> up every few days.
> If before a new feature is delivered the first time it has to be patched
> n times (like many new features do), the only entry needed in CHANGES is
> the one that announces the feature. Once the feature has actually been
> in a release, CHANGES entries for following releases should show how it
> was fixed.
> If some internal detail is changed (like a change to the private
> apu_dso_load function), it doesn't go in CHANGES.
> I don't see anything new about this philosophy. (That's not to say that
> the philosophy has been followed faithfully until now. It just seemed
> obvious to me that this particular CHANGES should be cleaned up on
> behalf of folks wondering why there is going to be an APR-util 1.4.0
match between the philosophy you've mentioned above, and criteria for
entries you removed from CHANGES.
For example, you removed this:
*) Add apr_crypto implementations for OpenSSL and Mozilla NSS.
It is in CHANGES; it isn't listed separately from the apr_crypto announcement.
Add a unit
test to verify the interoperability of the two modules.
IMO that is developer-only information that isn't needed by users.
to disabled unless explicitly enabled.
That could be interesting; I'll add it back.
That part is on the one apr_crypto announcement.
One of the key reasons the original apr_ssl code was vetoed was because
no second implementation existed that proved the abstraction was viable.
To fix that veto, implementations for OpenSSL and NSS were provided, and
the above changes entry confirms that.
As I said, it is in CHANGES still.
Someone asking the question "was my veto resolved" is going to go
straight to CHANGES to check. Only you've just removed the entry, so
there isn't a way they'll know, and they'll end up reopening the
The entries you've removed from CHANGES represent a significant period
of work that cover a number of months of development, I suspect you have
underestimated just how much scope these entries covered.
"period of work" and "number of months" aren't relevant to CHANGES
key differences between APR v1.3 and APR v1.4, and are definitely of
interest to library users.
please call out explicitly the other CHANGES entries I removed for which you would like an explanation.
I believe the key differences are in there. I'll add back the "disabled by default" aspect. First,