linaro-release team mailing list archive

[Loïc Minier <lool@xxxxxxxx>]

        Hi

 This bug (actual bug doesn't matter) was reported as private:
    https://bugs.launchpad.net/lava-scheduler-tool/+bug/842524
 but was immediately visible on the public list archives:
    https://lists.launchpad.net/linaro-release/msg00653.html

 While we rarely have private bugs, this seems very wrong and could put
 us in trouble for Landing Team bugs or if we have to handle real
 security bugs or other private bugs in the future.


 First, I wondered whether Launchpad had a borken privacy model here; I
 started discussion with Launchpad folks [1] and it's not a likely path
 of resolution (since any LP id could be pointing at a non-LP public
 list, LP can't grasp all these cases; we should be careful which LP ids
 are getting in the loop of private bugs and where these are
 distributing the traffic).

 Next, the ~linaro-release subscription was surprizing; I thought this
 was an important bug that ~linaro-release specially cared about, or
 perhaps ~linaro-release got in the loop due to some "security contact"
 escalation, but in fact it's simply that ~linaro-release is a member of
 ~linaro-validation:
    https://launchpad.net/~linaro-release/+participation

 This is wrong; let's revisit the reasons it's a member and find another
 way, or let's use two teams, one for the ML and one for the other
 reasons.

 Fathi, Joey: would you know why ~linaro-release has a ML? and why does
 it have these memberships?  Worst case, if LP allows it, we can switch
 to a private ML archive.

   Thanks!


[1] IRC extract of #launchpad:
09:13 < lool> just saw a case where a team with a public mailing-list archive 
              was subscribed to a private bug, and the private bug was of 
              course visible in the public archives
09:14 < lool> Is this something that Launchpad should avoid or warn about, or 
              is it just misuse on the users' side?
09:15 < wgrant> Launchpad could possibly special case that, but it seems 
                somewhat dangerous to let people expect a warning when many 
                teams use non-LP mailing lists that can't be warned about.
09:16 < wgrant> Shouldn't people normally be knowing about the team they're 
                subscribing to a private bug?
09:16 < lool> Here, it's a release team which is listed in the members of 
              another team which owns the project
09:16 < lool> https://bugs.launchpad.net/lava-scheduler-tool/+bug/842524
09:17 < lool> I don't understand the reasons why ~linaro-release is a member of 
              ~linaro-validation, this seems unnatural to me
09:19 < wgrant> It's unnatural, but a valid structure :)
09:19 < lool> well what I really wonder about is whether it's a really stupid 
              or a really clever one  :-)
09:20 < lool> wgrant: I'll pass the argument of non-lp MLs in the discussion 
              I'm startong; makes sense to me
09:21 < lool> wgrant: There is a real problem with LP MLs here though IMO: as 
              soon as you make a team a ML, then you lose the chance of using 
              for any private communication, but I guess that's the choice of 
              people setting this up
09:21 < wgrant> Yeah, it's not ideal, but it's not entirely clear how to make 
                it better.
09:22 < lool> yes


-- 
Loïc Minier