On 09/18/2012 12:19 PM, Aaron Bentley wrote: > On 12-09-18 11:03 AM, Curtis Hovey wrote: >> There are groups of people interacting with a project and they use >> different information types. > >> * Project Creators use Public, Proprietary, and Embargoed for >> planning. * Project Community uses Public, Private (user), Private >> Security > > I don't understand this distinction. It seems like "creator" actually > means "owner" or "planner", since people who had no role in the > creation of the project could wind up filing proprietary bugs later.
I use creator because Launchpad owner, maintainer, driver, and shared organisation do not properly encompass the case where Canonical "owned" projects are proprietary. Our organisation delegates the responsibility to deliver or maintainer the project to many people. People in these project roles are the core people who clearly are creators of features. The people the project shares with are also placed in the role of creators, though they rarely will make use of it. > I think you're describing three categories > Project Community, Project Creators who are not planning, who behave > the same, and Project Creators who are planning, who use different > types. (I split Project Creators into planning and non-planning to > reconcile with your later statement "The creators also work with > [Public, Private (user), Private Security].") This case has never been demonstrated to be true in Launchpad's data, but we do recognise it can happen. We called YAGNI on the case. For example, of the project that want to be proprietary, only 1 bug was every filed as a Private Security bug in 6 years. It was a mistake. Proprietary projects treat use other projects (via information bug linking) to manage Private Security and Private (user) bugs. > I don't think this is accurate, because some projects will use > Proprietary and Embargoed regardless of whether they are planning. > > Perhaps you meant: > * Project Creators use Public, Proprietary, > and Embargoed for planning, and all available types when not > planning. > * Project Community uses Public, Private (user), Private Security > > Is that it? It seems to disagree with this next statement, which > implies that creators do not create Private (user) or Private Security. > >> Project, teams, and blueprints originate from the creators, so they >> can only be Public, Proprietary, and Embargoed > > It's certainly *possible* for a blueprint to be security-related. > Similarly, it can contain private user data. I think the reason we > exclude those information types from Specifications is because we > don't think it's common enough to support. I don't think it's because > they originate from planning creators. Also, we don't prevent > non-creators from creating blueprints. Not so, the blueprint can be edited to remove the personal information about a user. While a blueprint may intend to solve a systemic security issue, it does not contain the security issue, nore does it contain the way to exploit the issue. Bugs do. While someone could put this information in the blueprint, it can be trivially removed. The external specification might contain details of the issue. Consider that we did find cases where branches contained Private (user) data. The fix is the delete the branch. A branch might exist to remove personal data that is already committed. This happened 3 times in that we know about. No user has ever asked for the feature. We decided that Admins can set branches to Private, but users will see Proprietary and Private Security. -- 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
