Peter Volkov wrote:
> ?? ??????, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??????????:
> > The traditional ChangeLog that is currently employed in gentoo-x86
> > (and in other projects) is simply an ugly hack
>
> The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used
> in other projects is

I think another very important distinction (that you imply below,
but I want to specifically point out here) is that we have *many*
per-project ChangeLogs whereas most other projects have a
*single* monolithic ChangeLog.

> > Think of it like this: if you make a typo in a commit message, or
> > forget to add something; you can't change it after you've published
> > the commit (cvs/svn commit or git push) to the world.
>
> And then it's better to keep ChangeLogs. For developers it was never a
> problem to script `echangelog "log" && repoman commit -m "log"` and
> conflict resolution is really not that hard with git. In spirit of
> Gentoo, it's better to write some tool to update Manifests after
> conflict resolution instead of making ChangeLogs less useful for those
> who uses them.

This is a very good point regarding ease of conflict resolution.

Further to my other point above, the traditional ChangeLog
ugliness really only hits you with a centralized setup+git if
*everyone* is editing the *same* ChangeLog: If every commit
touches the same file in the same place (ie, prepending to a
ChangeLog file in the same location), you are guaranteed to have
collisions every time you pull a new version of the file. This
is why most projects with a single monolithic changelog
auto-generate them, or perhaps just craft them at release time.

Our case, though it is a centralized repository model, is quite
different. The chance of collisions in a package-specific
ChangeLog is, as it is today with CVS, pretty unlikely. In fact,
I think the only time it usually happens to me is when an arch
stabilizes my package while I'm making a change, and these are
very easy to fix.

(In fact, it may be possible to help git out with this specific
ChangeLog situation by using a "custom merge driver", see
GITATTRIBUTES(5) for details, though deployment of a custom merge
driver can be tricky)

> BTW as for profiles ChangeLogs... May be it's better to generate them.

That's another important distinction and probably a good idea. I
think those profile ChangeLogs are also not as user-facing as the
per-package ones, so an autogenerated one makes a lot of sense.

--
Jim Ramsay
Gentoo/Linux Developer (rox/fluxbox/gkrellm)