This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ChangeLog entry complexity

On 03/25/2013 01:07 PM, David Miller wrote:
> From: "Carlos O'Donell" <>
> Date: Mon, 25 Mar 2013 12:55:46 -0400
>> Does anyone feel strongly that detailed change logs are limiting our
>> acceptance of new developers to the community?
> Let's take a real simple example.
> I figure out that internal function FOO no longer uses argument X,
> so I'm going to remove argument X from the interface.
> There are 1000 call sites.
> What value does that 1001 line ChangeLog entry provide?

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.

> Absolutely zero, and it's a waste of the submitter's time.  I might
> not do the conversion because the ChangeLog is so laborious.

I wouldn't judge you if you did.

> 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.

> And I know for a fact that many of Ulrich Drepper's large commits
> in the past ommitted many of the changes his patches made.  In fact
> he would always commit the ChangeLog update as a completely separate
> commit from the changes themselves.

That's disappointing.

> So you can't even say that the ChangeLog provides a way to search for
> changes, since it is provably non-trivially incomplete.

Also disappointing. Hopefully this is not happening today.

> ChangeLog files are absolutely of zero value when you have powerful
> version control, as we do.

I can agree to a certain degree. 

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]