[00:53] <cjwatson> wgrant: dogfood seems to have builders attached at the moment - is there a particular reason I shouldn't start buildd-manager to drive them, or are they busted?
[01:01] <wgrant> cjwatson: They're not meant to actually be up
[01:01] <cjwatson> OK, I will pretend I didn't see them
[01:06] <wgrant> cjwatson: buildd-manager probably hasn't been started since I restored the DB
[01:06] <wgrant> Since I removed it from upgrade-dogfood-launchpad to avoid having to kill it every time I wanted a page to not timeout
[01:07] <cjwatson> Commented out in upgrade-dogfood-launchpad, and indeed I haven't seen it running
[08:58] <adeuring> good morning
[09:43] <stub> How are we going with LP on Precise? Wondering if I need to back port something
[09:44] <wgrant> stub: We have no immediate plans to upgrade prod
[09:45] <wgrant> It'll be next year some time
[10:35] <czajkowski> adeuring: morning any advice on https://answers.launchpad.net/launchpad/+question/214223
[10:48]  * adeuring is looking
[11:17] <czajkowski> adeuring: thank you
[13:33] <jcsackett> wgrant: my understanding is that we shouldn't be setting a proprietary branch as the productseries branch for a public productseries--you can have branches that are prop/priv whatever, but shouldn't set them as the series branch.
[13:33] <jcsackett> (from the MP you looked at)
[13:34] <wgrant> jcsackett: That is breaking several years of existing practice, and puts every internal Canonical project into an illegal state.
[13:34] <wgrant> It also doesn't make sense
[13:34] <wgrant> Things can be more private than their container -- that's no problem
[13:35] <wgrant> The problems arise when something is *less* private than its parent
[13:38] <jcsackett> wgrant: we're not forbidding proprietary branches for a product (the actual container); just the linked productseries. but your point is interesting. canonical is using proprietary productseriesbranches on public projects? those aren't projects that will be migrated to proprietary?
[13:38] <wgrant> jcsackett: lp:foo is a productseries branch
[13:39] <jcsackett> wgrant: granted. that's not directly answering my question. do we have proprietary productseries branches on products that shouldn't be migrated to proprietary themselves?
[13:39] <jcsackett> and the intent is absolutely to stay that way.
[13:40] <wgrant> jcsackett: Yes. The U1 and LS servers, for example, have proprietary code but are otherwise public
[13:40] <wgrant> Launchpad until 2009/07/21
[13:40] <wgrant> etc.
[13:40] <jcsackett> wgrant: ah yes. of course. i am not thinking clearly.
[13:42] <jcsackett> wgrant: ok, i'll bring this up on our standup. this is meant largely to handle transitional issues, but i think there are edges that need more sorting.
[13:43] <wgrant> Indeed
[14:31] <deryck> jcsackett, ping for standup
[14:32] <jcsackett> deryck: having plus problems--restarting the plugin. be there in moments.
[14:32] <deryck> jcsackett, no worries
[14:34] <deryck> abentley, adeuring, rick_h, jcsackett let's try http://tinyurl.com/orange-standup
[14:35] <deryck> heh
[14:35] <deryck> hey! bye!
[14:35] <abentley> deryck: Is it dying for everyone else, too?
[14:35] <deryck> abentley, no, just you and jcsackett
[14:35] <jcsackett> we're cursed. :-P
[15:18] <sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/missing-potmsgset/+merge/134483
[15:31] <rick_h> adeuring: ping, do you know if the card you added I'm working on came from a bug somewhere? "filter private products in ProjectView.untranslatables"
[15:32] <adeuring> rick_h: no, there is no bug or oops. I simply looked for methods that return products
[15:33] <rick_h> adeuring: ok cool
[15:33] <adeuring> rick_h: might be even worth to check if this method is used at all ;)
[15:34] <rick_h> adeuring: yea, it's used but it's just projectgroup.products
[15:34] <rick_h> which is already filtered and there's tests for that property with non-public projects
[15:34] <rick_h> so just wanted to make sure I didn't need to add a note anywhere else
[15:34] <rick_h> e.g. bug
[15:34] <adeuring> rick_h: ah, ok, then just drop the card :)
[15:34] <rick_h> so I'll note in the card the findings and move to done so we keep track that we looked there
[15:35]  * sinzui thinks project groups listing project work fine now
[15:36] <rick_h> yep, should be good awesome card! :)
[15:43] <deryck> a lot of the cards remaining are like that.... i.e. just check to make sure we're safe in that area of the code/site.
[15:45] <maxb> ooi, what is the status of Barry's Lucid Python 2.7 PPA? Is that something LP is still looking at using?
[17:20] <jcsackett> abentley: you around, or off at lunch? questions from your MP.
[17:24] <jcsackett> abentley: comments left on MP.
[17:26] <sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/publishbinary-without-publications/+merge/134527
[17:27] <jcsackett> sinzui: you caught me just in time. :-) yeah, it's short enough i can take a look.
[17:29] <jcsackett> sinzui: r=me.
[17:29] <sinzui> jcsackett, this is also short  https://code.launchpad.net/~sinzui/launchpad/missing-potmsgset/+merge/134483
[17:29] <jcsackett> sinzui: already did that one. :-)
[17:29] <sinzui> thank you
[17:30] <jcsackett> you're welcome. :-)
[17:30]  * jcsackett lunches
[18:43] <rick_h> deryck: so build-not is having fun today
[18:43] <rick_h> out of the last 4 runs, 3 times LP failed to come up and the next to last one was something out of the actual parallel testing layer
[18:44] <deryck> rick_h, yeah, I wondered just now based on your tweet if we have a serious problem. doesn't seem random now.
[18:44] <rick_h> http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/294/steps/shell_9/logs/err.html
[18:44] <deryck> I just forced now, FWIW
[18:44] <deryck> to try to get my stuff in.
[18:44] <rick_h> yea, but the lp not coming up is typical
[18:47] <deryck> grrr, it fails faster than I can force and land my branch.  something seems borked now.
[18:49] <deryck> I see a reference to bug 504291 in the summary
[18:49] <_mup_> Bug #504291: DisconnectionErrors (already disconnected) happening again <fastdowntime> <lp-foundations> <oops> <Launchpad itself:Incomplete by stub> <Storm:Invalid> < https://launchpad.net/bugs/504291 >
[18:52] <rick_h> deryck: well looks like the normal beanch is in an ok state but the db one failed now
[18:52] <deryck> rick_h, yeah, I'm asking in our ops channel to see if there's something we can do to kick buildbot.
[18:53] <abentley> jcsackett: Yes, I was on lunch.  Thanks for the review.
[19:25] <jcsackett> abentley: thanks for responding on the MP.
[19:25] <jcsackett> rick_h: can i bother you to look at https://code.launchpad.net/~jcsackett/launchpad/filter-private-products-vocabulary/+merge/134542 ?
[19:27] <abentley> deryck: bug #1078410 can be marked invalid and its card deleted, right?
[19:27] <_mup_> Bug #1078410: Embargoed Products are not setup correctly when created <private-projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1078410 >
[19:27] <abentley> deryck: Or were you going to change it to just be about adding embargoed for bugs?
[19:27] <deryck> abentley, well, we need a bug for BugSharingPolicy.EMBARGOED_OR_PROPRIETARY....
[19:27] <deryck> abentley, right
[19:28] <deryck> abentley, or else mark it invalid and add another bug.  either way is fine.
[19:39] <jcsackett> i think rick_h is not here. deryck or abentley, can one of you review https://code.launchpad.net/~jcsackett/launchpad/filter-private-products-vocabulary/+merge/134542 for me?
[19:39] <abentley> jcsackett: On it.
[19:39] <jcsackett> abentley: thanks. :-)
[19:40] <deryck> yeah, thanks, abentley :)
[19:43] <abentley> jcsackett: Is test_search_respects_privacy_no_user actually testing the case of no logged-in-user, or an arbitrary one?  I could have sworn setUp gave us the latter.
[19:44] <jcsackett> the former.
[19:45] <jcsackett> abentley: it actually looks like the setUp for this testcase doesn't cover an arbitrary user either, but no user vs no user with rights shouldn't be different given the filter clause.
[19:51] <abentley> jcsackett: Please add a descriptive comment to your tests.  Other than that, r=me.
[19:51] <jcsackett> abentley: you got it. thanks.
[20:58] <jcsackett> deryck: can you think of anyway that you would be searching for a milestone where you wouldn't have access to the product? i think all of the milestone access points require you to already access the product.
[20:59] <jcsackett> been reading through the milestone tests and callsites, and i don't see anything that violates that idea...but a second opinion is welcome.
[21:00] <jcsackett> actually, i'll just open the above question up to anyone.
[21:01] <deryck> yeah, sinzui would absolutely know that. :)  But there is the project group milestone case.
[21:01] <deryck> jcsackett, so you could have access on a group and the group's milestone but an individual project could be private
[21:02] <deryck> I think this is handled already though
[21:02] <jcsackett> by group you mean projectgroup, right?
[21:03] <jcsackett> deryck: yeah, i think that's handled, and i don't believe it's using the MilestoneVocabulary.
[21:03] <sinzui> I think abentley addressed the cases where milestones from a private project are filtered when instantiating ProjectGroupMilestones
[21:03]  * sinzui looks on qastaging for early tests
[21:03] <deryck> right, he did, IIRC
[21:03] <deryck> jcsackett, and yeah I meant projectgroup.  I was lazy typing. :)
[21:04] <deryck> jcsackett, and I agree, I can't think of any case where you'd be using the vocab and not have project access.
[21:04] <jcsackett> deryck: ok, i think i'll move this card out of in progress then, as i think there's no further work to be done.
[21:04] <deryck> nice!
[21:04] <deryck> cards are dropping like that all over today. :)
[21:05] <jcsackett> i'm not sure if rick_h knows it, but we're having a race.
[21:05] <jcsackett> because he doesn't know it, i think i have a competitive advantage. which is just as well, as it's the only way i'll win. :-P
[21:10] <deryck> jcsackett, I always go for the win, whether the opponent knows it or not. :)
[21:10] <jcsackett> deryck: :-P
[21:54] <wgrant> deryck: Hi, have you verified the future scaling performance of your bug search changes?
[21:54] <deryck> wgrant, no, I have not.  Are you concerned?
[21:54] <wgrant> deryck: Very
[21:54] <deryck> wgrant, and hi, btw.
[21:55] <wgrant> The work we did earlier in the year was to *eliminate* joins, but this adds three or four more
[21:55] <wgrant> And it's to handle a circumstance that probably shouldn't ever exist
[21:55] <wgrant> So it seems like a lot of risk for minimal gain
[21:56] <deryck> wgrant, yeah, I did consider the extra join could cause problems.  I was going to be careful in qa and if it looked risky back it out.
[21:57] <wgrant> Well, it *is* risky and it *will* cause some problems eventually, but it's difficult to say on qastaging as bug search timeouts there are often dismissed as cold cache
[21:57] <wgrant> But I would be extremely wary about making this change
[21:58] <deryck> wgrant, ok, fair points.  I wouldn't dismiss timeouts as cold cache, FWIW.  I usually look at an OOPS and see what it tells me.  And compare to staging oops even.
[21:58] <wgrant> The bug search queries were redesigned and tweaked for performance, so making unnecessary changes which quadruple the number of considered tables needs to be considered and tested very carefully
[21:59] <deryck> wgrant, I've been a bit nervous about this change anyway. for that same reason.  and stuff I saw in tests had me nervous too.
[21:59] <deryck> wgrant, so I'm fine to just revert for paranoia's sake.
[21:59] <sinzui> Why are we search for impossible data? privacy is transitive, you cannot ever have public data in a confidential container.
[22:00] <deryck> well it will be impossible.  it's not currently.
[22:00] <wgrant> Right, so it sounds like it should be reverted
[22:01] <sinzui> I think we can fix the data faster than writing code...I bet it can be run in 2.5 seconds in sql by webops
[22:01] <deryck> yeah, agreed.
[22:01] <wgrant> (though we really should have been enforcing the privacy invariants before rolling out the beta, it's pretty easy to fix up later)
[22:01]  * sinzui would do the same with his current bug if he could workout what the right state is :(
[22:01] <wgrant> sinzui: Which bug is this?
[22:02] <sinzui> wgrant, https://bugs.launchpad.net/launchpad/+bug/1077351
[22:02] <_mup_> Bug #1077351: SourcePackageRecipeBuild:+index LocationError build <oops> <recipe> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1077351 >
[22:02] <wgrant> Aha
[22:02] <sinzui> I wanted to make the three items be build failed/success, but I need to look for evidence of success
[22:02] <deryck> wgrant, I'm about to go offline for some family stuff.  but I'll revert when I get back tonight.
[22:03] <deryck> wgrant, if you get anxious about it, I don't care if you revert it.
[22:03] <wgrant> Well, there's some interesting stuff I'd like to deploy this morning, so I might revert it now
[22:03] <deryck> wgrant, sure, feel free.  sorry about that.  just don't have the time to hang around now.
[22:03] <wgrant> np
[22:04] <deryck> later, everyone.
[22:36] <wgrant>  whaawmp        | 0.2.10.1-py24 | 32517 |   899
[22:36] <wgrant> StevenK: ^^
[22:39] <wgrant> SELECT product.name, milestone.name, productrelease.id, COUNT(*) FROM product JOIN milestone ON milestone.product = product.id JOIN productrelease ON productrelease.milestone = milestone.id JOIN productreleasefile ON productreleasefile.productrelease = productrelease.id GROUP BY product.id, milestone.id, productrelease.id ORDER BY COUNT(*) DESC LIMIT 200;
[23:01] <bigjools> good morning
[23:02] <sinzui> wgrant, are my qa instructions sane: https://code.launchpad.net/~sinzui/launchpad/publishbinary-without-publications/+merge/134527