www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal : aggregated dlang git repository

reply "Dicebot" <public dicebot.lv> writes:
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?
Feb 08 2015
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Feb 08 2015
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Feb 08 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 09 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
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?
Feb 09 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-02-10 at 07:02 +0000, Brian Schott via Digitalmars-d wrote:
 On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu=20
 wrote:
 Yet we do have matters that are important and urgent. We want to=20
 improve Phobos' take on memory allocation. Yet not one soul is=20
 working on RefCounted. Few know even what needs to be done of it.
=20 I think you may have just answered your own question. =20
 Why? Why are so many of us dedicating so much energy to
 tweaking what already works, instead of tackling real problems?=20
 Problems that e.g. - pardon my being pedantic - are in the
 vision document?
=20 I feel a bit of the myth of the interchangeable programmer creeping in here. Maybe the people who are working on websites=20 aren't memory management experts. Are our memory management experts working on websites? If a web designer was tasked with=20 improving RefCounted, what are the odds of their work getting through code review?
There is also the issue that very few, if any, people are paid to work=20 on D implementation. Thus with only volunteer labour (you may think of=20 that as labor if you really have to ;-) people will work on what they=20 want to work on, and systemically, are more likely to work on the=20 smaller things as they have clearly visible boundaries. And then there is the trivial that also become the barrier. For=20 example I find it very difficult to read Phobos style code, so I=20 don't. Not that Phobos code style should change because I don't like=20 it, but it shows that trivial barriers can stop contribution. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 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
Feb 10 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 February 2015 at 11:59:14 UTC, Russel Winder wrote:
 that as labor if you really have to ;-) people will work on 
 what they
 want to work on, and systemically, are more likely to work on 
 the
 smaller things as they have clearly visible boundaries.
refcounting is not a big thing, but I am not really sure if there is a clean way to do it with the current infrastructure. I am pretty sure that someone would do it if there was a clean design for it.
 And then there is the trivial that also become the barrier. For
 example I find it very difficult to read Phobos style code, so I
 don't. Not that Phobos code style should change because I don't 
 like
 it, but it shows that trivial barriers can stop contribution.
Yes, Phobos is too much like Tango. :-/ So I've started writing my own... :-P
Feb 10 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Feb 09 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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. :) )
Feb 09 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/9/15 11:28 PM, weaselcat wrote:
 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. :) )
One actionable item would be to point at a code fragment and argue "wtf - here's some good evidence". Thanks! -- Andrei
Feb 10 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 10 February 2015 at 17:00:18 UTC, Andrei Alexandrescu 
wrote:
 On 2/9/15 11:28 PM, weaselcat wrote:
 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. :) )
One actionable item would be to point at a code fragment and argue "wtf - here's some good evidence". Thanks! -- Andrei
My position isn't as a D developer but as a (somewhat new) D user attempting to port a C++ library. Many features in D feel unfinished and tons of feature requests sit on the bug tracker. Attempting to port a library that requires a lot of deterministic resource management to D has felt like I've been repeatedly kicked in the teeth. There was an enhancement request from 2009 that got closed by Walter about addressing D's lack of resource management utilities back in November (2014) saying just use refcounted. That would be great if refcounted wasn't half implemented and nearly featureless compared to C++'s shared_ptr. There was a few bug reports for unique/refcounted (submitted by you IIRC) to address their many issues that have pretty much just sat there and which are far beyond my current D skillset to work on. All while major D developers were working on the website and major D utilities are well - broken. Addendum, I wrote this on a phone during my commute so I apologize about the lack of specifics and links - I hate mobile typing. :) Also, I am not blaming anyone for not working on what I deem important in a FOSS project. I use almost only FOSS software and understand that if I want feature X I should submit a PR. But a lot of my disgruntlement using D has already been summed up in proposed DIPs that rot on the wiki. I'm probably going to continue using D because I like where it's headed but it would be very difficult for me to recommend it to any colleagues. Again I apologize for the briefness, I'll try to reply to this later with better details.
Feb 10 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/15 9:44 AM, weaselcat wrote:
 Again I apologize for the briefness, I'll try to reply to this later
 with better details.
Much appreciated, thanks. -- Andrei
Feb 10 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 10 February 2015 at 17:47:59 UTC, Andrei Alexandrescu 
wrote:
 On 2/10/15 9:44 AM, weaselcat wrote:
 Again I apologize for the briefness, I'll try to reply to this 
 later
 with better details.
Much appreciated, thanks. -- Andrei
To continue from earlier, Once again, my POV is that from a *user* of D, not a *developer.* I realize that a solid 9 out of 10 of the people on the newsgroup actively contribute to D and I don't want to offend anyone : ). I was just using RefCounted!T as one example of a major headache I've had with D. To follow up upon earlier, https://issues.dlang.org/show_bug.cgi?id=2757 This issue was filed in 2009 and succinctly covers why someone might need deterministic resource management(i.e - RAII.) 3 months ago it was marked WONTFIX with a statement to just use Refcounted. Great. Except the issue wasn't fixed because Refcounted has serious issues and IMO it shouldn't have been closed. I'd harp on this - but a feature request for it already exists. https://issues.dlang.org/show_bug.cgi?id=13983 Not just one either... https://issues.dlang.org/show_bug.cgi?id=13972 https://issues.dlang.org/show_bug.cgi?id=9998 (2013) (I don't think any of them address that refcounted is unusable on classes, abandon polymorphism all ye who attempt to work around the GC.) So pretty much the only way to handle resources that require cleanup is to use a struct. Using the destructor of an object for... well, nearly anything is undefined AFAICT. I have a fun game, walk up to a random person at the next CPPcon and tell them that they're no longer allowed to use destructors to manage resources and see what kind of face they make ;) At this point I start to realize that _most_ of the code I'm attempting to port requires this type of management. Suddenly I feel like I've been thrown a few decades in the past and get to use C with fancy semantics like slicing. The one thing the language has basically been designed around is completely unusable to me because I can't rely on the GC's non-deterministic behavior. I'd love the GC if it could actually _manage_ my garbage for me, but instead I feel like D has delegated me to the position of garbage collector in a much more serious way than C++ _ever_ has... well, C++11 and forward anyways. FYI, this thread has a great discussion on these issues. http://forum.dlang.org/thread/20140430231745.GA1125 quickfur.ath.cx?page=3#post-bqweskwediwlijuzfdts:40forum.dlang.org I'm sure I'll get a response from ketmar( ;-) ) or another D superuser who will scoff at my issues and how they know how to work around the warts in D by using arcane hacks and custom patches... but honestly I don't think I'm the first person to make these sort of complaints. Hell, the blog that started two(? one?) of the bug requests linked above mentioned the same issue. I made these two posts not to cry about the language, but to say "Hey, D is kind of really lacking here!" I'd love to just submit a PR, but it is above my paygrade to fix a major feature like RefCounted. I'm sorry if this is off-topic, I did not mean to derail your thread Dicebot. I just wanted to share my experience of trying to ease into D as someone who can't just open up phobos and begin hacking away enhancements like most of the people here. I hope this was the sort of reply you were looking for, Andrei.
Feb 10 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 11, 2015 at 03:20:57AM +0000, weaselcat via Digitalmars-d wrote:
[...]
 I was just using RefCounted!T as one example of a major headache I've
 had with D.
[...] Jakob Ovrum has just submitted a PR to make (the current version of) RefCounted reject interfaces, since currently it doesn't do that correctly (it refcounts the reference to the interface rather than the target object). Given this is the current situation, it would appear to me to make RefCounted work with class objects, "all" we have to do would be to specialize RefCounted for classes, use malloc to allocate the necessary space (plus the refcount, of course), and emplace() the class object onto that space. Right? Of course, given that it has been ... oh, months? years? since RefCounted issues have been addressed, I'm probably just kidding myself that there are no major monkey wrenches in the works that would make the above simplistic solution not work. And I'm not sure I really want to know... Not until I have an actual use case for RefCounted in my own code, anyway, since otherwise I wouldn't have any confidence that I was making the right decisions in making any changes to it. T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Feb 10 2015
next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 11 February 2015 at 05:39:59 UTC, H. S. Teoh wrote:
 Jakob Ovrum has just submitted a PR to make (the current 
 version of)
 RefCounted reject interfaces, since currently it doesn't do that
 correctly (it refcounts the reference to the interface rather 
 than the
 target object).

 Given this is the current situation, it would appear to me to 
 make
 RefCounted work with class objects, "all" we have to do would 
 be to
 specialize RefCounted for classes, use malloc to allocate the 
 necessary
 space (plus the refcount, of course), and emplace() the class 
 object
 onto that space. Right?

 Of course, given that it has been ... oh, months? years? since
 RefCounted issues have been addressed, I'm probably just 
 kidding myself
 that there are no major monkey wrenches in the works that would 
 make the
 above simplistic solution not work. And I'm not sure I really 
 want to
 know... Not until I have an actual use case for RefCounted in 
 my own
 code, anyway, since otherwise I wouldn't have any confidence 
 that I was
 making the right decisions in making any changes to it.
I also think it doesn't look like a big job, but I didn't see any current activity on the subject and my own immediate priorities are elsewhere, hence the simple one-line PR as a stop-gap measure.
Feb 11 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 February 2015 at 05:39:59 UTC, H. S. Teoh wrote:
 On Wed, Feb 11, 2015 at 03:20:57AM +0000, weaselcat via 
 Digitalmars-d wrote:
 [...]
 I was just using RefCounted!T as one example of a major 
 headache I've
 had with D.
[...] Jakob Ovrum has just submitted a PR to make (the current version of) RefCounted reject interfaces, since currently it doesn't do that correctly (it refcounts the reference to the interface rather than the target object). Given this is the current situation, it would appear to me to make RefCounted work with class objects, "all" we have to do would be to specialize RefCounted for classes, use malloc to allocate the necessary space (plus the refcount, of course), and emplace() the class object onto that space. Right? Of course, given that it has been ... oh, months? years? since RefCounted issues have been addressed, I'm probably just kidding myself that there are no major monkey wrenches in the works that would make the above simplistic solution not work. And I'm not sure I really want to know... Not until I have an actual use case for RefCounted in my own code, anyway, since otherwise I wouldn't have any confidence that I was
Biggest problem with RefCounted is that it is a struct. Thus it is inherently incompatible with polymorphic world. It is impossible to do reference counted exceptions without language changes (Andrei had proposal about it but it seems to have stalled). It may be possible but not obvious how to do referenced counted interfaces (that point to reference counted classes). It is unclear how one would write in an idiomatic manner a function that accepts object instance without caring if it is GC or ref-counted one (without resorting to templates).
Feb 11 2015
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 11/02/2015 13:52, Dicebot wrote:
 Biggest problem with RefCounted is that it is a struct. Thus it is
 inherently incompatible with polymorphic world.
For Unique, (which admittedly is a simpler concept), it does work with polymorphic types, see: http://dlang.org/phobos-prerelease/std_typecons.html#.Unique.this.3
Feb 11 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 11 Feb 2015 03:20:57 +0000, weaselcat wrote:

 I'm sure I'll get a response from ketmar( ;-) )
for your pleasure, sir! believe me or not, but i almost fully share your opinion. i'm not using=20 classes (well, almost), and when i have to, GC is working ok for me. but=20 i can see a need in deterministic resource management and classes=20 simultaneously. ;-) one of my hobbies is remaking ancient videogames=20 (don't ask; i never finished one ;-), so i can understand a desire to=20 aviod D GC. but hey, do you need classes at all? structs works too, you can have=20 pointers to functions inside, you can simulate inheritance with `alias=20 this`, and you can use `RefCounted!`. and there is mixin magic to write=20 nice initializers. (sorry, i just can't stand the temptation!)=
Feb 11 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 11 February 2015 at 08:21:27 UTC, ketmar wrote:
 On Wed, 11 Feb 2015 03:20:57 +0000, weaselcat wrote:

 I'm sure I'll get a response from ketmar( ;-) )
for your pleasure, sir! believe me or not, but i almost fully share your opinion. i'm not using classes (well, almost), and when i have to, GC is working ok for me. but i can see a need in deterministic resource management and classes simultaneously. ;-) one of my hobbies is remaking ancient videogames (don't ask; i never finished one ;-), so i can understand a desire to aviod D GC.
I see it as quite a shame that people repeatedly say they actively avoid using classes in D in favor of structs where possible, until forced to use classes.
Feb 11 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 11 Feb 2015 14:32:59 +0000, weaselcat wrote:

 I see it as quite a shame that people repeatedly say they actively avoid
 using classes in D in favor of structs where possible, until forced to
 use classes.
it has nothing with GC per se, i just don't like the concept. not=20 epsecially D classes, but the whole C++-inspired thing (yes, i know that=20 it wasn't C++ invention; yet it's C++ which popularized it). current OOP=20 is overrated. and real smalltalk-like OOP is not very vell suitable for=20 static typed languages. i'm still slowly developing a BlackBox-like system, though, that is fully=20 based on classes and modules. yet i don't want to develop it too far=20 before DDMD arrives. and i don't have a codegen (alas, this problem seems=20 unsolvable).=
Feb 11 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/15 7:20 PM, weaselcat wrote:
[snip]
 I hope this was the sort of reply you were looking for, Andrei.
Yes, that's good stuff. Thanks! -- Andrei
Feb 11 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Feb 10 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/9/15 11:17 PM, Dicebot wrote:
 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.
I only replied because you explicitly asked for my opinion, under the assumption it would be discussed civilly even if it is not aligned with yours. Andrei
Feb 10 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 February 2015 at 17:04:36 UTC, Andrei Alexandrescu 
wrote:
 On 2/9/15 11:17 PM, Dicebot wrote:
 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.
I only replied because you explicitly asked for my opinion, under the assumption it would be discussed civilly even if it is not aligned with yours. Andrei
There seems to be a weird miscommunication here. I have asked your opinion about this specific proposal - does it seem useful to you, would you be willing to endorse it as official starting point for D development etc. Instead I got verbose explanation about my attitude being wrong and how other areas are more important to work on. Thus it wasn't on point at all. By rejecting this you won't make me work on other things that _you_ consider more important - it will simply make me reconsider this project as private one and not keep in mind potential upstream inclusion. May I suggest you to do some research on open-source project management and related topics? It feels like there is a huge mismatch between how you expect things to work and how those happen to work in practice. Such misplaced expectations can do a lot of harm for project leadership.
Feb 11 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/15 5:48 AM, Dicebot wrote:
 There seems to be a weird miscommunication here. I have asked your
 opinion about this specific proposal - does it seem useful to you, would
 you be willing to endorse it as official starting point for D
 development etc.
Problem is I don't know. That's why I submitted that task https://issues.dlang.org/show_bug.cgi?id=11792 "Investigate...". I'm not a git expert so I don't have answers to a bunch of questions. I see from your opening arguments: * "experience was mostly pleasing so far" * "define a standard file layout cross-repo tools" * "allow anyone curious to quickly get started with D development by cloning a single repository" * Pointer to https://github.com/Dicebot/TestDlangAggregated/blob/master/README.md. Document shows how starting with the unified repository is easy. There are quite a few other questions to answer: * What's going to happen with the commit history for our current projects? * How about the pull requests history? * What are the changes in workflow compared to the current situation? * What tasks will be easier? * What tasks will be more difficult? And probably more questions I don't even know what they are. FWIW Martin Nowak is a key person to convince of the advantages of the change. My current perception is: - I have a simple workflow that I'd find difficult to assume would be radically improved. But it is possible there are conveniences I'm not anticipating. - The "getting started" advantage can be achieved on top of our current layout with tactical tools such as documentation and tools/update.sh. There's work there, of course. - I noticed people who contribute to dmd, druntime, and phobos are relatively specialized, i.e. Kenji seldom gets into phobos, H.S. Teoh seldom gets into dmd etc. That does seem to be an argument in favor of the current modularity. Furthermore they seem to have little friction getting into these projects if they do want to. Probably the main question is whether tooling with our layout is just fine. Andrei
Feb 11 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei 
Alexandrescu wrote:
 * What's going to happen with the commit history for our 
 current projects?

 * How about the pull requests history?
If you have to ask this question, there's clearly a big communication gap. This is not an overhaul of existing repositories or processes. The answer to both is "nothing", and I don't think anyone is seriously considering a change that would invalidate either.
Feb 11 2015
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 February 2015 at 16:30:21 UTC, Vladimir 
Panteleev wrote:
 On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei 
 Alexandrescu wrote:
 * What's going to happen with the commit history for our 
 current projects?

 * How about the pull requests history?
If you have to ask this question, there's clearly a big communication gap. This is not an overhaul of existing repositories or processes. The answer to both is "nothing", and I don't think anyone is seriously considering a change that would invalidate either.
I would like to add that, however, it might be worth considering moving everything to a single repository at the same time as the switch to DDMD. DDMD by itself is a big change, so aggregating other changes with big wolkflow impact (but net benefit in the long run) would make sense.
Feb 11 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/15 8:30 AM, Vladimir Panteleev wrote:
 On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei Alexandrescu wrote:
 * What's going to happen with the commit history for our current
 projects?

 * How about the pull requests history?
If you have to ask this question, there's clearly a big communication gap. This is not an overhaul of existing repositories or processes. The answer to both is "nothing", and I don't think anyone is seriously considering a change that would invalidate either.
Can't be "nothing" - there will be something. E.g. the commit history of the new repo will be a merge of the histories of the individual projects. Is that right? -- Andrei
Feb 11 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 February 2015 at 16:37:29 UTC, Andrei 
Alexandrescu wrote:
 On 2/11/15 8:30 AM, Vladimir Panteleev wrote:
 On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei 
 Alexandrescu wrote:
 * What's going to happen with the commit history for our 
 current
 projects?

 * How about the pull requests history?
If you have to ask this question, there's clearly a big communication gap. This is not an overhaul of existing repositories or processes. The answer to both is "nothing", and I don't think anyone is seriously considering a change that would invalidate either.
Can't be "nothing" - there will be something. E.g. the commit history of the new repo will be a merge of the histories of the individual projects. Is that right? -- Andrei
No. To clarify, the new repo is not a replacement of the existing ones. It is an additional meta-repository, which, when cloned with --recursive, gets all the other ones.
Feb 11 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/15 8:38 AM, Vladimir Panteleev wrote:
 No. To clarify, the new repo is not a replacement of the existing ones.
 It is an additional meta-repository, which, when cloned with
 --recursive, gets all the other ones.
I see, thanks. So the change is not that dramatic. Nice! What would be the nomenclature? Right now we have https://github.com/D-Programming-Language with individual projects. Is it possible for D-Programming-Language to be its own meta-repository so you clone git github.com:D-Programming-Language? I guess not. Then the meta-repository would be https://github.com/D-Programming-Language/dlang. Effectively we add dlang as another project parallel with dmd, druntime, etc. People could continue using the current workflow or hop on the dlang integrated tooling. Is that correct? What's the criteria for including/not including stuff in D-Programming-Language to dlang? Can tools in tools/ assume the dlang layout? Can they assume the existence of the meta-repo? Is the "dlang" name sufficiently descriptive? Possible alternatives: "dev", "core", "essentials", "init", "bootstrap", "root"... Andrei
Feb 11 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 February 2015 at 16:57:35 UTC, Andrei 
Alexandrescu wrote:
 What would be the nomenclature? Right now we have 
 https://github.com/D-Programming-Language with individual 
 projects.

 Is it possible for D-Programming-Language to be its own 
 meta-repository so you clone 
 git github.com:D-Programming-Language? I guess not.
Indeed.
 Then the meta-repository would be 
 https://github.com/D-Programming-Language/dlang. Effectively we 
 add dlang as another project parallel with dmd, druntime, etc. 
 People could continue using the current workflow or hop on the 
 dlang integrated tooling. Is that correct?
Yes.
 What's the criteria for including/not including stuff in 
 D-Programming-Language to dlang?
Interdependent components as a minimum (dmd, phobos, druntime, tools). But I suppose it's an open question.
 Can tools in tools/ assume the dlang layout?
Makefiles already do (e.g. the default settings reference ../phobos/...)
 Can they assume the existence of the meta-repo?
Code dealing with the meta-repo can be placed in the meta-repo directly.
 Is the "dlang" name sufficiently descriptive?
I think so.
 Possible alternatives: "dev", "core", "essentials", "init", 
 "bootstrap", "root"...
The repository's name is also the default directory name on the user's machine when cloned, so I think its name should identify that it is D-related.
Feb 11 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/15 9:08 AM, Vladimir Panteleev wrote:
 The repository's name is also the default directory name on the user's
 machine when cloned, so I think its name should identify that it is
 D-related.
In that case wouldn't "d" be best? -- Andrei
Feb 11 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-02-11 19:04, Andrei Alexandrescu wrote:

 In that case wouldn't "d" be best? -- Andrei
I don't think that is specific enough. I store all D related projects in a directory called "d". -- /Jacob Carlborg
Feb 11 2015
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 February 2015 at 16:37:29 UTC, Andrei 
Alexandrescu wrote:
 On 2/11/15 8:30 AM, Vladimir Panteleev wrote:
 On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei 
 Alexandrescu wrote:
 * What's going to happen with the commit history for our 
 current
 projects?

 * How about the pull requests history?
If you have to ask this question, there's clearly a big communication gap. This is not an overhaul of existing repositories or processes. The answer to both is "nothing", and I don't think anyone is seriously considering a change that would invalidate either.
Can't be "nothing" - there will be something. E.g. the commit history of the new repo will be a merge of the histories of the individual projects. Is that right? -- Andrei
No. New repo history will contain only information about commit hashes of submodules it contains: http://git-scm.com/book/en/v2/Git-Tools-Submodules
Feb 11 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 February 2015 at 16:16:41 UTC, Andrei 
Alexandrescu wrote:
 On 2/11/15 5:48 AM, Dicebot wrote:
 There seems to be a weird miscommunication here. I have asked 
 your
 opinion about this specific proposal - does it seem useful to 
 you, would
 you be willing to endorse it as official starting point for D
 development etc.
Problem is I don't know. That's why I submitted that task https://issues.dlang.org/show_bug.cgi?id=11792 "Investigate...". I'm not a git expert so I don't have answers to a bunch of questions.
That is perfectly fine - I can't guess what are questions are not clear without some non-expert feedback. It would be weird to do anything like that without ensuring you understand the rationale behind proposal. Your list of questions was very insightful. I will relevant information to readme once it is nailed down in this discussion.
 * What's going to happen with the commit history for our 
 current projects?
 * How about the pull requests history?
2 x "nothing changes". Important rationale I had in mind when choosing this specific layout is to make it purely additive change, without breaking anything in established development habits. Goal is to formalize existing working conventions into something that is stronger than convention,
 * What are the changes in workflow compared to the current 
 situation?
No mandatory changes - existing developers can keep their habits. In the long term I'd like to move makefile targets that make assumptions about external repos (like dlang.org phobos docs generation) into aggregated repos - but even that is optional and will happen only if no one objects.
 * What tasks will be easier?
Getting working set of git master tools from scratch will be considerably easier. git clone git github.com:D-Programming-Language:dlang.git cd dlang ./dlang.d update ./dlang.d build # all done, just add ./bin to PATH and get all stuff # available : dmd-dev, dub-dev, docs and whatever we add later # same on all platforms vs mkdir dlang; cd dlang git clone git github.com:D-Programming-Language:dmd.git git clone git github.com:D-Programming-Language:druntime.git git clone git github.com:D-Programming-Language:phobos.git git clone git github.com:D-Programming-Language:dlang.org.git git clone git github.com:D-Programming-Language:tools.git git clone git github.com:D-Programming-Language:dub.git # more and more cd dmd make -f posix.mak; cd .. cd .druntime make -f posix.mak; cd .. # repeat something like that for each repo. sometimes different commands # and for Windows entire flow is different install -m 655 ./dmd/src/dmd /usr/local/bin/dmd-dev # I am not even sure I haven't missed anything at this point http://github.com/D-Programming-Language/installer contains some of needed automation but it misses important "cross-platform development uniformity" bit.
 * What tasks will be more difficult?
Small added effort for release manager to update submodules in meta-repo upon new releases. Can't really imagine anything else right now.
 And probably more questions I don't even know what they are. 
 FWIW Martin Nowak is a key person to convince of the advantages 
 of the change.
It will be next step. No point in discussing smaller details with Martin if I can't communicate general concept to you first.
 - The "getting started" advantage can be achieved on top of our 
 current layout with tactical tools such as documentation and 
 tools/update.sh. There's work there, of course.
Consider this whole proposal as "tools/update.sh done right". It has similar goal but eliminations all possible conventions (which are inherent points of failure) and demands cross-platfrom uniformity as mandatory.
 - I noticed people who contribute to dmd, druntime, and phobos 
 are relatively specialized, i.e. Kenji seldom gets into phobos, 
 H.S. Teoh seldom gets into dmd etc. That does seem to be an 
 argument in favor of the current modularity. Furthermore they 
 seem to have little friction getting into these projects if 
 they do want to.
While I was regular Phobos reviewer my attention was focused there too. But I still had to build latest dmd to test changes, build latest dlang.org to check documentation updated and struggle each time proposed changes fail only on Windows for unclear reason.
 Probably the main question is whether tooling with our layout 
 is just fine.
Please ask more questions if I have not explained something in good enough details.
Feb 11 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/15 8:51 AM, Dicebot wrote:
[snip]

Thanks. I just asked a few more before reading this. -- Andrei
Feb 11 2015
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/15 8:51 AM, Dicebot wrote:
 In the long term I'd like to move makefile targets that make assumptions
 about external repos (like dlang.org phobos docs generation) into
 aggregated repos - but even that is optional and will happen only if no
 one objects.
One thing that'd be good is an integrated makefile right there next to dlang.d, called GNUmakefile (not posix.mak; this is what it is - it's a gnu-specific makefile and gnu recognizes it). It would include the respective makefiles for the subprojects, which need rework to avoid symbol collisions, and will be a one point of entry to building D artifacts. Right now the intercommunication between dmd/druntime/phobos is a bit inconsistent and tenuous. It does seem this might improve our quality of life. Andrei
Feb 11 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-11 17:51, Dicebot wrote:

 Small added effort for release manager to update submodules in meta-repo
 upon new releases. Can't really imagine anything else right now.
You're thinking the meta repository is only update on each release? Or would an automated approach be a good idea? -- /Jacob Carlborg
Feb 11 2015
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 February 2015 at 17:23:36 UTC, Jacob Carlborg 
wrote:
 On 2015-02-11 17:51, Dicebot wrote:

 Small added effort for release manager to update submodules in 
 meta-repo
 upon new releases. Can't really imagine anything else right 
 now.
You're thinking the meta repository is only update on each release? Or would an automated approach be a good idea?
Automated approach is D-dot-git: https://bitbucket.org/cybershadow/d
Feb 11 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 February 2015 at 17:23:36 UTC, Jacob Carlborg 
wrote:
 On 2015-02-11 17:51, Dicebot wrote:

 Small added effort for release manager to update submodules in 
 meta-repo
 upon new releases. Can't really imagine anything else right 
 now.
You're thinking the meta repository is only update on each release? Or would an automated approach be a good idea?
Yes. Updating it all the time to master creates a lot of noise in history for little practical benefit (updating to latest master is one command). For matching different repository history Vladimir maintains special repo in bitbucket with commits populated by a bot - but it is a different thing.
Feb 11 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/15 9:52 AM, Dicebot wrote:
 On Wednesday, 11 February 2015 at 17:23:36 UTC, Jacob Carlborg wrote:
 On 2015-02-11 17:51, Dicebot wrote:

 Small added effort for release manager to update submodules in meta-repo
 upon new releases. Can't really imagine anything else right now.
You're thinking the meta repository is only update on each release? Or would an automated approach be a good idea?
Yes. Updating it all the time to master creates a lot of noise in history for little practical benefit (updating to latest master is one command). For matching different repository history Vladimir maintains special repo in bitbucket with commits populated by a bot - but it is a different thing.
What does "update" mean in this context? I was expecting the projects to be more or less up to date. -- Andrei
Feb 11 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 February 2015 at 18:05:56 UTC, Andrei 
Alexandrescu wrote:
 What does "update" mean in this context? I was expecting the 
 projects to be more or less up to date. -- Andrei
$ git clone --recursive git github.com:D-Programming-Language/dlang This will clone all submodules set to latest released version tag (v2.066.1 right now) $ cd dlang; ./dlang.d update This will update all submodules to latest git master heads. git submodules are designed to track exact commit hash of remote repository - it is impossible to define those to always be cloned as most recent version of some branch. One can keep updating submodule references with some daemon service (Vladimir does exactly that in https://bitbucket.org/cybershadow/d) but that will pollute history of meta-repo with dozens of trivial commits every day making it hard to use it for any real code (and also relying on well-being of that daemon service).
Feb 11 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 11, 2015 at 06:17:35PM +0000, Dicebot via Digitalmars-d wrote:
 On Wednesday, 11 February 2015 at 18:05:56 UTC, Andrei Alexandrescu wrote:
What does "update" mean in this context? I was expecting the projects
to be more or less up to date. -- Andrei
$ git clone --recursive git github.com:D-Programming-Language/dlang This will clone all submodules set to latest released version tag (v2.066.1 right now) $ cd dlang; ./dlang.d update This will update all submodules to latest git master heads. git submodules are designed to track exact commit hash of remote repository - it is impossible to define those to always be cloned as most recent version of some branch. One can keep updating submodule references with some daemon service (Vladimir does exactly that in https://bitbucket.org/cybershadow/d) but that will pollute history of meta-repo with dozens of trivial commits every day making it hard to use it for any real code (and also relying on well-being of that daemon service).
I thought somebody mentioned that the latest version of git submodules now allows tracking branch heads instead of specific commits? T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
Feb 11 2015
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 February 2015 at 18:23:23 UTC, H. S. Teoh wrote:
 I thought somebody mentioned that the latest version of git 
 submodules
 now allows tracking branch heads instead of specific commits?
And I have replied several times already that it doesn't work the way those people expect it to work. Do you honestly think I have not tried that feature before proposing anything? It simply sets remote tracking branch for submodules allowing to update them all with simple one-liner `git submodule update --remote`. It still stores exact commit hash in history which gets cloned initially.
Feb 11 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 11 February 2015 at 18:23:23 UTC, H. S. Teoh wrote:
 I thought somebody mentioned that the latest version of git 
 submodules
 now allows tracking branch heads instead of specific commits?
Yeah, it turns out it doesn't work quite like you'd expect. They still track specific commits, but they also remember a ref (branch) that a commit can be on. Then, you can run "git submodule update --remote" to make it point to the latest commit on that branch.
Feb 11 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 11, 2015 at 06:27:44PM +0000, Vladimir Panteleev via Digitalmars-d
wrote:
 On Wednesday, 11 February 2015 at 18:23:23 UTC, H. S. Teoh wrote:
I thought somebody mentioned that the latest version of git
submodules now allows tracking branch heads instead of specific
commits?
Yeah, it turns out it doesn't work quite like you'd expect. They still track specific commits, but they also remember a ref (branch) that a commit can be on. Then, you can run "git submodule update --remote" to make it point to the latest commit on that branch.
Ah I see. Carry on, then. :-P T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen
Feb 11 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-02-11 19:17, Dicebot wrote:

 $ git clone --recursive git github.com:D-Programming-Language/dlang

 This will clone all submodules set to latest released version tag
 (v2.066.1 right now)
What I don't like about this is that you don't get the latest code. Maybe this will cause more problems for new developers than it will fix.
 $ cd dlang; ./dlang.d update

 This will update all submodules to latest git master heads.
And when you do have the latest code, you will also have a "dirty" working directory.
 git submodules are designed to track exact commit hash of remote
 repository - it is impossible to define those to always be cloned as
 most recent version of some branch. One can keep updating submodule
 references with some daemon service (Vladimir does exactly that in
 https://bitbucket.org/cybershadow/d)
I was thinking of using git hooks that updates the submodules. That is, each repository that is a submodule would have a git hook that is run after each commit. The hook would update the submodule in the meta repository.
 but that will pollute history of
 meta-repo with dozens of trivial commits every day making it hard to use
 it for any real code (and also relying on well-being of that daemon
 service).
Will there be much "real" code in the meta repository? Are you thinking about shared build scripts? -- /Jacob Carlborg
Feb 11 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 12 February 2015 at 07:35:07 UTC, Jacob Carlborg 
wrote:
 but that will pollute history of
 meta-repo with dozens of trivial commits every day making it 
 hard to use
 it for any real code (and also relying on well-being of that 
 daemon
 service).
Will there be much "real" code in the meta repository? Are you thinking about shared build scripts?
Yes, I'd like all build scripts and makefiles that work on multiple repos at time to be placed in meta repo to get rid of awkward "works if you follow convention" situation we have now. Also stuff from "installer" repo,
 And when you do have the latest code, you will also have a 
 "dirty"
working directory. Is it a problem? Root working dir will be dirty, correct, but not working dirs for each of submodules.
Feb 12 2015
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-02-12 09:07, Dicebot wrote:

 Is it a problem? Root working dir will be dirty, correct, but not
 working dirs for each of submodules.
I don't. It would be nice to have the latest code just by cloning. -- /Jacob Carlborg
Feb 13 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
So what happened with this? Ping   Dicebot -- Andrei
Mar 10 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 March 2015 at 20:28:10 UTC, Andrei Alexandrescu 
wrote:
 So what happened with this? Ping   Dicebot -- Andrei
Discussion mostly stalled with me and Vladimir having different estimate of trafe-off between keeping submodules on latest HEAD as opposed to only bumping those for releases. Check the last comments in https://issues.dlang.org/show_bug.cgi?id=11792 Considering you didn't seem convinced at that point I have decided to keep this as a personal project for now and possibly raise the topic again when it will have more tempting features (switched to more urgent stuff for now).
Mar 10 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/10/15 3:59 PM, Dicebot wrote:
 On Tuesday, 10 March 2015 at 20:28:10 UTC, Andrei Alexandrescu wrote:
 So what happened with this? Ping   Dicebot -- Andrei
Discussion mostly stalled with me and Vladimir having different estimate of trafe-off between keeping submodules on latest HEAD as opposed to only bumping those for releases. Check the last comments in https://issues.dlang.org/show_bug.cgi?id=11792 Considering you didn't seem convinced at that point I have decided to keep this as a personal project for now and possibly raise the topic again when it will have more tempting features (switched to more urgent stuff for now).
Understood, feel free to close the PR while the concept is on the backburner or in the works. To clarify: I'd initially misunderstood the scope of your proposal and I'd be happy with something that simplifies the overall "getting into dmd development" experience. A solid, simple and attractive charter is key here. Naming might be important, too, finding a good "D-all-in-one" moniker could help with traction a fair amount. The matter of "where do I put tools related to D development but not necessarily part of the distribution" remains. Thanks, Andrei
Mar 10 2015
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 10 March 2015 at 22:59:39 UTC, Dicebot wrote:
 On Tuesday, 10 March 2015 at 20:28:10 UTC, Andrei Alexandrescu 
 wrote:
 So what happened with this? Ping   Dicebot -- Andrei
Discussion mostly stalled with me and Vladimir having different estimate of trafe-off between keeping submodules on latest HEAD as opposed to only bumping those for releases. Check the last comments in https://issues.dlang.org/show_bug.cgi?id=11792
I believe the discussion was about a different proposal of permanently migrating everything to a single repository without submodules. But I only argued about the approach's benefits, without considering if the benefits will pay off with the high cost of the migration (which they probably won't, perhaps even when batched with other big breaking changes).
Mar 10 2015
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Dicebot"  wrote in message news:lbxhvakqmnaycgrlgduf forum.dlang.org...

 One can keep updating submodule references with some daemon service 
 (Vladimir does exactly that in https://bitbucket.org/cybershadow/d) but 
 that will pollute history of meta-repo with dozens of trivial commits 
 every day making it hard to use it for any real code (and also relying on 
 well-being of that daemon service).
You could put the 'real' code in tools (or yet another repo) instead of directly in the dlang repositoy.
Feb 13 2015
prev sibling parent "Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:
 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.
Excellence can come in part from getting many small things right (or at least just a little bit better) that most people think don't matter. I think Jobs was overrated compared to the technical people that made everything possible (and not just the ones at Apple), but his unreasonableness about not putting up with little things that irked him as a discerning judge did pay off for the user. A language ecosystem is not a consumer product, and an open source project is not a commercial venture; but perhaps it's worth bearing in mind whilst also wanting to make sure effort is marshalled towards things with demonstrably high payoffs. A difficult balance.
 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.
A certain renowned language designer once said that he found that working on projects he found personally important tended to pay off in the end, even if others couldn't see it in the beginning. That's probably not true of everyone, but maybe Dicebot isn't everyone. An economist I once knew said that entrepreneurship happens in the interstices of structure, because it is often hard to demonstrate the payoff in tangible terms...
 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?
What needs to be done?
Feb 10 2015
prev sibling next sibling parent reply "Mathias LANG" <geod24 gmail.com> writes:
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.
Feb 09 2015
next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Feb 09 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/9/15 11:49 PM, 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 still am. I think the result of the investigation should be a good analysis of the pros and cons. I don't see that, but instead a push to just do it with an unclear vision of the resulting setup.
 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.
I'd agree NIH has nothing to do with this discussion. Probably insufficient empowerment does. We have many talented contributors but we don't give them enough trust to let them embark on really big things. So they spin their wheels on dingy little things that can be easily argued, can be done relatively easily, and are unlikely to be rejected. We must break this pattern.
 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.
I've asked Martin whether we should remove it.
 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.
"All of Phobos or these particular modules are nogc." "D is safe". etc. Andrei
Feb 10 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Feb 10, 2015 at 09:13:10AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 2/9/15 11:49 PM, Mathias LANG wrote:
[...]
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.
I've asked Martin whether we should remove it.
[...] I've linked the Vision/2015H1 document to the front page, since otherwise it was literally impossible to find it. Perhaps it should even replace the Agenda page? T -- Tech-savvy: euphemism for nerdy.
Feb 10 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/15 9:18 AM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Feb 10, 2015 at 09:13:10AM -0800, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 2/9/15 11:49 PM, Mathias LANG wrote:
[...]
 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.
I've asked Martin whether we should remove it.
[...] I've linked the Vision/2015H1 document to the front page, since otherwise it was literally impossible to find it. Perhaps it should even replace the Agenda page?
Good idea. I think the Agenda page should stay only if someone commits to maintaining it. Martin? -- Andrei
Feb 10 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 09 Feb 2015 22:22:49 -0800, Andrei Alexandrescu wrote:

 Probably something that's neither important nor urgent.
=20
 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?
maybe 'cause people willing to fix the things that annoys them, not the=20 things someone says they should fix? those "small changes" annoys people=20 enough to do something, and they are relatively easy. not everybody has=20 enough time and/or motivation to work on big changes (especially if they=20 don't even use that things often enough). i, for example, happily spent two days restoring `typedef` feature in DMD=20 and GDC, 'cause i really want it, and `Typedef!` suxalot. yet i can't=20 care less about `RefCounted`, so i don't even want to start working on=20 it. same for most other things from "vision doc".=
Feb 10 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Feb 10, 2015 at 12:00:53PM +0000, ketmar via Digitalmars-d wrote:
 On Mon, 09 Feb 2015 22:22:49 -0800, 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.
 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?
maybe 'cause people willing to fix the things that annoys them, not the things someone says they should fix? those "small changes" annoys people enough to do something, and they are relatively easy. not everybody has enough time and/or motivation to work on big changes (especially if they don't even use that things often enough).
[...] Yeah, welcome to the open source community. People work on what they *want* to work on, not what somebody else tells them they should work on. :-) The corollary is, if you want people to work on X, you should make X attractive enough that people *want* to work on it. Inspiration tends to work a lot better than command in a volunteer project. T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Feb 10 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 February 2015 at 15:48:44 UTC, H. S. Teoh wrote:
 Yeah, welcome to the open source community. People work on what 
 they
 *want* to work on, not what somebody else tells them they 
 should work
 on.  :-)

 The corollary is, if you want people to work on X, you should 
 make X
 attractive enough that people *want* to work on it. Inspiration 
 tends to
 work a lot better than command in a volunteer project.
I want to note that I am not totally against more controlled contributions - but that is totally different type of collaboration that implies much more formal process, as well as willingness to actually manage such team. There is a big mindset gap between "I did those things I needed and can share them" and "I am going to work on things you consider important", those are not interchangeable.
Feb 10 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Feb 10, 2015 at 04:17:25PM +0000, Dicebot via Digitalmars-d wrote:
 On Tuesday, 10 February 2015 at 15:48:44 UTC, H. S. Teoh wrote:
Yeah, welcome to the open source community. People work on what they
*want* to work on, not what somebody else tells them they should work
on.  :-)

The corollary is, if you want people to work on X, you should make X
attractive enough that people *want* to work on it. Inspiration tends
to work a lot better than command in a volunteer project.
I want to note that I am not totally against more controlled contributions - but that is totally different type of collaboration that implies much more formal process, as well as willingness to actually manage such team. There is a big mindset gap between "I did those things I needed and can share them" and "I am going to work on things you consider important", those are not interchangeable.
I've been with the open source community for about two decades, and my observation is that the thriving ones tend to be the ones where people contribute because they want to, rather than because they were told to. Of course, that does not preclude leadership and direction -- in fact, the most successful projects tend to have people in charge with strong leadership skills, but said leadership tends to work best when they inspire people to follow them, rather than laying down the law and saying you must work on X, Y, Z, otherwise you're not helping The Cause. The successful projects also tend to be those where contributions of any kind are welcomed, no matter how trivial they may seem to be. There *are* successful projects that don't follow this pattern, but AFAICT they are quite rare. Just my $0.02, FWIW. T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Feb 10 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/15 9:16 AM, H. S. Teoh via Digitalmars-d wrote:
 I've been with the open source community for about two decades, and my
 observation is that the thriving ones tend to be the ones where people
 contribute because they want to, rather than because they were told to.
 Of course, that does not preclude leadership and direction -- in fact,
 the most successful projects tend to have people in charge with strong
 leadership skills, but said leadership tends to work best when they
 inspire people to follow them, rather than laying down the law and
 saying you must work on X, Y, Z, otherwise you're not helping The Cause.
 The successful projects also tend to be those where contributions of any
 kind are welcomed, no matter how trivial they may seem to be.
Totally. We're trying to do more of that going forward. -- Andrei
Feb 10 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 February 2015 at 17:19:16 UTC, H. S. Teoh wrote:
 leadership skills, but said leadership tends to work best when 
 they
 inspire people to follow them, rather than laying down the law 
 and
 saying you must work on X, Y, Z, otherwise you're not helping 
 The Cause.
This really depends. Human beings are oriented towards "gift exchange", so if you have good social glue between participants and they do things for each other on a personal level they will feel some kind of debt and want to return the "gift". Different social groups have different dynamics and cohesion. But when the project becomes big and it is difficult to perceive changes that are significant I suppose many will feel that contributions won't matter, because the context is too large. The website was small enough and contributions are visible... so people chimed in. D/phobos is experiencing constant increasing breadth, but if cutting down the scope is not possible to get backing for you can break it down into smaller units. Units that can be complete and polished in reasonable time. People need closure/catharsis with a reasonable pace...
 The successful projects also tend to be those where 
 contributions of any
 kind are welcomed, no matter how trivial they may seem to be
Yes, but I don't think it would hurt to map out what is needed and how to go about it. I has to be broken down to a measurable level and then you need to provide designs that are approved. Implementing a nicely architectured design that is not too big can be fun. Designing and implementing something that will be rejected is not fun... The hardest part to get approved is in the design. Most successful open source projects follow a ready made design... E.g. reimplementing commercial role models or implementing standards.
Feb 10 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 10 February 2015 at 22:07:50 UTC, Ola Fosheim Grøstad 
wrote:
 But when the project becomes big and it is difficult to 
 perceive changes that are significant I suppose many will feel 
 that contributions won't matter, because the context is too 
 large. The website was small enough and contributions are 
 visible... so people chimed in.
This is of course some of the dynamics in: http://en.wikipedia.org/wiki/Tragedy_of_the_commons But you can counter it by breaking up into smaller units, e.g. http://en.wikipedia.org/wiki/Adopt_a_Highway
Feb 10 2015
prev sibling next sibling parent reply "anonymous" <anonymous example.com> writes:
On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu 
wrote:
 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.
I'm the author of that pull request. So I guess maybe I should respond to this. I understand that it's a pretty large, rather dull change. If everyone's busy with more important things and therefore can't review that monster, then that's how it is. But I think it's not fair to ask me to work on RefCounted (or whatever) instead. I'm not a major contributor. With the recent focus on the website, I've become more active, but only in that specific area. I can see that reviewer time may be better spent elsewhere. My time, however, wouldn't necessarily be spent on other things D if not on the website. I've kinda slipped into spending more time on it that I'd like to. Doing a little web stuff again has been fun, but when I'm out of ideas for the website, it's probably going to be the occasional (simple) bug fix again. Also, improving the website is part of The Vision, no? "We aim to improve the brand of the D programming language. Part of that is raising the quality of all D-related materials: website, [...], etc."
Feb 10 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/15 12:16 PM, anonymous wrote:
 Also, improving the website is part of The Vision, no? "We aim to
 improve the brand of the D programming language. Part of that is raising
 the quality of all D-related materials: website, [...], etc."
Keyword here is impact. We may as well find fit to pull that but it turns out it's too much work for the impact. Thanks for your other work btw. -- Andrei
Feb 10 2015
prev sibling parent "Sativa" <Sativa Indica.org> writes:
On Tuesday, 10 February 2015 at 06:22:51 UTC, Andrei Alexandrescu 
wrote:
  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?
Because this is what people do! To avoid the bigger issues, which are hard, grueling, mind-numbing and without short term achievements. The good news is that with proper management it all could be done: 1. Proper D IDE with great debugging, library, and resource management. 2. Fixing the GC/phobos mess 3. Cross-platform Gui and 3d graphics library 4. etc... 5. etc.. etc... The great news is, that there are people working and willing to work on all these things. Also, most of them already have "Solutions"(not necessarily the best but people know what they needs to be done at least. The problem? Someone has to manage all this and see how all the pieces of the puzzle work together, knowing how each interact with each other, and guide those working on the individual parts as they so they can achieve their goal, which fills in large parts of the puzzle. Basically someone needs to step up and become the tzar/overseer. Someone that spends their time managing everything and allowing the worker bee's to collect honey. As it seems to me, most worker bee's are a bit confused on what they should/could be doing because there is not a clear and precise roadmap on what exactly needs to be done to reach the goal. (but there have been many maps made) (It's not as bleak as I've implied, just saying there is significant room for improvement in efficiency, which seems to be the main problem from my perspective)
Feb 13 2015
prev sibling parent reply "Luc Bourhis" <ljbo nowhere.com> writes:
On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
 Idea is to create an aggregated repository as part of 
 D-Programming-Language organization which will include other 
 existing ones as a submodules
Imho, git subtree would be a better idea
Feb 10 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/10/15 1:45 PM, Luc Bourhis wrote:
 On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
 Idea is to create an aggregated repository as part of
 D-Programming-Language organization which will include other existing
 ones as a submodules
Imho, git subtree would be a better idea
That's exactly why I asked for a real investigation that discusses pros, cons, cost, benefits, resulting context, alternatives - as opposed to "well let's do it". -- Andrei
Feb 10 2015
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 10 February 2015 at 21:48:58 UTC, Andrei Alexandrescu
wrote:
 On 2/10/15 1:45 PM, Luc Bourhis wrote:
 On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
 Idea is to create an aggregated repository as part of
 D-Programming-Language organization which will include other 
 existing
 ones as a submodules
Imho, git subtree would be a better idea
That's exactly why I asked for a real investigation that discusses pros, cons, cost, benefits, resulting context, alternatives - as opposed to "well let's do it". -- Andrei
Submitting an implementation for a proposal is a valid way to initiate discussion, and enables practical evaluation of one solution.
Feb 10 2015
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 10 February 2015 at 21:45:49 UTC, Luc Bourhis wrote:
 On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
 Idea is to create an aggregated repository as part of 
 D-Programming-Language organization which will include other 
 existing ones as a submodules
Imho, git subtree would be a better idea
I don't think so. What are the advantages? One big disadvantage that I see is that you can't create pull requests to the original repos from subtrees.
Feb 10 2015
parent reply "Luc Bourhis" <ljbo nowhere.com> writes:
On Tuesday, 10 February 2015 at 22:12:41 UTC, Vladimir Panteleev 
wrote:
 On Tuesday, 10 February 2015 at 21:45:49 UTC, Luc Bourhis wrote:
 On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
 Idea is to create an aggregated repository as part of 
 D-Programming-Language organization which will include other 
 existing ones as a submodules
Imho, git subtree would be a better idea
I don't think so. What are the advantages?
With subtree, one has a unified working directory from which one can straightforwardly make commits for each components. So if one makes a change on phobos that relies on a change on dmd, both changes can easily be made, committed and then pushed. With submodule, this is so cumbersome that it would requires some dedicated scripts.
One big disadvantage that I see is that you can't create pull
 requests to the original repos from subtrees.
You would create pull separate pull requests for the dmd repository, the phobos directory, etc. You mean you want to be able to do pull request from the master repository? Again, it seems to me this is not going to be intuitive at all with submodules.
Feb 11 2015
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 February 2015 at 13:33:29 UTC, Luc Bourhis wrote:
 On Tuesday, 10 February 2015 at 22:12:41 UTC, Vladimir 
 Panteleev wrote:
 On Tuesday, 10 February 2015 at 21:45:49 UTC, Luc Bourhis 
 wrote:
 On Monday, 9 February 2015 at 06:33:42 UTC, Dicebot wrote:
 Idea is to create an aggregated repository as part of 
 D-Programming-Language organization which will include other 
 existing ones as a submodules
Imho, git subtree would be a better idea
I don't think so. What are the advantages?
With subtree, one has a unified working directory from which one can straightforwardly make commits for each components. So if one makes a change on phobos that relies on a change on dmd, both changes can easily be made, committed and then pushed. With submodule, this is so cumbersome that it would requires some dedicated scripts.
Switching actual development to aggregated is not considered, because it is much more intrusive change. I have considered subtree and rejected that approach exactly because it does not actually track remotes for aggregated projects that way. My proposal does not change _anything_ in existing development process and this important. It simply adds extra layer of convenience on top. It is also important that changes to affect multiple repos at the same time are relatively rare and optimizing layout for those does not seem practical.
One big disadvantage that I see is that you can't create pull
 requests to the original repos from subtrees.
You would create pull separate pull requests for the dmd repository, the phobos directory, etc. You mean you want to be able to do pull request from the master repository? Again, it seems to me this is not going to be intuitive at all with submodules.
No so far one complained about it being counter-intuitive, quite the contrary. Complicated part is configuring and testing everything, not submitting pull requests - latter seems to work perfectly as it is now.
Feb 11 2015