Remote/import/mirror branch registration is beholden to the registrant

Letting multiple people register a branch could solve the problem, but it could also be confusing to have the same branch appear in listings multiple times.

Perhaps an alternative is to let people sponsor or vouch for an existing remote branch registration. Once multiple people had vouched for a registration, the original registrant could not change it or delete it (unless, possibly, they proved somehow that they were the remote branch owner).

If you subscribe to someone else's branch, they cannot delete it.

I would say it is an unlikely situation where the branch would have the contents replaced, as the branch is being mirrored, and to replace the contents, they would have to replace the branch at the remote location, and as such would still break if multiple people were mirroring the same branch.

If you think that the branch would be better owned by a team, then the first approach would be to write on the whiteboard of the branch to let the current branch owner know of the situation.

We really do not want to have multiple copies of the same branch in Launchpad.

Jelmer, can you give a concrete example of the problem?

I had registered some of the bzr-mirror branches on Launchpad and somebody came along asking me to delete it since they couldn't register it themselves (and were apparently doing packaging based on the gnome bzr-mirror branch).

His concerns were apparently satisfied by having the branches registered by the gnome-bzr-mirror team. This is not always the case though - I can very well imagine myself registering the main branch of some project that's using bzr but not launchpad.

Not being able to delete a branch if there are registrants isn't sufficient, the branch would have to be immutable (since otherwise, the registrant could change the mirrored branch to some malicious branch).

AIUI, this is a trust issue. The problem is that people are worried about depending on a branch owned by someone else. For mirrored branches, the need for this dependency is a little forced—there's no a priori reason for forbidding multiple Launchpad entries for a single Bazaar branch.

Subscribing yourself to the branch doesn't address the trust issue. Writing on the whiteboard is definitely a step, but it's not sufficient. The solution mpt describes would probably suffice, but it would be a lot of work to do well. Another variation is to allow projects to say that they explicitly depend on "branch X", and then lock branches depended on. Another solution might be to allow branches to be registered as "hardlinks" to other branches, when the URL changes, the link is broken.

Allowing multiple registrations of a single branch is another interesting solution. What are the issues in doing this?

Given that we are wanting to get rid of remote branches, I really don't think we are going to spend much time on this.

This is not just an issue for remote branches, but for imports as well.

Given that import branches are still in individual users' (or groups') namespaces, I think the most sensible thing to do would probably be to lift the "no dupe" restriction (without necessarily actually duplicating the actual work of importing); the being that each user be confident nobody can delete their import branch and replace it with another, subtly-different, branch.