On 1/6/2013 8:42 AM, Nick Sabalausky wrote:
> Like browsers, for instance. When Microsoft had their browser merely
> uninstallable and set as the *initial* default browser, the DOJ went
> apeshit, nevermind the fact that MS did *nothing* to prevent people
> from downloading and using competing browsers.

The other bizarre thing about that case was the browsers were all free - IE, Opera, Netscape. Arguably it isn't even a marketplace if all the products are free (contract law doesn't recognize a transaction unless there is an exchange of value, which is why you'll see contracts that pay $1). I don't see how anti-trust laws even applied.

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.

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.

My 2 cents,
Brad

On Sunday, January 06, 2013 17:28:57 Brad Roberts wrote:
> 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.

You'd have to look at major open source projects. They do sometimes come to together and agree on the direction that they should take (KDE and gnome would probably be good examples of that), and a lot of their efforts get focused on what gets decided, but I believe that it's still primarily a case of people working on what they want to work on. But I haven't examined the development processes of other open source projects in depth.

If you have enough people, then the holes tend to get filled, but plenty of stuff still falls through the cracks, and unlike projects like KDE or gnome, I don't think that we have a need to create a direction for our project(s) and decide where they're going to be going. That might happen if we were talking about D3, but we're not (and I think that even the KDE and gnome guys only tend to do that when they're talking about where to go with their next major version). It's more of an issue of making sure that all of the little stuff that needs doing gets done. And if there's something that no one wants to work on or if everyone with the time and skill are working on other stuff that needs to be worked on, then some stuff just doesn't get done. And like you, I have no idea how to fix that.

- Jonathan M Davis

On 1/6/2013 5:41 PM, Jonathan M Davis wrote:
> On Sunday, January 06, 2013 17:28:57 Brad Roberts wrote:
>> 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.
> 
> You'd have to look at major open source projects. They do sometimes come to together and agree on the direction that they should take (KDE and gnome would probably be good examples of that), and a lot of their efforts get focused on what gets decided, but I believe that it's still primarily a case of people working on what they want to work on. But I haven't examined the development processes of other open source projects in depth.
> 
> If you have enough people, then the holes tend to get filled, but plenty of stuff still falls through the cracks, and unlike projects like KDE or gnome, I don't think that we have a need to create a direction for our project(s) and decide where they're going to be going. That might happen if we were talking about D3, but we're not (and I think that even the KDE and gnome guys only tend to do that when they're talking about where to go with their next major version). It's more of an issue of making sure that all of the little stuff that needs doing gets done. And if there's something that no one wants to work on or if everyone with the time and skill are working on other stuff that needs to be worked on, then some stuff just doesn't get done. And like you, I have no idea how to fix that.
> 
> - Jonathan M Davis

Both KDE and Gnome have major distributions behind them which almost certainly provide a lot of the labor for the 'not fun' parts.  Essentially _every_ popular package has the same.  They might be open source, but it's not the volunteers that make them polished, for the most part.

Walter Bright, el  6 de January a las 16:36 me escribiste:
> On 1/6/2013 3:49 PM, Pierre Rouleau wrote:
> >If this list already contains all (does it?) of what is currently identified then is there some criteria one can use to try to infer what will be implemented in the next release? Or is it just "first come first served" where the solved enhancements automatically get pulled inside the release?
> 
> The thing is, roadmaps are a lot like planning for a war. The moment the first shot is fired, all the plans go out the window. What we need to get done next is a constantly evolving situation, based on:
> 
> 1. some crisis may occur
> 
> 2. some opportunity may present itself
> 
> 3. the language market may change its perception of what is important
> 
> 4. a member of the community may promote themselves to be a champion of some particular issue, and work to get it implemented
> 
> 5. our understanding of what is important and what isn't constantly evolves
> 
> 6. there's constant evolution of what exactly is best practice and the best way to realize that

This is all true for planning 5 years ahead, not 1~3 months. You don't even have to get a very precise plan, you can just focus on some aspect and try to advance in that direction. And having a plan doesn't mean you can't change it if something comes up.

> Probably pretty high on the list would be solving the rvalue reference problem.

This is a good example of something that can go into a roadmap for the next 1~3 months (AKA next release). See? You can do it. :P

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hello?
Is there anybody in there?
Just nod if you can hear me.
Is there anyone at home?

On 13-01-06 7:36 PM, Walter Bright wrote:
> On 1/6/2013 3:49 PM, Pierre Rouleau wrote:
>> If this list already contains all (does it?) of what is currently
>> identified
>> then is there some criteria one can use to try to infer what will be
>> implemented
>> in the next release? Or is it just "first come first served" where the
>> solved
>> enhancements automatically get pulled inside the release?
>
> The thing is, roadmaps are a lot like planning for a war. The moment the
> first shot is fired, all the plans go out the window. What we need to
> get done next is a constantly evolving situation, based on:
>
> 1. some crisis may occur
>
> 2. some opportunity may present itself
>
> 3. the language market may change its perception of what is important
>
> 4. a member of the community may promote themselves to be a champion of
> some particular issue, and work to get it implemented
>
> 5. our understanding of what is important and what isn't constantly evolves
>
> 6. there's constant evolution of what exactly is best practice and the
> best way to realize that
>
> Probably pretty high on the list would be solving the rvalue reference
> problem.
>
OK, I can understand that point of view and I recognize that it's been the view the project has taken which allowed D to evolved nicely.

So, given that enhancements are identified in Bugzilla, is there a review process?  Are ticket priorities and vote used?  Who decides what is the priority of an enhancement?   Who assigns them?

Also, given that view on the development of D, what is the position on the evolution of the language in context with backward compatibility and stability?   How can an organization of D users that are not also D developers can plan a project and use D for it?

Do you consider D stable enough for outside users/organizations to start using it in their own projects?

-- 
/Pierre Rouleau

On 13-01-06 8:41 PM, Jonathan M Davis wrote:
> On Sunday, January 06, 2013 17:28:57 Brad Roberts wrote:
>> 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.
>
> You'd have to look at major open source projects. They do sometimes come to
> together and agree on the direction that they should take (KDE and gnome would
> probably be good examples of that), and a lot of their efforts get focused on
> what gets decided, but I believe that it's still primarily a case of people
> working on what they want to work on. But I haven't examined the development
> processes of other open source projects in depth.
>
> If you have enough people, then the holes tend to get filled, but plenty of
> stuff still falls through the cracks, and unlike projects like KDE or gnome, I
> don't think that we have a need to create a direction for our project(s) and
> decide where they're going to be going. That might happen if we were talking
> about D3, but we're not (and I think that even the KDE and gnome guys only
> tend to do that when they're talking about where to go with their next major
> version). It's more of an issue of making sure that all of the little stuff
> that needs doing gets done. And if there's something that no one wants to work
> on or if everyone with the time and skill are working on other stuff that needs
> to be worked on, then some stuff just doesn't get done. And like you, I have no
> idea how to fix that.
>
> - Jonathan M Davis
>
Is this something that the most influential people in the D project want to fix?

-- 
/Pierre Rouleau

On Sunday, January 06, 2013 21:15:43 Pierre Rouleau wrote:
> So, given that enhancements are identified in Bugzilla, is there a review process?  Are ticket priorities and vote used?  Who decides what is the priority of an enhancement?   Who assigns them?

There's pretty much never any assigning of issues in D's developement. Developers work on whatever they feel like working on. An enhancement request gets implemented, because someone decided to put the time in to implement it. If it's controversial, then it'll generally get discussed in the newsgroup, though some of that is likely to take place in the bug report itself or in a pull request if the developer implements it without discussing it first. Large language changes always get major discussions, but we also don't get a lot of those at this point. It's mostly little stuff.

> Also, given that view on the development of D, what is the position on the evolution of the language in context with backward compatibility and stability?

We're trying to reach the point where you can count on your code compiling for years without changing it. We're getting there, but it doens't always happen. Even fixing bugs breaks code when code relies on buggy behavior. There's also still some API changes in Phobos which breaks stuff, but we've been cutting back on those and trying to avoid them, so they happen much less now then they used to. The recent change to make deprecated warn instead of giving an error should help with that.

> How can an organization of D users that are not also D developers can plan a project and use D for it?
> 
> Do you consider D stable enough for outside users/organizations to start using it in their own projects?

It's stable enough as long as you're continually working on your code. If you let it sit for a long period of time, you're likely to need the same compiler and library version that you used when you last worked on it. Breakages are _far_ fewer than they used to be, but they still happen. I'd expect that anyone using D seriously for professional development would stick to one version of the compiler for a while and then upgrade it when they have time to update their code (which they may not need to do, but it's still not quite to the point that there isn't at least a decent chance that a few lines of code will have to be changed).

API breakage does occur sometimes, but we're making an effort to keep that to a minumum, and we'd like to get rid of it completely. But regardless, I believe that most breakages at this point are due to bug fixes, so when we'll reach the point that you can really expect your code to continue to compile for years on newer compilers without trouble, I don't know. That may depend primarily on the bugs that we have left and how well regressions get caught. The work that's currently being done on formalizing and ironing out the release process should help with that though.

- Jonathan M Davis

On 1/6/2013 6:15 PM, Pierre Rouleau wrote:
> So, given that enhancements are identified in Bugzilla, is there a review
> process?  Are ticket priorities and vote used?  Who decides what is the priority
> of an enhancement?   Who assigns them?

Pretty much anyone who wants to take one of them on does so and when done, issues a pull request for it. At that point, there's a general discussion of it and a decision is reached, usually by consensus.


> Also, given that view on the development of D, what is the position on the
> evolution of the language in context with backward compatibility and
> stability?   How can an organization of D users that are not also D developers
> can plan a project and use D for it?
>
> Do you consider D stable enough for outside users/organizations to start using
> it in their own projects?

Yes, and it is used heavily for commercial purposes by at least a couple companies.

Like any other language, if you insist on using the latest feature and pushing it to the limit, you are more likely to run into problems than if you are a bit more modest in your use of it.

That said, we make a large effort to fix all regressions upon each release, and I push hard to avoid making breaking changes to the language unless it is really unavoidable.

On Sunday, January 06, 2013 21:22:18 Pierre Rouleau wrote:
> Is this something that the most influential people in the D project want to fix?

What exactly do you want fixed? Sure, it would be great if we could know when certain things are going to be implemented or fixed, but without people to work on them, we can't know when that's going to happen. A lack of time and of manpower are frequently the problem here. And if you want a particular problem fixed, someone else wants another one fixed. Frequently, both could be considered high priority, and the developers only have so much time. Also, it's frequently the case that specific people are needed to fix specific issues - especially if we don't have new people stepping up to the plate and learning how to do stuff - creating an even greater bottleneck.

Maybe we could get some sort of consensus on what the biggest issues are and try and get people to focus on those, but frequently, what we really need is for someone to step up and spend the time necessary to fix the issue. When that happens, stuff gets done. When it doesn't, it doesn't really matter what the biggest issues are, because there's a lack of manpower to fix them. And frequently, each major issue requires a different set of expertise, making it hard to for someone or even a small group of someones to work on all of the major issues. And we only have a small group of someones.

So, if you have any suggestions on how to improve the process or otherwise help us get stuff done, great. If you think that there's something that we can do to better encourage participation, we're all ears. For instance, the release process is currently being adjusted precisely because people thought that it was a major issue and have spent the time to work out what should be done about it. But to a great extent, I don't think we necessarily know what needs to be changed or how it should be changed. Good ideas are required, and we're tight enough on time and manpower as it is just trying to get done everything that we know needs to get done.

Almost always, the key is for someone who's passionate about something to get involved and make sure that it gets done.

- Jonathan M Davis