From dev-return-22359-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Oct 06 14:18:03 2009 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 11202 invoked from network); 6 Oct 2009 14:18:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Oct 2009 14:18:03 -0000 Received: (qmail 31587 invoked by uid 500); 6 Oct 2009 14:18:02 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 31482 invoked by uid 500); 6 Oct 2009 14:18:02 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 31474 invoked by uid 99); 6 Oct 2009 14:18:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Oct 2009 14:18:02 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 72.14.220.153 as permitted sender) Received: from [72.14.220.153] (HELO fg-out-1718.google.com) (72.14.220.153) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Oct 2009 14:17:53 +0000 Received: by fg-out-1718.google.com with SMTP id e21so917743fga.13 for ; Tue, 06 Oct 2009 07:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=n78x0ytoAFRjG9iN3Kkxc3RShcC7/EYW5+tZGlg65EU=; b=B8FUZR/iBVfOUEXoxJJmFpwpjaOuwGizabogx1IkYrkwp2vm3ZjPuT3dm73CRypEWS q24j13xQI4gzXf1Q24dLAN/TpM2OcaOe1IZaaE0FVFuYFrzLxsRzi9nrclJcqbVTfCcK FwkLk42QH083WV9ft0cR+LMK+r22cZ39Bf9f0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bZDOihwas0dvBVvc0Awkt+HPEE22KBCmZuZACYD9gjZ/dr7XG6mLaV/VjHPcjRERG4 8/9m0J6CwHSELg0gH7uJx2csh9epswNfTvq9vZkXrj+8hHyhUZ7oozi8J3wLZfNOppV5 VruL2hkRSZ4SaeWqieYrv1IwvZJKlk5CwbFNw= MIME-Version: 1.0 Received: by 10.86.230.30 with SMTP id c30mr552574fgh.68.1254838589759; Tue, 06 Oct 2009 07:16:29 -0700 (PDT) In-Reply-To: <4ACB4D03.4060808@sharp.fm> References: <20091006132009.4A9842388874@eris.apache.org> <4ACB4D03.4060808@sharp.fm> Date: Tue, 6 Oct 2009 10:16:29 -0400 Message-ID: Subject: Re: svn commit: r822263 - /apr/apr-util/branches/1.4.x/CHANGES From: Jeff Trawick To: dev@apr.apache.org Content-Type: multipart/alternative; boundary=001485e29a4c64a084047544e020 X-Virus-Checked: Checked by ClamAV on apache.org --001485e29a4c64a084047544e020 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 6, 2009 at 9:58 AM, Graham Leggett wrote: > trawick@apache.org wrote: > > > URL: http://svn.apache.org/viewvc?rev=822263&view=rev > > Log: > > Remove entries for iterative fixes to the crypto feature since > > it has not yet been in a release. > > > > Remove entry for a change to the apu_dso_load() interface since > > it is a private function. > > Can someone explain (and document) the new thinking behind how CHANGES > is supposed to work? > 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.) --001485e29a4c64a084047544e020 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 6, 2009 at 9:58 AM, Graham Leggett <= span dir=3D"ltr"><minfrin@sharp.fm> wrote:
trawick@apache.org<= /a> wrote:

> URL: http://svn.apache.org/viewvc?rev=3D822263&view=3D= rev
> Log:
> Remove entries for iterative fixes to the crypto feature since
> it has not yet been in a release.
>
> Remove entry for a change to the apu_dso_load() interface since
> it is a private function.

Can someone explain (and document) the new thinking behind how CHANGE= S
is supposed to work?

Generally: If it isn't us= eful info to library users, it doesn't go in CHANGES.=A0 We track CHANG= ES based on releases, not based on Subversion commits, so a further refinem= ent 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 patche= d n times (like many new features do), the only entry needed in CHANGES is = the one that announces the feature.=A0 Once the feature has actually been i= n 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_ds= o_load function), it doesn't go in CHANGES.

I don't see anyt= hing new about this philosophy.=A0 (That's not to say that the philosop= hy has been followed faithfully until now.=A0 It just seemed obvious to me = that this particular CHANGES should be cleaned up on behalf of folks wonde= ring why there is going to be an APR-util 1.4.0 release.)

--001485e29a4c64a084047544e020--