launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 06/27/2012 03:41 AM, William Grant wrote:
...
> 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.

I am certain we know how bugs will work. The UI will say
    [X] Bugs are proprietary by default
And will be supported over the API as
    Product.proprietary_bugs = True

Bugs are either public or proprietary by default. No one should install
your software if your default bugs are about security or user issues...

...And we want to apply this to branches. The UI will say
    [X] Branches are proprietary by default
And will be supported over the API as
    Product.proprietary_branches = True

Branches are either public or proprietary by default. You are a spammer
if your branches are always about user-data, or a cracker if your
project only has security branches.


I think the hard question is who can bend the rules, and how do they
bend? We would like the bug and branch rules to be symmetrical, but that
may not be possible. We expect project most project will share
proprietary, embargoed security, and user data information with their
maintainers, drivers, and organisation teams.

Setting aside what the Purple Squad has said in the past. I think
symmetrical rules would work like;
    Default public (branch or bug) rules
    1. Any user can create a public bug or branch.
    2. Any user can *create or change* a bug or branch to Embargoed
       Security because we do not want to stop someone from protecting
       others.
    3. Any user can *change* a bug or branch to User Data
       because we do not want to stop someone from protecting
       others.
       3.1 Only users that the project shares User Data with can report
           a User Data bug or create a User Data branch.
    4. If the project has a commercial subscription,
       Any user can *change* a bug/branch to proprietary to protect
       organisations.
       4.1 Only users that the project shares proprietary
           information with can create proprietary bugs or branches

    Default proprietary bug rules
    1. Any user can report a Proprietary bug.
       1.1 Only users that the project shares Proprietary
           information with can change a bug to Public.
    2. Any user can *create or change* a bug to Embargoed
       Security because we do not want to stop someone from protecting
       others.
       2.1 Only users that the project shares Embargoed
           Security information with may change the bug to Unembargoed
           Security or Proprietary.
    3. Any user can *change* a bug to User Data
       because we do not want to stop someone from protecting
       others.
       3.1 Only users that the project shares User Data with may change
           the bug to Proprietary.

    Default proprietary branch rules
    1. Only users that the project shares Proprietary information with
       can create branches.
    2. Any user can change a branch to Embargoed Security.
       2.1 Only users that the project shares Embargoed
           Security with may change the bug to Proprietary.
    3. Any user can change a branch to User Data.
       3.1 Only users that the project shares User Data with may change
           the bug to Proprietary.

The two proprietary sets of rules differ on creation rules. Launchpad
stacking rules require that you have access to the series branch to have
access to the feature/fix branch.

-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature