I haven’t been on d-d-l for months now, but when someone mentioned how comically entertaining the whole DVCS survey thread was, I just had to catch up.
From my cursory understanding, it seems like the data would be stored as bzr repositories and then new code would be developed to export those repositories over the git protocol, so that git users could use their own tools.
While it seems like a neat hack, and probably a worthwhile proof-of-concept, the idea that GNOME would switch to it seems completely insane to me. There are lots of reasons why, many addressed in the thread:
- Why develop this code only for GNOME, instead of developing it with the support and blessing of upstream bzr and/or git? There the collective experience of these communities could guide and influence the development.
- There is basically only one person developing this software, resulting in a critical piece of GNOME infrastructure with a bus factor of 1. This is very bad, and when you consider that the results of the survey strongly support Git, the vast majority of developers will be using it and would be inconvenienced if the system failed.
- GNOME has a terrible track record of abandoned software — maybe it’s not actually any worse than other 10 year old large-scale open source projects — but it is very common. I don’t have any data to back this up, but I feel that in a lot of ways this is even more true for infrastructure that most developers never see.
- The git-over-bzr option was never an option in the DVCS survey, but if it were it seems like it would have rated extremely lowly. There seems to be a vocal opposition to it in the thread.
- This is an abstraction, and abstractions are always leaky. wxWindows kinda sucks because it can’t emulate all windowing systems equally. There is no way a git compatibility layer on top of a bzr repository will ever be as good as a native solution, just like git-on-svn isn’t as good as a pure git solution.
- What happens when (not if, when) the git protocol changes in an incompatible way? Will we be at the mercy of someone to hack and fix the compatibility layer? Will the original author still be around and interested enough to do it, possibly years down the road?
The last point, combined with the abandonware point earlier, are what concern me the most. In the thread, David Zeuthen asked Olav Vitters:
Then what happens when a new version of git with a new feature, incompatible with the git-serve kludge, is released? Then we’re screwed, right? And who gets to pay? We do. We’re stuck with an old version of git. Us. The very same people who very clearly said “git”, not “bzr”.
Not the most politic way of saying it, but I think the point is valid. When I read that, I had deja vu, because I had just read this thread from early December about Bugzilla, initiated by Olav:
Subject: Reduced Bugzilla functionality for 6+ months — acceptable?
The GNOME Bugzilla is still using 2.20. Current stable upstream is at 3.2.
[...]
For that the proposal is that the following is not part of the initial
upgraded bgo:
* The points system
* index.cgi UI mods
* Making a new favicon
* The infomessages on show_bug.cgi
* Layout modifications for attachment table and the login box
* duplicates.cgi modifications
* Fixing the comment headers
* Patch and keyword emblems
* delete-keyword.pl, mass-reassign-bugs.pl, and year-end-stats.pl
* describeuser.cgi
In other words, upgrade the GNOME Bugzilla installation to a new version of the upstream software, and break all of GNOME’s current customizations. Is this not exactly what will happen eventually with the git kludge? I can foresee history repeating itself here. Bugzilla is pretty essential to GNOME, and degradation of service is undesirable. But a degraded, unavailable or fractured source control system is unconscionable.