launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

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 should allow users to correct their mistake.

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

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

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