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:
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




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

cd dmd
make -f posix.mak; cd ..
cd .druntime
make -f posix.mak; cd ..

commands

install -m 655 ./dmd/src/dmd /usr/local/bin/dmd-dev


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