<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-12-13 13:56 GMT+03:00 Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sorry for resurrecting a dead thread but I’ve been off the grid for two weeks traveling in Africa and I really wanted to weigh in on this.<br>
<br>
I don’t think anyone views CA’s role in CCL as a “secret cabal.”  I certainly don’t.  I see it more as a BDFL role that insures the project remains coherent and enforces (at least) some basic quality control.  Open-source projects tend to do better when they have some sort of central authority of this sort (c.f. Python (Guido) and Linux (Linus) vs., say, Bitcoin, which underwent a forking crisis a while back that might have posed an existential threat.)<br>
<br>
The other thing that makes CA’s centralized authority seem non-sinister to me is that it’s so easy to patch CCL at the user level.  My private library is chock-full of little tweaks and hacks to CCL internals, but I don’t need them to be rolled into the “official” CCL sources for them to be useful to me.  I just start with generic CCL and load my patches every time I start it up.  The fact that the CCL compiler is so wicked fast makes this a feasible approach.  In fact, it’s one of the reasons that CCL is my preferred development environment.  I have nearly infinite freedom, and this freedom is (almost) completely independent of what the base CCL looks like.<br>
<br>
For that reason, I don’t much care whether CCL is hosted on git or SVN.<br>
<br>
However… git in general, and github in particular, does have one significant advantage with respect to encouraging people to roll improvements back into the main CCL code base (assuming such a thing were desirable — the whole point of the preceding paragraphs is that this is far from clear): with github, if I want to submit a patch I know exactly what to do: I clone the CCL repo, make my changes, and submit a pull request.  With SVN I have no idea what to do.  My understanding is that I could probably get write permission to the SVN repo, but that’s a very different animal than submitting a pull request.  If I submit a pull request, CA still has the opportunity to review my changes in order to implement whatever quality control measures they decide to do.  If I have write authority to the SVN repo, then I have a lot of power and the associated responsibility not to screw things up.  This is the main (potential) advantage I see to switching.<br>
<br>
On the other hand, Trac, and its integration with SVN, is really handy dandy, and that is not something to be given up lightly either.<br>
<br>
It’s a tough call.  Like most tough calls, what it really boils down to is your quality metric, i.e. what do you really want CCL to look like in, say, ten years?  Logic and reason can’t help answer questions like that.<br></blockquote><div>Well, I personally agree with these points. I think that it would be best for the CCL project to comply</div><div>the nowadays. And the migration to Git is the first significant step in this direction. I'm ready to participate</div><div>in the migration process, but I believe the idea of migration must be approved and coordinated by Clozure.</div></div></div></div>