January 07, 2013
Brad Roberts, el  6 de January a las 17:28 me escribiste:
> On 1/6/2013 4:25 PM, Leandro Lucarella wrote:
> > I really hope at some point this will be addressed, and I think other areas of the development process have been improved enough to think this is a good moment to do so, but first management (OK, I will say it: Walter) have to be convinced (or pushed) to do so. Maybe it will take 2 or 3 years.
> 
> Believing that Walter is the problem is minimizing the problem.  There's no way that a single developer can own and drive a roadmap, and that's essentially what Walter is.  He's NOT a company of developers.  He doesn't have a cadre of people that follow his instructions.
> 
> If this community feels the need for a concerted _directed_ effort, the community needs to step up and volunteer to produce and progress upon that roadmap.  The problem is that while D currently has maybe a dozen developers, each of them is essentially entirely self directed, following their own personal interests.  There's nothing inherently wrong with that, and the results have been useful, but those results are also semi-chaotic and essentially impossible to predict.

I can write a roadmap, but then, nobody will listen to me. The reality is, Walter is the "leader" and who decides what gets in and what not. It happened to me before to implement stuff that doesn't get in. And that's fine. But Walter, as a "leader" have to step up and tell where he wants to move so people focus on the stuff that have a chance to be merged.

Otherwise the only road is forking, as it happened before. I don't think the Tango split and now Amber are coincidences. There is a lack of leadership in D, and talking with the community. Andrei tried to fill that leader position in the past, and even when I have lots of differences with Andrei, I think he successfully done that with Phobos. But he can't do that with DMD.

I agree that Walter doesn't have to do all, but at least he must be convinced there is a value in it, and encourage it and help whoever wants to step up. Why would I bother to do anything if is very likely that Walter don't want to go that direction and all my work was done for nothing? Been there before. Now I'm more cautious when selecting my battles.

> Does anyone know of any mechanism for getting people to do what needs to be done vs what they want to do that doesn't involve paying them?  The only long term successes I can point to all involve companies.

I do think that D to take the next leap needs to have more (directly or indirectly) payed development. But still that doesn't stop you from having a plan, a tentative roadmap.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
ELLA FUE INFIEL, PERO EX POLOLO PAGÓ
	-- TV CHILE
January 07, 2013
On 1/7/13 7:47 AM, Leandro Lucarella wrote:
> I can write a roadmap, but then, nobody will listen to me.

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.

> The reality is,
> Walter is the "leader" and who decides what gets in and what not. It happened
> to me before to implement stuff that doesn't get in. And that's fine. But
> Walter, as a "leader" have to step up and tell where he wants to move so people
> focus on the stuff that have a chance to be merged.
> Otherwise the only road is forking, as it happened before. I don't think the
> Tango split and now Amber are coincidences. There is a lack of leadership in D,
> and talking with the community. Andrei tried to fill that leader position in
> the past, and even when I have lots of differences with Andrei, I think he
> successfully done that with Phobos. But he can't do that with DMD.
>
> I agree that Walter doesn't have to do all, but at least he must be convinced
> there is a value in it, and encourage it and help whoever wants to step up.

I, too, think there is value in this approach.

> Why
> would I bother to do anything if is very likely that Walter don't want to go
> that direction and all my work was done for nothing? Been there before. Now I'm
> more cautious when selecting my battles.

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.

That should reduce the cognitive load ("am I working for nothing over here?") on the proponent of the feature and would also motivate the proponent to define the feature with reasonable completeness before implementing it.

>> Does anyone know of any mechanism for getting people to do what needs to be
>> done vs what they want to do that doesn't involve paying them?  The only long
>> term successes I can point to all involve companies.
>
> I do think that D to take the next leap needs to have more (directly or
> indirectly) payed development. But still that doesn't stop you from having a
> plan, a tentative roadmap.

I agree, and I happen to disagree with Walter's "Fog of War" theory which I consider somewhat a rationalization of the simple fact he enjoys, like we all do, working under the haphazard of creative flow. Short- and medium-range plans do make sense for us, and we should put them together. Important stuff keeps on remaining not done because at the end of each release cycle we don't have a clear notion of what to work on next.


Andrei
January 07, 2013
On Monday, January 07, 2013 08:09:01 Pierre Rouleau wrote:
> The worst part I see is that bug fixes and new feature introductions are lumped together inside releases. Combined with the fact that the development is not predictable means that if you develop products with D you have to keep updating it.  If you get stuck with a bug and wait for the release that fixes it, when that release comes out it could very well bring new language features that break the code that you have already written.
> 
> 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...

The reality of the matter is that most code breakage comes from bug fixes. New features rarely break much of anything, especially if you're not using them. Having API changes mixed in with bug fixes _can_ pose a problem, but I think that if you really looked into it, you'd find that stuff like UFCS and UDAs and whatnot have resulted in very little (if any) broken code. They may not have worked as well as they should have and have plenty of bugs in their implementation, but code which isn't using them (as code wouldn't be prior to their release) didn't get broken by its introduction. So, while it may be valuable to move to a major/minor release situation, I think that the reality of the matter is that it will have little effect on stability simply because it's bug fixes which break things - either because they fix previously buggy behavior (breaking any code which relied on that behavior) or because regressions are introduced, and while we try hard to catch those, we don't always manage it. And the only thing that I can think of which would do a better job of catching those would be a bettere beta program where the beta is somehow better vetted so that regressions just don't manage to get through (though how we'd get more people to try the beta, I don't know). Major and minor releases will have little effect on stability from the standpoint of the compiler. They could have an effect from the standpoint of API changes, but since we're trying to stop making breaking API changes entirely (or at least make them very rare), a major/minor release model probably won't help much there either.

- Jonathan M Davis
January 07, 2013
On Mon, 07 Jan 2013 07:57:07 -0500
Matthew Caron <matt.caron@redlion.net> wrote:

> On 01/05/2013 03:01 AM, Nick Sabalausky wrote:
> > On Thu, 03 Jan 2013 08:20:19 -0500
> > Matthew Caron <matt.caron@redlion.net> wrote:
> >
> >> On 01/02/2013 04:18 PM, Walter Bright wrote:
> >>>> Why would you need to? If your mail store is IMAP, just let it rebuild.
> >>>
> >>> I don't store email on the server, I store it locally.
> >>
> >> I gave that up years ago when I ended up with more than one device. Too much "did I get that email on my laptop or my desktop?" And now with tablet, phone, laptop, desktop, and several kiosk machines around the house (because how else do you watch Firefly whilst loading custom hunting ammunition in the gun room?) and then the device proliferation continues...
> >>
> >
> > Turn off "Delete email from server ten seconds after downloading it". Either increase it to a sane time period, or disable delete-from-server entirely. Problem solved. Worked fine for me.
> 
> Isn't this just "leave email on the server", which is what I suggested?
> 
> Of course, what you're saying is "use POP with leave on server enabled". A better solution is to just use IMAP.
> 
> > Accessing *sent* messages can be a different story though, but using your email client's setting for "BCC outgoing messages to..." to send to a special "messages I sent" address works well enough. Unless you need to use some shitty Fisher-Price email client like the one in iOS, because then you're just fucked. (But if you need to rely on iOS, you'll probably have bigger problems anyway.)
> 
> Or, you just use IMAP.
> 

I don't think you get a local copy of everything with IMAP though, or do you?

> >> Windows is only
> >> suitable for playing video games, and I'm looking forward to
> >> Steam's release for Linux such that I can power on the Wintendo
> >> less and less.
> >
> > Steam on Linux? That's like installing hydraulics on a Formula 1 or a rusty nail in a jock strap. Nothing that involves "Steam" is suitable for playing videogames, whether Win/Lin or anything else.
> 
> It's view it as an online shop which allows you to buy and install games for your platform.

That view is the problem. Steam is *not* merely an online store, Steam (just like iOS) is DRM made cool. And that asshole Newell has managed to brainwash people into actually believing that Steam isn't DRM which is patently absurd.

And as a "bonus", the Steam client itself is a very poorly written piece of shitware. Slow, buggy, ugly, refuses to close when I click the "close" button (one of those asinine programs like Skype that has decided "Close" should mean "Minimize to tray" and shouldn't even be optionally fixable).

Steam is NOT simply a store with community crap. And that fact that so many sheep think that it is, is a big part of what makes Steam and Newell so evil.

> I have no issue with this. I don't use all
> the fancy extra social video game crap.
> 
> > I'd be willing to *release* a game, *non-exclusively*, on steam just for the visibility and for the subset of PC gamers that are unfortunately dumb enough to think steam isn't DRM, but that's all steam is good for. Gabe can suck the shit out of my ass for destroying the last non-orwellian gaming platform in existence and essentially turning it into a goddamn iPhone.
> 
> You don't have to use it, you know. There are other games. GOG.com has a pile, and many of them run just fine under Wine and or DosBOX. I'd like to see them do more Linux, and I hope that the Steam port will be the beginning of more entries on to the platform.
> 

GOG.com is mostly for older games (which is great, of course). But most "PC" games that are being developed and released now are exclusively Steam. Even a lot of retail ones (like Super Meat Boy, as I was irritated to discover after the fact) still require Steam and won't even run without also starting up Steam (which of course must be installed on my system).

January 07, 2013
Andrei Alexandrescu, el  7 de January a las 08:31 me escribiste:
> >Why would I bother to do anything if is very likely that Walter don't want to go that direction and all my work was done for nothing? Been there before. Now I'm more cautious when selecting my battles.
> 
> 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.
> 
> That should reduce the cognitive load ("am I working for nothing over here?") on the proponent of the feature and would also motivate the proponent to define the feature with reasonable completeness before implementing it.

I think that would help a *LOT*. So basically this tag would mean something like: If somebody implement this AND the implementation is complete AND it has good quality, it will be in the next release?

If so, that's not too far from roadmap.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
22% of the time a pizza will arrive faster than an ambulance in Great-Britain
January 07, 2013
On 1/7/13 9:51 AM, Leandro Lucarella wrote:
> Andrei Alexandrescu, el  7 de January a las 08:31 me escribiste:
>>> Why would I bother to do anything if is very likely that Walter don't want
>>> to go that direction and all my work was done for nothing? Been there
>>> before. Now I'm more cautious when selecting my battles.
>>
>> 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.
>>
>> That should reduce the cognitive load ("am I working for nothing
>> over here?") on the proponent of the feature and would also motivate
>> the proponent to define the feature with reasonable completeness
>> before implementing it.
>
> I think that would help a *LOT*. So basically this tag would mean
> something like: If somebody implement this AND the implementation is
> complete AND it has good quality, it will be in the next release?

Yah, that's the idea.

> If so, that's not too far from roadmap.

It's less structured than a roadmap but maybe that's what would make it tenable!


Andrei
January 07, 2013
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.

-- 
/Jacob Carlborg
January 07, 2013
On 1/7/2013 4:41 AM, David Nadlinger wrote:
> On Monday, 7 January 2013 at 10:14:54 UTC, Robert Clipsham wrote:
>> Though I believe it will probably fail with older OS X versions which don't
>> have TLS support.
>
> Yes, it is not supported by linker and dyld versions shipping with OS X 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.

January 07, 2013
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).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Soy como una mosca, parada en el agua.
Y vos sos un transatlántico, querés nadar a mi lado.
Y me estás ahogando.
January 07, 2013
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.

-- 
/Jacob Carlborg