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
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
