I should have added:
Note that all of this is not about ChangeLog, but about po/ChangeLog.
On Thu, Mar 20, 2008 at 9:20 AM, Stéphane Charette
> > > For example, try to run the command "make distcheck". It dies because
> > > po/ChangeLog doesn't exist.
> > In my understanding, Brian proposed generating ChangeLog
> > from svn logs. If so then there's no need to avoid
> > ChangeLog -- just generate it before the release.
> > It is definitely a good idea to ship ChangeLog files with
> > the released code. It is also the requirement of the GPL
> > to document all the changes made to the code.
> Just so everyone understands, I have no problem with the fact the
> ChangeLog file is gone. Actually, I prefer to have our changes in the
> SVN log.
> But I do have a problem with generating a ChangeLog just for the
> purpose of building a release. When we take a revision from SVN, the
> build for that revision should be easy to duplicate. But now whenever
> someone checks out a 3.+ release tag, it will fail to build. There
> are additional steps/changes required to get a build started! This
> sounds like the wrong thing.
> I would say we have 3 options:
> 1) remove the dependency on ChangeLog from the build process (run
> "make distcheck" and you'll see the failure)
> 2) add an empty ChangeLog file, or one telling people the ChangeLog is
> now available from <URL> or an SVN command
> 3) add to the build process the steps required to dynamically build
> the ChangeLog file
> Think of it this way: The Debian guys who are not on this mailing
> list and don't participate on GRAMPS will eventually see we have a new
> version. Technically, they could check out tag "3.0.0" from SVN and
> attempt to build it and create a .deb file. But the build will fail.
> When you check out an official version from a software repository, you
> don't expect to have to make further modifications before it will