branch multi-tenancy causes confusion about ownership

[Curtis Hovey]

Branch multi-tenancy undermines the primary communities ability to manage it's data. Project maintainers want to set a policy of who has access to project's private data, but it is not necessarily true that the primary contributors (the maintainers) own the project data.

The project maintainers can, and do, make their branches private, which makes all stacked branches transitively private. Thus while a policy might permit another community to create private branches, it is not possible because they do not have access to the base branch. Branch multi-tenancy assumes that all branches are public, that users have access to base branches, which has not been the case since branch stacking was introduced. It is clear that Lp does recognise that the project maintainer does have the right to control their branch data, but it implies that this is not true.

[Robert Collins (lifeless)]

They don't need a subscription today, do they?

On 4/01/2011 9:40 AM, "Curtis Hovey" <email address hidden> wrote:

Public bug reported:

project maintainers, drivers, bug supervisors, and security contacts
should always have access to private branches. They should not need a
subscription to access their own project's private artefacts.

** Affects: launchpad
    Importance: High
        Status: Triaged

** Tags: disclosure

--
You received this bug notification because you are subscribed to
Launchpad Suite.
https://bugs.launchpad.net/bugs/696956

Title:
 Allow users in project roles to access private branches

[Curtis Hovey (sinzui)]

Users need to be a member of the owning or subscribing team.

[Francis J. Lacoste (flacoste)]

I have doubts about that requirement. Branches have a dual ownership project and owner. What you are suggesting here is that one owner (the project) preempts the other (the person owning the branch).

Wouldn't this precludes use cases like a team is working on an upstream project for an under-the-radar feature (exclusive launch then merged upstream, like we do in some OEM projects). The work should be in a private branch, but the upstream project owner shouldn't necessarily have access to it until the sponsor feels it's ready to merge back.

With this constraint in place, that use case would have to be serviced by creating a 'fork project' only to manage the maybe temporary secret fork.

If that requirement only applies to private projects, I think it could work. (Since by definition, nobody else can create branches on such a project).

[Curtis Hovey (sinzui)]

The underlying requirement for this bug is a statement from Canonical managers that Canonical staff should have access to Canonical's code. The subscription mechanism is a burden, see bug #474048. The goal is to minimise the number of steps and maybe their frequency so that an organisation can confidently share its code with its members.

This could apply to just private projects, but I believe Canonical would be dissatisfied. ISD and U1 will always have some public projects with private branches. Conversely, HWE will commonly be working with public projects that they do not own, but need to contribute to.

If we supported nested projects, we could build a hierarchy of projects under canonical's porject and set the policy exactly once for the Canonical team in Canonical's projects.

[Robert Collins (lifeless)]

I don't think we should design this in a bug; I'd like to take it
offline till the thunderdome and drill in there - this seems to have a
thorny nest of issues which we're also running into in the security
bug context: shared namespaces, disclosure and visibility.

[Curtis Hovey (sinzui)]

This bug can be closed when we dismantle the branch visibility policy that enables multi-tenancy on branches.

[Curtis Hovey (sinzui)]

William, mark this fix released when we enter the Sharing beta.