[Development] ChangeLogs

Sergio Ahumada sergio.ahumada at digia.com
Tue Mar 12 16:55:54 CET 2013

On 02/06/2013 07:25 PM, Olivier Goffart wrote:
> On Thursday 31 January 2013 07:50:32 Koehne Kai wrote:
>>> -----Original Message-----
>>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>>> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
>>> Behalf Of Matt Williams
>>> Sent: Tuesday, January 29, 2013 11:14 AM
>>> To: development
>>> Subject: Re: [Development] ChangeLogs
>>> On 29 January 2013 00:31, Alan Alpert <416365416c at gmail.com> wrote:
>>>> On Mon, Jan 28, 2013 at 4:21 AM, Jason McDonald
>>> <macadder1 at gmail.com> wrote:
>>>>> 4. Let's try to make the job of our maintainers that little bit
>>>>> easier by writing good commit summaries and diligently reviewing the
>>>>> commit summaries of our peers.
>>>> +1, but I think the tool is a more realistic way of making the task
>>>> easier for the maintainers.
>>> Within KDE we use a tool called Enzyme (http://enzyme-project.org/) which
>>> allows you to go through all the commits, marking certain ones as
>>> interesting in a collaborative way. It might not have _all_ the feature
>>> needed but it would probably help along the way. It's open-source so we
>>> could always tweak it as needed.
>> I'm all for a tool making things easier for the one writing the actual
>> ChangeLog file. But I think it's somewhat orthogonal to the question
>> whether the original author of a fix should write a ChangeLog line
>> somewhere, too .
>> So, did we come to any conclusion regarding adding a "ChangeLog: " entry to
>> commits? IMO it's worth a try.
> I'd say yes,
> Put a "Changelog:" entry somewhere with some text that will be processed
> manually by the release manager to fill the changelog.
> (The release manager can grep for it, and that will ease his task a lot to
> have already ready made sentence)
> [ The ones who are concerned about a bit of reddundancy in the commit message
> should as well leave the commit empty since it is already redundent with the
> diff itself :-) ]


Since it doesn't seem to be a final decision/consensus about this, I 
will just create empty changes files for 5.0.2 and Maintainers will have 
to fill them up.

ps1: any idea about the "git merge-driver" suggestion and/or the (qml 
based?) UI tool suggestion ?
ps2: I only found https://codereview.qt-project.org/47802 using the 
ChangeLog entry

Sergio Ahumada
Release Engineer - Digia, Qt

More information about the Development mailing list