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, 06 Oct 2009 15:24:28 GMT
Jeff Trawick wrote:

> 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
> release.)

Right, there is nothing new about this philosophy at all, but I see no
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. Add a unit
     test to verify the interoperability of the two modules. Builds default
     to disabled unless explicitly enabled.
     [Graham Leggett]

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.

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
discussion unnecessarily.

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. They detail
key differences between APR v1.3 and APR v1.4, and are definitely of
interest to library users. Please revert.


View raw message