Hi, On Sun, Jan 4, 2009 at 7:51 AM, Olav Vitters <o...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list