Re: ChangeLog entry complexity

[Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>]

On 25 March 2013 23:02, Carlos O'Donell <carlos@redhat.com> wrote:
> None in that case. I agree. We don't do much refactoring in glibc,
> but you do raise the very good point that writing change notes for
> refactoring is a serious issue.
>
> I still don't feel like your example applies to the kinds of patches
> we are actually getting on libc-alpha today, but you have made a valid
> point about refactoring.

Maybe we don't get those kinds of patches today because the ChangeLog
is too much work ;)

A closer example probably is adding a new function, where the abilist
of a dozen architectures is updated and you have to write individual
snippets for different ChangeLog files.

>> I'm pretty sure most developers don't take the ChangeLog seriously at
>> all, and therefore that's a place where errors are happening anyways.
>
> I take them seriously myself and when I do reviews.

I take them seriously too, but not because I care about them.  I take
them seriously under the assumption that everyone else cares about
them.

>> ChangeLog files are absolutely of zero value when you have powerful
>> version control, as we do.
>
> I can agree to a certain degree.

I was a support technician until not so long ago and my job was to
single out changes from upstream for backports.  When trying to find
out why a change was made, I only looked at ChangeLogs as a desperate
last attempt and in the few times I've done that, I don't remember a
single instance where they were helpful.  In contrast, every kernel
change is an education in itself because you can read why a certain
change occurred and you can then relate that to the 'how' by simply
reading the code.  I guess it could have been worse, like bash or ksh
where there is no revision control system[1].

> We need someone to lead the community through a transition from a
> process we know how to use to one we don't.
>
> If you feel strongly about the issue I would be more than happy
> to talk about how we can make this transition happen, but it will
> require non-zero work to move us in a new direction. Including
> a more thorough discussion on how we perform reviews and what's
> expected of a reviewer.

For something that's as completely useless as a ChangeLog, we could
just _stop_ doing it.  If not right now, we could stop doing it after
the next freeze and thaw, i.e. 2.19 development.  A git-email type
workflow should be good for us since it captures everything that we
need.

1. Submitter sends an email with the patch.  The email contains a
description of why the change is needed, the kind of testing done,
etc. which would eventually be part of the commit log along with a
Signed-off-by tag.
2. If the patch needs changes, then the reviewer suggests them and
we're back to (1).
3. Reviewer acks the change using the Acked-by tag.  (S)he may ask for
a second review, which will result in a second Acked-by tag.
4. After receiving sufficient acks, the submitter pushes the patch
with the signed-off and acked tags in place.

I guess this mostly is the process in the kernel project (based on the
couple of patches I've submitted in the past) with the exception of
the last step of actually pushing changes, which seems to be limited
to a few people.  This immediately gives us the extra feature of
tracking which change was acked by which reviewer, which is difficult
to achieve currently with our workflow.

Siddhesh

[1] Of course, bash has a revision system now, although I'm not sure
how useful it is.
-- 
http://siddhesh.in