D 2.062 release

Walter Bright newshound2 at digitalmars.com
Sun Feb 17 19:54:54 PST 2013


On 2/17/2013 7:36 PM, Steven Schveighoffer wrote:
> On Sun, 17 Feb 2013 21:44:18 -0500, Walter Bright <newshound2 at digitalmars.com>
> wrote:
>
>> On 2/17/2013 6:11 PM, Steven Schveighoffer wrote:
>>> Let me give you some examples of "new features"
>>>
>>> std.array.replace compile error (string and immutable string)
>>> There's no Duration.max
>>> Document extern properly
>>> etc.
>>
>> Compare the earlier changelogs with the bugzilla entries.
>>
>> It's EXACTLY THE SAME TEXT.
>>
>> EXACTLY.
>
> No.  We have quite a few messages that were not "bug reports" in prior
> releases.  These messages have no corresponding bugzilla entry.  These were
> truly useful descriptions.  The bug reports were few, and yes, there were a few
> instances like the ones I gave (I saw "relax inout rules" which is terrible as a
> description).
>
> for example:
>
> * std.​array.​insert has been deprecated. Please use std.​array.​insertInPlace
> instead.
> * Major overhaul of std.​regex module's implementation. Breaking change in std.​
> regex.​replace with delegate, use Captures!string instead of RegexMatch!string
> as delegate parameter.
>
> The latest versions have almost none of those useful descriptions.  They are
> almost exclusively of the cryptic
> you-have-to-click-on-me-to-understand-what-I-mean type.

All that's necessary is to edit the title description. I've done that on a few 
of them.


> Even if there are past examples of poor descriptions for the changelog, that is
> not not an excuse to make them all bugzilla reports.

It is no more or less effort to fix the bugzilla titles than it is to edit the 
changelog.


> A good first step would be to examine the bugzilla reports that will be listed
> as "new features" (should be easy since it's a report that's already being used
> by the web site), and change the descriptions to real useful enhancement
> descriptions before the release.  But I think the release needs a hard copy of
> these descriptions.
>
>> I understand many people do not like the change to the changelog - but I ask
>> for a reason that make sense. I keep hearing that the text is different, but
>> that is simply not so. It's the same exact information. Even the categories
>> are the same.
>
> I did a search for the above two examples in bugzilla, and I found nothing.
> Clearly, this is not the exact same information.

With the new system, all changes should have a bugzilla entry for them. With the 
old, there were occasional vacuous statements in the changelog with no links to 
any discussion or just what it was.

Look at the changelogs that list an issue number. All of them have the exact 
same text as the corresponding bugzilla title. I know they're the same because:

1. people requested that they be the same
2. I created them using cut & paste

With bugzilla entries for each item in the changelog, you have:

1. a title
2. discussion
3. link to the pull request that shows the code that changed to implement it

>> Also, anyone can go in and change the bugzilla issue titles to make them more
>> readable.
>
> That actually is not a good thing...  Anyone can maliciously affect the
> changlog, or alter the changelog at some later point because they wanted to
> 'reopen' a bug.

I know that there is the potential for malicious behavior, but thankfully we 
haven't seen any of that. If we do, we'll have to restrict write access to 
bugzilla. That'll be a sad day.


If someone wants to step up and take charge of doing a better job with the 
changelog, I'm all for it. The old way was NOT a better job. It was usually left 
to me (and Jonathan) to try to cobble something together. When I was the only 
committer, I'd edit the changelog as things got changed. With the larger number 
of committers today, this got overlooked. The result was incomplete, inaccurate, 
and a lot of belated "hey, you left out these changes" after the release.



More information about the Digitalmars-d-announce mailing list