openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #01972
Re: Moving code hosting to GitHub
2011/4/26 Thomas Goirand <thomas@xxxxxxxxxx>:
> On 04/26/2011 10:35 PM, Soren Hansen wrote:
>> I don't recall seeing anything that makes that a useful nor accurate
>> summary. Opinions have been voiced, that's all.
> Re-read then. What you believe are opinions might well be seen by their
> authors as useful and accurate points.
And you find this to be true only for the people commenting in favour of
git?
> I mentioned the fact that launchpad is really slow to access from
> China, and sometimes is even completely inaccessible. That one alone
> is enough, IMHO. (Please don't reply again that this will be improved
> later, or that they are working on it, too many things share that
> state, and it just wont happen tomorrow, and honestly, nobody has a
> clue on the ETA)
>
> Even if that was only opinions, don't you think they are important too?
Sure, and I'd hope the opposing opinions were equally important.
>>> Why can't we simply use the better tool at this moment?
>> For the sake of the argument, I'll pretend for second that git is a
>> better tool. What happens when the bzr developers fix the shortcomins
>> we've identified here, and bzr becomes the better tool, would you
>> support a switch back to bzr? If not, why not?
> One very strong argument is that almost all developers know Git, and
> not bzr. That isn't going to change soon.
It's very likely that more people know git than there are people who
know bzr, but I wouldn't go anywhere near as far as saying that almost
all developers know git. I'd wager that most developers on this planet
know neither git nor bzr (nor cvs nor svn).
> The introduction of this thread was:
>
> "In an effort to speed up our code development processes, reduce the
> friction amongst existing contributors and reduce barriers to entry
> for new contributors familiar with the popular git DVCS"
>
> I believe it still stands.
It's true. I'm also absolutely fed up with this discussion. I wish
people would just get stuff done instead of arguing over tools.
> Now, if we see that there's a really better tool that is available, and
> that it seems worth switching (and that makes the cost of switching
> worth too), why not?
As Ed points out, whether one or the other is better is contentious, and
that's unlikely to change.
> But it would have to improves productivity, and be widely accepted.
> Many projects switched from CVS to Git or mercurial, because it was a
> big step.
Lots of projects also switched from CVS to bzr.
> I don't see bzr as a big step compared to Git (and in few cases, it's
> worse).
We're not arguing moving *to* bzr from git. Had I spent months setting
up a whole bunch of infrastructure built around git, I'd be rather
attached to that, too.
>> You seem to be ignoring the cost of switching. A cost that you're not
>> going to pay. I, and the other people working on toooling, are going
>> to have to pay it, so yes, I'm feeling rather attached to a lot of our
>> existing choices of tools/technology.
> I believe that, in the long run, the cost of learning bzr for each new
> comer, is greater than switching the project to Git.
Depends *very* much on the people. If you just sit down and learn the
3-5 commands needed to get working, the cost is very, very small. If
you've decided you think it's a bad idea and something you don't want to
learn and you insist on not changing your habits, then the cost is much,
much higher.
Openstack has moved at an incredible pace. Apart from vocal minority who
take every chance to complain about bzr, I don't believe bzr/Launchpad
has been an impediment to attracting developers. Quite the contrary.
> Mistakes with the workflow, like I did when asking you for a review of
> my patches, are even greater costs.
I've been reviewing things for Nova for quite a while now. I do not
recall this having been a problem before.
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/
Follow ups
References