| wgrant | wgrant@mawson:~/lp$ bzr branch lp:launchpad/devel | 02:26 |
|---|---|---|
| wgrant | You have not informed bzr of your Launchpad ID, and you must do this to | 02:26 |
| wgrant | write to Launchpad or access private data. See "bzr help launchpad-login". | 02:26 |
| wgrant | bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/+branch/launchpad/devel": no supported schemes | 02:26 |
| wgrant | That's not meant to happen. | 02:26 |
| wgrant | Interesting. | 02:26 |
| wgrant | lp:launchpad works fine. | 02:26 |
| wgrant | Oh, there is no devel series. | 02:28 |
| wgrant | Still, unobvious error :( | 02:28 |
| StevenK | File a nastygram? | 02:28 |
| wgrant | wallyworld__: So, what are you up to on our first day of featureness? | 02:29 |
| wallyworld__ | wgrant: digesting all the material, mockups etc. working on the picker display bug. musing about horrible query used to populate picker | 02:31 |
| wgrant | wallyworld__: Yeah, I was going to look at that vocab and try to work out what we can do to it. | 02:31 |
| wallyworld__ | you? | 02:31 |
| wgrant | Since it needs a bit of work. | 02:31 |
| wgrant | And vaguely pondering UI. | 02:31 |
| wallyworld__ | should be an interesting sprint | 02:32 |
| huwshimi | wgrant, wallyworld__: Have you guys started working on disclosure stuff now? | 02:32 |
| wgrant | huwshimi: Yup. | 02:32 |
| huwshimi | wgrant: nice | 02:33 |
| wgrant | We'll soon see about that. | 02:34 |
| huwshimi | wgrant: Whether it's nice? | 02:40 |
| wgrant | Right, it is probably going to be a bit of a mess, at least to start :) | 02:40 |
| huwshimi | wgrant: And you won't have as much opportunity to contribute to the pie | 03:03 |
| wgrant | huwshimi: Indeed. | 03:04 |
| === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:213 - 0:[#####=__]:256 | ||
| === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:213 - 0:[######=_]:256 | ||
| lifeless | wgrant: so, critical bugs & bar charts | 04:09 |
| lifeless | wgrant: jmls challenge is at best a proxy for flacostes goal. | 04:10 |
| lifeless | wgrant: I'm charting flacostes goal: which was no open criticals | 04:10 |
| lifeless | gnuoy: your irc client is bouncing. Can has fix? | 04:10 |
| wgrant | lifeless: I thought it was to eliminate the backlog. | 04:11 |
| wgrant | But OK. | 04:11 |
| lifeless | wgrant: if we are at 5 (the current escalated count) come dublin, I'm --sure-- everyone will be ecstatic and pies will happen | 04:12 |
| wgrant | Heh | 04:12 |
| lifeless | I'll be happy if we're in the 10-20 range | 04:12 |
| wgrant | It is just somewhat demotivating to have the countdown regress when there's nothing we can do about it. | 04:12 |
| lifeless | uhm | 04:13 |
| lifeless | I hate to demotivate | 04:13 |
| lifeless | but francis is not letting every escalation through | 04:13 |
| wgrant | Ah, I see. | 04:13 |
| lifeless | and | 04:13 |
| wgrant | That's not been clear previously. | 04:13 |
| lifeless | he even unescalated one the other day | 04:14 |
| wgrant | I saw that. | 04:14 |
| lifeless | the target-to-project one | 04:14 |
| lifeless | concretely, we (the team) control what ones we're willing to escalate | 04:14 |
| lifeless | hmmm | 04:15 |
| lifeless | can I be bother kickbanning gn | 04:15 |
| lifeless | uoy | 04:15 |
| wgrant | Well, we have a room full of pingable people. | 04:15 |
| wgrant | LOSA ping :P | 04:15 |
| mbarnett | heya wgrant. | 04:19 |
| lifeless | wgrant: whats bug 78436 really about ? | 04:19 |
| _mup_ | Bug #78436: Careful publishing approach doesn't work <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/78436 > | 04:19 |
| wgrant | mbarnett: gnuoy was bouncing, but appears to have stopped now. | 04:20 |
| wgrant | lifeless: Do you understand what a careful publishing run is? | 04:20 |
| lifeless | wgrant: never heard of it until the summary in that bug | 04:20 |
| * mbarnett likes when things stop | 04:21 | |
| StevenK | mbarnett: No fair enclosing gnuoy's laptop in a Faraday cage. | 04:21 |
| wgrant | lifeless: The -C, -P, -A, -D options to publish-distro cause its various stages to become "careful". That means they run completely from scratch -- they don't just process pending data like a normal run. | 04:22 |
| wgrant | lifeless: For something the size of the primary archive this can take a Long Time. | 04:22 |
| wgrant | eg. -P causes all the package files to be republished, and took nearly 24 hours to do maverick on DF. | 04:22 |
| wgrant | I think the MemoryError is long-fixed. | 04:23 |
| lifeless | do you mean the Packages files or deb & sources ? | 04:23 |
| lifeless | because, the former - mmm, should be as-is :P | 04:23 |
| wgrant | Oh, and -A (careful index generation) can't regenerate byte-identical indices for released pockets, so it's not really useful. | 04:23 |
| wgrant | deb & sources | 04:23 |
| wgrant | The actual packages. | 04:23 |
| wgrant | should be as-is? | 04:23 |
| lifeless | wgrant: btw I did some lmirror testing the other day :) | 04:23 |
| wgrant | Oh? | 04:23 |
| lifeless | wgrant: I mean we recreate Packages.,* every run, no? | 04:24 |
| wgrant | lifeless: Not for all suites, but yes. | 04:24 |
| lifeless | lmirror - I think its at 'do some real world testing' stage | 04:24 |
| lifeless | I need to discuss w/ elmo again I think | 04:24 |
| wgrant | You said that a year ago :) | 04:24 |
| wgrant | But yes. | 04:24 |
| wgrant | I think so. | 04:24 |
| lifeless | wgrant: I did, but now I have twox1TB disks for testing | 04:25 |
| lifeless | only problem is my link is -fail- atm | 04:25 |
| wgrant | Ah, excellent. | 04:25 |
| lifeless | also python slow | 04:25 |
| wgrant | PyPy fast :) | 04:25 |
| lifeless | so so slow | 04:25 |
| wgrant | er | 04:25 |
| lifeless | 25% faster overall, and 400% at the tokenisation | 04:25 |
| lifeless | 400% slower that is | 04:26 |
| lifeless | ok, I'm going to nuke that memoryerror bug | 04:26 |
| wgrant | Erk. | 04:26 |
| wgrant | But didn't you have a faster generator-based method? | 04:27 |
| lifeless | that was slower | 04:27 |
| wgrant | Wow. | 04:27 |
| wgrant | OK. | 04:27 |
| lifeless | https://bugs.pypy.org/issue718 | 04:27 |
| lifeless | 300%, 4times | 04:27 |
| wgrant | Self-signed cert ew | 04:28 |
| wgrant | Bad cn, too. | 04:28 |
| lifeless | so an interesting question is | 04:52 |
| lifeless | what auth for internal services | 04:52 |
| lifeless | host based? basic? oauth? | 04:53 |
| * lifeless doesn't really fancy having oauth overhead in every microservice. | 04:53 | |
| lifeless | not to mention the bootstrap complexity for stuff the SSO wants to reference. | 04:53 |
| wgrant | I think bsic. | 04:53 |
| wgrant | +a | 04:53 |
| wgrant | I guess host-based could work, but it has certainly fallen out of favour in the last couple of decades. | 04:54 |
| lifeless | I'm inclined to say hosts + basic (must pass both checks) | 04:54 |
| wgrant | Yeah. | 04:54 |
| lifeless | belt and braces | 04:54 |
| wgrant | I imagine lots of these will be available far more widely than the present librarian, so, yeah. Probably a good thing. | 04:55 |
| lifeless | I can imagine support oauth eventually, optionally | 04:58 |
| lifeless | so hosts + basic, or oauth from anywhere | 04:58 |
| lifeless | but I'm willing to have to retrofit than pay up front | 04:58 |
| wgrant | Authentication on these primarily-private services should be easy to fix. | 04:59 |
| wgrant | zomg | 05:31 |
| wgrant | non-Rabbit lucid_db_lp failure! | 05:31 |
| StevenK | Say it ain't so! | 05:31 |
| lifeless | woo | 05:34 |
| LPCIBot | Project db-devel build #569: ABORTED in 3 hr 9 min: https://lpci.wedontsleep.org/job/db-devel/569/ | 05:34 |
| StevenK | Oh, stop that Jenkins | 05:35 |
| StevenK | Using a slave that I'm trying to destroy is not cool | 05:35 |
| LPCIBot | Project windmill-db-devel build #301: STILL FAILING in 1 min 21 sec: https://lpci.wedontsleep.org/job/windmill-db-devel/301/ | 05:36 |
| === almaisan-away is now known as al-maisan | ||
| nigelb | Hi! I'm trying to figure out how to fix bug 90628. Do I create a new property and use that? | 06:14 |
| _mup_ | Bug #90628: Subscribers to a spec are randomly arranged <easy> <lp-blueprints> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/90628 > | 06:14 |
| lifeless | nigelb: so, I think we show all subscribers | 06:14 |
| lifeless | nigelb: in which case just sort the list in the view is simplest and not unreasonable | 06:14 |
| nigelb | hrm, I tried to figure out the flow of control and got lost ^-^ | 06:15 |
| lifeless | ok, its fugly but starting to come together https://launchpad.net/bugs/90628 | 06:15 |
| _mup_ | Bug #90628: Subscribers to a spec are randomly arranged <easy> <lp-blueprints> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/90628 > | 06:15 |
| lifeless | bahhh | 06:15 |
| lifeless | https://dev.launchpad.net/ArchitectureGuide/ServicesRoadmap | 06:15 |
| nigelb | heh | 06:16 |
| lifeless | nigelb: so - SpecificationView | 06:16 |
| lifeless | lib/lp/blueprints/templates/specification-portlet-subscribers.pt | 06:16 |
| lifeless | which uses context/subscriptions | 06:17 |
| lifeless | which is on model/specification | 06:17 |
| lifeless | as a multiple join | 06:17 |
| lifeless | one was is a new property | 06:17 |
| lifeless | I'd be inclined to move the existing join to _subscriptions | 06:17 |
| lifeless | and make a cachedproperty which eager loads the subscribers and sorts appropriately. | 06:18 |
| nigelb | the one from line 185 in the model? | 06:18 |
| lifeless | yes | 06:18 |
| nigelb | okay, I am getting used to my way around LP codebase. | 06:18 |
| lifeless | wgrant: did you get an oops for bug 786804 | 06:19 |
| _mup_ | Bug #786804: branch scanner fails with MemoryError leaving branch page in intermediate state <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/786804 > | 06:19 |
| nigelb | lifeless: ok, I'll try to figure this out and ask again if I'm lost. | 06:19 |
| wgrant | lifeless: There wasn't one. | 06:20 |
| lifeless | wgrant: >< | 06:20 |
| wgrant | http://launchpadlibrarian.net/72030392/lWzH7ofhPZuORhdAbLi89zRxIV9.txt | 06:20 |
| lifeless | wgrant: isn't it meant to oops ? | 06:20 |
| wgrant | Oh. | 06:20 |
| wgrant | There is one, on the next line. | 06:20 |
| wgrant | 2011-05-19 17:42:47 INFO Job resulted in OOPS: OOPS-1965SMS9 | 06:20 |
| lifeless | thanks | 06:21 |
| StevenK | The OOPS prefix is SMS? Fail. | 06:22 |
| wgrant | Supermirror scanner. | 06:23 |
| wgrant | Not that fail. | 06:23 |
| wgrant | Just old :) | 06:23 |
| nigelb | lifeless: should the join be moved from SQLBase to StormBase? | 06:47 |
| === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:213 - 0:[######=_]:256 | ||
| jtv | huwshimi, hi! Can I trouble you for some UI expertise? | 07:12 |
| huwshimi | jtv: Of course! | 07:12 |
| LPCIBot | Project windmill-db-devel build #302: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-db-devel/302/ | 07:12 |
| jtv | Great. It's about this page: https://dogfood.launchpad.net/ubuntu/oneiric/+localpackagediffs | 07:12 |
| jtv | huwshimi: I'm just setting you up with the privileges you need to see the pertinent parts. | 07:13 |
| jtv | huwshimi: if you have those privileges, you should see a checkbox to the left of each entry. | 07:13 |
| jtv | That checkbox lets the user select specific entries in order to synchronize them. | 07:13 |
| jtv | But that doesn't make sense for ones that are already being synchronized. | 07:14 |
| huwshimi | jtv: Hmmm... don't have any checkboxes | 07:14 |
| LPCIBot | Project windmill-devel build #118: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/118/ | 07:14 |
| StevenK | huwshimi: Are you logged in? | 07:14 |
| jtv | Try reloading. You should just have received the privileges to get them. | 07:14 |
| jtv | Oh, yes, and what Steve said. This is dogfood, a special test server. | 07:15 |
| huwshimi | StevenK: Thanks :) | 07:15 |
| huwshimi | jtv: Still no checkboxes | 07:15 |
| jtv | You do see a table with green package names with "details" widgets, right? | 07:16 |
| jtv | StevenK: might he need anything more than anoint-dogfood-admin? | 07:17 |
| StevenK | I don't think so | 07:18 |
| huwshimi | jtv: yeah | 07:18 |
| StevenK | Perhaps you annoited the wrong user? | 07:18 |
| wgrant | Erm, let's not anoint-dogfood-admin without extreme caution and consideration, please :) | 07:18 |
| === al-maisan is now known as almaisan-away | ||
| jtv | anoint-dogfood-admin huwshimi | 07:18 |
| jtv | Looks right to me. | 07:18 |
| wgrant | Indeed, that is correct. | 07:18 |
| wgrant | Do admins have launchpad.Append, though? | 07:19 |
| wgrant | Wait, it doesn't use launchpad.Append any more... | 07:19 |
| wgrant | needs an archivepermission. | 07:19 |
| * wgrant fixes. | 07:19 | |
| wgrant | (by removing from ~admins and adding to ~ubuntu-core-dev0 | 07:19 |
| jtv | Thanks. | 07:19 |
| wgrant | If the picker loads... | 07:19 |
| wgrant | huwshimi: Should work now. | 07:20 |
| huwshimi | wgrant, jtv: Got it | 07:20 |
| jtv | Great. | 07:20 |
| jtv | Now, to see how I'm signaling that a package is synchronizing (which means there's no point in requesting synchronization), look for "Synchronizing" | 07:21 |
| huwshimi | jtv: Yep | 07:21 |
| jtv | You'll note two things: the checkbox is disabled, and there's a "(Synchronizing)" in italics next to the package name. | 07:21 |
| huwshimi | jtv: Yep | 07:21 |
| jtv | Those are the changes I wanted your feedback on. Very simple, really. | 07:22 |
| jtv | But I wanted to be sure that I'm not causing any distress anywhere by just slapping a bit of extra text into that column. | 07:22 |
| jtv | (Disabling the checkbox seems like a bit of a no-brainer in retrospect, but I played with putting a "please wait" icon in its place) | 07:24 |
| huwshimi | jtv: I think that looks alright. The loading icon is something that should be used if the action happens in a short period of time (and an ajax event that will update the page) | 07:25 |
| jtv | Yes, that's one of the reasons why I ended up not going with that. There's no polling as yet. | 07:25 |
| huwshimi | jtv: yeah | 07:25 |
| huwshimi | jtv: You could have some kind of static icon symbolizing that it is synchronizing | 07:25 |
| jtv | (Another reason is that we don't seem to _have_ a "please wait" icon :) | 07:25 |
| huwshimi | jtv: What is the time scale for the sync | 07:26 |
| huwshimi | > | 07:26 |
| huwshimi | *? | 07:26 |
| jtv | A minute perhaps. | 07:26 |
| StevenK | I doubt it | 07:26 |
| jtv | Possibly much less. | 07:26 |
| StevenK | If it's done via a job, maybe a little bit longer than a minute | 07:27 |
| jtv | The job was to run every minute I believe; though rabbit will make it much faster. | 07:27 |
| jtv | An icon is an interesting idea, but will it be clear enough? | 07:27 |
| jtv | Mind you, this UI is only for a select few experts. But still, the less expertise I add to the requirements the better. | 07:28 |
| huwshimi | jtv: At the very least I would consider adding an ellipsis after "synchronizing" as it is not a permanent state | 07:29 |
| jtv | Would that work well with the parentheses? | 07:30 |
| jtv | (Synchronizing...) | 07:30 |
| huwshimi | jtv: The icon would be an addition, not replacement | 07:30 |
| jtv | oic | 07:30 |
| huwshimi | jtv: I think English allows you to do that | 07:30 |
| jtv | Well yes, it's probably allowed — just asking whether it's nice. :-) | 07:31 |
| huwshimi | jtv: Yeah, I'm not sure | 07:32 |
| jtv | Let me try it. | 07:32 |
| jtv | huwshimi: try reloading the page? | 07:33 |
| jtv | (And I just updated it to use … | 07:33 |
| jtv | ) | 07:33 |
| huwshimi | jtv: Hmm... | 07:34 |
| jtv | Doesn't quite look right, does it? | 07:35 |
| jtv | What if I dropped the parentheses? | 07:35 |
| jtv | foo — synchronizing… | 07:35 |
| huwshimi | jtv: You could try dropping the parentheses, and maybe adding a bit more space between the name and the sync | 07:37 |
| jtv | But no emdash? | 07:37 |
| huwshimi | jtv: Yeah I think so | 07:37 |
| * jtv fiddles | 07:37 | |
| jtv | Oh, and drop the capital letter? | 07:38 |
| huwshimi | jtv: I'm not sure about that | 07:38 |
| jtv | huwshimi: try now | 07:39 |
| huwshimi | jtv: OK, maybe also drop the italics and make it a bit grey? | 07:40 |
| huwshimi | jtv: Actually we do have an icon | 07:43 |
| === stub1 is now known as stub | ||
| huwshimi | jtv: It might be good to add that before the "synchronizing..." | 07:43 |
| huwshimi | jtv: It's a little clock, let me find it | 07:44 |
| jtv | That's the one I was trying to find as well. | 07:44 |
| jtv | It's animated though. | 07:44 |
| jtv | huwshimi: hmm... I worry that an icon there may be a bit distracting. | 07:46 |
| jtv | I've got the space-separated grey text now though. | 07:46 |
| jtv | Looks nice and discreet. | 07:46 |
| huwshimi | jtv: Ugh, the demo text is so distracting | 07:46 |
| wgrant | /@@/processing? | 07:46 |
| StevenK | henninge: Hi! Do you mind reviewing a slightly oversized branch? | 07:47 |
| StevenK | henninge: (833 lines) | 07:47 |
| jtv | Thanks wgrant. I guess animating sprites wasn't a good idea. | 07:47 |
| wgrant | jtv: Quite possibly not. | 07:47 |
| henninge | StevenK: Sure, I'll do it after I finish jtv's branch. | 07:48 |
| jtv | henninge: just a mentoring request :) | 07:48 |
| wgrant | StevenK: Why the change in nascentupload-announcements? | 07:48 |
| henninge | jtv: I know | 07:48 |
| huwshimi | jtv: Actually the one I was looking for turns out to be the milestone icon | 07:49 |
| huwshimi | jtv: So nevermind that | 07:49 |
| jtv | wgrant: /@@/processing isn't working for me I think | 07:49 |
| wgrant | https://launchpad.net/@@/processing works for me... | 07:49 |
| StevenK | wgrant: The first one is just a e-mail change, it doesn't actually send the annoucement -- and I didn't want to special case "Don't set the announce list if dry_run is True" | 07:49 |
| jtv | Hmm | 07:49 |
| StevenK | wgrant: The second one is due to notify() hooking into notify_spr_less() which does far less logging | 07:50 |
| jtv | Ah, I got the syntax all wrong. | 07:50 |
| jtv | Been a while since I used non-sprite images! | 07:50 |
| jtv | huwshimi: got it with the wait icon now | 07:51 |
| jtv | …and now the spaces are on the right side of the icon | 07:52 |
| LPCIBot | Project windmill-db-devel build #303: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-db-devel/303/ | 07:58 |
| jtv | huwshimi: the icon is a bit distracting, isn't it? | 07:58 |
| lifeless | nigelb: generally do just one thing | 08:06 |
| nigelb | okay | 08:06 |
| nigelb | I'm getting so many OOPS because I'm doing it wrong. | 08:06 |
| lifeless | nigelb: so yes, we should move the class including the joins, to storm base. But either do that, or the sort. Don't do both (a change doubled is a risk quadrupled) | 08:06 |
| nigelb | ah, okay. I'll stick with the sort | 08:07 |
| lifeless | nigelb: please feel free to chat here and say 'help, X happened' :) | 08:07 |
| nigelb | okay :) | 08:07 |
| huwshimi | jtv: So there will be a trade-off between how obvious the notification needs to be and how often it will be shown | 08:10 |
| jtv | I suspect it needn't be very obvious. | 08:10 |
| huwshimi | jtv: It will be a short term thing, so maybe a little bit more distracting is ok | 08:11 |
| huwshimi | jtv: In that case it might be fine without it. | 08:11 |
| huwshimi | jtv: This might be a situation where we can release the feature and keep an eye out for feedback | 08:11 |
| huwshimi | jtv: And iterate when we need to | 08:11 |
| jtv | Yes... I suspect people won't care much either way. | 08:12 |
| jtv | For me it's more an explanation for the "hey why can't I sync this?" moment | 08:12 |
| huwshimi | jtv: OK, sure | 08:14 |
| jtv | Then I'll go with what he have: spaces, grey text, ellipsis; no icon, no upper-case, no parentheses. | 08:15 |
| jtv | Thanks for the help! | 08:15 |
| henninge | jtv: r=me | 08:28 |
| jtv | thanks henninge! | 08:28 |
| StevenK | henninge: Do you need the URL for my MP? | 08:30 |
| henninge | StevenK: usually no | 08:31 |
| henninge | ;) | 08:32 |
| henninge | got it | 08:32 |
| lifeless | foodingk | 08:36 |
| wgrant | henninge, StevenK: I have reviewed that MP, but henninge's opinion is also useful given that I don't really exist yet. | 08:38 |
| StevenK | wgrant: :-( | 08:44 |
| StevenK | wgrant: I explained the two test changes on IRC | 08:44 |
| adeuring | good morning | 08:48 |
| jtv | hi adeuring | 08:49 |
| adeuring | hi jtv! | 08:49 |
| wgrant | StevenK: Yeah, but they were in the textbox already and I don't really trust it. | 08:50 |
| huwshimi | jtv: No problems :) | 08:51 |
| huwshimi | jtv: Anytime | 08:51 |
| StevenK | wgrant: You don't trust the textbox, or the changes I made? | 08:52 |
| wgrant | StevenK: That you're not invalidating part of the test. | 08:52 |
| wgrant | You probably aren't. | 08:52 |
| wgrant | But still, I wanted to record my concern. | 08:52 |
| StevenK | wgrant: The first test I had to change is a crook anyway. "If dry_run is specified, we don't send a mail. But oh, let's look for the entire thing, verbatim, in the logs." | 08:54 |
| wgrant | StevenK: I'd expect to see something there, like the "Would have sent a mail" bit. | 08:55 |
| StevenK | And the subject bit is dangerous? | 08:56 |
| StevenK | Er? The old code didn't use packageupload.displayname? | 08:56 |
| wgrant | 287- # Weed out duplicate name entries. | 08:56 |
| wgrant | 288- names = ', '.join(set(packageupload.displayname.split(', '))) | 08:57 |
| wgrant | 298- subject = '[%s/%s] %s %s (%s)' % ( | 08:57 |
| wgrant | 299- packageupload.distroseries.distribution.name, suite, names, | 08:57 |
| wgrant | 300- packageupload.displayversion, message.STATUS) | 08:57 |
| StevenK | Ah | 08:57 |
| mrevell | Hello | 09:01 |
| === a1 is now known as al | ||
| jtv | hi mrevell! | 09:14 |
| === almaisan-away is now known as al-maisan | ||
| * henninge relocates | 09:19 | |
| jtv | wallyworld__: reviewed your branch. A few changes to make. | 09:39 |
| jtv | allenap: do we have a job runner for IPlainPackageCopyJob? | 09:50 |
| allenap | jtv: It gets run by cronscripts/process-job-source-groups.py | 09:51 |
| allenap | jtv: It runs on loganberry every 5 minutes. | 09:51 |
| jtv | Can I run it on dogfood? | 09:51 |
| bigjools | wgrant: hello | 10:02 |
| bigjools | wgrant: can you follow up on Steve's MP that you started to review, I will mentor you. I'm happy with it myself now. | 10:04 |
| jtv | henninge: can I trouble you for another one? https://code.launchpad.net/~jtv/launchpad/db-bug-786822/+merge/61924 | 10:04 |
| jtv | allenap: and another question. When a PlainPackageCopyJob raises CannotCopy, do we know reliably which package the error was for? | 10:08 |
| * allenap looks | 10:09 | |
| allenap | jtv: Only if we parse the exception content. | 10:11 |
| jtv | :( :( :( | 10:12 |
| jtv | May be a good idea to change that then. | 10:12 |
| jtv | So that we may accurately report errors. | 10:12 |
| jtv | I think I'll go grab a bite first though. | 10:13 |
| === jtv is now known as jtv-eat | ||
| allenap | jtv: Yeah, good idea :) | 10:13 |
| LPCIBot | Project windmill-db-devel build #304: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/304/ | 10:20 |
| wgrant | bigjools: Looking. | 10:20 |
| lifeless | mpt: hi | 10:20 |
| mpt | hi lifeless | 10:20 |
| lifeless | mpt: book you might like (or even love) - the innovators solution | 10:21 |
| bigjools | wgrant: thanks | 10:21 |
| lifeless | jml: around? | 10:21 |
| mpt | lifeless, oh yes, I saw your tweet about that | 10:22 |
| lifeless | mpt: cool; evan's post about ~ubuntu-metrics reminded me you would probably get a lot out of (or vigorously agree and say you know it already :P) it | 10:23 |
| lifeless | bigjools: when you say you're not happy about the feature flag do you mean 'its not complete' or 'it shouldn't be flagged'. I don't care which you mean, but I can't *tell* which you mean :) | 10:25 |
| bigjools | lifeless: I was too brief after discussing it with steve, he knows what I mean :) | 10:26 |
| mpt | lifeless, found a copy on the Millbank bookshelves :-) | 10:30 |
| wgrant | bigjools: Done. | 10:31 |
| LPCIBot | Project windmill-devel build #119: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/119/ | 10:32 |
| lifeless | mpt: hah! nice. | 10:34 |
| bigjools | StevenK: you have your answers, go forth and fix0rate | 10:36 |
| lifeless | allenap: bugs fixed | 11:02 |
| allenap | lifeless: Awesome :) | 11:02 |
| lifeless | rev 11 | 11:03 |
| lifeless | bah | 11:03 |
| lifeless | 151 | 11:03 |
| lifeless | or wait for the ppa to pick it up | 11:03 |
| stub | What was the query we wanted to denormalize Revision.revision_date to BranchRevision.revision_date for? | 11:04 |
| lifeless | merge proposal page IIRC | 11:04 |
| lifeless | its in the bugs tagged timeout | 11:05 |
| stub | Why did it want Revision.revision_date instead of using BranchRevision.sequence to filter or order? | 11:05 |
| lifeless | You'll need to have a nosy | 11:06 |
| lifeless | I have paged it out | 11:06 |
| stub | Bug #778393 isn't it | 11:07 |
| _mup_ | Bug #778393: Branch:+index timeouts <dba> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/778393 > | 11:07 |
| stub | I see - Bug #742916 | 11:07 |
| _mup_ | Bug #742916: BranchMergeProposal:+index timeouts - slow query plan <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/742916 > | 11:07 |
| LPCIBot | Project windmill-db-devel build #305: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-db-devel/305/ | 11:08 |
| StevenK | wgrant: You will cope with bpn_archtag? | 11:08 |
| StevenK | wgrant: And how do you want confirmation about partner? | 11:09 |
| wgrant | StevenK: I guess QA on DF would be fine. | 11:10 |
| lifeless | hey allenap | 11:28 |
| lifeless | btw, you've invalidated the test | 11:28 |
| allenap | lifeless: Explain? | 11:28 |
| lifeless | the hunk @@ -28,10 +27,7 @@ | 11:28 |
| lifeless | had explicit connection logic | 11:28 |
| stub | lifeless: I think the query is broken anyway. It is trying to display the set of revisions that were reviewed, between two timestamps. That timestamp is the timestamp when the revision first entered Launchpad - it isn't the timestamp that it landed on the branch being reviewed. | 11:29 |
| lifeless | now its calling a method that could in principle be lazy | 11:29 |
| lifeless | so its not valid anymore | 11:29 |
| allenap | lifeless: Okay, I'll revert that bit. Are you happy with the rest? | 11:29 |
| stub | c/'first entered launchpad'/'system timestamp when the revision was committed to its original branch' | 11:30 |
| allenap | I mean, it's just stuff I twiddled as I read the code. | 11:30 |
| lifeless | allenap: the other functional thing is 'getConnection' - its basically noise | 11:30 |
| lifeless | allenap: because the parameter list including things like require etc will need to be reflected in it | 11:31 |
| lifeless | allenap: which is why I had and then deleted a get_connection method | 11:31 |
| lifeless | allenap: so I'd delete that method | 11:31 |
| === al-maisan is now known as almaisan-away | ||
| LPCIBot | Project db-devel build #570: FAILURE in 5 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/570/ | 11:31 |
| lifeless | allenap: you might want to have it glued in with the lazr.config settings for rabbit | 11:32 |
| stub | Am I mistaken that Revision.revision_date is untrusted data, originating from a remote system timestamp? | 11:32 |
| lifeless | allenap: if you pull in my rabbit branch to get the layer | 11:32 |
| lifeless | stub: it is untrusted, yes | 11:32 |
| lifeless | allenap: other than that its all fine; some minor could-be-done different stuff (e.g. I was going PEP 8 on the methods, leaving stuff that hadn't been migrated uncommented so that when we fix it up the diff is saner) | 11:33 |
| allenap | lifeless: Is there a reason why ExportRabbitServer and RunRabbitServer are split into two? | 11:33 |
| lifeless | allenap: but nothing to sweat about any which way | 11:34 |
| lifeless | allenap: I'm glad you asked. Yes, there is | 11:34 |
| lifeless | allenap: they do different things | 11:35 |
| lifeless | the exporter exports enough to run rabbitctl or rabbit server or both | 11:35 |
| lifeless | you often want to run the former separate from the latter | 11:36 |
| lifeless | allenap: I don't object to it being camelcase, though it is hard on the eyes | 11:37 |
| === matsubara-afk is now known as matsubara | ||
| allenap | lifeless: I'm happy to go PEP8. Our coding standards and actual practice are a bit schizophrenic on the matter. | 11:38 |
| lifeless | oh, one other thing - def start() | 11:40 |
| lifeless | allenap: that looks like its not a public method | 11:40 |
| lifeless | allenap: so its odd for it to be missing the _ | 11:40 |
| allenap | lifeless: I guess stop() isn't either? | 11:40 |
| lifeless | indeed | 11:41 |
| lifeless | that was oversight | 11:41 |
| lifeless | I would change stop to _stop | 11:41 |
| lifeless | I can't see the bugfix you mention | 11:41 |
| lifeless | oh | 11:42 |
| lifeless | also | 11:42 |
| lifeless | fq_nodename is a method because its not cheap to call | 11:42 |
| allenap | lifeless: Re. getConnection, that's just a rename from get_connection. Do you suggest I ditch that altogether and use amqp.Connection everywhere instead, rename it back, or move it elsewhere (ExportRabbitServer doesn't seem like the right place for it now anyway). | 11:42 |
| lifeless | allenap: | 11:43 |
| lifeless | + def getConnection(self): | 11:43 |
| lifeless | + return self.server.getConnection() | 11:43 |
| allenap | lifeless: Is gethostname() really that expensive? | 11:43 |
| lifeless | allenap: that one isn't a rename | 11:43 |
| allenap | lifeless: Okay, yeah, I'll ditch that. | 11:43 |
| allenap | lifeless: The bugfix is actually in the prerequisite branch. This is a bit of a muddle :-/ | 11:45 |
| allenap | lifeless: It wasn't sleeping when calling check_running during start-up. | 11:46 |
| allenap | lifeless: Also, the reason I went camelCase is because of Fixture.setUp(). | 11:48 |
| lifeless | yeah, thats in the fixture protocol, a bit sadly | 11:48 |
| lifeless | its camelcase because of TestCase.setUp | 11:48 |
| allenap | Yeah, I assumed as much. | 11:48 |
| lifeless | but, FWIW, I use PEP8 everywhere else in the fixtures library | 11:48 |
| lifeless | anyhow, this is ok as is, everything is changable if needed :P | 11:49 |
| lifeless | I'm glad you're digging into it | 11:49 |
| lifeless | I think you should do what you think is best | 11:50 |
| lifeless | the only thing that really matters is the test actually showing what its testing | 11:51 |
| allenap | lifeless: Thanks, and I'll try not to make so many cock-ups in future :) | 11:51 |
| LPCIBot | Project windmill-db-devel build #306: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-db-devel/306/ | 11:54 |
| lifeless | allenap: hah no worries :) | 11:54 |
| lifeless | allenap: have you had a chance to look at the layer patch? | 11:55 |
| allenap | lifeless: Briefly, that's all, but I have it on the list. | 11:55 |
| lifeless | cool | 11:55 |
| stub | jtv-eat: http://paste.ubuntu.com/611779/ is the diff of a launchpad schema dump before and after applying my current 'Drop BranchRevision.id' patch. It all looks healthy so far. | 11:59 |
| stub | jtv-eat: https://code.launchpad.net/~stub/launchpad/drop-branchrevision-id/+merge/55480 has the db patch at the bottom, not much simpler. The existing UNIQUE constraint is a big help, not a hindrance. | 12:01 |
| bigjools | anyone else getting bzrlib.errors.ReadOnlyError when doing "bzr up" in download-cache? | 12:14 |
| wgrant | Sure it was bzr up and not bzr pull? | 12:16 |
| bigjools | yes | 12:18 |
| bigjools | rf-get is falling over and I've not changed that ;) | 12:18 |
| jml | lifeless: sorry. | 12:21 |
| StevenK | bigjools: henninge was | 12:21 |
| henninge | yes, I was. | 12:21 |
| bigjools | did you file a bug henninge? | 12:21 |
| henninge | I forgot but I can still do it. | 12:22 |
| bigjools | ok | 12:22 |
| bigjools | I have a fresh crash file | 12:22 |
| henninge | bigjools: I don't ;) | 12:23 |
| henninge | bug I can make one | 12:23 |
| bigjools | well apport says bzr is not a genuine Ubuntu package here :) | 12:23 |
| henninge | StevenK: Sory about your MP, btw. I just don't feel up to it atm. | 12:23 |
| StevenK | henninge: It's perfectly fine, wgrant has already written me a novel | 12:25 |
| henninge | weired, I cannot reproduce it on this computer | 12:25 |
| * henninge tries laptop again | 12:25 | |
| henninge | s/weired/weird/ | 12:25 |
| === jtv-eat is now known as jtv | ||
| jtv | stub: ah yes, you don't have to invert the dependency like we do when we start with an index, right? (Going from memory; hope to look deeper later) | 12:29 |
| stub | jtv: Yup. The pg_depends stuff seems identical for a unique and a primary key index, so just changing the type in pg_constraint seems to work fine. | 12:34 |
| stub | jtv: Claim that MP review if you want to double check the work. | 12:35 |
| * jtv wonders if unique and primary-key constraints wouldn't be easier if they merely enforced the existence of a suitable index. | 12:35 | |
| stub | I've just pushed updated sampledata and set the MP status to needs review. | 12:35 |
| jtv | stub: err ok | 12:35 |
| stub | jtv: I think that would help, yes. | 12:36 |
| jtv | Just going through review fin/ack for Ian, and checking up on one of my own. | 12:37 |
| stub | jtv: Sure. No need to do it now. I do want it on staging though, so if you can't check it over tomorrow I'll land it r=stub and we can inspect what happens on real data. | 12:38 |
| jtv | But yes, I should go over it definitely and decide whether I need plastic surgery, spare passport etc. | 12:38 |
| jtv | stub: maybe want to walk me through it IRL? Just an idea. | 12:39 |
| stub | Sure. | 12:39 |
| === almaisan-away is now known as al-maisan | ||
| nigelb | okay, take 3 at fixing the specification ordering bug. | 12:49 |
| jml | :) | 12:50 |
| === henninge is now known as henninge-lunch | ||
| nigelb | okay, what is subscription and subscribers in lp/blueprint/model/specifications.py | 12:58 |
| nigelb | I can't figure out how they're different. | 12:58 |
| nigelb | so, this is what life less told me earlier today on fixing this. | 13:04 |
| nigelb | http://pastebin.ca/2067555 | 13:04 |
| === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge, benji | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:213 - 0:[######=_]:256 | ||
| nigelb | can I just move the query onto specificationsubscription.py and will it Just Work? | 13:05 |
| jml | nigelb: 'subscriptions' is a result set of SpecificationSubscription objects | 13:06 |
| jml | nigelb: 'subscribers' is a result set of Person objects | 13:06 |
| nigelb | jml: ah. | 13:06 |
| jml | ffs | 13:06 |
| jml | my mobile phone operator needs to check my age :\ | 13:06 |
| nigelb | did they give you free texts for a month? | 13:07 |
| nigelb | :P | 13:07 |
| nigelb | okay, I find to find the person who tagged the bug I'm working easy :/ | 13:08 |
| nigelb | This is my third attempt and I'm going no where :( | 13:08 |
| jml | nigelb: I can't view that paste. sorry. | 13:09 |
| jml | nigelb: what are you trying to do? | 13:09 |
| nigelb | jml: I'm trying to fix bug 90628 | 13:10 |
| _mup_ | Bug #90628: Subscribers to a spec are randomly arranged <easy> <lp-blueprints> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/90628 > | 13:10 |
| jml | nigelb: how are you trying to do it? | 13:11 |
| nigelb | http://irclogs.ubuntu.com/2011/05/23/%23launchpad-dev.html#t06:14 | 13:11 |
| nigelb | there ^^ that way. | 13:11 |
| jml | nigelb: thanks. | 13:13 |
| jml | nigelb: so, you are trying to order the subscribers on the web page by changing the ordering of Specification.subscriptions? | 13:13 |
| nigelb | jml: yeah, and failing of course :) | 13:14 |
| jml | nigelb: do you understand what lifeless meant by "cached property"? | 13:14 |
| nigelb | they way the subscription is done seems vastly different from how the sprint was. | 13:14 |
| nigelb | isnt the one with a @cachedproperty wrap? | 13:15 |
| nigelb | *isn't it | 13:15 |
| jml | nigelb: exactly. | 13:15 |
| jml | nigelb: lifeless was saying, "rename ISpecification.subscriptions to ISpecification._subscriptions" | 13:15 |
| jtv | bigjools: did you say that the Version(x) < Version(y) is not the right way to compare versions in a DSD? | 13:15 |
| jml | nigelb: and then add a new property called "subscriptions" | 13:15 |
| nigelb | oh | 13:15 |
| jml | nigelb: this new property should just return _subscriptions, but sort it first. | 13:15 |
| nigelb | jml: okay, let me see if I can get that bit. | 13:17 |
| benji | gary_poster: I didn't see that one; I made one specifically for the bug; | 13:26 |
| benji | I'm also in the wrong chan. | 13:26 |
| gary_poster | :-) | 13:26 |
| nigelb | Is there an easier way to clear cache other than stopping and starting LP? | 13:26 |
| lifeless | jml: sorry? | 13:29 |
| wgrant | nigelb: Which cache? The code cache? | 13:29 |
| nigelb | wgrant: well, I changed the code, isn't reflecting on refresh, I presume its cached | 13:29 |
| lifeless | jml: you might like to cast your eye over the 'wiki' lep. I suspect its a little gung ho without enough thought about the end product & what we want out of it | 13:30 |
| wgrant | nigelb: Right, the appserver doesn't reload code, because in Python that doesn't really work. | 13:30 |
| lifeless | jml: other than that I was going to propose a catchup at your convenience | 13:30 |
| nigelb | wgrant: so restart LP? :) | 13:30 |
| wgrant | nigelb: I tend to run 'bin/run -r librarian -i development' directly, since make run takes forever. | 13:30 |
| wgrant | Right. | 13:30 |
| nigelb | oh | 13:31 |
| nigelb | I don't have to do make run every time? :O | 13:31 |
| lifeless | wgrant: s/doesn't really work/really doesn't work/ | 13:31 |
| nigelb | (and yeah, it does take forever) | 13:32 |
| === Ursinha-afk is now known as Ursinha | ||
| wgrant | nigelb: Our Makefile sort of sucks, so it rebuilds far more than necessary. | 13:33 |
| nigelb | \o/ It works! | 13:33 |
| nigelb | lifeless, jml: Thanks :) | 13:33 |
| wgrant | nigelb: Run 'make jsbuild' if you make JS changes, make something else if you make CSS changes, otherwise just use bin/run. | 13:33 |
| nigelb | oh, wait. I need to write tests. | 13:34 |
| lifeless | nigelb: there will be tests already | 13:34 |
| lifeless | nigelb: you just need to update htem | 13:34 |
| nigelb | whee, so just run all the tests, something will fail, fix them :D | 13:34 |
| nigelb | hrm, I don't see any tests testing the sort order. | 13:36 |
| lifeless | bin/test -vvt blueprints | 13:37 |
| lifeless | I bet something will fail | 13:37 |
| jml | lifeless: yeah. | 13:40 |
| jml | lifeless: I'm unwell today, so maybe tomorrow morning UK time? | 13:41 |
| lifeless | sure | 13:41 |
| lifeless | get well soon | 13:41 |
| nigelb | I guess it will take a while. Tests running. | 13:44 |
| lifeless | night y'all | 13:45 |
| wgrant | nigelb: blueprint doesn't have that many tests. | 13:46 |
| wgrant | Which may be a good or a bad thing :) | 13:46 |
| nigelb | night lif | 13:47 |
| nigelb | night lifeless | 13:47 |
| nigelb | wgrant: heh | 13:47 |
| nigelb | wgrant: I fear doctests. | 13:47 |
| === Ursinha is now known as Ursinha-afk | ||
| wgrant | Everybody does. | 13:48 |
| === Ursinha-afk is now known as Ursinha | ||
| nigelb | I'm glad I have company. | 13:48 |
| nigelb | Oh, well. Something did fail. | 13:52 |
| nigelb | Of course, doctests. | 13:52 |
| bigjools | jtv: right, you need to use apt_pkg.VersionCompare() | 13:59 |
| jtv | bigjools: touché—I already implemented it. :) | 13:59 |
| deryck | Hi adeuring and henninge-lunch. Running just a minute or two late for our standup. | 14:00 |
| deryck | Morning everyone else! :-) | 14:00 |
| jtv | bigjools: the hard part for tracking errors, I think, is finding the DSD that matches a PlainPackageCopyJob. After all some PPCJs may not be related to DSDs. | 14:00 |
| jtv | hi deryck | 14:01 |
| bigjools | jtv: gavin added extra columns to the PCJ table to support querying. I'd get all jobs and match what you can. | 14:02 |
| jtv | Yes, I suppose. It's not a very critical path, since it's an error case in an offline process. | 14:02 |
| bigjools | jtv: when I say get all jobs, get all jobs for that archive/distroseries, then sift the json_data | 14:04 |
| jtv | Yes I wasn't thinking of getting _all_ all jobs, thank you :) | 14:05 |
| bigjools | jtv: just clarifying :) | 14:05 |
| henninge-lunch | deryck: stand up over? | 14:06 |
| === henninge-lunch is now known as henninge | ||
| deryck | henninge, no, still in progress | 14:06 |
| henninge | deryck: wating for my laptop to boot | 14:06 |
| henninge | oh, standby | 14:06 |
| bigjools | henninge: did you report that bug? | 14:10 |
| henninge | bigjools: no yet, sorry. otp now | 14:11 |
| bigjools | henninge: I'll do it | 14:11 |
| henninge | bigjools: ok | 14:11 |
| henninge | bigjools: we had noticed that the failing branch had the same parent branch with a different url | 14:11 |
| bigjools | henninge: https://code.launchpad.net/~launchpad/lp-source-dependencies/trunk ? | 14:12 |
| henninge | bigjools: whereas the new, working checkout does not have a parent branch at all. | 14:12 |
| henninge | yeah | 14:12 |
| bigjools | henninge: what new checkout? | 14:12 |
| henninge | bigjools: http://paste.ubuntu.com/611718/ | 14:13 |
| henninge | bigjools: I worked around it by creating a new checkout of lp-source-dependencies/trunk | 14:13 |
| henninge | the paste ^ is the broken one. | 14:13 |
| bigjools | henninge: my broken one has no parent | 14:13 |
| henninge | so that is not related ... | 14:14 |
| gary_poster | deryck, hi! When you get a chance, I'd love to chat about CHR to get hints and clues | 14:15 |
| henninge | bigjools: what's your bzr version | 14:17 |
| bigjools | 2.3.3 | 14:17 |
| henninge | me, too. | 14:17 |
| henninge | The bug does not appear to be in 2.3.1 | 14:17 |
| deryck | gary_poster, sure. Just finishing standup. Let me close out notes and then we can chat anytime. | 14:18 |
| gary_poster | cool thanks a lot deryck | 14:18 |
| henninge | bigjools: I have that on my desktop machine and a copy of the "broken" branch and it's not failing. | 14:18 |
| bigjools | henninge: https://bugs.launchpad.net/bzr/+bug/786980 | 14:18 |
| _mup_ | Bug #786980: bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction <Bazaar:New> < https://launchpad.net/bugs/786980 > | 14:18 |
| henninge | bigjools: thanks, I'll comment there | 14:19 |
| bigjools | henninge: oh well :/ | 14:19 |
| bigjools | I'll make a new checkout then | 14:19 |
| deryck | adeuring, bug 739075 is still InProgress but you're done on that, right? | 14:20 |
| _mup_ | Bug #739075: Person:+questions timeouts <qa-ok> <question> <timeout> <users> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/739075 > | 14:20 |
| adeuring | deryck: yes, that should be "fix committed", if not fix released | 14:20 |
| deryck | adeuring, awesome, thanks | 14:21 |
| deryck | adeuring, it's db-stable stuff, so committed not released. | 14:21 |
| adeuring | well, it's not "fix released": requires a DB schema change... | 14:21 |
| jtv | allenap, bigjools (in alphabetical order): errors from package copy jobs need to appear to come from a Launchpad user. Is there a user identity that properly represents the package copier? | 14:22 |
| bigjools | jtv: no, we need to get the requesting user from somewhere | 14:25 |
| jtv | bigjools: I thought it'd be more intuitively accurate to have "Launchpad" make the comment, and also help prevent confusion over manually pasted messages vs. automatically generated ones. | 14:26 |
| bigjools | jtv: it would be better to show who caused the problem, then you can talk to them., | 14:27 |
| bigjools | we can make it look obviously auto-generated in other ways | 14:27 |
| jtv | Yes, that'd be nice too. But showing them as the actual person making the comment seems a bit too much of a good thing to me. | 14:27 |
| jtv | We can, but AFAICS that means adding schema. | 14:27 |
| jtv | (Not saying that's a problem, just a thing to keep in mind) | 14:28 |
| bigjools | jtv: well there's a "launchpad" celeb | 14:28 |
| bigjools | oh wait that's a project | 14:29 |
| bigjools | the mild-mannered launchpad janitor? | 14:29 |
| jtv | The janitor cleans things up. Not the person people would look to as a spokesperson for industrial processes. | 14:35 |
| deryck | gary_poster, I can chat now. Or whenever you like from here on out. | 14:40 |
| gary_poster | deryck, now would be great thanks | 14:41 |
| gary_poster | skype or mumble? | 14:42 |
| deryck | gary_poster, lets mumble! | 14:42 |
| bigjools | henninge: ok so there's a workaround that doesn't require a re-checkout | 14:42 |
| bigjools | use bzr switch lp:lp-source-dependencies | 14:42 |
| nigelb | bah, doctests giving me random failures :( | 14:42 |
| StevenK | nigelb: Such as? | 14:43 |
| nigelb | StevenK: part of the test which exploded http://paste.ubuntu.com/611854/ | 14:44 |
| sinzui | jcsackett: do you have time to mumble? | 14:44 |
| jcsackett | sinzui: i was just about to ask you that very question. | 14:44 |
| StevenK | nigelb: "The joys of doctests." | 14:45 |
| nigelb | StevenK: Hah. I know! | 14:45 |
| StevenK | TALES does not love you, given that traceback | 14:45 |
| jcsackett | sinzui: can you hear me? | 14:45 |
| jcsackett | i cannot hear you, though i see that you are talking. | 14:46 |
| sinzui | I ead you | 14:46 |
| sinzui | heard | 14:46 |
| nigelb | StevenK: how do I fix that? :( | 14:47 |
| StevenK | nigelb: It looks like context/@@+portlet-subscribers is the issue | 14:48 |
| StevenK | And given you changed subscribers ... | 14:48 |
| nigelb | yeah, I did | 14:48 |
| nigelb | let met get you my branch's diff on LP | 14:48 |
| nigelb | *me | 14:48 |
| nigelb | StevenK: My diff that caused the explosion :) http://bazaar.launchpad.net/~nigelbabu/launchpad/90628-spec-sub/revision/13102 | 14:58 |
| === al-maisan is now known as almaisan-away | ||
| deryck | henninge, you're not in a hurry for your review, right? Since you're OCR. I'm just burning down a couple open tasks and then will turn to it, if that's ok. | 15:01 |
| henninge | deryck: go, burn'em! | 15:02 |
| * deryck lights a fire | 15:02 | |
| LPCIBot | Project windmill-db-devel build #307: STILL FAILING in 1 hr 17 min: https://lpci.wedontsleep.org/job/windmill-db-devel/307/ | 15:03 |
| === almaisan-away is now known as al-maisan | ||
| deryck | sinzui, even though I'm a crybaby about project review, I do give you mad props from the new interface.... | 15:03 |
| deryck | sinzui, it's a million-hundred-thousand-and-two times better than it used to be. :-) | 15:04 |
| sinzui | deryck: You should withhold props. I realised after I landed the UI that the license_approved field is smart and will change the project_reviewed field to true, but you do not see that in the UI :( | 15:06 |
| deryck | sinzui, ah! That is nicer still! So we only have to mark the license approved in the web UI? | 15:07 |
| deryck | sinzui, but I guess the list won't change for us to know what's left until that's fixed. | 15:07 |
| deryck | still it's a nice improvement for ye days of old. | 15:07 |
| deryck | s/for/from/ | 15:07 |
| sinzui | The list will change after you reload, the item does fall off the list. I think I need to add a callback to update the state the of other field in the ui. | 15:08 |
| deryck | ah, ok | 15:09 |
| deryck | sinzui, that's good to know thanks! | 15:09 |
| sinzui | deryck: I chose to not remove the entry from the list after I changed the status because I was unsure of how to find the project if I make a mistake. Maybe we do not make mistakes often enough to care | 15:10 |
| sinzui | nigelb, most tests is stories are rubbish.Most tests think they are testing the view and model code. A story test should be written from a user's perspective. It is an acceptance tests that demonstrates the user can accomplish a simple task and verify how he knows it was completed. I tend to delete failing stories. Sometime I do not need to write a replacement test in browser/tests because there already is one. | 15:13 |
| nigelb | sinzui: At this point, I'm still not sure how my code caused something to fail :( | 15:14 |
| sinzui | nigelb: this error is a string indication that the test is bad. A test of the model or the view would clearly state what is wrong and you would know how to fix it. tales hides the error most of the time. Can you paste a diff of your branch, or have you pushed it so that I can take a look? | 15:15 |
| nigelb | I | 15:16 |
| nigelb | I've pushed it | 15:16 |
| nigelb | https://code.launchpad.net/~nigelbabu/launchpad/90628-spec-sub | 15:16 |
| sinzui | nigelb: You have a simple branch. I do not see what broke the page yet. Maybe there is something else looking at the value. I think we need to look at browser/specification at the "Unsubscribe" action | 15:21 |
| * sinzui does | 15:21 | |
| * nigelb looks too | 15:22 | |
| sinzui | wow, this does not use LaunchpadForm | 15:24 |
| nigelb | yeah, I don't think blueprints have had much love :) | 15:25 |
| sinzui | nigelb: their is a contradiction introduced by Specification.unsubscribe in the model | 15:25 |
| sinzui | That method iterates over the .subscriptions, and mutates it. We have two choices | 15:25 |
| sinzui | 1. clear the property cache after we change subscriptions or | 15:26 |
| nigelb | not cache the property at all? | 15:26 |
| nigelb | I hope (2) isn't rewrite unsubscribe :) | 15:27 |
| sinzui | 2. Use a different way to get the subscription. The method is guessing at the subscription, and loading a lot of data what will not be used | 15:27 |
| sinzui | let me check if there is already a method that gets the sub | 15:27 |
| sinzui | There is not, so we choose option 1 | 15:28 |
| nigelb | aha | 15:29 |
| nigelb | clear_property_cache ? | 15:31 |
| sinzui | nigelb: at a minimum, we want to | 15:31 |
| sinzui | from lp.services.propertycache import get_property_cache | 15:31 |
| sinzui | del get_property_cache(self).subscriptions | 15:31 |
| nigelb | okay | 15:32 |
| sinzui | nigelb: but we could just remove the sub so we do not reload the users. maybe... | 15:32 |
| sinzui | get_property_cache(self).subscriptions.remove(sub) | 15:33 |
| sinzui | SpecificationSubscription.delete(sub.id) | 15:33 |
| nigelb | sinzui: that would delete the property entirely? | 15:34 |
| sinzui | nigelb: ^ I have not done this before, but It is worth a try because it means there is no performance hit. In fact, you are making Lp faster! | 15:34 |
| nigelb | or remove that particular subscription? | 15:34 |
| nigelb | in which case, I'll gladly try this! | 15:34 |
| wgrant | bac: Hi. | 15:35 |
| sinzui | nigelb: The first form deletes the cached value. The second gets the cached value (a list) and removes the found subscription from it | 15:35 |
| nigelb | sinzui: so, the second form needs to be done along with what's existing right? | 15:36 |
| sinzui | nigelb: yes. we are just teaching Specification.unsubscribe() about your change | 15:37 |
| nigelb | okay, let me run the tests again :) | 15:37 |
| nigelb | sinzui: Does this sort of difficulty happen often? | 15:44 |
| sinzui | nigelb: I see that Specification.subscribe() is implicitly accessing .subscriptions() using a .subscription(person) We may need to delete the cache or add the user to the list (which means resorting it) | 15:45 |
| nigelb | sinzui: ah, yes/ | 15:45 |
| sinzui | nigelb: yes, but the test issue is no, Blueprints was not actively developed between 2007 and 2011. There is a lot of bad code in it | 15:46 |
| nigelb | sinzui: True :( | 15:46 |
| nigelb | If it weren't for the fact that its going away, I would have loved to help remove some of the b0rk. | 15:49 |
| sinzui | nigelb: I believe a lot of the code rules will be combined in a future issue tracker. So there should be no guilt is making the code better. | 15:50 |
| === Ursinha is now known as Ursinha-afk | ||
| nigelb | sinzui: In which case, I'm happy to fix whatever I can. Though its big of an overhead because I have to get someone to help :) | 15:52 |
| LPCIBot | Project windmill-db-devel build #308: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-db-devel/308/ | 15:53 |
| wgrant | bac: You marked bug #777789 qa-bad... It doesn't seem like a really risky change, except for the Y.Node.create('<div />') thing. If it really is bad, could you please roll it back ASAP? | 15:54 |
| _mup_ | Bug #777789: "Other subscriptions" description of direct team subscription makes no sense <qa-bad> <story-better-bug-notification> <Launchpad itself:Fix Committed by bac> < https://launchpad.net/bugs/777789 > | 15:54 |
| benji | henninge: would you like for me to review https://code.launchpad.net/~henninge/launchpad/bug-740208-leak-email-bug-title/+merge/61784? | 16:12 |
| === al-maisan is now known as almaisan-away | ||
| nigelb | sinzui: okay, the tests did pass :) | 16:25 |
| nigelb | sinzui: Now I guess I need to figure out the subscribe() bit :) | 16:25 |
| sinzui | nigelb: excellent | 16:27 |
| nigelb | sinzui: How do I fix the subscribe() where it again modifies the list? | 16:42 |
| * sinzui thinks | 16:42 | |
| sinzui | nigelb: how did you fix the unsubscribe case? | 16:43 |
| nigelb | sinzui: I removed it from the cache as well. | 16:44 |
| nigelb | so update the cache and the *real* one and then resort both? | 16:44 |
| sinzui | okay. then I think we can do the same at # since no previous subscription existed, create and return a new one | 16:44 |
| sinzui | nigelb: we want to append the sub to the cached list, then resort on displayname | 16:45 |
| sinzui | Then we call notify() | 16:45 |
| LPCIBot | Yippie, build fixed! | 16:47 |
| LPCIBot | Project db-devel build #571: FIXED in 5 hr 15 min: https://lpci.wedontsleep.org/job/db-devel/571/ | 16:47 |
| === deryck is now known as deryck[lunch] | ||
| nigelb | sinzui: does this look right? http://pad.ubuntu-uk.org/VX7IyBpAbD | 17:01 |
| sinzui | nigelb: I am not sure you are mutating the cached list. Are you? I an sure you are working with the real item when I read | 17:03 |
| sinzui | get_property_cache(self).subscriptions | 17:03 |
| nigelb | ah | 17:03 |
| nigelb | sinzui: is the self.subscription = correct? or is there a more correct call to update the item in cache? | 17:04 |
| sinzui | nigelb: you approach might work because propertycache is returning a mutable instance. Well it probably is since I can change a cached person object. | 17:04 |
| LPCIBot | Project windmill-db-devel build #309: STILL FAILING in 49 min: https://lpci.wedontsleep.org/job/windmill-db-devel/309/ | 17:05 |
| sinzui | bigjools: I think you need to do | 17:05 |
| sinzui | get_property_cache(self).subscriptions = sorted(subscriptions, key=lambda sub: sub.person.displayname) | 17:05 |
| nigelb | aha | 17:07 |
| nigelb | fixed that. | 17:07 |
| sinzui | nigelb: self.subscription is a cached property so I do not think it can really be assigned without a setter explicitly defined. | 17:07 |
| nigelb | ahh. | 17:07 |
| nigelb | Does it look right now though? | 17:08 |
| sinzui | yes, it does | 17:08 |
| nigelb | :) | 17:08 |
| nigelb | That definitely wasn't an "easy" bug. | 17:09 |
| sinzui | nigelb: no bug is really easy without 3 months of experience working with Lp's byzantince code. I do think you could repeat your change to fix other bugs in less than a day, so this class of bug is not easy | 17:12 |
| nigelb | sinzui: heh. I agree. Unless its just text fixing, everything else needs a fair bit of delving. I'm a bit more confident now. | 17:13 |
| === Ursinha-afk is now known as Ursinha | ||
| * bigjools morphs into nigelb | 17:18 | |
| nigelb | haha | 17:18 |
| nigelb | that was a wrong ping :p | 17:18 |
| bigjools | it's ok I'm used to Curtis' typos :) | 17:19 |
| === deryck[lunch] is now known as deryck | ||
| nigelb | This one's the most satisfying bug fix. I spent quite a bit of time trying to fix this :) | 17:56 |
| === matsubara is now known as matsubara-lunch | ||
| LPCIBot | Project windmill-db-devel build #310: STILL FAILING in 51 min: https://lpci.wedontsleep.org/job/windmill-db-devel/310/ | 18:07 |
| deryck | sinzui, hi. Could I get some time with you to do a pre-imp call on a bug? | 18:30 |
| sinzui | I can talk now | 18:31 |
| deryck | excellent. I'll jump to mumble. | 18:31 |
| nigelbabu | benji: Hi, could you review https://code.launchpad.net/~nigelbabu/launchpad/90628-spec-sub/+merge/62003 for me? :) | 18:39 |
| sinzui | nigelbabu: why doesn't the diff show a change to subscribe()? | 18:46 |
| nigelbabu | sinzui: woah, let me look! | 18:46 |
| nigelbabu | sinzui: heh, did someone break that preview? :P | 18:49 |
| nigelbabu | because its there on my branch http://bazaar.launchpad.net/~nigelbabu/launchpad/90628-spec-sub/revision/13102 | 18:49 |
| nigelbabu | Its showing a diff of last commit to branch vs trunk | 18:49 |
| nigelbabu | instead of entire branch vs trunk. | 18:50 |
| nigelbabu | wait. | 18:50 |
| nigelbabu | its showing last commit to branch vs its previous commit :( | 18:50 |
| nigelbabu | sinzui: ^^ | 18:50 |
| sinzui | nigelbabu: did you not commit and push changes toe the scrubscribe() method. I saw it on the collaborative notepad | 18:53 |
| LPCIBot | Project windmill-devel build #120: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/120/ | 18:54 |
| gary_poster | In https://answers.launchpad.net/launchpad/+question/158714 , someone is asking to recreate an old PPA from when they left LP (they have now returned) . Can anyone help with that? I don't even know if it is possible. | 18:55 |
| benji | nigelbabu: sure I'll review it for you, let me know when you get the merge proposal straightened out | 18:56 |
| nigelbabu | benji: yup :) | 18:56 |
| nigelbabu | sinzui: okay, now I'm confused. I commited everything and I see the code locally. | 18:57 |
| nigelbabu | I did a bzr status and it didn't return anything | 18:57 |
| LPCIBot | Project windmill-db-devel build #311: STILL FAILING in 50 min: https://lpci.wedontsleep.org/job/windmill-db-devel/311/ | 18:57 |
| nigelbabu | bah, I didn't save the file :/ | 18:58 |
| sinzui | nigelbabu: but did you push the branch to lp:~nigelbabu/launchpad/90628-spec-su | 18:58 |
| sinzui | bzr st -r branch:lp:~nigelbabu/launchpad/90628-spec-sub | 18:58 |
| nigelbabu | sinzui: I hadn't done the unsubscribe, my mistake. | 19:00 |
| nigelbabu | well, I didn't save the file, so it didn't show up in bzr st :\ | 19:00 |
| nigelbabu | sinzui: IRobot++ :) | 19:03 |
| sinzui | No one will follow up on my suggestion to break IPerson is role/app interfaces. ITranslator, IQuestioner, IBugger | 19:04 |
| nigelbabu | haha | 19:04 |
| nigelbabu | IBugger lol | 19:04 |
| sinzui | nigelbabu: did specification-notifications.txt really verify you could subscribe someone twice? | 19:07 |
| nigelbabu | sinzui: didn't get you | 19:07 |
| nigelbabu | sinzui: until I removed the two instances of test@canonical.com, the test wouldn't pass. | 19:08 |
| nigelbabu | poolie: woah, thanks for featuring cjohnston and me on the blog :) | 19:08 |
| sinzui | nigelbabu: I think you may have fixed another bug :) | 19:08 |
| nigelbabu | sinzui: with the sort? | 19:08 |
| nigelbabu | woah | 19:09 |
| sinzui | A user cannot/should not be able to subscribe twice, yet the test you changed appears to say a user could be subscribed twice :( | 19:09 |
| cjohnston | go nigelbabu | 19:10 |
| sinzui | Since the code clearly did not allow it, I think the defect is in sample data. That is why we prefer to test using a factory to create only the objects under test. | 19:10 |
| nigelbabu | hrm, do you want me to write new unit tests? | 19:11 |
| nigelbabu | I could potentially write something under browser/test | 19:11 |
| nigelbabu | sinzui: anything more you want me to do on that branch before I ask for it to be reviewed? :) | 19:18 |
| sinzui | nigelbabu: I am not going to burden you with extra tests. I may write one. I am reading lib/lp/blueprints/doc/specification-notifications.txt and I am perplexed by the test@canonical.com addition (Sample Person). Your change looks like what should have always been the case. Why were we really sending Sample Person two emails? Where they the same email? | 19:18 |
| nigelbabu | sinzui: heh, indeed. | 19:19 |
| * sinzui looks for existing bug | 19:19 | |
| nigelbabu | sinzui: and why hasn't anyone complained yet | 19:19 |
| nigelbabu | we really need to fix mails from blueprints. Its quite chatty like bugs. | 19:19 |
| nigelbabu | switching nicks. | 19:20 |
| nigelb | o/ | 19:20 |
| sinzui | nigelb: The test indicates sample person was not subscribed. Then we was, and he got 2 emails. Yet your change is made *before* notify where you ensure the user subscription is created, and the list of subscribers is sane. I am going to add a sanity check to the existing test to search how many notifications. | 19:24 |
| nigelb | sinzui: okay, will you be making your change on top of mine? | 19:25 |
| LPCIBot | Project windmill-devel build #121: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/121/ | 19:40 |
| sinzui | nigelb: I think something is broken. The doctest does not do what it thinks it dos. It does not commit the transaction from the previous block and verify that Sample Person got an email stating that he was subscribed. I can see that two messages were sent to test@, the first because the the subscription two blocks before, then because of the spec change. your test change implies the subscribe email was not sent | 19:51 |
| * sinzui crafts a test fix to verfiy the expected behaviour | 19:51 | |
| nigelb | sinzui: so, my change should not have been necessary? | 19:52 |
| sinzui | nigelb: You have already made the change to the second chunk. Make the first set of changes to verify a subscription email was sent: http://pastebin.ubuntu.com/611986/ | 19:52 |
| nigelb | sinzui: okay! | 19:53 |
| sinzui | I see that the code that manages email notification is not in blueprints. That is why I could not see what was going on | 19:56 |
| nigelb | ahh | 20:00 |
| nigelb | I'm not sure if I'm picking progressively harder LP bugs, but it sure does seem that way :) | 20:01 |
| nigelb | sinzui: pushed :) | 20:07 |
| sinzui | nigelb: did the test pass with the change? | 20:09 |
| nigelb | sinzui: woops, didn't run them. gimme 5 minutes :) | 20:09 |
| sinzui | The change you made looks correct | 20:10 |
| === lifeless changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: henninge, benji | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| lifeless | sinzui: "specificationsubscription_spec_person_uniq" UNIQUE, btree (specification, person) | 20:15 |
| lifeless | sinzui: even the sample data can't have someone subbed twice | 20:15 |
| sinzui | hm | 20:16 |
| sinzui | lifeless: fab, So we just need to learn if we lost a subscription with the change. | 20:16 |
| lifeless | sinzui: so, disclosure eh? | 20:20 |
| jcsackett | henninge or benji: can i throw https://code.launchpad.net/~jcsackett/launchpad/dont-expose-domains/+merge/62023 on the review queue? | 20:20 |
| benji | jcsackett: Sure. I can look at it right now in fact. | 20:21 |
| jcsackett | benji: great, thanks! | 20:21 |
| === benji changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| nigelb | sinzui: bah, 3 tests failed :( | 20:28 |
| nigelb | let me echo it into a file and upload somewhere | 20:28 |
| sinzui | You ran -m lp.blueprints? | 20:28 |
| * sinzui can see the doctest in question passed | 20:29 | |
| lifeless | deryck: gary_poster: sinzui: -extremely- rough as yet - https://dev.launchpad.net/ArchitectureGuide/ServicesRoadmap | 20:30 |
| nigelb | sinzui: no, I ran bin/test --vvt blueprints | 20:30 |
| LPCIBot | Project windmill-devel build #122: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/122/ | 20:32 |
| gary_poster | lifeless, I expect you've been considering where Python 3 might fit into this as well? | 20:33 |
| deryck | lifeless, thanks for the link. | 20:33 |
| deryck | lifeless, on first read, looks good. | 20:34 |
| sinzui | nigelb: that is about the same as -m lp.blueprints. It may have run more | 20:34 |
| sinzui | nigelb: what were the failing tests. I merged your changed and I see that doc/specification-notifications passes | 20:35 |
| nigelb | sinzui: specification.txt fails | 20:35 |
| nigelb | and sprint-meeting-export.txt | 20:35 |
| gary_poster | lifeless, curious in regards to rest bits about "optimises for things that don't really affect us". I would guess that some do, and some don't. Can I assume that we at least will follow standard and basic "GETs don't write" no matter what the protocol? | 20:36 |
| lifeless | gary_poster: hell yes | 20:37 |
| gary_poster | ok, good | 20:37 |
| gary_poster | lifeless, and did you already reject the github xmlrpc competitor I mentioned? It's fine, I just saw it mentioned, but I thought it was worth making sure that you had seen it. Trying to find it again | 20:37 |
| lifeless | gary_poster: I had a look, I think I disliked something - I | 20:38 |
| gary_poster | lifeless, then that's good enough for me | 20:38 |
| lifeless | 'll have another look now and either document that or add it in | 20:38 |
| sinzui | nigelb: okay. good. This means the cache was not made yet. We only want to update the cache is it was made!. | 20:38 |
| gary_poster | eh, maybe so noone else bothers with it | 20:38 |
| * sinzui reads code | 20:39 | |
| lifeless | gary_poster: yeah | 20:39 |
| * sinzui run test again | 20:41 | |
| * sinzui has a fix | 20:42 | |
| lifeless | gary_poster: oh, I remember | 20:42 |
| lifeless | its erlang binary wire encoding | 20:42 |
| sinzui | nigelb: I am prepare a patch for you. It incorporates my change as well as a number of lint fixed from by unposted review. | 20:43 |
| * nigelb hugs sinzui | 20:43 | |
| lifeless | gary_poster: which is a bit esoteric for something folk may have to debug from time to time | 20:43 |
| === matsubara_ is now known as matsubara-afk | ||
| gary_poster | lifeless, yeah. Of interest if (a) they have thought something through that we ought to; or (b) we ever care about erlang, but I hear you. I don't think I saw a reply to my Python 3 question: do you expect these services to be in Python 3? | 20:44 |
| lifeless | gary_poster: on the restful side, it optimises to make the path visible and have the ability to cache, and neither of those really make a difference to us. | 20:45 |
| lifeless | gary_poster: If all things are equal, I think restful is nicer than xmlrpc | 20:46 |
| lifeless | just cause I'm an http junkie | 20:46 |
| gary_poster | making path visible and giving ability to cache *and* giving another opportunity to divide up services by boxes | 20:46 |
| gary_poster | (different resources by different machines) | 20:47 |
| lifeless | gary_poster: python3; uhm, if we can, sure. Python3 in lucid is 3.1, but we'd really only have the standard library available to us. | 20:47 |
| lifeless | gary_poster: yes, but we're already dividing the services up | 20:47 |
| lifeless | gary_poster: so we don't need a single url space for heterogeneous services internally | 20:47 |
| gary_poster | And we'll never have another bottleneck? Rephrased: taking easy steps for future proofing makes sense to me | 20:48 |
| nigelb | Tests with failures: | 20:48 |
| nigelb | lib/lp/blueprints/doc/specification.txt | 20:48 |
| nigelb | lib/lp/blueprints/doc/sprint-meeting-export.txt | 20:48 |
| nigelb | lib/lp/blueprints/stories/standalone/subscribing.txt | 20:48 |
| nigelb | sinzui: ^^ | 20:48 |
| gary_poster | I don't mean a single space for heterogeneous services, actually lifeless | 20:48 |
| gary_poster | I mean... | 20:48 |
| lifeless | gary_poster: we're starting out with horizontal scaling built-in for each microservice | 20:48 |
| gary_poster | like, resources beginning with identifiers A-M are handled by box X | 20:49 |
| gary_poster | or resource foo is a biggie | 20:49 |
| gary_poster | it is handled by special box Y | 20:49 |
| sinzui | nigelb: apply this patch to add a guard, wrap long lines, and remove trailing whitespace: http://pastebin.ubuntu.com/612018/ | 20:49 |
| lifeless | gary_poster: I think for most of our internal services doing that would be an antipattern | 20:50 |
| nigelb | sinzui: tests fail for lint? :O | 20:50 |
| gary_poster | lifeless, using what mechanism (and why does it make it unnecessary to consider others)? | 20:50 |
| gary_poster | (horizontal scaling) | 20:50 |
| lifeless | gary_poster: haproxy to some N instances, where N >= 2 | 20:50 |
| gary_poster | lifeless, that's a common pattern...as is the one I'm describing. They both are valuable for different sorts of problems | 20:51 |
| lifeless | agreed | 20:51 |
| sinzui | nigelb: they will no fail for lint, but we have a coding style. Some merges get screwed up if we do not follow the recommended style, such as alphabetised imports | 20:51 |
| gary_poster | and I don't see any convincing evidence that we would have only a single kind of problem :-) | 20:51 |
| nigelb | sinzui: wah, I didn't know about the alphabetized imports | 20:52 |
| lifeless | gary_poster: I think we have many kinds of problems; we're selecting a -default- not a -required- | 20:52 |
| lifeless | gary_poster: uhm, to me, that means picking the cheapest-to-deploy-and-use 80% fit | 20:52 |
| sinzui | nigelb: and I did not fix line 50 in you Mp's diff, those two imports should be on single lines so that subsequent changes do not inflate the diff | 20:53 |
| lifeless | gary_poster: so what I'm saying isn't that the restful design principles are invalid - they are valid | 20:53 |
| sinzui | nigelb: ps, You are a much better engineer after today | 20:53 |
| nigelb | sinzui: you mean on individual lines? | 20:53 |
| nigelb | sinzui: hehe | 20:54 |
| lifeless | gary_poster: I'm saying that it optimises - by doing the things we're discussing - for specific cases, most of which won't affect us most of the time | 20:54 |
| sinzui | nigelb: yes | 20:54 |
| nigelb | aha, /me fix0rs | 20:54 |
| gary_poster | lifeless, cheapest to deploy and use 80% fit: that can be primary guide, but "supporting best practices" is a reasonable secondary guide | 20:54 |
| gary_poster | lifeless, so the convincing argument get me to be quiet about this is whether or not it really is that much harder to build a REST service--or at least | 20:55 |
| benji | jcsackett: hi, I added some comments to https://code.launchpad.net/~jcsackett/launchpad/dont-expose-domains/+merge/62023 for you to consider. | 20:55 |
| gary_poster | a service that is more REST than XMLRPC | 20:55 |
| lifeless | gary_poster: I have no desire to get you to be quiet :) | 20:55 |
| gary_poster | lifeless, lol, I have a desire to be quiet ;-) | 20:56 |
| jcsackett | benji: dig. | 20:56 |
| lifeless | gary_poster: so building a REST service requires url routing that is object identity aware; building an RPC service requires routing that is function aware | 20:57 |
| gary_poster | perhaps a better phrasing would be, "...a way to convince me is to determine whether..." | 20:57 |
| lifeless | gary_poster: ditto consumption | 20:57 |
| gary_poster | true | 20:57 |
| lifeless | gary_poster: one has a hierarchy that has to be designed - and many toolkits don't offer great migration support (by which I mean after you make a mistake, what then) | 20:58 |
| benji | Everyone enjoys the melodic bass tones that emanate from gary. | 20:58 |
| lifeless | gary_poster: RPC on the other hand is essentially a freeform space, which on the downside is basically freeform | 20:58 |
| gary_poster | benji :-P :-) | 20:58 |
| gary_poster | lifeless, if XMLRPC is freeform, that means it doesn't have migration support either | 21:00 |
| gary_poster | (and I would agree with that) | 21:00 |
| gary_poster | If instead you begin with a simple pattern like lazr.restful has | 21:00 |
| gary_poster | with a first element that is in essence a namespace | 21:00 |
| lifeless | gary_poster: it doesn't, but it doesn't need migration support anywhere near as much because of two things: you can trivially bind a function to two names (giving you migration), and the function name is not impacted or altered by data model. | 21:01 |
| gary_poster | then you have the building blocks for a nice migration story | 21:01 |
| gary_poster | lifeless, I'm not clear on how the RESTful namespace doesn't give you similar power | 21:02 |
| lifeless | perhaps I misunderstand, but AFAICT you'd be cloning all your functions across | 21:03 |
| lifeless | so something like /1/object/query_op?params | 21:04 |
| gary_poster | (where "1" is the namespace? | 21:04 |
| gary_poster | ) | 21:04 |
| lifeless | would migrate as /2/object/differentname?params | 21:04 |
| lifeless | which would work for many things because you'd be able to register the new thing | 21:05 |
| lifeless | gary_poster: I'm sure something can be worked out - but this is kindof my point - its a very heavy hammer vs migrating individual methods, and thats driven by the structure (which is its blessing and its curse) | 21:06 |
| lifeless | flacoste: are we on now ? | 21:06 |
| benji | as a reformed Windows developer I have bad memories of APIs having a "Foo" function and adding a "FooEx" function in order to change the signature for a later version of Windows | 21:06 |
| gary_poster | lifeless, I didn't follow so much... | 21:07 |
| sinzui | nigelb: I approved your branch. I am landing it now | 21:07 |
| gary_poster | lifeless, we can continue at later date :-) | 21:07 |
| nigelb | sinzui: woah, thanks :) | 21:07 |
| lifeless | gary_poster: sure ;) | 21:07 |
| nigelb | sinzui: I was still trying to run the tests again before poking you to land :) | 21:07 |
| sinzui | okay. I need to reconfigure to land anyway. Lp assumes that Lp engineers only hack on the Lp project | 21:08 |
| lifeless | gary_poster: here is a concrete example of the sort of complexity rest adds - is a 404 a missing object or a bad method name? [python itself has this complexity, so it is toleratable but still confusing] | 21:09 |
| === benji changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| gary_poster | lifeless, (niggle where I might be wrong but I think I'm right: with "true" REST at least AIUI, you don't have a method name in the URL...but you might have specialized objects and a 404 inherently doesn't tell you where you went wrong specifically with the path and so your underlying point is still valid ISTM) XMLRPC doesn't buy you anything there, lifeless. | 21:16 |
| gary_poster | REST isn't adding complexity, but offering a solution equivalent in my mind to what an RPC offers. RPC let's you send a payload back that you have to know how to interpret; and so can REST. Perhaps you could even argue that REST has a more regular and yet flexible language for communicating errors and what to do with them (with hypertext) but decisions still need to be made on how to interpret the error response, no | 21:16 |
| gary_poster | But again, there's no XMLRPC win. | 21:16 |
| gary_poster | Maybe there's a Google protocol win there, or whatever the Facebook equivalent is; I haven't looked at those. I suspect it is easier to argue against XMLRPC than some of the newer options. | 21:16 |
| gary_poster | (Well, I've looked at them, but not lately, and I've forgotten the error passing mechanisms) | 21:17 |
| === benji changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| lifeless | benji: (re FooEx - yes, mistakes Will Happen) :) | 21:18 |
| benji | gary_poster: are you referring to Protocol Buffers? or maybe Google Data Protocol? <shudder> | 21:21 |
| benji | the former is just a data format (like JSON) as far as I know so it doesn't have an error channel, and the latter should die in a fire (it [ab]uses Atom as the data format) | 21:22 |
| gary_poster | benji, let's see the Facebook thing is Thrift... | 21:22 |
| benji | I'll have to take a look at Thrift. | 21:23 |
| gary_poster | benji, and for Google I was thinking of protocol buffers, yeah | 21:24 |
| gary_poster | which I see you are right, is just a data format, as opposed to thrift, which is more of a full-flledged rpc | 21:27 |
| lifeless | thrift is apparently fffugly | 21:27 |
| lifeless | according to the cassandra folk, which are trying to make thrift diaf | 21:28 |
| benji | lifeless: the wire format? | 21:28 |
| lifeless | benji: the whole kit and caboodle | 21:28 |
| benji | heh | 21:28 |
| gary_poster | heh, ok | 21:29 |
| lifeless | http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking | 21:30 |
| lifeless | is an interesting read | 21:30 |
| lifeless | gary_poster: FWIW I'd be entirely happy with us making early mistakes here - we're aiming for such narrow services migrating one to a new protocol should be low cost | 21:31 |
| lifeless | gary_poster: not saying I *want* to make mistakes | 21:32 |
| gary_poster | link is interesting, yes. never heard of kryo...or many others | 21:32 |
| lifeless | gary_poster: just that I think the cost is easily absorbed | 21:32 |
| benji | gary_poster: there are several RPC mechanisms based on protocol buffers: http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns#RPC_Implementations | 21:45 |
| gary_poster | want to make mistakes: heh :-) . lifeless, that's fair enough, but IME, the "I should have had a V8" moment (did you all have that ancient ad campaign?) with the XMLRPC approach was pretty far down the line for us, when expenses were much higher than they could have been, for following what is so often described as best practice anyway. | 21:46 |
| gary_poster | benji, which is the one that should diaf? :-) | 21:46 |
| nigelb | sinzui: Thank you so much for helping me out today. Even though LP is hard, its nice you folks are all so helpful :) | 21:47 |
| LPCIBot | Project windmill-devel build #123: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/123/ | 21:47 |
| benji | gary_poster: all of those are innocent until immolated; I was referring to http://code.google.com/apis/gdata/ | 21:47 |
| gary_poster | benji, lol, ok cool | 21:47 |
| sinzui | nigelb: Your welcome. It is always nice to see contributors completing a goal | 21:48 |
| gary_poster | one is developed on LP, so obviously superior ;-) | 21:48 |
| benji | obviously the bad part is that none of those are "official" | 21:48 |
| benji | heh | 21:48 |
| nigelb | sinzui: :) | 21:48 |
| lifeless | which one is developed on LP ? | 21:51 |
| gary_poster | lifeless, Twisted based: https://launchpad.net/txprotobuf/ | 21:52 |
| benji | gary_poster: last commit was 3 years ago | 21:52 |
| gary_poster | bah :-) | 21:52 |
| gary_poster | that's because the twisted stuff is rock solid! :-) | 21:53 |
| rockstar | gary_poster, you should ask lucio about protobuf and Ubuntu One. | 21:53 |
| gary_poster | rockstar, can you give a one sentence preview? :-) | 21:53 |
| benji | gary_poster: the only ones with Python bindings that have any sort of recent activity apear to be http://zeroc.com/ice.html and http://code.google.com/p/protobuf-socket-rpc/ | 21:53 |
| rockstar | gary_poster, not much more than what vds just told me (he's sitting right in front of me): It's slow, had a lot of problems, lucio would know more. | 21:54 |
| gary_poster | benji, I left the first when it started looking commercial...did I leave too soon? | 21:54 |
| benji | (and ICE doesn't list Ubuntu as supported) | 21:54 |
| gary_poster | fair enough, thanks rockstar. lifeless, I expect you saw that, and quite possibly knew that already :-) | 21:54 |
| benji | gary_poster: it is commercial (and GPL) | 21:54 |
| rockstar | gary_poster, thrift is my serializable protocol of choice right now. | 21:54 |
| gary_poster | ah | 21:54 |
| gary_poster | rockstar, ack | 21:55 |
| gary_poster | rockstar, lifeless was saying that cassandra wanted it to diaf | 21:55 |
| rockstar | thrift? | 21:55 |
| gary_poster | yeah | 21:55 |
| rockstar | Huh. I assume the Casandra people are much smarter than I. | 21:56 |
| gary_poster | <shrug> :-) | 21:56 |
| jcsackett | benji: i've pushed up changes on my MP and replied to your comments. | 21:57 |
| benji | I assume we want a synchronous protocol (meaning that protobuf+rabbitmq wouldn't be attractive). | 21:58 |
| benji | jcsackett: cool, I'll look now | 21:58 |
| gary_poster | benji, I assume so as well. AIUI, we're talking about building pages | 21:58 |
| lifeless | gary_poster: I did :) | 21:58 |
| gary_poster | :-) | 21:58 |
| deryck | sinzui, hi. Mind doing an easy review for me, based on this morning's call? | 21:58 |
| sinzui | okay | 21:58 |
| lifeless | gary_poster: currently slow in the cons, based on talking with lucio :) | 21:58 |
| gary_poster | lifeless, heh, cool | 21:59 |
| deryck | sinzui, https://code.launchpad.net/~deryck/launchpad/bug-activity-do-not-snapshot-680131/+merge/62035 | 21:59 |
| * gary_poster running away | 21:59 | |
| lifeless | ciao | 21:59 |
| gary_poster | bye! | 21:59 |
| lifeless | flacoste: yo? | 21:59 |
| deryck | sinzui, thanks! | 21:59 |
| sinzui | deryck: r=me | 22:00 |
| deryck | sinzui, many thanks! | 22:03 |
| benji | jcsackett: I think I'm confused. The code to add prefixes to generated names is still there and doesn't seem to be tested anywhere else; shouldn't we test it in test_nickname.py? | 22:07 |
| jcsackett | benji: it is tested; in the collision test use up the nick with the suffix, and try the nick generation again to trigger prefix. | 22:08 |
| jcsackett | that was the copied code you saw earlier--me getting ready to set up that part of the test and forgetting it. now it's there. | 22:09 |
| jcsackett | the rest of the doctest deals with it using more and more of the email domain. | 22:09 |
| benji | ah! I'll look at that then. Thanks. | 22:09 |
| benji | jcsackett: I'm done with https://code.launchpad.net/~jcsackett/launchpad/dont-expose-domains/+merge/62023. | 22:15 |
| === benji changed the topic of #launchpad-dev to: Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| jcsackett | thanks benji. | 22:16 |
| benji | my pleasure | 22:16 |
| nigelb | night folks, hopefully I should have a mail with the landing results when I wake up :) | 22:16 |
| lifeless | sinzui: I've tagged bug 633 as disclosure | 22:31 |
| lifeless | sinzui: this may be incorrect, so I'm letting you know ;) | 22:31 |
| sinzui | I hate you | 22:31 |
| lifeless | sinzui: I love you too | 22:31 |
| sinzui | I was using that tag to ask my team to fix them. I wont now | 22:31 |
| lifeless | sinzui: well thats why I'm mentioning it | 22:32 |
| sinzui | I think I need a new tag that only jml can assign | 22:32 |
| lifeless | sinzui: you can use disclosure for that | 22:32 |
| lifeless | what tag should I use here though? | 22:32 |
| * sinzui is not working a a 13 month feature again | 22:32 | |
| lifeless | the bug is about accidental information disclosure when someone subscribes the wrong person | 22:32 |
| lifeless | so your trusted picker work will reduce the incident rate (but not eliminate it) | 22:33 |
| sinzui | lifeless: We used privacy or private before. I added disclosure to the bug that were very relevant to features stakeholders were requesting | 22:33 |
| lifeless | I'll change it to privacy | 22:33 |
| sinzui | I wonder what the overlap is? | 22:34 |
| lifeless | well | 22:34 |
| lifeless | if this bug were fixed a stakeholder would be a little bit happier right now :P | 22:34 |
| sinzui | oh | 22:34 |
| sinzui | lifeless: you are going to laugh at me. I thought you wrote that you added the 'disclosure' tag to 633 bugs, or 10% of all Lp bugs | 22:35 |
| lifeless | sinzui: HAHAHHAHAHHAHAHAHAHAHAHAHA | 22:35 |
| lifeless | sinzui: your comments make a lot more sense now | 22:36 |
| sinzui | lifeless: we have several dupes of 633. We absolutely are fixing this. | 22:38 |
| lifeless | sinzui: I know you have dupes about accidental subscriptions | 22:38 |
| lifeless | sinzui: this is about dealing with them after they happen (and they still will), I wasn't sure if that was on your plate | 22:38 |
| sinzui | I Changed Answers API to collect subscribed_by two weeks ago, and secretly changed the permission so that LOSAs can remove answer contacts | 22:38 |
| lifeless | how do you get the email address for someone suspended ? | 22:40 |
| sinzui | staging | 22:41 |
| sinzui | I am not joking | 22:41 |
| lifeless | is there a bug for this? | 22:41 |
| sinzui | No, There was a bug, but we had a partial fix so it was closed | 22:41 |
| lifeless | do we cc feedback@ or anything on mails to hacked-account-spammers ? | 22:41 |
| jcsackett | i haven't. wiki doesn't say anything about it. doesn't seem like a bad idea though. | 22:42 |
| sinzui | We have not this year, we used to last year and it was felt that we should track this in answers when we can | 22:42 |
| lifeless | ah | 22:43 |
| lifeless | so I should have insisted on a Question | 22:43 |
| sinzui | Of course a suspended user cannot use answers, so we end up asking the question. Which is one reason ~registry got permission to just fix the account | 22:44 |
| lifeless | right, I've cc'd feedback | 22:45 |
| lifeless | because there was no Question | 22:45 |
| sinzui | fab | 22:45 |
| lifeless | bac: hi | 22:47 |
| sinzui | benji: was bug 315563 solved by muting or filters? | 22:50 |
| _mup_ | Bug #315563: can't unsubscribe from team-related bug-activity emails <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/315563 > | 22:50 |
| lifeless | sinzui: no | 22:53 |
| lifeless | sinzui: assignee != subscription I suspect. IMBW | 22:54 |
| lifeless | sinzui: the data model permits muting a *subscription* but its flexible enough to treat assignment as a form of subscription | 22:54 |
| sinzui | That's right, the assignee is added the the subscribers list if he is not explicitly subscribed | 22:55 |
| lifeless | exactly. But its only a presentation as a subscriber. Its not modelled as such lower down. It probably should be., | 22:56 |
| benji | sinzui: muting, where applicable. It isn't possible to mute a team subscription if the team has a contact email address because we (LP) isn't in charge of parceling out the individual emails and so can't squelch the ones to people with mutes | 22:59 |
| sinzui | benji: thanks. | 23:02 |
| lifeless | benji: am I wrong? you can mute an assignment ? | 23:09 |
| benji | lifeless: unfortunately I don't know; I'm inclined to say you can't. | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!