apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r822263 - /apr/apr-util/branches/1.4.x/CHANGES
Date Tue, 06 Oct 2009 15:41:08 GMT
On Tue, Oct 6, 2009 at 11:24 AM, Graham Leggett <minfrin@sharp.fm> 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

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

View raw message