On 13-01-04 11:50 AM, Jonathan M Davis wrote:
> 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
>
If this is the case, why not add the mention "experimental" inside the documentation?  Readers (users and developers) would be aware of the new feature and the fact that it might change or go away.

/Pierre

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

>
> 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.


Yeah. OK, water under the bridge.


> I thought that we had decided that they'd be in 2.061 but undocumented for the moment so that people could use them


I'm afraid I see a slight contradiction in the previous statement :)


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.


 Er...

I propose this:

- update the changelog to say UDA are implemented, but are potentially
subject to change. Use them, people, and report!
- merge Jacob's pull request to have a documentation. Proeminently put a
warning in the docs saying this is an experimental feature (I know, this
should be a parallel branch, that's not the case, give it a rest).
- collect impression in 1-2 months.

I mean, how can the devs hope for any return on UDA if they are an Easter egg feature?

On Fri, Jan 4, 2013 at 6:13 PM, Pierre Rouleau <prouleau001@gmail.com>wrote:

>
>>
>>  If this is the case, why not add the mention "experimental" inside the
> documentation?  Readers (users and developers) would be aware of the new feature and the fact that it might change or go away.
>
> /Pierre
>

Ow, ninja'd!

On 13-01-04 12:18 PM, Philippe Sigaud wrote:
>
>
>
>
> I propose this:
>
> - update the changelog to say UDA are implemented, but are potentially
> subject to change. Use them, people, and report!
> - merge Jacob's pull request to have a documentation. Proeminently put a
> warning in the docs saying this is an experimental feature (I know, this
> should be a parallel branch, that's not the case, give it a rest).
> - collect impression in 1-2 months.
>
+1

On 1/4/2013 2:11 AM, Jonathan M Davis wrote:
> I just don't want to not have the ability to add notes to
> developers beyond that.

You can do that. Just issue a pull request, and it'll get merged in.

On 1/4/2013 2:09 AM, Jonathan M Davis wrote:
> What's their purpose? I can understand automatically generating the list and
> putting it in changelog.dd or putting some sort of javascript or whatnot in
> there to generate the list when the page is loaded, but if you're just putting
> a link to bugzilla to give the list, why list the bugs in a comment which
> doesn't show up on the webpage at all?

I had already made that list, and if the new links didn't work out I could quickly revert to it.

On 1/4/2013 6:02 AM, Leandro Lucarella wrote:
> Walter Bright, el  3 de January a las 23:03 me escribiste:
>> On 1/3/2013 9:49 PM, Jonathan M Davis wrote:
>>> but other lines like
>>>
>>> $(LI std.string: $(RED The implementations of std.string.format and
>>> string.sformat have been replaced with improved implementations which conform
>>> to writef. In some, rare cases, this will break code. Please see the
>>> documentation for std.string.format and std.string.sformat for details.))
>>
>> Yes, you can put this in as the bugzilla title, though I'd tighten it up a little.
>
> Are you being serious? Do you really think this would be useful for the
> user?  That the user will be able to spot that particular comment among
> hundreds of bugs in a bugzilla search query result?

It's not hundreds. It's the new/changed list, which is rather short. It was a little longer this time because it's been several months. Usually, it's just a handful.


> Is really that hard to acknowledge that release notes are better than
> doing that? I can understand if you see problems on keeping up to date
> the release notes, but I can't believe that anyone can think is plain
> better to user bugzilla instead (for the user POV at least).
>
> Can we at least agree on that and then see if is feasible to have good
> and up to date release notes?

But we've done that before. It was not working.


> I understand that, but I don't think that work should be optional and
> only done if somebody feels like. Every pull request should include
> proper documentation update. Can we try to focus on that for the next
> release?

We are all volunteers. You are welcome to help out with this.

On 1/4/2013 2:19 AM, Dmitry Olshansky wrote:
> With all due respect I just plain refused crawling through the list of links of
> bugzilla to understand the whole amount of changes and/or enhancements.

That's the way we've been doing it for years.


> New features need to be  featured (!) at the top of changelog and represented in
> the on-line spec obviously.

Just click on New/Changed Features and you get a list.

On 1/4/2013 8:59 AM, Pierre Rouleau wrote:
> Don't you think a process that requires reviewing these titles *before* the
> actual software release announcement posting would help?

Of course it would. Do you wish to help? All help is welcome.

On 1/4/2013 8:13 AM, Jonathan M Davis 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?

No, that was just the [attribute] form. The @(attribute) form should be documented.