Re: [STATUS] 1.2.1

["Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU>]

>>Vote on these over next few days.  Commit them to 1_2_X branch (be sure to
>>update CHANGES, I notice that HEAD is missing some CHANGES updates).
>
>Don't bother. Our "policy" (actually, something I decided a few months
>ago when I noticed src/CHANGES was rather large, and no one
>complained) is to not update src/CHANGES for major releases (e.g.,
>1.3b1), only for minor ones (.e.g, 1.2.1, 1.3b2).

Consider this a complaint.  Doing that left a huge gap in our acknowledgement
of contributions, which I was unable to fill because poring over four months
worth of new-httpd per gap is not my idea of fun.  As far as I'm concerned,
committing a developer-visible change to the source without a corresponding
entry in the CHANGES file is justification to revert the change.

If CHANGES gets too big (whatever that means), we can always trim it later.

....Roy

Re: [STATUS] 1.2.1

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Mon, 23 Jun 1997, Roy T. Fielding wrote:

> Consider this a complaint.  Doing that left a huge gap in our acknowledgement
> of contributions, which I was unable to fill because poring over four months
> worth of new-httpd per gap is not my idea of fun.  As far as I'm concerned,
> committing a developer-visible change to the source without a corresponding
> entry in the CHANGES file is justification to revert the change.
> 
> If CHANGES gets too big (whatever that means), we can always trim it later.

Actually, that wasn't really the real problem. I was remembering the
reason I made the change incorrectly. The reason was that we had done
six months of Apache development, only about 5% of which was noted in
the src/CHANGES file. No one wanted to go through thousands of
apache-cvs mails and fill in the remainder, so we decided to just
erase all of them.

IMHO, that's appropriate. cvs log will tell developers everything they
need to know, and users don't really need to know every single change
that happened in a large release, especially when many of those
changes are contridicary and redundent ("Added foo feature." "Fixed
foo feature." "Oops. Really fixed it this time." "Decided to remove
foo feature." "Added foo again, this time with different code." "Fixed
it again.")

So Roy, if you want to take charge of making sure CHANGES is kept up
to date, be my guest. But it's not something we were able to do
between 1.0 and 1.1, nor 1.1 and 1.2. It only really seems to work for
us with smaller releases.

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/