December 24, 2012
On 12/24/12 12:12 PM, Jonathan M Davis wrote:
> On Monday, December 24, 2012 18:08:58 Andrej Mitrovic wrote:
>> On 12/24/12, Jonathan M Davis<jmdavisProg@gmx.com>  wrote:
>>> I don't understand why you're so against having notes from human beings in
>>> the changelog.
>>
>> I don't understand why we can't have both. One is a list automatically
>> added via bugzilla, and then a separate section of handwritten
>> changes.
>
> Exactly.

worksforme(tm)

Thanks,

Andrei

December 24, 2012
12/24/2012 9:12 PM, Jonathan M Davis пишет:
> On Monday, December 24, 2012 18:08:58 Andrej Mitrovic wrote:
>> On 12/24/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>>> I don't understand why you're so against having notes from human beings in
>>> the changelog.
>>
>> I don't understand why we can't have both. One is a list automatically
>> added via bugzilla, and then a separate section of handwritten
>> changes.
>
> Exactly.
>
> - Jonathan M Davis
>

+1
Just make changelog.dd to be manually edited list of what's new + future plans. Then tuck in an automated tool to generate bugs section to the release packaging scripts.

And automating bug entries list is trivial e.g. here is a D sketch (std.net.curl & std.csv rox) to generate DDoc entries in current changelog.dd format given 2 dates:

https://gist.github.com/3734045

And staying on topic it would be terrific (and simple) to have separate sections on bugzilla entries fixed per category: bugs/enhancements/regressions.

-- 
Dmitry Olshansky
December 25, 2012
On 12/24/2012 9:03 AM, Jonathan M Davis wrote:
> How about the very example that I gave about specifically providing a note to
> developers about the impending changes to std.format? No bug had been fixed,
> and no enhancement request had been implemented. No code change had even taken
> place yet. It was a note about a future change that developers needed to be
> made aware of.

Well, a future change shouldn't be in a *change* log any more than it should be in bugzilla.

What you're talking about should be called "release notes".

December 25, 2012
On Tuesday, December 25, 2012 03:07:35 Walter Bright wrote:
> On 12/24/2012 9:03 AM, Jonathan M Davis wrote:
> > How about the very example that I gave about specifically providing a note to developers about the impending changes to std.format? No bug had been fixed, and no enhancement request had been implemented. No code change had even taken place yet. It was a note about a future change that developers needed to be made aware of.
> 
> Well, a future change shouldn't be in a *change* log any more than it should be in bugzilla.
> 
> What you're talking about should be called "release notes".

If you want to be pedantic about it, sure. But we don't have release notes separate from the changelog at this point. And while some changes which aren't currently put in bugzilla _could_ be put there (e.g. the addition of a new module), that doesn't necessarily mean that they belong there. So, while automating the list of bug fixes makes good sense, having a section of the changelog or release notes or whatever which is written by humans also makes good sense.

- Jonathan M Davis
December 25, 2012
On 12/25/2012 3:14 AM, Jonathan M Davis wrote:
> On Tuesday, December 25, 2012 03:07:35 Walter Bright wrote:
>> What you're talking about should be called "release notes".
>
> If you want to be pedantic about it, sure. But we don't have release notes
> separate from the changelog at this point. And while some changes which aren't
> currently put in bugzilla _could_ be put there (e.g. the addition of a new
> module), that doesn't necessarily mean that they belong there. So, while
> automating the list of bug fixes makes good sense, having a section of the
> changelog or release notes or whatever which is written by humans also makes
> good sense.

I'd be in favor of a changelog auto-generated from bugzilla, and a human editted releasenotes.

Because, as Andrei pointed out, maintaining the changelog is currently tedious and error prone. I know that a number of pull requests have not made it into the current changelog, because the people who pull them do not go through the tedium of doing that, and they shouldn't have to.

Automation is the answer.

December 25, 2012
On Tuesday, December 25, 2012 03:20:26 Walter Bright wrote:
> On 12/25/2012 3:14 AM, Jonathan M Davis wrote:
> > On Tuesday, December 25, 2012 03:07:35 Walter Bright wrote:
> >> What you're talking about should be called "release notes".
> > 
> > If you want to be pedantic about it, sure. But we don't have release notes separate from the changelog at this point. And while some changes which aren't currently put in bugzilla _could_ be put there (e.g. the addition of a new module), that doesn't necessarily mean that they belong there. So, while automating the list of bug fixes makes good sense, having a section of the changelog or release notes or whatever which is written by humans also makes good sense.
> 
> I'd be in favor of a changelog auto-generated from bugzilla, and a human editted releasenotes.
> 
> Because, as Andrei pointed out, maintaining the changelog is currently tedious and error prone. I know that a number of pull requests have not made it into the current changelog, because the people who pull them do not go through the tedium of doing that, and they shouldn't have to.
> 
> Automation is the answer.

I think that that's what most of us are agreed upon at this point. What is currently the WHATSNEW section will continue to be done by hand, but the LIBBUGSFIXED section will be autogenerated.

- Jonathan M Davis
December 25, 2012
On 12/25/2012 3:41 AM, Jonathan M Davis wrote:
> I think that that's what most of us are agreed upon at this point. What is
> currently the WHATSNEW section will continue to be done by hand, but the
> LIBBUGSFIXED section will be autogenerated.

WHATSNEW is a list of new features, which are (or should be) in bugzilla as enhancement requests.

Various musings, rationales, future changes, etc., should go in a separate document called releasenotes.

I don't think it's viable to have a document half-generated automatically and half-editted by humans.

December 25, 2012
On 12/23/2012 8:18 PM, Jonathan M Davis wrote:
> On Sunday, December 23, 2012 23:13:53 Andrei Alexandrescu wrote:
>> On 12/23/12 11:08 PM, Jonathan M Davis wrote:
>>> It's just the WHATSNEW section that makes no sense to automate.
>>
>> Enhancement requests may fill most of the bill...
>
> They definitely don't fill all of it though. We need to be able to put specific
> messages in the changelog separate from bugzilla entries.

An example would be helpful, as I'm not seeing the rationale.

December 25, 2012
On 12/25/12 7:18 AM, Walter Bright wrote:
> On 12/25/2012 3:41 AM, Jonathan M Davis wrote:
>> I think that that's what most of us are agreed upon at this point.
>> What is
>> currently the WHATSNEW section will continue to be done by hand, but the
>> LIBBUGSFIXED section will be autogenerated.
>
> WHATSNEW is a list of new features, which are (or should be) in bugzilla
> as enhancement requests.
>
> Various musings, rationales, future changes, etc., should go in a
> separate document called releasenotes.
>
> I don't think it's viable to have a document half-generated
> automatically and half-editted by humans.

Yes please. I was about to write something along the same lines - glad I read this first.

Andrei
December 25, 2012
On Tuesday, 25 December 2012 at 11:15:17 UTC, Jonathan M Davis wrote:
> On Tuesday, December 25, 2012 03:07:35 Walter Bright wrote:
>> On 12/24/2012 9:03 AM, Jonathan M Davis wrote:
>> > How about the very example that I gave about specifically providing a note
>> > to developers about the impending changes to std.format? No bug had been
>> > fixed, and no enhancement request had been implemented. No code change
>> > had even taken place yet. It was a note about a future change that
>> > developers needed to be made aware of.
>> 
>> Well, a future change shouldn't be in a *change* log any more than it should
>> be in bugzilla.
>> 
>> What you're talking about should be called "release notes".
>
> If you want to be pedantic about it, sure. But we don't have release notes
> separate from the changelog at this point. And while some changes which aren't
> currently put in bugzilla _could_ be put there (e.g. the addition of a new
> module), that doesn't necessarily mean that they belong there. So, while
> automating the list of bug fixes makes good sense, having a section of the
> changelog or release notes or whatever which is written by humans also makes
> good sense.

Lots of projects take the changelog from the SCM log instead, which is the REAL changelog. Of course to do that you have to write good commit messages...