Does anybody know of code hosting for bzr that is not Launchpad?

[Martin Pool]

On 18 October 2011 04:50, Colin D Bennett <colin at gibibit.com> wrote:
> On Fri, 9 Sep 2011 19:16:01 +1200
> Patrick van der Velde <petrikvandervelde at gmail.com> wrote:
>
>> Is there an alternative to Launchpad for bzr hosting.
>>...
>> I'd really like to use bzr for
>> my public code but Launchpad is just to crappy compared to
>> bitbucket or github.
>
> I'll chime in and say that while Launchpad is a great resource and
> has a lot of neat features, it feels UNBEARABLY slow compared to
> GitHub.  Just clicking on various page links within a project
> (Code, Bugs, whatever) takes 4 to 7 seconds on average to bring up
> the page for me.  Just a few clicks and it brings back the
> nostalgia that is my old 14.4k modem.

I certainly wish it was faster too.  (I've fixed some performance bugs
in my spare time, but there are a lot more.)  A few of the factors I'm
aware of are:

 * it's hosted in the UK, which is great for people there but pretty
bad for the rest of the world; if you're going to have a single site
the US is the place to put it
 * for a long time db performance was neglected; now the back-end time
is dropping quite a lot from month to month, but still not all it
could be
 * beyond back end render time there seems to be more ssl and request
overhead than would really be necessary, so this is deployment rather
than

It is an open project so patches are always welcome, and it is
possible to fix some of these things as a community contributor,
though I realize most people just want a service to use not a project
to hack on.

> I see that Launchpad uses https always, which is actually
> reassuring from a security standpoint, to prevent man-in-the-middle
> attacks, I guess.  But, is there any way to NOT use https and
> still have enough security?  We're not doing anything secret here,
> it's all open source, so no confidentiality issues.

For a long time we had an item to switch Launchpad to using http for
requests for public objects, which is what many other sites were doing
a few years ago: as you logged in you would do a little dance through
https to http and back.  It takes a lot of care to make sure firstly
that you never serve private data over http, and secondly that you do
not pass credentials insecurely: the code may be open but we still
don't want people stealing cookies and changing things they shouldn't
be able to get at.

The currently popular approach is to just use ssl all the time and not
take the risk of leaking something.  In fact I think SPDY has no
option for unencrypted connections.  So it turns out at least in this
aspect lp was right all along.

Unauthenticated pages are served (eg to spiders) unencrypted.

m