Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Nirbheek Chauhan <nirbheek@gentoo.org>]

On Sun, Jun 5, 2011 at 1:30 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote:
>> All these problems are fixed if we don't re-generate the *existing*
>> ChangeLogs. We should simply archive the existing ChangeLog, and
>> append to it after the move to git.
>
> About this slightly hybrid approach:
>
> - the ChangeLog file is retained, some script just appends from VCS log
>  to it
>  * where is the ChangeLog file stored?
>  * is the VCS log appended to the ChangeLog every time it is generated,
>    or is it "committed" to the file?
> - in case of a committed update to the ChangeLog file (commit hook?
>  repoman?), people would have the ability to edit the ChangeLog
>

I would suggest these things (I've omitted details irrelevant to
ChangeLog management):

(1) Convert using cvs2git, archive the old cvs repo. We now have a git
repo with full history.
(2) The new git tree must be without ChangeLog or (optionally)
non-DIST Manifests. Remove all crud, git commit -m "Cleanup useless
crud".
    Reason: no need to clutter the tree up with useless stuff that no
one should touch. This will reduce the checked-out tree size by half.
(3) No merge commits allowed to gentoo-x86.git. All commits must be
rebased during pulls (git pull --rebase) or before pushing (git rebase
&& git push).
   Reason: keeps the history simple and easy to follow. The server can
be made to reject merge commits. Most centralized git repos already
follow this model.
(4) No forced pushes which rewrite history are allowed to the server.
   Reason: well, this one is obvious. A lot of servers are configured
to completely disallow this.
(5) ChangeLogs do not exist in the git tree, they're maintained in a
separate git repo by a script[1].
   Reason: a git repo with history allows us to debug problems with
the script, and follow its progress.
(6) ChangeLog is updated incrementally with each changeset[2] (or
every $time?), and the changes committed to its own git repo. This is
made possible by (3) and (4).
   Reason: this way the workload of generating the ChangeLog won't
increase at O(n*m) with time[3].
(7) The rsync server just copies over ebuilds, and then ChangeLogs,
re-manifests (introducing non-DIST manifests if needed), maybe signs
everything, and then pushes to mirrors.

[1]. Note that pkgmoves would have to be detected and handled properly.
[2]. This involves updating old ChangeLog entries if there are new git notes.
[3]. n is the no. of commits per package, and m is the total no. of
packages in the portage tree.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team