launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Fri, 2010-09-17 at 12:54 -0400, Curtis Hovey wrote:
...
> Full and Partial Disclosure
> ---------------------------
> 
> Launchpad will permit users to have full or partial disclosure to a private
> structure. The mechanism will be like a subscription. The owner can subscribe
> users and restricted teams to their structure or its items. Access to
> a structure gives the user access to all subordinate items. Subscription
> is not about notification in this case, it is about disclosure.

bac: I think the term 'subscription' is fatally overloaded at this
point.  Could you call it 'access' or something besides subscription?
A person doesn't really subscribe to a project but is granted access
to it.  Unfortunately 'access' is closely tied to 'ACL' so that may be
a reason to avoid it.

sinzui: I agree, and I first used the term access and realised I was
leading people down the ACL discussion again. We use the terms view and
traversal, and I tried to create terms for them without success. I
wasn't happy with "Permit" and "Grant" either, but I agree that
subscribe is wrong. This feature is about managing disclosure of
information.

>     * Full disclosure means user can view all aspects of the project.
> 
>       * The user can see private branches of code, bug reports, and
>         personal private package archives (P3A) automatically.

bac: The private PPA access may be sticky, given their use of tokens
and custom-generated .htaccess files.  Not that it cannot be done, but
I'd suspect to see objections from Julian.

sinzui: Launchpad traversal was invented so solve this very use case.
Users were given view and we know that is wrong.

>       * The user does not need to be subscribed to the specific item.
> 
>       * The user does not need to be a member of the bug supervisor team
>         to gain access to a bug report (and will not receive unwanted email).

bac: Will the bug supervisor team automatically be given access, as
is done now?

sinzui: excellent question: I have an opinion, and am sure I am right,
but have not proposed that we fix the cluster of bugs already reported.
Namely. Changing a bug supervisor is impossible for large projects
because
      * The new supervisor is not added the existing bugs...they do not
        get access to private bugs :(.
      * The old supervisor continues to get emails :(
      * Having view on a private structure, or being an owner/driver for
        the pillar (public or private) should suffice to access any bug
        for the pillar.
      * Certainly, being a supervisor should give you access to any bug
        that affects the project, distro, or package. 
      * Consider the stupidity of malone right now, If a bug is report
        on a project without a bug supervisor creates an email to the
        owner...even if the pillar does not use Launchpad Bugs! We can
        easily fix this rule to use the bug supervisor instead, and only
        send the email if malone is official.
So I think that I do not need need to be a bug supervisor gain access to
bugs or to get bug mail (via a structural subscription). The bug
supervisor can change the status of bugs, just as the owner and driver
can (or should). We only need a bug supervisor rule is the role needs
different permission from drivers. I think drivers permissions are
broken though (that is a separate bug).

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

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