The purpose of this template is to help us get ReadyToCode on features or tricky bugs as quickly as possible. See also LaunchpadEnhancementProposalProcess.

Remove the hosted area in codehosting

Remove the distinction between the hosted and mirrored area

On Launchpad: hyperlink to a blueprint, normally

As a developer using Launchpad's code hosting
I want changes I make to branches over bzr+ssh to be available over HTTP as soon as I make them
so that interacting with Launchpad involves less waiting

As a LOSA
I want codehosting to not use twice as much disk space as it needs to
so that I don't have to buy and install more disks so often

Rationale

Why are we doing this now?

No particular reason for right now. It's something we've been wanting to do since forever.

What value does this give our users? Which users?

It mainly wastes less resources, and so benefits our sysadmins.

Although this is mostly an architectural change, it should make Launchpad simpler to use by removing an obscure concept users need to understand.

Stakeholders

Who really cares about this feature? When did you last talk to them?

Admins, I guess. I haven't talked to them for a while.

Constraints

What MUST the new behaviour provide?

What MUST it not do?

Success

How will we know when we are done?

When we can delete the /srv/bazaar.launchpad.net/push-branches directory on crowberry.

How will we measure how well we have done?

This is a pretty binary thing

Thoughts?

Put everything else here. Better out than in.

How do we prevent abuse of Launchpad as a file hosting service?

• I guess we don't care too much. Some kind of monitoring for abuse, there shouldn't be a security risk here as the branch data is only served over http (or some ssh backed protocol), not https and the interesting launchpad cookies are marked secure.

What do we do if someone uploads a branch reference to or a branch stacked on somewhere cheeky?

• We have to be careful about opening branches. We can probably do this by making it easy to open branches the safe way (i.e. by having IBranch.getBzrBranch DTRT).

Places that open branches for writing:

• codehosting, sort of -- the launchpad specific stuff is all at the transport level though
• the puller

• createmergeproposaljob -- the bundle -> branch + merge proposal stuff

• the translations export to branch stuff

Places that open for reading:

• all of the above
• codebrowse
• translations import
• scanner
• other places??

The puller should change to not actually pull any revisions. Something like the puller still needs to process hosted branches so that the scanner runs and various other fields get updated. Also the stacked-on URL may need massaging.

The above-mentioned stacked-on URL massaging means we'll be directly editing the data the user has uploaded for the first time. I don't think this is a big issue though.

The fact that the mirrored area contains a copy of the branch has occasionally allowed us to easily recover from the version in the hosted area getting trashed somehow.

The codehosting vfs won't actually change that much, although perhaps it makes sense to rename hosted_transport and mirror_transport to ro_transport and rw_transport or something.

Various parts of launchpad that wait until the branch has been pulled before doing things should be changed to not do that.

Lots of places that sets up branches for integration testing should become easier to understand.