After some discussions on topic I decided to have a look how it actually may look in practice and experience was mostly pleasing so far.

Trivial proof of concept : https://github.com/Dicebot/TestDlangAggregated

Idea is to create an aggregated repository as part of D-Programming-Language organization which will include other existing ones as a submodules and host utility script(s) for easy jump in and release management.

There is somewhat similar project by Vladimir (https://bitbucket.org/cybershadow/d) but it has different goals - providing synchronised history across all dlang repos. In my proposed repo actual submodule commits get updated only when new compiler release is being made and updating to latest development version from a fresh clone is done via simle script.

That will both define a standard file layout cross-repo tools can rely on and allow anyone curious to quickly get started with D development by cloning a single repository - without polluting the system with any additional artifacts.

See repo README.md for more details

Additional possibilities for future development:

1) replacing makefiles with D-based build scipts for perfect cross-plafrom bootstrapping with no extra dependencies
2) including Digger (https://github.com/CyberShadow/Digger) into standard layout for those who need more sophisticated repo management
3) enabling GitHub issues _for that one repo_ to use milestones instead of wiki.dlang.org/Agenda for release planning

Destroy?

On 02/08/2015 10:33 PM, Dicebot wrote:

> Trivial proof of concept : https://github.com/Dicebot/TestDlangAggregated

Great idea. I've been using the following one just to keep up-to-date with git head dmd and Phobos:

  https://github.com/carlor/dlang-workspace

Ali

On Monday, 9 February 2015 at 07:04:35 UTC, Ali Çehreli wrote:
> On 02/08/2015 10:33 PM, Dicebot wrote:
>
> > Trivial proof of concept :
> https://github.com/Dicebot/TestDlangAggregated
>
> Great idea. I've been using the following one just to keep up-to-date with git head dmd and Phobos:
>
>   https://github.com/carlor/dlang-workspace
>
> Ali

Probably about time we merged all those efforts into single standard solution under D-Programming-Language ;)

I want to get Andrei/Walter on board first though.

On 2/8/15 11:58 PM, Dicebot wrote:
> On Monday, 9 February 2015 at 07:04:35 UTC, Ali Çehreli wrote:
>> On 02/08/2015 10:33 PM, Dicebot wrote:
>>
>> > Trivial proof of concept :
>> https://github.com/Dicebot/TestDlangAggregated
>>
>> Great idea. I've been using the following one just to keep up-to-date
>> with git head dmd and Phobos:
>>
>>   https://github.com/carlor/dlang-workspace
>>
>> Ali
>
> Probably about time we merged all those efforts into single standard
> solution under D-Programming-Language ;)
>
> I want to get Andrei/Walter on board first though.

Well I have to say something.

This proposal is a good example of a cultural lore we should unlearn: high-churn, low-impact changes. https://github.com/D-Programming-Language/dlang.org/pull/896 is another example. Meaning changes with a large surface that rewire vast areas, yet result in only dingy improvements.

The main problem with these is they're easy to argue in favor of. Yes, an aggregate repository will make certain things easier. I'm unclear on the relative advantages and disadvantages, but I have no doubt Dicebot has some good arguments loaded already. On that pull request, yes, searching the language definition separately is a nice thing to have.

Yet, even after executing e.g. the unified repository to perfection and after everything was said and done, we're like... how much better than we were? What pain points did we fix? What is the impact?

Probably something that's neither important nor urgent.

Yet we do have matters that are important and urgent. We want to improve Phobos' take on memory allocation. Yet not one soul is working on RefCounted. Few know even what needs to be done of it. Why? Why are so many of us dedicating so much energy to tweaking what already works, instead of tackling real problems? Problems that e.g. - pardon my being pedantic - are in the vision document?

Don't get me wrong. It's quite likely a unified repo would be nice. As would be a separate directory for the language definition. But it's just not what we should be on right now.

This culture of riding the stationary bike faster and faster must change. We must hop on the real bike and get to pedaling.


Thanks,

Andrei

On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu wrote:
> Yet we do have matters that are important and urgent. We want to improve Phobos' take on memory allocation. Yet not one soul is working on RefCounted. Few know even what needs to be done of it.

I think you may have just answered your own question.

> Why? Why are so many of us dedicating so much energy to tweaking what already works, instead of tackling real problems? Problems that e.g. - pardon my being pedantic - are in the vision document?

I feel a bit of the myth of the interchangeable programmer
creeping in here. Maybe the people who are working on websites
aren't memory management experts. Are our memory management
experts working on websites? If a web designer was tasked with
improving RefCounted, what are the odds of their work getting
through code review?

On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu wrote:
> Well I have to say something.

Great, lets debate :P

> This proposal is a good example of a cultural lore we should unlearn: high-churn, low-impact changes. https://github.com/D-Programming-Language/dlang.org/pull/896 is another example. Meaning changes with a large surface that rewire vast areas, yet result in only dingy improvements.
>
> The main problem with these is they're easy to argue in favor of. Yes, an aggregate repository will make certain things easier. I'm unclear on the relative advantages and disadvantages, but I have no doubt Dicebot has some good arguments loaded already. On that pull request, yes, searching the language definition separately is a nice thing to have.

It is a delicate matter. Yes, spreading over less important issues is harmful for focusing on core ones. But the same time having many small issues unresolved harms the contribution culture as those keep annoying people over and over again.

In this specific case I didn't take go at this because I was bored and wanted to do _something_. It was because problem with lack of reliable standard layout kept appearing every time we wanted to improve build tools and release automation. It was because I was annoyed that I still can't test Phobos pull requests on Windows machine even despite getting one - because setting up a dev environment is just too different between platforms.

There is a great value in rejecting or delaying controversial changes if those don't improve on core areas. But with no real controversy (is there one for this proposal?) it is simply rejecting work available for free.

> Yet, even after executing e.g. the unified repository to perfection and after everything was said and done, we're like... how much better than we were? What pain points did we fix? What is the impact?
>
> Probably something that's neither important nor urgent.

It had good enough importance/effort _ratio_. Low-hanging fruit how you tend to call it.

> Yet we do have matters that are important and urgent. We want to improve Phobos' take on memory allocation. Yet not one soul is working on RefCounted. Few know even what needs to be done of it. Why? Why are so many of us dedicating so much energy to tweaking what already works, instead of tackling real problems? Problems that e.g. - pardon my being pedantic - are in the vision document?

This proposal directly addresses two of vision document points - "Improve the brand" and "Raise participation" by trying to minimize entry barrier for D development.

At the same time stuff like RefCounted is a mess. I have no idea how to do something useful about it without language changes. I disagree with all your proposals on topic. I don't actually need solution for that issue in my daily D coding. Do you honestly expect me to spend any effort at all on it simply because you mentioned that in vision doc? Seriously?

> Don't get me wrong. It's quite likely a unified repo would be nice. As would be a separate directory for the language definition. But it's just not what we should be on right now.
>
> This culture of riding the stationary bike faster and faster must change. We must hop on the real bike and get to pedaling.

I do what I feel needs to be done. You are free either reject or accept it. But please don't tell me how I should manage my own spare time. If you want cultural change - lead by example.

On Tuesday, 10 February 2015 at 07:17:11 UTC, Dicebot wrote:

> At the same time stuff like RefCounted is a mess.

+1
(Sorry for the noise, just wanted to share the opinion. :) )

On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu wrote:
>
> Well I have to say something.
>
> This proposal is a good example of a cultural lore we should unlearn: high-churn, low-impact changes. https://github.com/D-Programming-Language/dlang.org/pull/896 is another example. Meaning changes with a large surface that rewire vast areas, yet result in only dingy improvements.

I was quite surprised with your post, as you seemed on board with this idea last year (https://issues.dlang.org/show_bug.cgi?id=11792).

> Why? Why are so many of us dedicating so much energy to tweaking what already works, instead of tackling real problems? Problems that e.g. - pardon my being pedantic - are in the vision document?
>

We do have a strong syndrome of NIH in this community, but I don't think it's the issue here.
You mentionned in a thread the vision documentation was stuff you and Walter were working on, rather than "TODO list" for contributors.
I think what we need ATM is not a vision, but milestones. What's outlined in the doc has little value for someone who wants to contribute.

IMO the agenda ( horribly outdated: http://wiki.dlang.org/Agenda ) is more important than the vision if you want people to work on a specific area.

You'll measure success more effectively if you are able to quantify (and consequently, tell you you're done with) a task. I don't see any of the points mentionned in the vision document as something that can be "ticked off". Beside "Create a D Language Foundation", but I can't do it myself.

On Tuesday, 10 February 2015 at 07:49:28 UTC, Mathias LANG wrote:
> On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu wrote:
>>
>> Well I have to say something.
>>
>> This proposal is a good example of a cultural lore we should unlearn: high-churn, low-impact changes. https://github.com/D-Programming-Language/dlang.org/pull/896 is another example. Meaning changes with a large surface that rewire vast areas, yet result in only dingy improvements.
>
> I was quite surprised with your post, as you seemed on board with this idea last year (https://issues.dlang.org/show_bug.cgi?id=11792).

I knew this was old, didn't realize it was _that_ old :) Will link my repo from that issue too.

Also, to put it differently : getting small things done is better than not getting big things done. Main harm comes from bikeshedding about no-so-important issue, not from implementing those.