Re: Generating the ChangeLog files from the commit messages

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> We should generate a single ChangeLog, OTOH.
> Btw, there's another minor issue with a single large ChangeLog: the
> size suggested by Paul (32MB AFAIR) is above the default value of
> large-file-warning-threshold (currently 10,000,000 bytes).

IIUC this figure was computed for a combined single file of the
whole history.  The generated file would start empty (since it wouldn't
include the part that's already present in the existing ChangeLog files).

It makes sense to roll those files on a release-number basis rather than
just size.

Paul said:
> The 10 MB limit is too small nowadays for typical machines.

Could be.  I rarely bump into it, personally.  But I wouldn't mind
increasing it a bit, tho probably not by a factor of ten.

> I regularly run into it and it's a genuine (albeit minor) annoyance.

What value would stop you from bumping into it, and on which kinds of
files do you typically bump into it.

> When the 10 MB limit was established back in 2003, machines typically
> had 64 MiB or so of RAM.

Reality check: my 2003-vintage X30 laptop (which I happily use when
doing presentations) came with 768MB of RAM.  This was fairly generous
back then (it's actually the max it can take, AFAIK).  The 2003 12"
PowerBook I got at the same time had 256MB (with a max of 1.25GB) and it
was considered "under provided" so I upgraded it to 786MB even before
I added a wifi card to it.  IOW I don't think 64MB was typical back then.

> Nowadays 8 GiB is closer to being typical and the 10 MB limit is way
> below the sweet spot for warnings.

But the size of human-edited files (the bread-and-butter for Emacs)
hasn't increased nearly as much.


        Stefan