[Openmcl-devel] making contributions to ccl easier (by using git?)

Ron Garret ron at flownet.com
Sun Dec 13 02:56:52 PST 2015


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.

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.)

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.

For that reason, I don’t much care whether CCL is hosted on git or SVN.

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.

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.

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.

rg

On Nov 30, 2015, at 11:02 AM, R. Matthew Emerson <rme at clozure.com> wrote:

> I would like to say that it has never been anyone's intention or desire to limit development of CCL to Clozure Associates people or to the members of some affiliated secret cabal.  It is certainly true that Clozure Associates has put a lot of time and money into supporting its development (including by supporting me, for which I am grateful).  If this has caused Clozure CL to be viewed as Clozure's semi-proprietary product, maybe this has (justly or not) been a disincentive for others to contribute.  That's regrettable if true.
> 
> I would be very pleased to see more people contribute to CCL.  If there are things that make contributing difficult, I'd like to try to remove those difficulties if I can.  I hear several people saying that Subversion is one of those difficulties, and that moving to git would remove that difficulty.
> 
> I will take you at your word.  I truly don't mean to sound snide, but isn't the key to contributing to CCL one's enthusiasm for and knowledge of CCL rather than proficiency with one VCS or another?  It isn't like Subversion is obscure and complicated to use;  it's certainly no harder than git.  Indeed, clients like magit exist precisely to make git (which by all accounts can be rather complicated) easier to use.
> 
> On the other hand, I recognize that it's often easy to start small, and if contributing even a tiny change to CCL involves learning the basics of Subversion, I suppose I can understand why people wouldn't bother.
> 
> If we were to switch, we'd need to
> 
> * Do something about trac.clozure.com/ccl.  There are a lot of tickets (and ticket history) there.  We often refer in ticket comments to particular commits with the convenient r12345 notation, and we have a post-commit hook that will annotate or close tickets based on phrases in the commit message.  So, we can write a commit message like "Frob the foo.  Closes ticket:123", and Trac ticket 123 will be annotated and closed automatically.  Dumping Trac entirely and moving to something else is not really very attractive (at least to me).
> 
> * Come up with some convenient way to distribute binaries (bootstrapping heap images, interface databases).  I just recently added scripts/get-binaries, which uses svn export to grab a heap image and interface databases.  I wrote this script because I check out ccl with
> 
> svn://svn.clozure.com/openmcl/trunk/source ccl
> 
> because the externals get in my way when committing.  But I say again that the externals do provide a way for users to get a complete working ccl with one command, which is a good thing.  Perhaps there's some alternative to using svn to distribute ccl.  People in the past have suggested making .deb/.rpm packages, or .msi files for Windows, for instance.  If creation of those packages could be automated (along with something for OS X and the other platforms), that might be a possibility.
> 
> * I would greatly prefer any solution to be self-hosted.
> 
> 
> In summary, I'm not afraid of git (although maybe Yoda would say "you will be"), and I'm not married to Subversion.  But I would rather hack lisp than fiddle with a VCS, and a migration to git seems like it would be a non-trivial job (for me anyway).  And at the end of a successful migration, I will be more-or-less exactly where I am today, only instead of "svn log/blame/diff/update/add/remove/commit/merge", I will be typing different commands which will take me a while to get used to.  (And I will have new git features available too, of course.  But really, I'm a caveman VCS user.)
> 
> I would like it to be clear that I am not dismissing out of hand the idea of a migration, especially if some git-proficient people wanted to explore how a migration might work, and propose ways that we might address the issues I mention above.  But I doubt that switching to git will by itself unleash a torrent (or even a trickle) of new contributors.  (The fact that there are not many contributors to CCL is probably due to other reasons, IMO.)  But maybe a switch would be helpful to our users even so.  I am willing to help as I can with such exploratory efforts.
> 
> Thanks for reading this long message.  I like CCL, and I want to see it prosper.
> 
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel




More information about the Openmcl-devel mailing list