RE: Why just one DVCS?

Following up John's and Juanje's thoughts on the topic.

John's idea of having a compatibility layer sounds like a good idea to me, I'm not aware of the consequences of such solution, but basically, if it is doable, I totally agree it's worth trying as it will help to keep hardcore git/hg/bzr users happy despite the choice we make.

However, I don't think that such a solution should prevent us to make a choice. A choice has to be made, for reasons of common consistence and for not confuse newcomers with a "choose whatever you like" statement. That's worse than picking the wrong DVCS or staying.

What really worries me is that this whole GNOME choice of DVCS discussion seems to be driven as a popularity contest rather than a purely technical decision, pretty Vim vs. Emacs alike. And everytime someone tries to evaluate the tool from other perspective than the hardcore hacker workflow, there's someone with an over reaction, pissing off the people trying to make decisions things on the right way.

There should be a well stablished criteria to make such choice: Which one has better documentation? Which one has a public API that allow us to extend our development tooling? Which one will ease our sysadmins life (bkor, I'm looking at you ;-)? Which one is easier to learn? Which one would ease the transition from SVN users? Which one has positive answers for these questions _now_?

Five years ago, most of us were not hacking on GNOME, and a lot of us won't be hacking on GNOME in five years time either. Making decisions like this based on the personal preferences of the current hackers seems like a really selfish reasoning. Translating or patching GNOME is a task hard enough already, and if we are not careful with our choices in this matter, we would raise the entry barrier a little higher.

If we can make a choice, and still allow compatilibity to other DVCSes tools and workflows, I'm all for that. But despite that a choice has to be made.

9 thoughts on “RE: Why just one DVCS?

  1. I’m totally agree with you. I didn’t really explain myself on my post. It was just a kind of brain dump about this idea was around my head lately.
    I think as well we need to choose a DVCS which won’t be high barrier for the people who want to start in GNOME. But my idea was more for the other part. The developer who already use another tool.
    Some times because they need something from it, some because they feel more comfortable or because need it to interact with other projects, doesn’t matters the reason, but it’s already happening.
    To have a single good, well documented and trusted DVCS for GNOME is not against to provide an “interface” to use others DVCS. But I don’t think the import/export thing, and the read-only mirroring could be the solution.
    That’s why I launched the idea about abstraction layer where everyone can work with.
    Actually, the files (the code) is the same in all D/VCS and they share a lot of metadata, so create “drivers” to push and pull changes for different ones (git, hg, bzr…) shouldn’t be a problem.


  2. Why does it seem to be driven as a popularity contest? The poll asks which VCS systems you are familiar with, and also which you think Gnome should use. People can use whatever criteria they like when answering the second question.


  3. I agree with your observation regarding lack of thought regarding a choice. Unfortunately popularity it is. I have no interest in that. Not saying popularity can be dismissed entirely btw.
    Regarding sysadmins, I’m willing to do all work together with Jc2k for Bzr while ensuring it works for Git as well. I have no interest to stand by if the ‘implemention plan’ will be as careless as I think it will be (no point in having a hobby/helping out if it isn’t fun).


  4. Which one would ease the transition from SVN users?
    That does seem like a good thought at first but giving it a deeper thought this will favor the VCS that is more similar to SVN. That is hardly a good idea since we are trying to get rid of SVN for good reasons and we don’t want to replace it with another VCS which allows the same crappy workflow.
    Having said that, no one is stopping us from providing helper utilities that allows people to keep on using the same workflow (Tim’s yyhelp is one example) but this shouldnt’ be taken as part of the criteria to choose the best DVCS out there, instead the opposite.


  5. This is one of the many problems with the “everybody has a say” model of decision making.
    GNOME has a technical board, doesn’t it? Let the technical board open up a request for comments with a specific time frame, and after that take a few weeks to make a decision; whatever decision they make is final.
    You will never, ever please everybody. Someone with the proper level of authority needs to make a decision and stick with it, or no decision will ever be made. Small projects can get by with a democratic-consensus approach, but once you start having dozens or even hundreds of developers… ugh.
    Alternatively, if you really want every developers’ voice to count, run a poll. I personally vastly prefer letting a small group of intelligent, rational, informed people make decisions, but if you want input from every barely-involved developer, a poll is the only way you’ll get a real decision made.


  6. Is a ‘popularity contest’ a bad thing? Seems to me that if one tool is standing out from the others in terms of people already using it, that’s pretty good qualifications. A tool might not technically be the best, but if it’s one people are clearly happy with, surely that’s good enough?


  7. keithp’s point wasn’t that the decision shouldn’t occur by popular consensus. it was that uninformed people shouldn’t be in charge of the decision.
    2 years ago, when keithp started researching other SCMs, few in the OSS community were familiar with git. that’s hardly the case now. gnome has git and bzr mirrors, and the developers have been able to discuss the results.
    it’s hardly apples to oranges.


  8. If you really want every developers’ voice to count, run a poll. I personally vastly prefer letting a small group of intelligent, rational, informed people make decisions, but if you want input from every barely-involved developer, a poll is the only way you’ll get a real decision made.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s