On Wed, Jan 31, 2018 at 09:07:39PM +0000, John Gabriele via Digitalmars-d wrote: > On Wednesday, 31 January 2018 at 20:03:11 UTC, Adam D. Ruppe wrote: > > > > {snip} (well, I tried to get it upstream but I think upstream is a > > brick wall and not worth trying anymore) > > That is very concerning to hear.
FWIW, here's my POV regarding "upstream", speaking as one who has no prior (or current!) personal connection with anyone involved with D development at the time, and who got granted commit access to Phobos only because one day I and another person whom I do not wish to name (who was at the time also not connected to "upstream") were complaining on the forum about lack of response to Phobos PRs, and *somebody*, presumably Andrei (but this is speculation on my part, as I was never actually told what happened exactly), decided to hand us the keys to the kingdom, so to speak, to see what we'd do with it. I didn't merge anything for about a month or more afterwards, not out of intimidation or anything like that, but just feeling unqualified to make decisions of that sort just yet. I continued submitting PRs like an "outsider" for a while, and only later began to build up enough confidence to start merging PRs. Even today, I contribute to D development purely out of my own interest, both in terms of technical interest, interest in seeing D improve because I use it for numerous personal projects, and also some amount of personal fulfilment in being able to contribute to something bigger than just my own projects. The way I see it, is that the majority of PRs that get merged are in the category of small, incremental changes, things like bugfixes, small improvements to existing features, the odd useful tool here and there, that sort of thing. Larger-scale changes do tend to take a lot more work (and persistence!) to push through, not because of any active policy or motive that hinder such changes, but primarily because as a volunteer-driven project, it's not very often that someone from among the volunteers would: (1) Have the time to spend reviewing a large and complicated change; (2) Have enough expertise in the affected area(s) of the project to feel confident enough to make decisions about it; (3) Have all of the above plus the interest to actually *want* to wade into the depths of a large changeset, which implies the commitment to continue interacting with the submitter until it's merged or rejected, rather than do something else that's (a) more self-contained and easier to review, (b) can be done in a short amount of time that fits into their current stretch of free time, and (c) still contributes something positive to the project. Large-scale changes do happen every now and then, such as Daniel Murphy's monumental effort in translating dmd's original C++ source into D, leading to the bootstrapping compiler we have today. But these require a lot more effort and coordination with key decision makers, usually Walter & Andrei, and it really helps if you can convince one or both of them to take your side. A "small fry" like myself wouldn't dare to push the merge button on changes of this kind of magnitude, since it could have drastic consequences that I can't foresee due to not having a full grasp of the full scale of what is being changed. Plus, sometimes somebody else *did* raise valid points of concern against the PR, so I would hold off merging until the concern is addressed and that person approves of the updated change. And in a large changeset, there can be a large number of such concerns, which requires a lot of back-and-forth before a decision can be reached. Anyway, as far as Adam's dpldocs are concerned, the way I see it is this (and I'm saying this not as someone making the decision, but as a mostly-disinterested observer): Around the time it was first proposed, there are already two other competing documentation systems: - The ddoc system, the original, and still in heavy use at the time, up till today; - Sonke's newer one-page-per-function ddox system (which today has been partly integrated, but still not fully the default yet because of various issues that I didn't look too much into). Having 3 different competing documentation systems is really crowded for this space, so for any of them to stand a chance, it has to be either already entrenched (ddoc), or else must offer significant advantages over its competitors. More importantly, its proponent(s) would have to convince Andrei or Walter of said significant advantages, since that's what will tip the scale (obviously, its proponents must believe it has significant advantages otherwise they wouldn't have proposed it in the first place -- but the deciding factor is whether Andrei and/or Walter think likewise). And IIRC, Andrei had already bought into the ddox system by then (the process of merging it might have already begun, I'm not 100% certain), so dpldocs was already starting from a disadvantaged position, whatever merits it may have on its own. And I'll be frank that sometimes Andrei can take some effort to convince, and it takes a certain amount of dogged persistence (and thick-skin) to get through to him sometimes. And it doesn't help that he has so much on his plate, and generally doesn't have enough time to dedicate to all the decisions waiting upon him to make, so sometimes it can be frustrating trying to get through to him. So to get through, dpldocs would need show a major advantage over ddoc and ddox, and Adam (and whoever else) would need to be persistent enough to convince Andrei to approve of it, and then it would require the effort to integrate it into everything else that's currently being used for generating docs on dlang.org -- since obviously, it wouldn't do for a new doc system to get merged, only for everyone to find that parts of dlang.org are now broken, or not working as well as before, or Phobos doc builds now have new issues, etc.. AFAICT, none of this is any deliberate roadblock or "brickwalling" to stop alternative proposals from being accepted, but it's mostly just due to circumstantial situations that arose, for better or for worse, as part of how D came to be what it is today. In that sense, I don't blame Adam from deciding to fork instead -- given the circumstances, that's certainly the path of least resistance, unfortunate as it is. With ddoc still entrenched as the de facto documentation system, and with ddox already merged and continuing to be improved with the view of becoming the new default docs (not my personal preference, but that's the direction it's headed), any alternative proposals would have a pretty tough uphill fight to get through. It's unfortunate, but I don't think it's unreasonable either -- as I said, if it would not bring new, compelling advantages to the table, then it's pretty hard to justify all the work it would take to merge it and then maintain it afterwards. At least, it would be pretty tough to convince Andrei about this. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs