[08:39] <adeuring> good morning
[09:41] <LPCIBot> Project devel build (347): STILL FAILING in 3 hr 30 min: https://hudson.wedontsleep.org/job/devel/347/
[14:30] <LPCIBot> Project db-devel build (261): STILL FAILING in 3 hr 34 min: https://hudson.wedontsleep.org/job/db-devel/261/
[14:50] <gary_poster> jelmer: ping?
[14:52] <gary_poster> jelmer: unping
[14:54] <jelmer> gary_poster: hi :-)
[14:55] <gary_poster> hi jelmer :-) sorry, I'm chr and didn't know the answer to a soyuz question, but someone else stepped in
[16:31] <sinzui> jml. sorry for missing our standard meeting time. My computer needed a stern whack.
[18:17] <lifeless> good morning launchpad
[18:20] <jkakar> Good morning lifeless, Happy New Year! :)
[18:30] <lifeless> hi jkakar !
[18:35] <lifeless> [18:35] <lifeless>     Hard / Soft  Page ID
[18:35] <lifeless>       29 / 3980  Archive:+index
[18:35] <lifeless>       29 /  170  BugTask:+index
[18:35] <lifeless>       22 /  239  Distribution:+bugs
[18:35] <lifeless>       12 /  151  POFile:+translate
[18:35] <lifeless>       10 /   17  DistroSeriesLanguage:+index
[18:35] <lifeless>        8 /   95  ProjectGroupSet:CollectionResource:#project_groups
[18:35] <lifeless>        7 /  235  Distribution:+bugtarget-portlet-bugfilters-stats
[18:35] <lifeless>        6 /    4  ProjectGroup:+milestones
[18:35] <lifeless>        5 /    5  Archive:+copy-packages
[18:35] <lifeless>        5 /    2  Product:+filebug-show-similar
[19:39] <lifeless> sinzui: did you have a good break?
[19:50] <sinzui> lifeless I suppose so. I have not completed updating gedit-developer-plugins to libpeas and gobject-introspected, but my version is running on my natty alpha one desktop
[19:51] <sinzui> Once I upgraded to the alpha, making my primary tools work became an imperative. I think this means they will ship with quickly by default by the beta release
[19:52] <lifeless> flacoste: hi
[19:52] <lifeless> flacoste: are we talking today ?
[19:52] <flacoste> hi lifeless!
[19:52] <flacoste> we are
[19:52] <lifeless> kk
[20:07] <flacoste> lifeless: https://lpstats.canonical.com/graphs/PPR/20100104/20110104/
[20:20] <lifeless> https://lpstats.canonical.com/graphs/PPR/20101228/20110104/
[20:25] <lifeless> http://newrelic.com/
[20:26] <lifeless> http://omniti.com/video/noit-oscon-demo ?
[21:52] <flacoste> lifeless: http://launchpad.leankitkanban.com/Boards/Show/12720553
[21:58] <jml> sinzui: I'm off all week
[21:58] <lifeless> jml: doh
[21:58] <lifeless> jml: I was hoping for a chat
[21:59] <wgrant> gary_poster: Hi.
[21:59] <lifeless> flacoste: https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=feature-flags
[22:02] <jml> lifeless: maybe we can work something out
[22:02] <gary_poster> wgrant: hi.  (if you are responding to my ping, someone was asking for soyuz help and I was flailing for help since I didn't see bigjools around.  someone else replied at the time.  thank you)
[22:03] <wgrant> gary_poster: I was actually around a few minutes after that, but decided that 2am wasn't a good time to be working.
[22:03] <gary_poster> wgrant: lol, I agree
[22:04] <wgrant> gary_poster: I'm actually wondering if there's any reason I shouldn't copy bzr-pqm and bzr-tarmacland in the PPA to natty.
[22:04] <wgrant> Because your new launchpad-dependencies is uninstallable.
[22:04] <gary_poster> wgrant: argh!  should have thought of that.  no, there is no reason not to copy them (with binaries)
[22:05]  * wgrant does so.
[22:05] <wgrant> Thanks.
[22:05] <gary_poster> thank you wgrant
[22:05] <wgrant> Hmm, although they each have separate lucid and maverick uploads.
[22:05] <wgrant> Should I use the recipe, or just copy the maverick ones?
[22:06] <gary_poster> I'm pretty sure copying will work, but Ursinha or matsubara-afk can you offer any insight?
[22:07] <wgrant> It should work. And if it doesn't, the new version will be newer, so it will be easily fixable.
[22:07]  * wgrant does it.
[22:07] <gary_poster> +1
[22:09] <Ursinha>  not really, I think copying should be enough..
[22:35] <lifeless> jml: well ping me your morning or something
[22:47] <lifeless> wgrant: ok, so Archive:+index
[22:48] <lifeless> its tagged for stub; suggest grabbing him this arvo
[22:48] <lifeless> I think he looked and said (roughly) 'fugly queries'
[22:48] <wgrant> Yeah, that's about what I recall.
[22:48] <wgrant> I will grab him.
[22:49] <lifeless> it may be worth changing it from prejoin to using DRS and doing a couple of simple serial queries.
[22:50] <wgrant> sinzui: Hi.
[22:50] <sinzui> hello
[22:51] <wgrant> sinzui: I just saw bug #696954.
[22:51] <_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/696954 >
[22:51] <wgrant> Surely embargoed security bugs should not be seen by everyone?
[22:52] <sinzui> I am not certain of that. But I have said before that we are working on privacy issues, not security issues
[22:52] <sinzui> wgrant: I do not have a strong opinion about who should see security bugs.
[22:52] <wgrant> sinzui: Well, at least for Ubuntu the bug supervisor *must not*.
[22:53] <sinzui> At this time, I think security bugs are only seen by subscribers. There is plenty of opportunity to shoot yourself in the foot by unsubscribing.
[22:53] <wgrant> Sure.
[22:53] <wgrant> But that's how it has to be.
[22:54] <wgrant> Unless you add an implicit security contact subscription.
[22:54] <wgrant> Which might be OK once we have anti-subscriptions.
[22:54] <lifeless> we had anti subscriptions
[22:54] <lifeless> they were removed
[22:54] <wgrant> Did we?
[22:54] <sinzui> I believe there are 50 private Lp bugs that we cannot see
[22:55] <wgrant> I don't recall there ever being anti-subscriptions.
[22:55] <sinzui> wgrant: I am fine with not showing security bugs to drivers and bug supervisors. I think owners need to see them because the role is rarely delegated
[22:56] <wgrant> Bug contacts could initially unsubscribe, but that's because there were no implicit subscriptions.
[22:56] <wgrant> sinzui: For Ubuntu that is probably still a really bad idea.
[22:56] <lifeless> well
[22:56] <lifeless> there are some nuances here
[22:56] <lifeless> firstly, shared namespaces.
[22:56] <sinzui> We should not trust the owner? maybe we should not report a bug in their project then. I expect owners to fix their work
[22:56] <lifeless> secondly, CVE legal requirements
[22:56] <wgrant> sinzui: Embargoes.
[22:56] <wgrant> As lifeless says.
[22:57] <wgrant> The security team is to have access to those.
[22:57] <wgrant> Not ~ubuntu-drivers.
[22:57] <cody-somerville> What about making it configurable? ie. you could have a matrix, roles vs. bug type
[22:57] <wgrant> Launchpad seems to hate configurability.
[22:57] <wgrant> But that would indeed be optimal.
[22:57] <lifeless> cody-somerville: bite your fingers
[22:58] <cody-somerville> but that'll hurt :-(
[22:58] <sinzui> Ubuntu should fix itself or raise their issues as top priority in stakeholders meetings. making a driver team the owner is just wrong. If they are note really owners, them make the real ownes the owner
[22:58] <wgrant> sinzui: It's arguable that even the project's owners should not know.
[22:59] <wgrant> Although I guess they can change the security contact anyway.
[22:59] <wgrant> It would be nice to still have separation.
[22:59] <cody-somerville> If permission stuff could be changed on the fly instead of hard coded they would probably be more open to trying to get things as intended. right now people are finding all kinds of creative ways to get launchpad to do what they want (or as close to it).
[22:59] <lifeless> so
[23:00] <lifeless> we have a requirement from mark to minimise variation between projects in LP
[23:00] <wgrant> That is going to limit adoption. Because Ubuntu is not other projects.
[23:00] <lifeless> so that once someone learns *lp* they can predict its behaviour for ubuntu, zope, launchpad itself etc etc etc
[23:00] <cody-somerville> wgrant, I disagree. There has to be a buck stops here type position that has access to everything. You don't want to get into a scenario where no one can access something anymore because no one with the required role exists anymore.
[23:01] <lifeless> sinzui: I suggest that 'security team' as a role with implicit subscription is all thats needed, no ?
[23:01] <sinzui> wgrant: the project owner can *choose* to have full access simply by they control who in in the security  role. Private bugs will only have 1 bug target. So when the owner sees a count of bugs higher than listed, he will cease control
[23:01] <lifeless> this doesn't help the shared namespace problem
[23:01] <lifeless> but we were perhaps on crack doing that right from the beginning
[23:01] <wgrant> sinzui: But changing the security contact is a very explicit action. I don't think that giving them implicit access to the security bugs is a fantastic idea.
[23:02] <cody-somerville> lifeless, I think the intention there might have been more like not letting them decide the layout of the 'portlets' (or w/e you call them) on the project page and not intentionally cripling the usefulness of Launchpad by always having to have the lowest common denominator when it comes to functionality.
[23:02] <wgrant> +1
[23:02] <lifeless> cody-somerville: no, thats not it
[23:02] <sinzui> I think a user is a security role gets to see all security bugs. The subscription is only needed for email. That is not required though because th security team could have a structural subscription
[23:03] <wgrant> sinzui: True. One could have a security-only structural subscription.
[23:03] <lifeless> cody-somerville: this has been discussed a lot previously; its about behaviour not presentation
[23:03] <wgrant> So all we really need is for structural subscriptions to work for private bugs, detach viewing rights from subscriptions, and allow structural subscriptions based on the security flag.
[23:04] <lifeless> cody-somerville: our *job* is to make the lcd very powerful and find ways to solve the tensions present
[23:04] <sinzui> cody-somerville: But I think most of us agree that the project page is designed to be useless for people who need to use it
[23:04] <cody-somerville> we have to be pragmatic here.
[23:05] <cody-somerville> The same permission policy for all projects just isn't going to work.
[23:05] <lifeless> cody-somerville: it has for 6 years and we have plenty of adoption.
[23:05]  * cody-somerville laughs.
[23:05] <wgrant> FSVO plenty.
[23:05] <wgrant> And FSVO adoption.
[23:05] <lifeless> Look, reframing the problem is one route forward.
[23:05] <lifeless> I'm not ruling it out - thats for jml, as proxy-mark, to do.
[23:06] <lifeless> What I am doing is telling you *how* its been communicated to me previously.
[23:06] <cody-somerville> I understand that.
[23:06] <lifeless> I will say that just because its hard to do doesn't mean its impossible or unvaluable.
[23:07] <sinzui> We are being asked to make it clear who does have access, and to make it simple to grant someone access to all of a project. We do not need to concern ourselves with a lot of details to be successful. We can continue to limit who can see the security issues knowing that an owner can always choose to know, and that it will be common knowledge how to choose.
[23:08] <lifeless> indeed
[23:08] <lifeless> so - for instance - showing a 'has access' portlet in addition to the subscribers
[23:08] <lifeless> I *do* think that the security contact should act as an implicit subscription not a template subscription
[23:09] <cody-somerville> +1
[23:09] <cody-somerville> btw, is there another web application that does this really well that could be a role model?
[23:09] <lifeless> not that I've seen
[23:09] <wgrant> The only template subscription should be the reporter.
[23:10] <wgrant> That's easy to do once access is separate.
[23:10] <lifeless> wgrant: it won't be separate
[23:10] <lifeless> wgrant: subscription will still imply access; it will be additive
[23:10] <wgrant> Right.
[23:14] <lifeless> flacoste: we have a lot of sev 0 rt tickets
[23:16] <lifeless> flacoste: https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone#preview updated
[23:32] <flacoste> poolie: http://en.opensuse.org/openSUSE:OSC
[23:33] <flacoste> poolie: http://en.opensuse.org/openSUSE:Build_Service_Collaboration