Thought-provoking post from Stefano (as usual) as to the merits of decentralized source control systems like Git. The most interesting bits to me are the possible community health risks of not using such a system.
When we started Pyro, my first task was to set up the version control system. I spent around 30 minutes searching and fiddling, trying to figure out how to store a simple Git repository on my hosted web server. Something that I would consider to be the main usecase for such a system.
Eventually I gave up, opting for Bzr, which was a joy to set up. My first commit message succinctly expressed the annoyance I was feeling at the time: “Fuck Git.”
But in the end, we made the pragmatic decision to switch to Subversion. Why? Because people kept complaining that they didn’t have Bzr installed, and were too lazy to figure it out just so they could try out our random project.
Unfortunately, this kind of laziness has become pervasive in the Free Software world, as compared to say 10 years ago. Back then it was all but expected that you’d have to fix the build to get something working. But it was fine, because you would fix it and send a quick patch. Believe it or not, this actually felt pretty awesome. You were helping to keep the train on the tracks, and that meant getting your hands messy.
Today I worry that people are unwilling to try out new things. At least until their Linux distribution makes installing them a single command-line away. Getting people to build from source is now akin to pulling teeth.
Even more worrisome, there seems to be a strong correlation between developer seniority and the unwillingness to tinker with new things. Ideally, getting the people who have the most to offer interested in a fledgling project would be easier, and senior people would be seeking out new projects to toy with, eager to get involved (even in just an advisory role).
I’m wondering if a decentralized source system could help make this better, and bring us back to the bad old days. Maybe breaking from the “Give me a packaged Deb/RPM release, then we’ll talk” mentality and back to scary, unreliable bleeding-edge source code would be a good thing.
-
Seriously,
do you expect people who can’t be bothered to install bzr (and I say this as a git person) to contribute anything substantial to Pyro ?
Food for thought
-
@Rémi: Considering I’m talking specifically about the individuals who built GNOME from the ground up, yes, I do think they could add a lot
-
Is it such a surprise? Used to be that anyone could learn CVS and quickly become a useful contributor to any open-source project. Now, it seems that every project uses a different version control system – cvs, subversion, git, bzr, mercurial, etc.
If I want to work on an open-source project, I want to code. I don’t want to have to learn half a dozen different vcs tools, just to do the peripheral task of source control. I want to code.
-
@Simon: You probably know that doing software involves more than just coding. If you don’t know how to perform the usual contributor workflow with a certain SCM tool for a project you’re interested in, and can’t find any tutorial-level info on the web easily (which would hardly be the case with any of them, but anyway), you could let the maintainer(s) know and suggest that they put a summary of the few commands necessary as a reference on the project web site.
By the way, saying how you “have to learn half a dozen different vcs tools” would mean that you’re working on half a dozen different projects, which is quite unlikely isn’t it?
Besides, I look at the current diversity of SCM tools as a natural phase in the “evolution” after legacy systems such as CVS. In time there probably won’t be that “many” again…
-
I’m no stranger to building software. I cut my teeth getting Gnome 0.13 and dependies running on my desktop (which was at least nominally Slackware 95). And now I’ve got six years under my belt of being almost solely responsible for software builds and packing at work.
Honestly? My patience has worn thin over the years. I’ve tinkered with enough source control systems. Enough new build systems. Enough new test architectures. Enough esoteric (and often unnecessary) dependencies. Just … enough.
These days, unless it’s something I need for work, I expect the developers to meet me half-way by using a well-established build system unless there’s a damn good justification not to, using well-established APIs rather than depending on the cutting edge and sticks to a reasonably sane build procedure, preferably well established (this seems worst with Perl module developers … in the worst case I had to build over a dozen dependencies just to get a clean build because they just /had/ to use an alternate build system which in turn depended on a marginal test harness which in turn depended on a test builder, set functions, etc, etc). Bonus points for reasonable defaults on the configure. Extra bonus points for a working spec file. Even on my test machines I like software to be managed by the package manager. Besides, by having a spec file I can ensure that my build procedure is reproducable so any changes I make are isolated.
-
Considering that most SCMs allow fairly seamless operation with svn upstream, I don’t see what’s the big deal. Want to use Git? Run git-svn. Want to use Bzr? Use bzr-svn. No big deal.
For better or for worse, svn is now the de facto upstream format. If you host with something else you’re erecting a fairly significant initial hurdle for potential contributors.
-
An additional thought: it would be nice if SCMs could talk to each other. Why can’t I pull changes into my Git repo from Alex’s Bzr? It seems like now is the time to define a decentralized generic wire protocol. It would be a shame if the only way to get SCMs to communicate is if they need to go through an intermediate svn translation step.
But that’s the direction we’re headed in… :-/
-
We have tried GIT just for the kernel side development with about 4 people. That’s right just four people using and we still had a lot of trouble handling remote webserver and all those awful and obscure commands. Git has got to be the most unusable piece of SCM software I have ever inflicted on someone intentionally.
We are switching to Mercurial. I agree Fuck Git.
-
@Marko – I don’t think working on multiple projects is all that unusual. My perspective is as a casual developer/user – rather than working on a single project that I own, I contribute minor bug fixes and other small patches to projects that I use.
So if I want to fix something that annoys me, I need to find out how to obtain the source tree from whatever version control system the project uses, keep it up to date if I’m working on it for more than a day or so, and how to generate a patch to send upstream. I know how to do that for CVS and Subversion, but haven’t a clue what to do with anything else. And as a casual contributor only, I’ve little interest in learning how they all work.
-
For people just interested in a quick fix here and there it doesn’t matter what vcs the project use, as long as they have a couple of lines of how-to-get-hacking-fast, which at least the project I’m involved in have. You don’t have to know git to be able to check out the source code, hack some, create a diff and post it to our bugtracker. People who contribute more often will then move on to the more advanced sections we have written and learn more. But it’s important to keep the lowest level of learning $vcs easy for people to find, and learn.
As for people who are afraid of building from source I can understand. I would love if more projects had scripts to run the project from a separate root dead easy, so you don’t have to pollute your system with random non-pkg-controlled libraries and stuff that may or may not conflict with other programs today or in the future.
SCons is a build system that has tried to eliminate this problem by adding support in the build-system to easy generate .deb, .rpm, .ipk, .msi packages with just one line in the build scripts. If the lib/app you just built is contained in a removable package then it’s much easier to remove it if something goes wrong. And of course, as the user turns into a developer he will move away from building packages, and install as usual due to the time it takes to build packages, but I think it’s a good way to trick/attract users into becomming developers. -
Most distributions already provides almost all vcs, since packagers often need to check the latest developpement version to produce diff or to get fixes ( at least, I do ), so I think the problem is not really here.
The problem is to have 4 or 5 differents vcs, each one being slightly different, sometime quite painful to use. For example, someone already tried to get a snapshot of pidgin latest version with monotone ? Or nobody except me ever lost time on reading git tutorials to see after 3 h this was changed with 1.5 and the branch was not what was expected ?
-
Life is too short to be spent on $scms and $buildsystems.
Just a giveaway from a senior developer
-
It’s interesting that 5 different vcs are a problem to get people contributing, yet no one complains about programming languages. I guess the usual desktop uses at least 10 different languages. But it seems noone has a problem with them. I wonder why…
-
Pingback from Swfblag » Blog Archive » The good old days on 8/30/2007 at 6:59 am
-
@Benjamin – the situation wih languages isn’t quite so extreme. Yes, there are apps in many different languages. But if you can code in C/C++, you can probably work on at least 80% of things out there.
Besides, that comes back to my earlier comment – as a coder, what I want to do is code. Knowing different languages fits in fine with that – it’s part of the coding role, so to speak. Having to learn lots of peripheral tools isn’t.
Comments are now closed.
16 comments