Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Nirbheek Chauhan]

On Thu, Jun 2, 2011 at 4:59 AM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@g.o> wrote:
> On 01-06-2011 19:50, Nirbheek Chauhan wrote:
>> The current situation is:
>>
>> (a) Not dire.
>> (b) Not urgent.
>
> (c) has irked enough developers and users that people pushed council to
> update the policy about the use of ChangeLogs.


Yes, and I'm surprised that these same developers pushed towards a
negative solution (kick productive people out) rather than a positive
solution (move to git).

>> And if we decide, hey, let's move to git instead of having this
>> discussion, the current situation is also:
>>
>> (c) A waste of everyone's time.
>>
>> So no, future plans are not independent of the current situation, and
>> a move to git *is* a way to deal with the current situation.
>>
>> In effect, we kill (at least) two birds with one stone and prevent a
>> lot of argument and bad blood.
>
> To be clear I support the goal to move our tree to git.
> However, I'd like to point out that simply moving to git will leave us
> in the same state. Assuming everyone agrees that git is far more useful
> than cvs to check for changes in the tree, a simple but important issue
> remains: the plan is to move the "development tree" to git, but to keep
> the rsync mirrors for users. So the "move to git" doesn't fix the issue
> for users or developers using an rsync tree.

Arguably, if developers want to know the history they should use the
copy of the git tree that they're supposed to be having. Relying on
ChangeLogs for history is just silly if you have the complete history
at your fingertips with git.

> One solution that has been proposed before and that was raised again in
> this thread is to generate ChangeLogs directly from scm commit messages.
> That is already a solution with cvs, so moving to git won't help here.

This is not true. One of the main problems of generating ChangeLog
messages from cvs/svn is that you don't have much control over the
`cvs log` output, cvs itself is extremely slow, and cvs maintains log
information *per-file*. Hence ChangeLog generation in the format we
want would be slow/impractical. There's tens of thousands of packages.
How long do you think it'll take to generate ChangeLogs from cvs for
all of them?

Notice how every project that did a move to git from cvs/svn started
auto-generating ChangeLogs[1]. One reason was that ChangeLogs will
*always* cause merge conflicts, and they're duplicate information, so
there's no point keeping them in the local tree. The other reason is
that with git it takes a fraction of a second to generate a ChangeLog
from the commit messages.

1. https://live.gnome.org/Git/ChangeLog

> The same objections that have been raised about doing it for cvs, not
> being able to use different messages for the commit message and in
> ChangeLog (something I understand but admit have hardly used before),
> are also valid if we move to git.
>

Not really. This problem has been raised and the solution is to add a
'[trivial]' or '#trivial' etc tag to the commit message (either
subject of body), and it won't be included in the auto-generated
ChangeLog.

The main issue that people have with not writing ChangeLog messages
for removals is that developers can't figure out when, why, and by
whom an ebuild was removed; because there's no ChangeLog entry, and
cvs log/cvs diff is too painful to use. This makes it hard to fix
breakage.

There's a fringe issue of users wanting to know why an 'old' ebuild
was removed while they're offline in a train or something (and don't
want to keep a cloned git repo around), but that's not reason enough
to kick our second-most-hardworking developer.

In essence, the most basic issue here is *not* users who want to have
all information offline, but the fact that /developers/ rely on
ChangeLog for information because cvs log/diff suck. Note that the
developer in question always wrote proper commit messages, so `git
log` WOULD solve all our problems.

Cheers,

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team