Re: changelog rotation...

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
>> I actually like the split-by-year scheme.  This tends to place about
>> the right number of entries in each file regardless of whether there
>> are six months or two years between GDB releases.

Eli> Why is this important to have ChangeLog files be of similar sizes?

IMO, ChangeLogs should have sufficent information density yet not be
so large that they are difficult to use.

What I mean by information density is that a ChangeLog file should be
"large enough" that it is likely to contain entries that refer to the
same change.  In my experience, changes are not always 100% correct
when they are committed.  In most cases, residual problems are quickly
identified and fixed; but occasionally a problem is discovered months
afterward.  I find it convenient to be able to search backwards in the
same changelog file to find related changes.  

Of course this breaks down at the changelog rotation dates.  This
could be fixed by having just one (huge) ChangeLog file, but that has
its own problems.  Recently there was a discussion on the gcc list
about the large ChangeLog causing problems with remote CVS on slow
networks.

If we had a lot more changes, a more frequent rotation interval might
be more appropriate; while if GDB development slowed down, a slower
one might be best.  I think it is interesting to note that the sizes
are roughly the same over the last 10 years.  Perhaps that indicates
that something is bounding the rate of change that can be sustained on
GDB (lack of infrastructure, lack of volunteers, lack of interest,
etc.).  If we could identify and eliminate those roadblocks, we might
be able to make larger strides in the coming years.

But for now, the split-by-year scheme that we have been using seems to
be a good balance of these opposing forces.

        --jtc

-- 
J.T. Conklin
RedBack Networks