Open Stack

On 04/11/2011 09:43 AM, Elliot Murphy wrote:
> Hi!
> 
> On Sunday, April 10, 2011, Thomas Goirand <thomas at goirand.fr> wrote:
>> On 04/09/2011 05:21 AM, Jay Pipes wrote:
>>> All,
>>>
>>> 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, we (the
>>> OpenStack at Rackspace team) have been studying a transition of our code
>>> hosting from Launchpad to GitHub. We understand others would be
>>> proposing the same at the design summit, but we figured it would be
>>> good to get the discussion started earlier.
>>
>> It seems that my previous mail never reached the list, so I'll do again.
>>
>> Launchpad is *EXTREMELY* slow from here in Shanghai, and it should be
>> even worth from the center of China. Even doing a simple thing like "bzr
>> launchpad-login" can even fail because of connectivity, and I hardly can
>> get few KB/s when I do a clone of a bzr repo.
>>
>> I mostly don't mind so much bzr, even though starting has been really
>> annoying, and that I don't know much about advanced usage like I would
>> with Git. But what I welcome the most is the hosting on a platform that
>> has an acceptable speed from Asia, which really, isn't the case at all
>> for Launchpad. Also, the fact that Git doesn't do network connections
>> unless its really needed is very welcome.
> 
> I am responsible for supporting the teams that develop and operate
> Launchpad and other tools and systems at Canonical that we provide as
> a high tech incubator of sorts for open source projects.

Having a discussion with Soren about merging a branch, we had the
following discussion:

On 04/19/2011 05:55 AM, Soren Hansen wrote:
> 2011/4/18 Thomas Goirand <thomas at goirand.fr>:
>> Can't you just pull each individual patches that you feel ok with?  Is
>> it simply not technically possible with bzr?
>
> Short answer: no. Longer answer: Of course it's possible to extract
> individual patches and apply them elsewhere, but it's tedious, manual
> and throws away history. We bzr users care deeply about history :)

I don't know bzr enough to be able to tell, but it seems like an area of
improvement. History, for me, is quite important.

With Git, it's really easy to get a bunch of patches, select the one we
want, and reject others. To compete with Git, Bzr *must* be able to do
that, and allowing rebase and merge of patches in order to keep a clean,
readable, patch history.

Forcing people into using so many small branches, just in order to
maintain patches separately, doesn't seem convenient. And will take a
lot of useless disk space which, for a big project, can be an issue.
Having to make a copy of 100s of megs just for isolating a small patch
seems quite unreasonable to me (imagine if it was maintained like that
for the Linux kernel, openoffice or firefox, for example...).

I just hope the above help.

Thomas