[02:33] <cjohnston> sinzui: would you say that bug #295872 can be closed since it has been reworded and not had a reply from the op?
[02:33] <_mup_> Bug #295872: more info required about sprints and meetings on subscribe pages <confusing-ui> <lp-blueprints> <sprints> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/295872 >
[09:07] <czajkowski> frankban: morning
[09:07] <frankban> czajkowski: morning
[11:07] <czajkowski> gmb: morning any idea on https://answers.launchpad.net/bugzilla-launchpad/+question/216825 not sure why you're sub'd to it
[11:09] <gmb> czajkowski: I'm not sure what he's getting at… it looks like maybe he wants to have a CSV export of bugs; I don't think we offer that (allenap, do we?). I'm subbed to it through the Bugzilla Launchpad plugin, which is what he filed it against.
[11:14] <czajkowski> ah I see
[11:14] <czajkowski> morning btw
[11:28] <czajkowski> sinzui: aloha
[12:04] <allenap> czajkowski, gmb: The only vaguely relevant thing that comes to mind is +text for individual bugs.
[12:26] <sinzui> czajkowski, allenap, gmb. I am still a sleep. I replied to the bug suggesting an API script and provided a sample that will make a CSV for all the bugs in a project
[12:26] <czajkowski> sinzui: morning lotta bugs in there atm and not sure how to triage them
[12:27] <czajkowski> when you're more awake aka had some coffee fancy going through them so I can learn
[14:08] <sinzui> hi czajkowski. I am awake.
[14:12] <czajkowski> sinzui: not sure what https://bugs.launchpad.net/lpsetup/+bug/1090934  should be triaged
[14:12] <_mup_> Bug #1090934: Error: unable to find the ip address of the LXC container: Command '['/usr/bin/env', 'lp-lxc-ip', '-i', 'eth0', '-n', 'lptests']' returned non-zero exit status 1 <lpsetup:New> < https://launchpad.net/bugs/1090934 >
[14:12] <sinzui> czajkowski, high. We don't need to fix it until the next LTS or if it blocks canonical developers from doing their job
[14:13] <czajkowski> nods
[14:13] <sinzui> czajkowski, the key here is blocking us or buildbot
[14:13] <sinzui> So the scheduled fix is more than a year away :(
[14:14] <czajkowski> sinzui: what tags do I need to add
[14:14] <sinzui> non
[14:15] <sinzui> I was going to say none, but I think we want to add LTS and add a comment that the script has to work in LTSs and we believe this bug means it will not work in LTS T
[14:15] <sinzui> The loggerhead bug is low, No comment, no tags
[14:21] <czajkowski> sinzui: thanks
[14:21] <jcsackett> sinzui: can you refresh my memory on something? for +sharing, is the intent that drivers should be able to modify data on that page, or just see it?
[14:22] <sinzui> Only see it
[14:22] <jcsackett> sinzui: ok, thanks.
[14:32] <czajkowski> sinzui: do you mean will work in non LTS ?
[14:34] <sinzui> czajkowski, it does not have to work for a non-LTS like quantal We use it on LTSs to test Lp.
[14:34] <czajkowski> ah I see
[14:34] <czajkowski> thanks for the calrification
[14:34] <sinzui> czajkowski, lpsetup is a "nice to have" for developers who do not use non-lts
[14:36] <czajkowski> nods
[18:07] <timrc> sinzui, why isn't it possible to make a public team, private?
[18:07] <sinzui> because something the team has done has become a public
[18:08] <timrc> sinzui, I thought that private teams could operate in public contexts now
[18:08] <timrc> and only identifying details would be shared
[18:08] <sinzui> I cannot say exactly what. If the team owns something that cannot be owned by a private team or if its identity is know to a bug, mailing list, or public ppa, we know google knows all about it
[18:08] <sinzui> timrc, no, the mailing list is public forever
[18:09] <timrc> sinzui, sure but what if the list of people in the team before it's made private is irrelevant... e.g. the reason we want to make the team private is to hide the identity of new members?
[18:09] <sinzui> The team membership detail could be cached...
[18:09] <timrc> sinzui, the pre-privatization detail...
[18:09] <sinzui> and its involvement in bugs and answers was not sanitised. lots of data leaked though those interactions
[18:10] <sinzui> timrc, honestly Lp does not support it. No one wants to pay us to sort out the details of changing team visibility
[18:10] <timrc> sinzui, that's the answer I wanted :)
[18:10] <sinzui> timrc, I advise everyone in this case to create a replacement team that is setup right, and merge the problem team into it
[18:11] <sinzui> You have to setup memberships again, and you loose PPAs and mailinglists, but it gets around the team restrictions
[18:17] <timrc> sinzui, cool... so would adding the public team to the private team be a satisfactory way of creating a new private team with the members of the old public team?
[18:18] <sinzui> adding/
[18:18] <sinzui> ?
[18:19] <timrc> sinzui, yeah, I got "Add member", specify the team, then as an admin of that team, accept the invite?
[18:19] <timrc> er goto
[18:20] <sinzui> timrc, You can a private team to a public team. The public team members will be permitted to know about the private team even if the members do not intersect because the super team has the right to vet its members
[18:20] <sinzui> I think that is a safe solution
[18:21] <sinzui> s/You can a/You can add/
[18:21] <timrc> It appears that I can add a public team to a private team as well, but you're saying that's not safe?
[18:23] <timrc> It seems safe in the sense that people can't arbitrarily add themselves to the public team to gain access to the private team unlawfully
[18:40] <sinzui> timrc, sorry, I had to deal with a deliver
[18:40] <sinzui> y
[18:41] <sinzui> timrc, let's not confuse visibility public/private with exclusive/inclusive membership policies
[18:44] <sinzui> timrc, we do not trust inclusive team (Open and Delegated) because they do not vet membership. All exclusive (Restricted and Moderated) teams can own trusted things because they check their members. You can add exclusive teams as members and you don't need to worry about if their visibility is public or private
[18:45] <sinzui> timrc, Since you care most about hiding some member, I think you suggestion of a private subteam is sensible
[21:29] <jcsackett> anyone free to review https://code.launchpad.net/~jcsackett/launchpad/edit-icons-permissions/+merge/140556
[21:44] <czajkowski> jcsackett: evening
[22:02] <timrc> sinzui, so why is "embargoed" for private projects (re: http://blog.launchpad.net/general/private-projects-and-private-blueprints-leave-beta) not simply "Proprietary, can be public" to keep it consistent with other sharing policy information type meanings
[22:03] <timrc> the meaning of embargoed in the context of branch sharing, for example, seems different than in the context of project type
[22:03] <sinzui> timrc, yes, it is
[22:03] <sinzui> timrc, different teams built the features that the meanings were not reconciled
[22:04] <wgrant> Hm
[22:04] <wgrant> How is the meaning different?
[22:04] <wgrant> Stuff in an Embargoed project can't be public
[22:04] <timrc> wgrant, there is another information type for sharing, called Proprietary, can be public which is what is described at that  blog post
[22:04] <sinzui> nor is the use of embargoed symmetric. you cannot have embargoed bugs, but you can have branches and blueprints
[22:05] <timrc> but as embargoed
[22:05] <wgrant> timrc: That's not an information type. It's a rule for what information types the project can contain, and it's not the same as Embargoed.
[22:05] <timrc> ok, so there's Embargoed and then there's Embargoed, got it ;)
[22:06] <wgrant> Nope
[22:06] <wgrant> Where is the second meaning
[22:06] <wgrant> ?
[22:07] <sinzui> I think the real issue is that a project can be embargoed, but no policy recognises embargoed bugs
[22:07] <timrc> The meaning of Embargoed in terms of a sharing policy: http://pastebin.ubuntu.com/1448655/
[22:07] <timrc> wgrant, ^
[22:07] <timrc> The blog describes an Embargoed project as "Embargoed exists for projects that intend to start private but later be revealed publicly. All other private projects should be proprietary."
[22:08] <wgrant> Oh
[22:08] <wgrant> They actually still went with that?
[22:08] <sinzui> Embargoed can also become public if the project changes.
[22:08] <wgrant> But in terms of what they actually mean in terms of Launchpad restrictions, they are the same
[22:08] <wgrant> But the described uses are different
[22:08] <sinzui> timrc, from your perspective, nothing goes public
[22:09] <timrc> sinzui, right, we are just contemplating the use of private projects in the new year, so I'm trying to really understand all this stuff now :)
[22:38] <timrc> So within my team we have the unique ability of adding external sources for PPAs... let's say that the external dependency is a snapshot of -updates for some Ubuntu series, will the PPA still build with the latest -updates and supercede any dependencies in my snapshot with whatever's latest?
[22:39] <timrc> or will adding an external dependency cause the PPA to not build with the latest Ubuntu -updates
[22:40] <StevenK> You can edit the external dependencies to not pull from -updates
[22:40] <timrc> StevenK, Ah, yes that's right
[22:40] <timrc> StevenK, Thanks for the reminder