Launchpad should run a Bazaar server and advertise bzr:// URLs.

This is a good idea. If it came down to a choice, I think I'd rather have bzr+http working though (see bug 165087).

Also, instead of advertising bzr:// URLs, we're intending to advertise branches using lp:/// URLs.

Advertising lp: may well benefit Launchpad but does not benefit Bazaar, which is the point of the exercise.

There a a great many people who are evaluating Bazaar; establishing confidence for such people is a high priority. If Launchpad were to use bzr:// this would lend credence to the fact that the Bazaar server is a reliable piece of engineering.

Also, there is the fact that lp: is not a URL - bzr:// is the protocol with the registered IANA port.

As for getting bzr+http working, that has stymied my team as well. More important would be having it work transparently (see bug 132643 for further) because there will continue to be a great number of http:// URLs advertised for some time to come, and I agree that making the experience for people who "accidentally" use such URLs as optimal as possible is in everyone's best interest.

AfC

I wrote up https://dev.launchpad.net/Code/AnonymousSmartServer as something like a plan for this.

On 4 March 2010 16:12, Michael Hudson <email address hidden> wrote:
> I wrote up https://dev.launchpad.net/Code/AnonymousSmartServer as
> something like a plan for this.

Sounds reasonable.

If we do this it would be common sense to run it quietly for a while
before switching lp: to point at this.

As a baby step, perhaps we could allow it only from one ip address,
then pull via ssh tunnels from there.

We should think about the consequences for
1- changing the lp: directory mechanism (away from xmlrpc etc)
2- branch privacy (probably not a big deal)

--
Martin <http://launchpad.net/~mbp/>

Martin Pool wrote:
> On 4 March 2010 16:12, Michael Hudson <email address hidden> wrote:
>> I wrote up https://dev.launchpad.net/Code/AnonymousSmartServer as
>> something like a plan for this.
>
> Sounds reasonable.
>
> If we do this it would be common sense to run it quietly for a while
> before switching lp: to point at this.

Sure.

> As a baby step, perhaps we could allow it only from one ip address,
> then pull via ssh tunnels from there.

I don't understand what you mean here?

A way of testing at a very early stage would be to set up the service on
a machine in the DC that's not accessible from the internet and not have
the port forwarding on bazaar.launchpad.net but just test it from within
the data centre. Is that the sort of thing you meant?

> We should think about the consequences for
> 1- changing the lp: directory mechanism (away from xmlrpc etc)

There are roughly none, I think -- it's just a matter of returning
different URLs from the service (bzr+ssh, bzr, http), not how its
implemented.

> 2- branch privacy (probably not a big deal)

Shouldn't be, no.

Cheers,
mwh

On 5 March 2010 06:47, Michael Hudson <email address hidden> wrote:
> Martin Pool wrote:
>> On 4 March 2010 16:12, Michael Hudson <email address hidden> wrote:
> I don't understand what you mean here?
>
> A way of testing at a very early stage would be to set up the service on
> a machine in the DC that's not accessible from the internet and not have
> the port forwarding on bazaar.launchpad.net but just test it from within
> the data centre.  Is that the sort of thing you meant?

Yes.

>
>> We should think about the consequences for
>> 1- changing the lp: directory mechanism (away from xmlrpc etc)
>
> There are roughly none, I think -- it's just a matter of returning
> different URLs from the service (bzr+ssh, bzr, http), not how its
> implemented.

Right, but if we cut out that step altogether, which I think might be
good, then we would have to make the tcp server say "oh, you want
write access? try ssh" or handle redirections for series branches.
But I don't think this really strongly affects this bug; it will only
need to be parallel to what's done for ssh.
--
Martin <http://launchpad.net/~mbp/>

Martin Pool wrote:

>>> We should think about the consequences for
>>> 1- changing the lp: directory mechanism (away from xmlrpc etc)
>> There are roughly none, I think -- it's just a matter of returning
>> different URLs from the service (bzr+ssh, bzr, http), not how its
>> implemented.
>
> Right, but if we cut out that step altogether, which I think might be
> good, then we would have to make the tcp server say "oh, you want
> write access? try ssh" or handle redirections for series branches.
> But I don't think this really strongly affects this bug; it will only
> need to be parallel to what's done for ssh.

Oh I see; yes, that would be nice and yes, that's not really anything to
do with this bug at this stage.

Cheers,
mwh