[Openmcl-devel] making contributions to ccl easier (by using git?)
R. Matthew Emerson
rme at clozure.com
Mon Nov 30 11:02:51 PST 2015
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
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.
More information about the Openmcl-devel