January 07, 2013
On 1/7/2013 8:31 AM, Andrei Alexandrescu wrote:
> Walter can write a roadmap, nobody will listen to him.
>
> One thing that few people know is that Walter and I have tried to kindly
> convince people to work on specific things we believed were important. Such
> attempts have been largely unsuccessful.

True. Another thing that's been a bit frustrating to me is people regularly ask me (or the ng) "what should I work on?" I provide a list, and they go do something else.

The reality is that, in a volunteer community, people work on what interests themselves. Finding ways to work successfully with that dynamic is the big challenge we face.
January 07, 2013
On Mon, 2013-01-07 at 21:12 +0100, Jacob Carlborg wrote:
> On 2013-01-07 20:54, Walter Bright wrote:
> 
> > It's pretty clear where we'll be going with this. We'll be abandoning OS X versions older than 10.7.
> 
> Would it be a bad idea and do what the dynamic linker does in the druntime to support TLS? This would make it work on Mac OS X 10.6.
> 
> > I don't know enough about the Mac ecosystem to know when we can pull the plug on that.
> 
> Me neither. Mac OS X 10.6 was released August 28, 2009. There have been two major releases since then.

As far as I am aware white MacBooks cannot run 10.7 and 10.8, but are stuck at 10.6

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 07, 2013
On Monday, 7 January 2013 at 19:54:54 UTC, Walter Bright wrote:
> On 1/7/2013 4:41 AM, David Nadlinger wrote:
>> Yes, it is not supported by linker and dyld versions shipping with OS X 10.7.

Sorry, I wrote my last post in a hurry – I suppose it's clear anyway, but that should have been »by the linker and dyld versions Apple shipped with OS X prior to 10.7«.

>> This is also the reason why LDC 2 only supports OS X 10.7+, as LLVM does not
>> implement a workaround for older versions (although implementing one up to the
>> point where it is good enough for D should be doable without too much effort).
>
> It's pretty clear where we'll be going with this. We'll be abandoning OS X versions older than 10.7.
>
> I don't know enough about the Mac ecosystem to know when we can pull the plug on that.

I don't know the current relative market share of the different OS X versions on top of my head either, but as we were getting a couple of bug reports from people who had tried to use LDC 2 on 10.6 (before we figured out that LLVM doesn't emulate TLS there), I guess it's too soon to drop support for it still. However, when finally somebody finds the time to implement shared library support in the runtime, the situation might have already changed anyway.

David
January 07, 2013
Am Mon, 07 Jan 2013 19:39:52 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2013-01-07 19:29, Andrei Alexandrescu wrote:
> 
> > It's less structured than a roadmap but maybe that's what would make it tenable!
> 
> It would be like a roadmap without the timeline. That's a lot better than nothing.
> 

aka TO-DO list
January 07, 2013
On 1/7/2013 11:40 AM, Leandro Lucarella wrote:
> Andrei Alexandrescu, el  7 de January a las 08:31 me escribiste:
>> One thing I want to do is enshrine a vetting mechanism that would
>> allow Walter and myself to "pre-approve" enhancement requests.
>> Someone (including us) would submit an enhancement request to
>> Bugzilla, and then Walter and I add the tag "preapproved" to it.
>> That means an implementation of the request has our approval
>> assuming it has the appropriate quality.
>
> BTW, I wouldn't mind if you like to try this out with issue 7044 (see the pull
> request for more comments), which is really annoying us at work but I never got
> to fix because the lack of feedback (a perfect example of somebody willing,
> almost craving, to fix something and not doing it because of the lack of
> feedback).
>

At this point, reading the discussions in the links, I don't know just what the latest proposal is.

https://github.com/D-Programming-Language/dmd/pull/497
http://d.puremagic.com/issues/show_bug.cgi?id=7044
http://forum.dlang.org/thread/mailman.1605.1334108859.4860.digitalmars-d@puremagic.com
January 07, 2013
On 1/7/2013 12:12 PM, Jacob Carlborg wrote:
> On 2013-01-07 20:54, Walter Bright wrote:
>
>> It's pretty clear where we'll be going with this. We'll be abandoning OS
>> X versions older than 10.7.
>
> Would it be a bad idea and do what the dynamic linker does in the druntime to
> support TLS? This would make it work on Mac OS X 10.6.

I don't think it's worth the effort. We don't have the resources to expend on platforms that are already obsolete.


>> I don't know enough about the Mac ecosystem to know when we can pull the
>> plug on that.
>
> Me neither. Mac OS X 10.6 was released August 28, 2009. There have been two
> major releases since then.

Sounds like we can pull the plug.

January 07, 2013
On Thu, 03 Jan 2013 17:08:58 +0100
"deadalnix" <deadalnix@gmail.com> wrote:
> 
> However, it is just to discover that this do not work :
> 
> struct Bar {}
> auto foo(ref Bar bar) {}
> 
> foo(Bar()); // Now this is an error !
> 
> I still have code broken all over the place.

IIRC, they tried to include this change in 2.060 (or was it 2.059?), but due to the major problems it causes, and the fact that it *does* make sense to use a temporary as an lvalue if you don't intend to use it again afterwords, there was a big discussion about it on the beta list and it was ultimately nixed. I'm disappointed to see that it snuck back.

January 08, 2013
On 1/7/2013 3:19 PM, Nick Sabalausky wrote:
> On Thu, 03 Jan 2013 17:08:58 +0100
> "deadalnix" <deadalnix@gmail.com> wrote:
>>
>> However, it is just to discover that this do not work :
>>
>> struct Bar {}
>> auto foo(ref Bar bar) {}
>>
>> foo(Bar()); // Now this is an error !
>>
>> I still have code broken all over the place.
>
> IIRC, they tried to include this change in 2.060 (or was it 2.059?),
> but due to the major problems it causes, and the fact that it *does*
> make sense to use a temporary as an lvalue if you don't intend to use
> it again afterwords, there was a big discussion about it on the beta
> list and it was ultimately nixed. I'm disappointed to see that it snuck
> back.
>

Well, fixing the rvalue ref problem is still on the front burner.
January 08, 2013
On 1/7/13 12:39 PM, Johannes Pfau wrote:
> Am Mon, 07 Jan 2013 19:39:52 +0100
> schrieb Jacob Carlborg<doob@me.com>:
>
>> On 2013-01-07 19:29, Andrei Alexandrescu wrote:
>>
>>> It's less structured than a roadmap but maybe that's what would
>>> make it tenable!
>>
>> It would be like a roadmap without the timeline. That's a lot better
>> than nothing.
>>
>
> aka TO-DO list

unprioritized
January 08, 2013
On 13-01-07 9:12 AM, Matthew Caron wrote:
> On 01/07/2013 08:09 AM, Pierre Rouleau wrote:
>> It would be nice to have bug fixes separated from new feature
>> introductions by having major and minor releases and branches for these
>> releases.  Contributors of a release could backport bug fix in the
>> release they use if that was required by their project using the now old
>> compiler version.
>>
>> Of course I realize that this means more overall work, more people,
>> someone or a set of people in charge of release management, etc...
>
> I also think that you'd be hard-pressed to find anyone who does
> development like that, proprietary or open source. It's not uncommon to
> have bugfix only releases, but having a new features release that
> doesn't fix any bugs is, in my experience, unheard of.

I agree that feature releases mostly also contain bug fixes. I should have said, and I was thinking about proposing a process where minor releases that would only include bug fixes, and where major releases would mainly introduce new features but would also include some bug fixes.

At work this is exactly what we do. And today, at work, I was just in a meeting evaluating bugs to identify bugs that will be fixed in a release of our product that will only contain bug fixes.  The fixes that are selected where selected based on their severity, the impact they have on end-users and the time it takes to fix them.

And maybe an alpha process suggested by Jonathan M. Davis is a better idea.

>
> Also, I'd be STRONGLY against it, because I have a fix bugs first
> mentality, and if you find a bug while implementing a new feature, it
> should be fixed.
>

In my work I also have a bug-fix first mentality and I push for that everyday. I strongly agree with that. All I was suggesting (or checking if this is the way this group handles it) is whether bug fixes are isolated from feature implementations (and I assume they are since they are separate Bugzilla tickets).

And at work, when a new feature is implemented and a bug is found during the process of developing that feature the first thing that is done is to create a _separate_ bug report ticket (separate from the ticket that request the introduction of the new feature or enhancement) to identify the presence of that bug if that bug affects release code.  The releases the bug affects are identified and typically within a week, the bug is "scrubbed" in a meeting where people with different roles attend.  The priority and severity of the bug is discussed, and the release version for the fix is identified in a forecast. Developer(s) have to estimate the time it will take to fix the bug (as is done for every ticket in our bug tracking system (bug fix, feature implementation, enhancement, etc...).  A test case is also created for the bug since it was an escape from the test plan/integration test/unit test side of things.

The bug is fixed, regression tested and the new feature is implemented on top of the bug fix.  The sequence of events may differ depending on how we want to handle things with the VCS we use and the moment of the event respective to the product release plan.

I am not suggesting to not fix a bug found when a new feature is introduced. I was trying to propose something that would help predictability and stability.

Now I understand that I am comparing a commercial product development with an open source project here.  But I am also comparing what a user *sees* from other projects that are used where I work; the PR part, the marketing material that help sells the product to people.  When I look at Python and Erlang for instance, those two projects seem, I say seem (from the user's perspective) to provide more information to the user's base in terms of those two criteria of predictability and stability simply because of the various documents provided and release strategies one can see from the evolution of their projects.

It possibly is only a matter of perception and Public Relations but D2 first release was done June 17, 2007 which is over 5 years and six months ago.  I see nothing in the release version number that gives any outsider a vision of the stability of D2 or it's evolution milestone-wise.  The first release number was D 2.000 and we are 66 months later at version 2.061. That's about a release a month.  How can an outside user see the major milestones in those 5 years and a half?  I imagine that some of you guys remember what were the significant releases, you have been living with it for those last 66 months.  But how can you convince potential new users to use it in projects where manpower is also limited and continuous updates may not be possible? How can they see that its stabilizing? How many more releases may affect the development of products?  In June 2007 I was using Python 2.5.1, Python 2.7.3 and 3.3.0 are the two official releases now.  All of these versions have had bug fix (and security) releases independently of the other ones. These versions had reached a point of finality. I have not yet switched to Python 3.3 for production code but have upgraded from 2.5 to 2.6 and 2.7.   Each time we looked at the major changes prior to the upgrades to identify the amount of work required in order to schedule it in the work flow.  I have also upgraded from minor to minor releases much quicker. We do the same for Erlang.  To be able to use D at work for product development, I will have to be able to do the same.

And now I understand that D1 is no longer officially supported. If I understand properly D1 first release was 6 years ago.  Lets assume I would have started a product development with it say 2 years ago because it was deemed relatively stable then.  And now I want to support 64-bit Windows and my customers are starting to ask for Windows-8 support.  Or some other things gets in the way (a bug somewhere, Windows 9 getting released sooner because Windows 8 is not as popular as Microsoft would have hoped.) What would be my alternatives? Port all the code to D2?  Is this what will happen to D2? I'd like to know before I commit people and convince others.

At the moment what I see of the current state is that if I am interested, I should join the developers group and use D for fun and expertise.  I just hope that I am missing something (beside the fun and expertise) that could help convince myself and others that I could depend on D for product development at work.

BTW, the proposal from Andrei to implement a "pre-approved" non-prioritized enhancement request mechanism seems a very good idea and a step in the good direction IMHO (from the outside).





-- 
/Pierre Rouleau