January 04, 2013
On 1/3/2013 4:22 PM, deadalnix wrote:
> Ran into some trouble to make it work, but awesome news : the GC collecting live
> stuff problem is gone (most likely a closure bug rather than a GC bug).


There are still a couple of memory-corrupting closure bugs left. Turns out they are rather hard to solve, were found only at the last minute, and have always been there, so I thought it was ok for them to go one more release.

January 04, 2013
On 1/3/2013 3:38 AM, deadalnix wrote:
> On Thursday, 3 January 2013 at 01:06:46 UTC, Walter Bright wrote:
>> Please post example to bugzilla.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9263

Thank you. (And whaddya know, Kenji just fixed it!)
January 04, 2013
On Friday, 4 January 2013 at 03:21:46 UTC, Walter Bright wrote:
> On 1/3/2013 3:38 AM, deadalnix wrote:
>> On Thursday, 3 January 2013 at 01:06:46 UTC, Walter Bright wrote:
>>> Please post example to bugzilla.
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=9263
>
> Thank you. (And whaddya know, Kenji just fixed it!)

Excellent. This also demonstrates why a better release
process would be nice -- I can either compile with -wi
and filter out warnings until 2.062 or roll back to
2.060. Bug fix releases would be super keen. :D

But eh, 64 bit support? UDAs? I can hardly complain.*

-Bernard.





* I'm still going to complain. :P
January 04, 2013
On 1/3/13 10:07 PM, Walter Bright wrote:
> On 1/3/2013 11:17 AM, Andrei Alexandrescu wrote:
>> Andrei "I don't yet run my own SMTP and IMAP server" Alexandrescu
>
> Sheesh. How can you ever hold your head up again after that admission?

I actually used to, heh. Communigate Pro they called it, beautiful software. Then understood the email security model better and figured running one's own server doesn't make any sense - sorry Russel :o).

Andrei "I know better than run my own SMTP/IMAP servers" Alexandrescu
January 04, 2013
Walter Bright, el  3 de January a las 19:10 me escribiste:
> On 1/3/2013 11:36 AM, Jonathan M Davis wrote:
> >Oh. Those are links. I was wondering when the data was actually going to be posted. When compared to the previous ones, it looks like there's only headers with no information.
> 
> The idea is to add explanatory information to the bugzilla issue being pointed to.

Please, please, consider adding release notes, at least for new features is not good enough to just use bugzilla links, you need a clear, succinct explanation of the feature. Where would you put it? In the bug report itself? Most of the time is not clear enough by the time the bug is created and the feature is polished after a long discussion. You shouldn't make users go through the entire history of a bug, which is completely internal to the compiler development, to know what have changed.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Cuando le dije si quería bailar conmigo
Se puso a hablar de Jung, de Freud y Lacan
Mi idiosincracia le causaba mucha gracia
Me dijo al girar la cumbiera intelectual
January 04, 2013
On Thursday, January 03, 2013 19:10:59 Walter Bright wrote:
> On 1/3/2013 11:36 AM, Jonathan M Davis wrote:
> > Oh. Those are links. I was wondering when the data was actually going to
> > be
> > posted. When compared to the previous ones, it looks like there's only
> > headers with no information.
> 
> The idea is to add explanatory information to the bugzilla issue being pointed to.
> 
> Making some effort to clarify the title of the bugzilla issue is also justified.
> 
> This change to the changelog presentation does require that we up our game with bugzilla - accurate tags (you can see at the top what is being keyed on), accurate titles, and accurate information.

No offense, but that doesn't cut it. Maybe it makes sense to create bugzilla entries for stuff like

$(LI std.digest.ripemd: Added RIPEMD-160 digest implementation.)

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

or

$(LI std.range.hasSlicing has been made stricter in an effort to make it more reliable. opSlice for infinite ranges must now return the result of std.range.take, and any range with slicing which supports $(D $) must now support it with the same semantics as arrays (including supporting subtraction for finite ranges).)

are purely notes which developers should be made aware of which should _not_ be buried in a list of bugzilla entries where most people won't see them (not to mention, how many people do you think actually read through that list of bug fixes; I think that it's mostly the notes that were at the top which people cared about, and now they're gone).

If you want to have a "release notes" section for them separate from the changelog section, fine. But these are notes which should be relatively prominent so that people see them! And they're specifically notes for people to read and not enhancement requests or bug fixes or whatnot. In your zeal to automate the bug fix list, you're throwing away something of real value.

Automating the bug list is fine, but don't throw away all of the non-bugzilla stuff that we've been putting in the changelog.

- Jonathan M Davis
January 04, 2013
On 13-01-03 10:18 PM, Walter Bright wrote:
> On 1/3/2013 12:27 PM, Leandro Lucarella wrote:
>> BTW, Changelogs looks extremely naked now, I think release notes are
>> really needed now. Al least for new features. Is far from ideal to make
>> people go through a bug report to know how they can adapt their code to
>> new features.
>
> On the other hand, the older way of doing changelogs routinely missed a
> *lot* of things. Relatively few people doing the pulls would bother to
> log the changes. I think there were easy double the number of changes
> showing up in the search than were in the log.
>
>
>> And sometimes bug reports are not updated on how things turned out, for
>> example #7041[1], a feature I implemented myself. The bug report is
>> outdated AFAIK, the title talks about a -di flags which doesn't even
>> exist, you actually have to go through the pull request[2] to see what
>> the hell is going on. And even then the behaviour of that pull request
>> was changed in a subsequent one[3], and there are no visible links
>> between those 2 pull requests.
>
> Please update that bugzilla issue. As I posted elsewhere in this thread,
> this method does require upping our game with bugzilla tags, titles, and
> descriptions.
>
> I don't see that it is any *harder* to update the bugzilla issue than it
> is to provide a brief summary in the changelog.
>
> As for what's new, the failure here is the failure to document those
> changes. This is not a failure of the changelog - it's a failure of the
> documentation pages. The bugzilla should have a link to the relevant
> documentation.
>
> I do *not* think that a changelog new feature entry takes the place of
> updating the documentation, and I do not agree with writing the
> documentation twice (changelog and documentation).
>
>
>> Anyway, at least for this particular change, the changelog is basically
>> useless, and I don't think the bug report is the right place to inform
>> users about compiler changes.
>
> We've been using bugzilla for a long time to organize enhancement requests.
>
>> Users don't care about the history and
>> discussion around a change, they just only want to know how to take
>> advantage of new features and how to fix their code (possibly with some
>> exceptions of course, in which case they can still go back to the bug
>> report and pull requests).
>
> I agree this new system is imperfect - but I argue it is better than
> what we were doing before.
>

I would agree with you that updating documentation and having access to the exact details is a very good thing to do.  And most current developers already using D will most likely be satisfied with this.

However, for outsiders like me, that manages development groups and is waiting for D2 to become stable enough to start investing preliminary prototypes in D2 and developing software in house (first for tools while training new developers with it) and given the fact that D2 is still stabilizing, an explicit description of the highlights of the major changes of a new version is a good selling point for the language.

I was able to introduce Python in a group that was very conservative and old die-hard C programmers, simply because the documentation of Python was so well done.  Each *major* release is fully documented.

Now, D is newer, D2 is not yet completely stable yet (not that anything these days is).  So maybe I am comparing apples and oranges.  Python has lots of changes between official versions (with its own bug tracker with all the details of the various changes), but then they have a *release* version (eg. Python 2.7, Python 3.3, ...) and minor releases on top of those. The model seems to be a little different in D.  Will it get closer to a model similar to Python in the future? In the Python model of development it seems easier to create documentations for important releases.

I really hope D succeeds in becoming an important programming language; it's got so many nice features and its community is so knowledgeable.  A little PR here and there around the releases, where a quick review would identify major breakthrough would probably not hurt D's popularity though. Since I agree on avoiding duplication, would a list of major new features of the release (similar to what existed in previous logs), made of links to the updated documentation, help?

Anyway, I know I'm an outsider and have not participated in the development of this incredible language and all wonderful programs that the community came up with.  I just wanted to give you some feedback from the outside and, at the same time, thank Walter all the D community for the wonderful work that has been done!


/Pierre


January 04, 2013
On Thursday, January 03, 2013 19:18:25 Walter Bright wrote:
> As for what's new, the failure here is the failure to document those changes. This is not a failure of the changelog - it's a failure of the documentation pages. The bugzilla should have a link to the relevant documentation.
> 
> I do *not* think that a changelog new feature entry takes the place of updating the documentation, and I do not agree with writing the documentation twice (changelog and documentation).

In general, the only "new features" which need to be in the documentation but don't end up there are in dmd. But even then, they need to be in the changelog or release notes - preferrably the release notes, if we're separating them. I expect that very few people will comb through the list of bug fixes. They want to know the highlights, and we should list those. And _no one_ is going to dig through the documentation to try and figure out what changed. So, omitting a new feature entirely from the changelog or release notes because it's been put in the updated documentation makes no sense. The changelog and release notes definitely do _not_ replace proper documentation, but they're a necessary companion to it when new features are added or major changes are made.

- Jonathan M Davis
January 04, 2013
Walter Bright, el  3 de January a las 19:18 me escribiste:
> On 1/3/2013 12:27 PM, Leandro Lucarella wrote:
> >BTW, Changelogs looks extremely naked now, I think release notes are really needed now. Al least for new features. Is far from ideal to make people go through a bug report to know how they can adapt their code to new features.
> 
> On the other hand, the older way of doing changelogs routinely missed a *lot* of things. Relatively few people doing the pulls would bother to log the changes. I think there were easy double the number of changes showing up in the search than were in the log.

I agree completely. I'm not saying having a well maintained bug tracker is a bad think! Is great, and is great to be able to automatically list all the bugs fixed in a release. Is think is a huge improvement. I'm just saying is not good enough, there is more room for improvement IMHO.

> >And sometimes bug reports are not updated on how things turned out, for example #7041[1], a feature I implemented myself. The bug report is outdated AFAIK, the title talks about a -di flags which doesn't even exist, you actually have to go through the pull request[2] to see what the hell is going on. And even then the behaviour of that pull request was changed in a subsequent one[3], and there are no visible links between those 2 pull requests.
> 
> Please update that bugzilla issue. As I posted elsewhere in this thread, this method does require upping our game with bugzilla tags, titles, and descriptions.
>
> I don't see that it is any *harder* to update the bugzilla issue than it is to provide a brief summary in the changelog.

Is harder for the **user**, not for the developer! I updated all the documentation in the compiler itself and the man page, I just never wrote changelog entries in the documentation.

If you really want to make people update all the documentation, you should reject pull requests until they are **complete**. If I missed updating something is because nobody told me I had to. I'll happily update release notes in the future if you tell me where they are.

> As for what's new, the failure here is the failure to document those changes. This is not a failure of the changelog - it's a failure of the documentation pages. The bugzilla should have a link to the relevant documentation.

Please see my other comment. I really think you're getting this wrong. Bugzilla is for internal development, not to inform people about new features. New features might end up being completely different from what the user reported in the first place, and it's very cruel to make users have to read a complete discussion about a feature (or to scroll to the end of a bug report to find a link, or even to click on 2 links for each new/changed feature!).

I agree is the same work for a developer to update the documentation, being in bugzilla or in the repository, but having a proper document with at least big changes explained is much more useful to the user (and I think is even easier to edit for the developer). And then, is harder to reject pull request if they don't update some documentation in the same repo the pull request is made than checking some bugzilla report to see if is properly updated.

> I do *not* think that a changelog new feature entry takes the place of updating the documentation, and I do not agree with writing the documentation twice (changelog and documentation).

We agree on this too. I don't know why are you getting the impression I want something else in this matter.

> >Anyway, at least for this particular change, the changelog is basically useless, and I don't think the bug report is the right place to inform users about compiler changes.
> 
> We've been using bugzilla for a long time to organize enhancement requests.

And that's perfect too.

> >Users don't care about the history and
> >discussion around a change, they just only want to know how to take
> >advantage of new features and how to fix their code (possibly with some
> >exceptions of course, in which case they can still go back to the bug
> >report and pull requests).
> 
> I agree this new system is imperfect - but I argue it is better than what we were doing before.

And I'm not suggesting going back to where we were before, just keep improving.

What I'm suggesting is:
* Keep handling *all* development (bugfixes and new features) through bugzilla
* Keep listing bugfixes and new features lists automatically as bugzilla
  queries (I think it would be better to automatically generate a nicer
  document with those lists though, but that's just details)
* Keep having the complete documentation for new features where it should be
  (the website/specs).
* Add a release notes documents (that could be also the base to announce
  releases with more details in the e-mail release) which gives a brief summary
  of the focus of the current release and any important changes visible to the
  users. When new features are added, include the link to the proper
  documentation.
* Reject pull requests that don't update either the documentation or the
  release notes, but TELL people what's missing for the pull request to be
  merged, so they learn how to do pull requests that are complete.
* Review the release notes just before the release to make it coherent.

Another good example of release notes is the LLVM project.

Please, take a look at Python release notes and LLVM release notes if you haven't before. Just take a look.

Examples:
http://python.org/download/releases/3.3.0/
http://llvm.org/releases/3.2/docs/ReleaseNotes.html (this link might be wrong
because I can't access the llvm website right now to check)


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Cómo ser inconmensurablemente atractivo a la mujer del sexo opuesto.
	-- Libro de autoayuda de Hector Mesina.
January 04, 2013
On 1/3/2013 9:54 PM, Pierre Rouleau wrote:
> However, for outsiders like me, that manages development groups and is waiting
> for D2 to become stable enough to start investing preliminary prototypes in D2
> and developing software in house (first for tools while training new developers
> with it) and given the fact that D2 is still stabilizing, an explicit
> description of the highlights of the major changes of a new version is a good
> selling point for the language.

The whatsnew section is pretty short, and it's just a click away. I just don't understand why this is so objectionable.