Purple Squad's unified sharing model lets projects manage who can see private bugs and branches. It replaces the bug and branch subscription-based access control lists, and it replaces most of BranchVisibilityPolicy's functionality.
But one bit of BVP remains unreplaced: defining who can *create* private branches. We also don't have a really good answer for the same question for bugs, even now. Original behaviour ------------------ Before Better Privacy, bugs and branches had divergent access control mechanisms. New bugs were public by default, unless the project had the private_bugs flag set, in which case they were private by default. In either case, users could select a checkbox to make their new bug private+security rather than private or public. After filing, anyone who could see the bug was able to change the private and security flags to any value. There was also an undocumented feature used by Ubuntu's apport to file private non-security bugs in Ubuntu, as if it had private_bugs set. The rules around branches were a little more obscure. New branches were public, unless the project had BranchVisibilityPolicies configured. A BVP overrode the public default, causing branches for members of a certain team to be public, private, or disallowed entirely. There was no way to override the default when creating a branch, and in normal circumstances only a Launchpad admin could change the privacy after creation. Use cases --------- Different projects use bug and branch privacy in several different ways. Ubuntu primarily uses public bugs and branches; both should be public by default. But Ubuntu also makes extensive use of private user data and private security bugs. User data bugs tend to only be filed by apport, but it's not clear that they're not desirable in other cases too. Private security bugs are filed by users and the security team to track embargoed security issues, through an option on +filebug. Both user data and security bugs are frequently disclosed later when they no longer contain confidential information. It's also reasonably plausible that they might want to use private security branches in future. Ubuntu One Servers has private (proprietary) bugs and branches by default. Its branches are exclusively proprietary and can only be created by its engineers, but it extensively uses public bugs, with a smattering of private security. All bugs start private, and anyone can file one, but a combination of reporters and engineers make them public as appropriate. Launchpad, like most FOSS projects, nowadays mostly uses public bugs and branches, except for the very occasional private user data or security bug. Both should default to public, but we need the ability to create private security bugs and branches as required. Launchpad in 2008 mostly used public bugs, but only proprietary branches. Bugs defaulted to public, but engineers occasionally filed private bugs containing code details. Like other proprietary projects, only engineers could create branches. Hypothetical Proprietary Project uses only proprietary bugs and branches. Everything starts private, and cannot be made public. Only engineers can create branches. Depending on how they feel, they might let anyone file a bug, or in the future they could be a private project that restricts bug filing. The future ---------- BranchVisibilityPolicy and probably Product.private_bugs need to be replaced in ways that are compatible with the example projects I outlined above, and probably more that I have not considered. They need to both support customising the default. They also need to be able to restrict certain types to certain groups of people (a normal user can't create a public Ubuntu One Servers bug, and nobody can create a proprietary Ubuntu bug or a public Hypothetical Proprietary Project bug), both during and after creation. I don't know how best to model this. Ideas? Cases that I haven't considered? Anything? William.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
