On Sunday, 1 February 2015 at 10:20:47 UTC, Dicebot wrote:
> I'd really like "Emphasize vibe.d" to be replaced with "Emphasize dub". Get the latter and you get the former essentially for free (and it is WIP already).

I wish inclusions like this would go through a code review, the sort we put new Phobos modules through. I don't use Dub but in #d you can regularly hear complaints about it crashing or inversely, silently catching all exceptions in some places.

Of course, this is wishful thinking - we have no resources to spare for such reviews, no resources to follow up on such reviews, and no resources to come up with alternatives that would pass these hypothetical reviews.

Still, who is going to take care of all these issues?

https://github.com/D-Programming-Language/dub/issues

On Sunday, 1 February 2015 at 14:00:37 UTC, Marc Schütz wrote:
> I think I can mostly agree with the plan, but:
>
>> Improve language stability
>> Define appropriately fuzzily-defined areas of the language (e.g. shared semantics, @property).
>
> This is either a contradiction in itself, or "stability" actually means "change".

I agree. If you substitute "feature completion" for "stability" the vision statement makes more sense.

On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> Walter and I have been mulling for a while on a vision for the first six months of 2015.
>
> http://wiki.dlang.org/Vision/2015H1
>
> This is stuff we consider important for D going forward and plan to work actively on. We encourage the D community to focus contributions along the same lines.
>
> We intentionally kept the document short and high-level as opposed to discussing tactical details. Such discussions are encouraged in the appropriate forums.
>
>
> Thanks,
>
> Walter and Andrei

Some of these vision statements are easier said than done. I'm reminded of the Serenity Prayer:

http://en.wikipedia.org/wiki/Serenity_Prayer

Question: When you say, "a focus on quality", what is that contrasted with? In the general sense, it's redundant to desire quality.

On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> Walter and I have been mulling for a while on a vision for the first six months of 2015.
>
> http://wiki.dlang.org/Vision/2015H1
>
> This is stuff we consider important for D going forward and plan to work actively on. We encourage the D community to focus contributions along the same lines.
>
> We intentionally kept the document short and high-level as opposed to discussing tactical details. Such discussions are encouraged in the appropriate forums.
>
>
> Thanks,
>
> Walter and Andrei

I'm surprised by one of the goals:
> Our aim is to top 2000 pull requests by June 30, 2015.

This is arguably the most well-defined goal here, but at the same time, it sounds strange to judge the contributions by the numbers of pull request. We could top that number -and I'm afraid we'll be tempted to do so- by submitting a streamline of pull requests fixing trivial doc problems / mispelling (I'm not saying docs P.R. are worthless), or implementing trivial functions.

I'd rather see a list of (high-level) wanted features here, either in Phobos (better file abstraction, better release process...) than "Receive & accept 2000 P.R in 6 months".

Regarding Vibe.d:
I partly agree with Dicebot that we should focus on dub first.
However, I like the idea that not-breaking-Vibe.d should be required for a release (2.067 being a perfect example of a major breaking change for Vibe.d).

In fact, something that I wanted to do for a long time is to have "badges" on code.dlang.org, which indicates which library builds with which compiler. This is important for the overall quality of the language, as, once it's in place, dub will be able to refuse fetching a library that's not building with 2.0XX, providing a much nicer experience to user. We'll also be able to see how much code a release / nightly (which is also something we lack) will break code, and how much code in code.dlang.org works with which version.

On 2/1/15 7:48 AM, Mathias LANG wrote:
> This is arguably the most well-defined goal here, but at the same time,
> it sounds strange to judge the contributions by the numbers of pull
> request. We could top that number -and I'm afraid we'll be tempted to do
> so- by submitting a streamline of pull requests fixing trivial doc
> problems / mispelling (I'm not saying docs P.R. are worthless), or
> implementing trivial functions.

Yah, Walter is also unconvinced of such metrics. There's anecdotal evidence the use of simple metrics could go either way, the risk for abuse being obvious.

However lack of measurable metrics on account of them being open to abuse may lead to lack of progress. I've had excellent experience with good use of metrics and proxies, and I trust our community there's little motivation to look good by playing the numbers.


Andrei

I think if a concrete number inspires people to commit loads of small fixes to docs, unittests, etc., then this is a good thing. It's not like anyone is going to give up on committing when the target's reached.

On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> http://wiki.dlang.org/Vision/2015H1

- Create the D Language Foundation

What exactly is this idea about, can you elaborate a bit?

On Sunday, February 01, 2015 08:41:54 Andrei Alexandrescu via Digitalmars-d-announce wrote:
> On 2/1/15 7:48 AM, Mathias LANG wrote:
> > This is arguably the most well-defined goal here, but at the same time, it sounds strange to judge the contributions by the numbers of pull request. We could top that number -and I'm afraid we'll be tempted to do so- by submitting a streamline of pull requests fixing trivial doc problems / mispelling (I'm not saying docs P.R. are worthless), or implementing trivial functions.
>
> Yah, Walter is also unconvinced of such metrics. There's anecdotal evidence the use of simple metrics could go either way, the risk for abuse being obvious.
>
> However lack of measurable metrics on account of them being open to abuse may lead to lack of progress. I've had excellent experience with good use of metrics and proxies, and I trust our community there's little motivation to look good by playing the numbers.

I would think that an open source community of volunteers would stand a better chance of avoiding some of the negatives of tracking various metrics, because the monetary compensation, promotion opportunities, etc. that such things can affect in a full-time job are not normally present in an open source project. There are likely other ways that they could lead to bad behavior that would affect us, but in general, I think that the odds that tracking metrics and pushing for their improvement will cause problems are fairly low. Now, they may not help particularly either, but I see no harm in trying. We can always stop if we find that it's causing problems.

- Jonathan M Davis

On Sunday, 1 February 2015 at 22:12:41 UTC, Andrej Mitrovic wrote:
> On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>> http://wiki.dlang.org/Vision/2015H1
>
> - Create the D Language Foundation
>
> What exactly is this idea about, can you elaborate a bit?

I think it's a reference to this thread:

http://forum.dlang.org/thread/m0q2hk$jj4$1@digitalmars.com

On Sunday, 1 February 2015 at 22:31:47 UTC, bachmeier wrote:
> On Sunday, 1 February 2015 at 22:12:41 UTC, Andrej Mitrovic wrote:
>> On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce
>> <digitalmars-d-announce@puremagic.com> wrote:
>>> http://wiki.dlang.org/Vision/2015H1
>>
>> - Create the D Language Foundation
>>
>> What exactly is this idea about, can you elaborate a bit?
>
> I think it's a reference to this thread:
>
> http://forum.dlang.org/thread/m0q2hk$jj4$1@digitalmars.com

Well the question is more like "what exactly are you going to do about it from all ideas mentioned?" :)

btw I personally think this is single most important point in the list that is necessary to actually moved forward with others in focused manner. But it really depends on how it is defined.