launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-09-18 12:32 PM, Curtis Hovey wrote:
>> 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.

Okay, I think I was confused because I thought we were talking about
all projects and you were talking about projects that want to be
proprietary.

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

Oh, I thought it would happen on publicly-seen, privately-developed
projects like the Ubuntu One server.

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

Oh, so I misunderstood you.  While "The creators also work with
[Public, Private (user), Private Security].", you're saying the data
shows they never intentionally *create* them in proprietary-wanting
projects.

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

This is also true of bugs.  We commonly file apprort bugs as private
(user) and then clean them up later, so I don't see how it
demonstrates that a blueprint *cannot* contain private user data.
Maybe the distinction you see is that some bugs *must* contain user data?

Anyhow, perhaps "not common enough to support" and "originate from the
creators" are two side of the same coin if we include "and the data
shows creators never do this".

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBYqUAACgkQ0F+nu1YWqI2dHACcD0IYl9iydHcfy6gKQUVnHEFs
6ckAnRn9vD4Can7wjRoUz1s9lxPDeYam
=fQeV
-----END PGP SIGNATURE-----