On Friday, 4 January 2013 at 07:03:26 UTC, Walter Bright wrote:
> On 1/3/2013 9:49 PM, Jonathan M Davis wrote:
>> but other lines like
>>
> Yes, you can put this in as the bugzilla title, though I'd tighten it up a little.

>
> This is 3 separate enhancements, each of which should be its own issue, and will certainly fit as the issue title.

One problem that I see with the current form of Bugzilla query is that is quite difficult to inform the user about how the enhancement are connected one with another (for example, if one new feature requires another new feature or changing an old behavior). These may be part of several Bugzilla issues and there is no easy way to highlight this logical connection through the SQL query.

Also, not even the physical proximity of logically-related issues is not achievable through Bugzilla (maybe the issue which appears at the top is a logical consequence of the issue that appears at the bottom, or maybe they are related in terms of strategy and goals, but who's gonna say that and how?).

I would vote for requiring explicitly that the pull request properly modifies the documentation in those parts that it impacs.

On 2013-01-04 15:27, Philippe Sigaud wrote:

> Nice move!
>
> Too bad I get a pink unicorn from this one. Github is becoming stranger
> and stranger :)

Works for me. Try this one:

https://github.com/jacob-carlborg/d-programming-language.org/commit/bddbdf18353203ba12d8e0e44391e8b6a031b91a

-- 
/Jacob Carlborg

On Friday, 4 January 2013 at 15:26:35 UTC, Jacob Carlborg wrote:

> Works for me. Try this one:
>
> https://github.com/jacob-carlborg/d-programming-language.org/commit/bddbdf18353203ba12d8e0e44391e8b6a031b91a

Yeah, that works, thanks! Now for some reading.

I'll still start a thread on D.main, because this is hidden inside the 2.061 announcement.

On 2013-01-04 16:32, Philippe Sigaud wrote:

> Yeah, that works, thanks! Now for some reading.

This might be easier to read. I rendered the DDOC to HTML:

https://dl.dropbox.com/u/18386187/attribute.html#uda

There's also documentation for the Traits section but nothing which isn't available on the Attribute section.

-- 
/Jacob Carlborg

On Friday, January 04, 2013 14:30:01 Leandro Lucarella wrote:
> I think the best way to do it is to put it in the repository where the changes were made (this implies having separate release notes for dmd, phobos and druntime, I know).
> 
> This way is trivial to see if some important change deserves a note in the release notes and if it does, for the reviewers to reject the pull request until it has proper release notes.
> 
> Having them elsewhere will make the review process very difficult and lots of changes will still be missing.
> 
> As part of the release process, we can merge these notes together and add them to the website. Even when doing it manually shouldn't be that time consuming (is only copy&paste), this could also be automated.

This is what we've been doing for ages. With the bug fixes being in there, it's been a big problem, because it creates merge conflicts up the wazoo. So, we've generally avoided updating the changelog as part of pull requests with code in them. However, now that the bugzilla portion is being automated, it may be feasible to update changelog.dd in the pull requests with code changes.

- Jonathan M Davis

On Friday, January 04, 2013 15:03:42 deadalnix wrote:
> Isn't that feature supposed to be here in that form for strategic reasons and should remains kind of hidden ?

Yeah. I thought that UDAs were supposed to be undocumented for the moment?

- Jonathan M Davis

On Fri, Jan 4, 2013 at 5:13 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Friday, January 04, 2013 15:03:42 deadalnix wrote:
> > Isn't that feature supposed to be here in that form for strategic reasons and should remains kind of hidden ?
>
> Yeah. I thought that UDAs were supposed to be undocumented for the moment?
>

????

On Friday, January 04, 2013 17:35:32 Philippe Sigaud wrote:
> On Fri, Jan 4, 2013 at 5:13 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> > On Friday, January 04, 2013 15:03:42 deadalnix wrote:
> > > Isn't that feature supposed to be here in that form for strategic reasons and should remains kind of hidden ?
> > 
> > Yeah. I thought that UDAs were supposed to be undocumented for the moment?
> 
> ????

They were shoved out the door without being fully sorted out first instead of being done on a separate branch first and sorted out there prior to being released. I thought that we had decided that they'd be in 2.061 but undocumented for the moment so that people could use them but that they wouldn't be put in the docs until they had been fully sorted out so that they could be properly treated as experimental.

- Jonathan M Davis

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

On 13-01-04 10:49 AM, Jacob Carlborg wrote:
> On 2013-01-04 16:32, Philippe Sigaud wrote:
>
>> Yeah, that works, thanks! Now for some reading.
>
> This might be easier to read. I rendered the DDOC to HTML:
>
> https://dl.dropbox.com/u/18386187/attribute.html#uda
>
> There's also documentation for the Traits section but nothing which
> isn't available on the Attribute section.
>
Thanks to both of you!

Is there a location where a user can see what version a feature was introduced? If not, would it not be a good idea to include a "introduced in 2.061" note (or similar) beside features that are new, inside the documentation?

/Pierre