On Tue, Oct 6, 2009 at 11:24 AM, Graham Leggett <[email protected]> wrote:
> 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. > 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. Builds default > to disabled unless explicitly enabled. > That could be interesting; I'll add it back. > [Graham Leggett] > 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 > 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. "period of work" and "number of months" aren't relevant to CHANGES > They detail > key differences between APR v1.3 and APR v1.4, and are definitely of > interest to library users. I believe the key differences are in there. I'll add back the "disabled by default" aspect. First, please call out explicitly the other CHANGES entries I removed for which you would like an explanation.
