launchpad-dev team mailing list archive

[William Grant <william.grant@xxxxxxxxxxxxx>]

On 31/07/12 00:01, Matthew Revell wrote:
> Hi Deryck, Curtis,
> 
> Over the past few days, Deryck and I have been chatting to the
> Canonical stakeholders who want private projects in Launchpad. The
> result is a bunch of updates to the private projects LEP:
> 
>   https://dev.launchpad.net/LEP/PrivateProjects
> 
> Some questions are outstanding:
> 
>  * ISD want hybrid projects when the project is public but bugs and
> branches are private by default. Curtis seems to have ruled this out.
> Is this possible within our budget?

How was that ruled out? AFAIK (and I'm implementing it this week, so it
is hopefully the case...) public projects can opt in to default-private
or exclusively-private bugs and branches with no problem, it's just that
private projects will be restricted to exclusively-private.

>  * Once a private project is made public it's not just the bugs and
> branches that need to stay private. At the least we also need to
> consider Answers and Blueprints. What else?
> 
>  * How can we tell people that their bug comment, for example, is
> private and then later allow the project maintainer to expose it to
> the world? Isn't that rather obnoxious?

Well, the project maintainer could also copy and paste the comment into
a public bug. We can't stop them from deliberately leaking it one way or
another, so the question is not whether we should allow it, but rather
whether we should arbitrarily make it more awkward. I suspect we shouldn't.

>  * Is it simpler to disable karma for private projects rather than
> deal with the potential for leaks?

AFAIK the only place we expose karma context information outside the
context project is in the "Most active in" list on Person:+index, and
there are other similar non-karma-derived lists like that that need
filtering anyway. I don't really see karma as a special case here.
Person:+karma reveals the timestamp and type of the action, but no
detail about which objects were involved.

> I'd welcome your thoughts on these.

After a quick glance over the LEP, I'd be extremely wary of the user
story about daily builds of private branches. It may be desirable, but
it's a significant chunk of work in codehosting and the build farm, when
neither component would otherwise be touched by the Private Projects work.

Attachment: signature.asc
Description: OpenPGP digital signature