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? | 00:53 |
---|---|---|
wgrant | cjwatson: They're not meant to actually be up | 01:01 |
cjwatson | OK, I will pretend I didn't see them | 01:01 |
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:06 |
cjwatson | Commented out in upgrade-dogfood-launchpad, and indeed I haven't seen it running | 01:07 |
=== gary_poster is now known as gary_poster|away | ||
adeuring | good morning | 08:58 |
stub | How are we going with LP on Precise? Wondering if I need to back port something | 09:43 |
wgrant | stub: We have no immediate plans to upgrade prod | 09:44 |
wgrant | It'll be next year some time | 09:45 |
=== almaisan-away is now known as al-maisan | ||
czajkowski | adeuring: morning any advice on https://answers.launchpad.net/launchpad/+question/214223 | 10:35 |
* adeuring is looking | 10:48 | |
=== al-maisan is now known as almaisan-away | ||
czajkowski | adeuring: thank you | 11:17 |
=== jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On Call Reviewer: jcsackett | Firefighting: - | Critical bugs: ~200 | ||
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:33 |
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:34 |
wgrant | The problems arise when something is *less* private than its parent | 13:35 |
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:38 |
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:39 |
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:40 |
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:42 |
wgrant | Indeed | 13:43 |
deryck | jcsackett, ping for standup | 14:31 |
jcsackett | deryck: having plus problems--restarting the plugin. be there in moments. | 14:32 |
deryck | jcsackett, no worries | 14:32 |
deryck | abentley, adeuring, rick_h, jcsackett let's try http://tinyurl.com/orange-standup | 14:34 |
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 | 14:35 |
sinzui | jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/missing-potmsgset/+merge/134483 | 15:18 |
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:31 |
adeuring | rick_h: no, there is no bug or oops. I simply looked for methods that return products | 15:32 |
rick_h | adeuring: ok cool | 15:33 |
adeuring | rick_h: might be even worth to check if this method is used at all ;) | 15:33 |
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:34 |
* sinzui thinks project groups listing project work fine now | 15:35 | |
rick_h | yep, should be good awesome card! :) | 15:36 |
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:43 |
maxb | ooi, what is the status of Barry's Lucid Python 2.7 PPA? Is that something LP is still looking at using? | 15:45 |
=== deryck is now known as deryck[lunch] | ||
jcsackett | abentley: you around, or off at lunch? questions from your MP. | 17:20 |
jcsackett | abentley: comments left on MP. | 17:24 |
sinzui | jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/publishbinary-without-publications/+merge/134527 | 17:26 |
jcsackett | sinzui: you caught me just in time. :-) yeah, it's short enough i can take a look. | 17:27 |
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:29 |
jcsackett | you're welcome. :-) | 17:30 |
* jcsackett lunches | 17:30 | |
=== deryck[lunch] is now known as deryck | ||
=== yofel_ is now known as yofel | ||
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:43 |
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:44 |
deryck | grrr, it fails faster than I can force and land my branch. something seems borked now. | 18:47 |
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:49 |
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:52 |
abentley | jcsackett: Yes, I was on lunch. Thanks for the review. | 18:53 |
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:25 |
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:27 |
deryck | abentley, or else mark it invalid and add another bug. either way is fine. | 19:28 |
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:39 |
deryck | yeah, thanks, abentley :) | 19:40 |
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:43 |
jcsackett | the former. | 19:44 |
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:45 |
abentley | jcsackett: Please add a descriptive comment to your tests. Other than that, r=me. | 19:51 |
jcsackett | abentley: you got it. thanks. | 19:51 |
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:58 |
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. | 20:59 |
jcsackett | actually, i'll just open the above question up to anyone. | 21:00 |
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:01 |
deryck | I think this is handled already though | 21:02 |
jcsackett | by group you mean projectgroup, right? | 21:02 |
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:03 |
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:04 |
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:05 |
deryck | jcsackett, I always go for the win, whether the opponent knows it or not. :) | 21:10 |
jcsackett | deryck: :-P | 21:10 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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. | 21:59 |
deryck | well it will be impossible. it's not currently. | 22:00 |
wgrant | Right, so it sounds like it should be reverted | 22:00 |
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:01 |
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:02 |
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:03 |
deryck | later, everyone. | 22:04 |
=== jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~200 | ||
wgrant | whaawmp | 0.2.10.1-py24 | 32517 | 899 | 22:36 |
wgrant | StevenK: ^^ | 22:36 |
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; | 22:39 |
bigjools | good morning | 23:01 |
sinzui | wgrant, are my qa instructions sane: https://code.launchpad.net/~sinzui/launchpad/publishbinary-without-publications/+merge/134527 | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!