On 13-01-04 3:45 AM, Walter Bright wrote:
On 1/4/2013 12:16 AM, eles wrote:
Two concrete examples:
http://d.puremagic.com/issues/show_bug.cgi?id=5992
is described in the list as: " Phobos Win64 - D2 "; At least, change
its title
to something more human, like "Win64 alpha has been released with working
Phobos." (yes, that's exactly Don's comment, but at the end of the
discussion).
http://d.puremagic.com/issues/show_bug.cgi?id=5269
is described as: "version(assert)". Only if you read the discussion you
understand that "version(unittest) that allows setup code for assertions
to run when assertions are enabled and be compiled out when assertions
are
disabled" was implemented.
It is very different thing to see "version(assert)" and reading a
meaningful
description of it...
I understand and agree. And, as I posted previously, anyone can fix the
issue titles. I've already fixed a few.
Don't you think a process that requires reviewing these titles *before*
the actual software release announcement posting would help?
Would it not be useful to have a person in charge of the redaction of
this type of software release? That person would be able to review all
Bugzilla reports that have been automatically generated and create a
separate document titled "What's new in D 2.xxx" that would provide an
overview of the release. Of course the existing four lists (new/changed
features, DMD bugs fixed,...) would still exists and would be reachable.
But this new document would present all the information about the
changes, their intent, the way they interact together and influence
writing D code. That document itself would be created during the same
development cycle than the code itself. And would be reviewed.
Having this document might be seen as duplication of information. It
can also be seen as a central idea repository for the presentation of
the changes/fixes of the release and the activity leading to the
creation of this document could generate extra discussions that may lead
to new ideas and more bugs being fixed. It would help introduce the
information to users and if anyone is interested in the details then
they can always go to the actual Bugzilla entries listed the way they
are now.
As an example of what I am thinking about, see
http://docs.python.org/2/whatsnew/2.7.html
Note, in that document the links to the various issues. The 4 lists of
Bugzilla issues could be located at the top of the release document.
/Pierre
