Gentoo Archives: gentoo-dev

From: Jim Ramsay <lack@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Date: Sun, 02 May 2010 15:14:13
Message-Id: 20100502151350.GA1280@woodpecker.gentoo.org
In Reply to: Re: [gentoo-dev] [git migration] The problem of ChangeLog generation by Peter Volkov
1 Peter Volkov wrote:
2 > ?? ??????, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??????????:
3 > > The traditional ChangeLog that is currently employed in gentoo-x86
4 > > (and in other projects) is simply an ugly hack
5 >
6 > The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used
7 > in other projects is
8
9 I think another very important distinction (that you imply below,
10 but I want to specifically point out here) is that we have *many*
11 per-project ChangeLogs whereas most other projects have a
12 *single* monolithic ChangeLog.
13
14 > > Think of it like this: if you make a typo in a commit message, or
15 > > forget to add something; you can't change it after you've published
16 > > the commit (cvs/svn commit or git push) to the world.
17 >
18 > And then it's better to keep ChangeLogs. For developers it was never a
19 > problem to script `echangelog "log" && repoman commit -m "log"` and
20 > conflict resolution is really not that hard with git. In spirit of
21 > Gentoo, it's better to write some tool to update Manifests after
22 > conflict resolution instead of making ChangeLogs less useful for those
23 > who uses them.
24
25 This is a very good point regarding ease of conflict resolution.
26
27 Further to my other point above, the traditional ChangeLog
28 ugliness really only hits you with a centralized setup+git if
29 *everyone* is editing the *same* ChangeLog: If every commit
30 touches the same file in the same place (ie, prepending to a
31 ChangeLog file in the same location), you are guaranteed to have
32 collisions every time you pull a new version of the file. This
33 is why most projects with a single monolithic changelog
34 auto-generate them, or perhaps just craft them at release time.
35
36 Our case, though it is a centralized repository model, is quite
37 different. The chance of collisions in a package-specific
38 ChangeLog is, as it is today with CVS, pretty unlikely. In fact,
39 I think the only time it usually happens to me is when an arch
40 stabilizes my package while I'm making a change, and these are
41 very easy to fix.
42
43 (In fact, it may be possible to help git out with this specific
44 ChangeLog situation by using a "custom merge driver", see
45 GITATTRIBUTES(5) for details, though deployment of a custom merge
46 driver can be tricky)
47
48 > BTW as for profiles ChangeLogs... May be it's better to generate them.
49
50 That's another important distinction and probably a good idea. I
51 think those profile ChangeLogs are also not as user-facing as the
52 per-package ones, so an autogenerated one makes a lot of sense.
53
54 --
55 Jim Ramsay
56 Gentoo/Linux Developer (rox/fluxbox/gkrellm)