Re: GNOME DVCS Survey Results

["Elijah Newren" <newren gmail com>]

Hi,

On Sun, Jan 4, 2009 at 7:51 AM, Olav Vitters <olav bkor dhs org> wrote:
> Anyway, I'd rather add John Carr to the sysadmin team. I plan to make a
> proposal to switch GNOME to a DVCS where Git works using Johns
> suggestion. Then other sysadmins[1] can suggest whatever proposal they
> want. These proposals can be investigated on merit and then a one can be
> chosen (chosen as in: "go ahead and try if this would work", not "go
> ahead blindly"; everything must be tested before a cutover).
>
> [1] or whomever. Although I don't see how that would work.

While I'm sure John will at least be able to get basic functionality
working, and the project has a certain amount of cool geek factor,
taking John's proposal as a path forward concerns many in the
community for a variety of reasons[*1].  (In fact, I bet such an
option would rank lower than any native vcs option had it been
included in the survey.)

I'd like to help with another path forward, namely native git
repositories since I believe that is what most of the community wants.
 As you said, it isn't clear how it could work for non-sysadmins to
come up with clear proposal strategies and implementations.  Are there
others on the sysadmin team who are willing to work on such a
transition?  If so, how can I help?

Elijah


[*1] Reasons I've seen or can think of off the top of my head:
* As James H. mentioned on John's blog, you'd likely end up with "the
intersection of the features of the two version control systems rather
than improving things."
* John's project does not have a large community behind it and
supporting it.  In fact, it may end up with a bus factor of 1[*2].
Even if it increases, it doesn't have the kind of large community
that, say, git-svn has.  In general, it's unsettling to many to adopt
a project without a large community behind it.
* John's bridge would have to be updated whenever either the bzr or
git formats changed (in particular, bzr has changed repository formats
several times and even promotes it's ability to seamlessly change
repository formats as an advantage), or whenever the network protocols
changed (including protocol extensions, such as the git push
tell-me-more extension).
* It would introduce extra lag between when new features become
available, since the bridge would need to be updated for each such
change.
* There's no guarantee bzr and git will change in ways that will make
them remain compatible, so we run the risk of accepting (additional)
feature losses as time goes on.  It may be a small risk, but we simply
don't know and have no way of knowing.
* All software has bugs.  John's bridge can't be exempt, and
particularly as new and not-yet-tested software, it's more of a risk.
Will that mean data loss?  Loss of features?  Inability to perform
certain operations?  While the bugs are being investigated and fixed,
what do maintainers do?  Use bzr since it's the official format?  I
think John's pretty clever and that we would likely avoid most such
issues -- but there's no guarantee and this is something that affects
developers daily work.
* I believe bzr proponents even admit that bzr is still slow for
network operations.  John's bridge would essentially add another layer
on top of that.

[*2] http://en.wikipedia.org/wiki/Bus_factor