launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Thu, 2010-09-30 at 17:00 -0400, Francis J. Lacoste wrote:
> On September 22, 2010, Curtis Hovey wrote:
> > Retargeting Private Project or Distro Artefacts
> > ...............................................
> > 
> > Private artefacts can never be retargeted to other projects and distros
> > because the comments and history may contain private information. Users
> > who reply via email under the assumption that their message is private
> > would in fact be leaking information. This means that bugs, questions,
> > and blueprints will always remain with the project or distro they were
> > created in.
> > 
> 
> Isn't that overly restricted? What about filing a bug on the wrong private 
> project. OEM engineers typically work on many projects and I can surely 
> imagine that they file one bug on the wrong project and then retarget it to 
> the correct project. 

We allow the user to use the clone bug feature to which permits them to
redact. This is very restrictive because the risk of leaking something
to between partners is is high. This is not about me and my projects,
this about is *everyone* in the other project permitted to see this
information.

> We should allow users to correct their mistake.

I think the clone bug feature addresses some of this. I would like to be
able to delete bugs.

> > Public bug, questions, and blueprints cannot be targeted to private
> > projects and distros because the artefacts subscribers and the former
> > and current context subscribers are all notified of the change. This act
> > will reveal the existence of the private project or distro, and possibly
> > leak information about who is involved in it.
> 
> Again, same rationale here. If by 'reveal the existence of the private 
> project' you are thinking of the notification / activity, we can redact the 
> name of the private target in the message.
> 
> Reading this I was worried about the way we would represent a common case 
> where a customer bug is really a generic Ubuntu bug. I understand that bug 

We are most concerned about the comments in a bug from many users. Some
may subscribe to the bug. If I can move the bug to another project, that
has a different set of permitted people, I may be leaking information.

Subscribers are kept during a retarget. This could give a partner
knowledge of another partners concerns.

OEM has to copy bugs now. They have to redact information that is in the
copied bug.

> > 
> > 
> > Code Branches
> > .............
> > 
> > Branches for private projects and distros (source packages) are private,
> > they cannot be public. Any user with access to the private project or
> > distro can access the branch. The project primary context owner can
> > subscribe a user or restricted team to the branch. Public projects can
> > still have private branches to solve security vulnerabilities or for
> > commercial development.
> 
> This also seems overly restrictive. We have to think about a very common use 
> cases where a team works on a project privately and then release it to the 
> public. Is the way to model that by switching the privacy of the primary 
> context? But this means that you cannot do a graded disclosure (when one 
> releases a branch, then all the bugs and branches).

It is not our intent to support this--the primary context is private,
making the branch public will not give anyone access to it. The branch
will have to be pushed to a public location.

We are not changing the rules for pubic projects with private artefact.
So I can have a private bug and private branch on a public project.


-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part