| sinzui | wallyworld: I head you | 00:03 |
|---|---|---|
| lifeless | pop quiz | 00:21 |
| lifeless | should we count both open tasks in aggregates | 00:21 |
| lifeless | e.g if a distro has 1 bug with 2 tasks on different source packages | 00:21 |
| lifeless | should we should 'open bugs 1' or 'open bugs 2' | 00:21 |
| LPCIBot | Project windmill build #215: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/215/ | 00:31 |
| sinzui | wallyworld: maybe this bug next https://bugs.launchpad.net/launchpad/+bug/757248 | 00:46 |
| lifeless | 51 / 0 RootObject:index.html ?! | 02:12 |
| wgrant | lifeless: Probably tests from gac before memcached was fixed last night. | 02:17 |
| wgrant | Which prefixes? | 02:18 |
| lifeless | indeed | 02:30 |
| lifeless | A/B etc | 02:30 |
| lifeless | gac is out of rotation now though | 02:30 |
| wgrant | Oh, why? | 02:31 |
| wgrant | (memcached was fixed before it was put into rotation) | 02:31 |
| lifeless | internal xmlrpc failures showing up on bzr ops | 02:32 |
| wgrant | I wondered about those. | 02:32 |
| lifeless | theres an rt | 02:32 |
| lifeless | with comments about it | 02:32 |
| wgrant | It wasn't a bad haproxy config? | 02:34 |
| lifeless | no idea | 02:35 |
| lifeless | till tom comments I can't really tell | 02:35 |
| wgrant | Ah, you bring that up later on, I see. | 02:35 |
| wgrant | lifeless: Seen the RootObject:+login timeouts? | 03:27 |
| lifeless | yes | 03:36 |
| lifeless | oh you mean the new ones | 03:37 |
| wgrant | The ones that show the OpenID association begin taking 10s. | 03:37 |
| wgrant | As expected. | 03:38 |
| lifeless | I filed a bug about pageid not working | 03:38 |
| lifeless | aren't you on leavce today? | 03:38 |
| wgrant | I am, but I couldn't leave #launchpad's commercial query go unanswered. | 03:39 |
| lifeless | fair enough | 03:40 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/770647 | 03:42 |
| lifeless | stuartm has indicated that isd can't spare anyone to work on this for weeks or months | 03:42 |
| lifeless | so I'm going to talk to flacoste about that a little | 03:42 |
| lifeless | and probably escalate the bug about the pageid: scope not working for this page | 03:42 |
| wgrant | i'm intrigued that their primary consumer is not worth the time, but OK. | 03:43 |
| lifeless | not a matter of worth | 03:43 |
| wgrant | I was going to look at the scope issue on Wed anyway. | 03:43 |
| lifeless | same trap LP was in | 03:43 |
| lifeless | every-dev-developing at capacity | 03:43 |
| lifeless | LP was equally totally unresponsive to not-quite-crisis situations until we reorged | 03:44 |
| wgrant | Isn't this a crisis? | 03:44 |
| lifeless | its intruiging that its so precisely 10 seconds | 03:44 |
| wgrant | The point of splitting SSO out was to make it HA :( | 03:44 |
| beuno | to be fair, u1 is a pretty huge consumer (payments, sso) | 03:44 |
| lifeless | wgrant: 50/300000 requests are slow | 03:44 |
| lifeless | wgrant: how was that ever the point ? | 03:45 |
| lifeless | this 10 second thing is -damn -weird | 03:57 |
| wgrant | Checked python-openid for the 10s request timeout it probably has? | 03:58 |
| lifeless | beuno: this is unlikely to be -not- affecting them | 03:58 |
| lifeless | wgrant: it appears to be working | 03:58 |
| wgrant | Or SSO for its 10s statement timeout? | 03:58 |
| lifeless | wgrant: a 10s fail open auth logic would scare me | 03:58 |
| lifeless | (but no, I haven't) | 03:58 |
| wgrant | lifeless: Fail open? | 04:05 |
| wgrant | Howso? | 04:05 |
| lifeless | wgrant: I may be misreading it | 04:11 |
| lifeless | wgrant: but it looks to be completing the handshake when it hits the LP timeout | 04:11 |
| wgrant | lifeless: OpenID is a bit special. | 04:11 |
| wgrant | It will probably fall back to stateless mode if stateful setup fails. | 04:12 |
| wgrant | (in stateful mode the OP signs the response so the RP can verify it itself; stateless requires the RP send the response to the OP for verification) | 04:13 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | \o/ | 04:56 |
| lifeless | total bug aggregates, with privacy, in 50ms | 04:56 |
| lifeless | 223ms for the tag counts | 04:57 |
| * lifeless thinks this will do | 04:57 | |
| LPCIBot | Project windmill build #216: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/216/ | 05:02 |
| jtv | lifeless: https://dev.launchpad.net/Foundations/JobSystem seems to use bug heat calculation as its prime example, but the cron script it refers to doesn't exist. | 06:34 |
| StevenK | Yes, bug heat used to be done via a job, and isn't any more. | 06:36 |
| StevenK | Bug heat is now done via a garbo script | 06:36 |
| lifeless | stub: hi | 07:26 |
| stub | lifeless: yo | 07:27 |
| lifeless | lp:~lifeless/launchpad/bug-758587 has my bugsummary schema | 07:27 |
| stub | Is there a MP up on that? | 07:27 |
| lifeless | I'm still agonising over trigger vs appserver | 07:27 |
| stub | Don't worry, in hindsight you will decide you did it the wrong way no matter which choice you make. | 07:28 |
| lifeless | stub: I'm wondering if you could have a peek at the patch in it (-63-) and see if any direction pops out as better from that, IYO | 07:28 |
| stub | k | 07:29 |
| lifeless | the query table ends up with 1/2 million rows but can answer tag summaries for all of lp in 250ms | 07:30 |
| lifeless | (with privacy) | 07:30 |
| stub | Merging in now. Its good to have a merge proposal flagged WIP so there is always a diff ready. | 07:31 |
| lifeless | loggerhead can dothat on the fly | 07:32 |
| stub | Your indentation sucks :-) viewedby should be viewed_by | 07:32 |
| lifeless | http://bazaar.launchpad.net/~lifeless/launchpad/bug-758587/view/head:/database/schema/patch-2208-63-0.sql | 07:33 |
| stub | That orrible CHECK constraint reminds me we really need a BugTarget table to do that multiplexing instead of having that logic in BugTask, BugSummary and whereever else we do similar. But that is a separate issue. | 07:34 |
| lifeless | yeah | 07:35 |
| lifeless | I considered doing that first | 07:35 |
| lifeless | but decided against it | 07:35 |
| lifeless | http://bazaar.launchpad.net/~lifeless/launchpad/bug-758587/view/head:/database/schema/patch-2208-63-0.sql | 07:35 |
| lifeless | rename done | 07:35 |
| stub | lifeless: We have to have a primary key on the table or replication explodes. | 07:36 |
| lifeless | stub: can that be the unique dimension tuple ? | 07:36 |
| stub | I don't think we have a sane candidate, so likely will need an id column | 07:36 |
| lifeless | COALESCE(product, (-1)), | 07:36 |
| lifeless | COALESCE(productseries, (-1)), | 07:36 |
| lifeless | COALESCE(distribution, (-1)), | 07:36 |
| lifeless | COALESCE(distroseries, (-1)), | 07:36 |
| lifeless | COALESCE(sourcepackagename, (-1)), | 07:36 |
| lifeless | COALESCE(viewed_by, (-1)), | 07:36 |
| lifeless | COALESCE(tag, ('')), | 07:36 |
| lifeless | status, | 07:36 |
| lifeless | COALESCE(milestone, (-1))); | 07:36 |
| stub | Can't do that sorry | 07:37 |
| stub | Need a set of NOT NULL columns that are unique. | 07:37 |
| stub | Maybe that is too strict - I'll need to look up the docs | 07:37 |
| lifeless | http://www.postgresql.org/docs/8.4/static/ddl-constraints.html | 07:37 |
| lifeless | (looking laready) | 07:37 |
| lifeless | ok, I'll add a noddy id | 07:39 |
| lifeless | unless we coalesce on inserts | 07:40 |
| lifeless | and make that simply non-null | 07:40 |
| stub | lifeless: So I'm thinking we should use triggers to cope with simultanous updates. When two threads do UPDATE ... count=count+1, postgresql does all the locking for us. But if out code does SELECT count; update ... set count=:old_count+1, that only works if we are in a serialized transaction (by raising a serializable exception for one transaction and making us retry) | 07:46 |
| stub | appservers would be fine, but scripts run in read committed isolation by default (because they normally don't need the extra isolation and 'retrying the transaction' is non-trivial for many scripts) | 07:48 |
| lifeless | stub: won't triggers end up with relaxed isolation too ? | 07:48 |
| stub | lifeless: No. Triggers run in the same transaction as the rest of the connection. | 07:48 |
| lifeless | stub: thats what I meant | 07:49 |
| lifeless | stub: I should rephrase, how do triggers differ from python code doing read, add, write | 07:49 |
| stub | ahh... but your trigger will do UPDATE BugSummary SET count=count+1 rather than SELECT count FROM BugSummary INTO old_count; UPDATE BugSummary SET count=:old_count + 1 | 07:50 |
| stub | With Storm code, you will likely get the latter structure. So you either need to somehow force storm to do the former, or use raw SQL. | 07:50 |
| lifeless | stub: it needs to be upsert and delsert | 07:50 |
| stub | yucky. | 07:51 |
| lifeless | stub: in that we may not have a row for a given aggregate (no row has count 0) | 07:51 |
| * stub wishes PG had an UPSERT extension | 07:51 | |
| lifeless | stub: and that if the count drops to 0 we need to delete the row (at some point, not necessary to do it immediately) | 07:52 |
| stub | So a proper upsert and delsert in a trigger will do the right thing. | 07:52 |
| stub | One that loops over INSERT and UPDATE until one of them succeeds, such as the example in the PG reference. | 07:53 |
| lifeless | should that be a trigger or a helper function? | 07:54 |
| stub | You usually hand roll the upsert logic in the trigger function. I've not seen a generic upsert that takes a tablename etc. | 07:55 |
| lifeless | http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE | 07:55 |
| stub | That is the one | 07:56 |
| stub | If you need multiple triggers doing the upsert, a helper would be best yes. | 07:57 |
| lifeless | bug | 07:58 |
| lifeless | bugtask | 07:58 |
| lifeless | bugmessage | 07:58 |
| lifeless | bugtag | 07:58 |
| lifeless | bugsubscription | 07:58 |
| lifeless | are the input tables | 07:58 |
| stub | What can create new rows though? BugTask and Milestone I would have thought are the only tables that can trigger creating new rows. | 07:58 |
| lifeless | a new subscription to a private bug | 07:59 |
| stub | k | 07:59 |
| lifeless | toggling a bug from duplicateof to not-a-duplicate | 07:59 |
| lifeless | adding a bugtag | 07:59 |
| stub | oh right... one row per tag. | 07:59 |
| lifeless | stub: how do you normally test trigger based stuff | 08:00 |
| stub | So far, at the higher level. Create an object foo from Python and confirm the FooCache is updated in the following transaction. That way the tests aren't wedded to the trigger implementation. | 08:01 |
| lifeless | ok | 08:02 |
| lifeless | bit late to really fiddle, but I'll get on it tomrrow morning | 08:02 |
| stub | I can't recall if we have UPSERT or similar at the moment, but if we do, we are not trying to engineer a race to test that code path. | 08:02 |
| lifeless | how would decrement-or-delete look like | 08:03 |
| stub | feel free to hand ball it if you want me to work on the triggers. Only thing with a deadline at the moment is the deployment scripts | 08:03 |
| lifeless | decrement; delete from where count=0; return ? | 08:03 |
| stub | I'd just do decrement and have the garbo delete 0 count rows. | 08:03 |
| lifeless | ok | 08:04 |
| lifeless | stub: if you feel like helping with this, awesome | 08:04 |
| stub | I think 'if count == 1 then delete row else update set count=count-1' would work | 08:04 |
| lifeless | stub: just refresh my branch as I pushed that variable rename | 08:05 |
| lifeless | stub: and push your branch before you EOD; I'll pull it back into mine and work on it during my day. | 08:05 |
| stub | ok | 08:05 |
| lifeless | stub: if I don't have mail from you I'll assume you didn't get to it and start on the triggers from scratch | 08:05 |
| stub | right | 08:05 |
| === jam1 is now known as jam | ||
| === almaisan-away is now known as al-maisan | ||
| lifeless | wgrant: why is ppa privacy linked to copyable-to-mainability? | 08:58 |
| wgrant | lifeless: lalalalalalalalalala | 09:03 |
| wgrant | lifeless: You do not want to go there. | 09:03 |
| wgrant | But it's because private->public copies trigger the delayed copy mechanism. | 09:03 |
| wgrant | Which applies overrides and sends announcements. | 09:03 |
| wgrant | Direct copies do not, and delayed copies cannot be explicitly requested. | 09:04 |
| lifeless | so we should always do delayed copies? | 09:04 |
| wgrant | No, delayed copies should die since they are now slower than direct copies. | 09:04 |
| lifeless | This came up because doko wants to let folk see his oni packages | 09:05 |
| wgrant | We just need to port a couple of things into the direct copy logic. | 09:05 |
| wgrant | And then we can abolish delayed copies. | 09:05 |
| wgrant | And the world will be a less nauseating place. | 09:05 |
| lifeless | such as overides and announcements? | 09:05 |
| wgrant | Right. | 09:05 |
| wgrant | And de-restricting the files. | 09:05 |
| wgrant | (currently done by reuploading, but we can just toggle the flag now) | 09:06 |
| wgrant | None of which are at all hard. | 09:06 |
| wgrant | Since the refactoring. | 09:06 |
| mrevell | Hi! | 09:10 |
| adeuring | good morning | 09:12 |
| jtv | hi adeuring | 09:12 |
| adeuring | hi jtv! | 09:12 |
| jtv | wgrant: did you say that publish-distro needs the overrides symlinks? They're still dangling when we do the original publish-distro run, no? | 09:13 |
| wgrant | jtv: It needs them for proper functionality. | 09:13 |
| wgrant | So yes, the first run will be bogus. | 09:13 |
| jtv | Ah | 09:14 |
| jtv | Anyway, no matter actually: I schedule the initial publish-distro runs during i-f-p | 09:14 |
| jtv | Any reviewers out there? https://code.launchpad.net/~jtv/launchpad/db-bug-766807/+merge/59027 | 09:26 |
| jtv | gmb, are you OCR today? | 09:28 |
| wgrant | jtv: Why are we passing in what appears to be a shell command-line? | 09:32 |
| wgrant | Our internal script interfaces should not require such terrors. | 09:32 |
| jtv | wgrant: you mean, to the publish_distro invocation? | 09:33 |
| wgrant | Yes. | 09:33 |
| jtv | For the umpteenth time, it doesn't use our internal script interface. :) | 09:33 |
| jtv | I'd love to clean that up, but not as part of a large feature branch. | 09:33 |
| wgrant | I mean, it doesn't really make sense to call a script from a job. | 09:33 |
| wgrant | It should call some publisher thing with nice arguments, and publish-distro.py is just a wrapper around that. | 09:34 |
| jtv | Well by modern convention we have 3 layers: script, script object, and underlying logic. In this case, there's only script and underlying logic. So I call the underlying logic. | 09:34 |
| wgrant | The underlying logic takes getopt-style arguments? | 09:34 |
| jtv | Yes. :/ | 09:35 |
| * wgrant dies violently. | 09:35 | |
| gmb | jtv: I am, yes. Give me a short while to get sorted and I'll pull your branch from the queue first. | 09:53 |
| gmb | Oh, unless wgrant has dealt with your branch already. | 09:53 |
| LPCIBot | Project windmill build #217: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/217/ | 10:01 |
| wgrant | gmb: Sorry, I'm still on leave, was just doing a quick sanity check of that scary MP. | 10:16 |
| gmb | wgrant: Well, I may punt it yet since I'm just coming back myself. Anyway, ta for checking it | 10:17 |
| gmb | Now bugger off :) | 10:18 |
| gmb | jtv: So, I'm not actually mentally capable of reviewing that yet (and like wgrant, I find it scary). I may take another stab at it in my afternoon, though, but if you find someone else to review it in the meantime that's fine. | 10:23 |
| === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | https://code.launchpad.net/launchpad-project/+activereviews | ||
| jtv | gmb: I doubt I can find anyone else today... if it's any consolidation, this feature is turned off by feature flag so there's time yet to have Julian pass verdict on the design choices. | 10:31 |
| gmb | jtv: Okay. I'll hopefully be back up to speed this afternoon anyway so I'll give it a shot then. | 10:32 |
| jtv | maverless | 10:32 |
| gmb | I'm just struggling to remember how Python works at the moment. | 10:32 |
| wgrant | Oh no. | 10:32 |
| jtv | this sounds bad. | 10:32 |
| gmb | Then I need to re-learn Zope. | 10:32 |
| wgrant | No Julian during release-week. | 10:32 |
| jtv | gmb: okay, so we're talking post-lunch then? | 10:32 |
| wgrant | After the biggest refactoring in history, too :( | 10:32 |
| gmb | jtv: Pretty much :) | 10:32 |
| gmb | wgrant: That sounds like a big, scary, un-fun... | 10:33 |
| jtv | wgrant: the critical stuff is all behind feature flags and unlanded crontabs branches though, right? | 10:33 |
| wgrant | jtv: Right, but distroseries initialisation has still changed massively. | 10:33 |
| wgrant | I guess we'll still have to use the manual script for now, though? | 10:33 |
| * jtv nods unsmilingly | 10:33 | |
| wgrant | And just hope it works? | 10:33 |
| jtv | wgrant: which manual script do you mean? | 10:33 |
| wgrant | initialise-from-parent.py | 10:34 |
| jtv | wgrant: I haven't landed any chances to that one, personally... wouldn't know what others might have done to it. | 10:35 |
| wgrant | It's been mostly rewritten. | 10:35 |
| jtv | ah | 10:35 |
| jtv | So that old-school non-LaunchpadScript script is probably still needed, rather than the job runner? | 10:35 |
| wgrant | I don't trust that the jobrunner is going to be usably tested by Thursday. | 10:36 |
| wgrant | Unless you know otherwise? | 10:36 |
| jtv | Nope | 10:36 |
| jtv | In fact there's a ticket marked "PLEASE QA THIS WHILE I'M AWAY." | 10:37 |
| wgrant | Forboding. | 10:37 |
| jtv | wgrant: any objects to me restarting the df app server? | 10:37 |
| wgrant | jtv: None. | 10:37 |
| jtv | wgrant: where was our wiki page full of recipes such as "what to pay attention to when restarting the app server" again? | 10:39 |
| wgrant | https://wiki.canonical.com/Launchpad/Soyuz/CommonTasks | 10:39 |
| jtv | Thanks. | 10:40 |
| jtv | I was searching for "Routine." | 10:40 |
| LPCIBot | Project windmill build #218: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/218/ | 10:42 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | night | 11:49 |
| === Ursinha-afk is now known as Ursinha | ||
| deryck | Morning, all. | 11:58 |
| wgrant | rvba: I've replied to your email with something hopefully not entirely unhelpful. | 11:59 |
| rvba | wgrant: I'm reading it ... thanks a lot ... since I'm relatively new to all this, having as much information as possible about the problem is really helpful. | 12:00 |
| rvba | wgrant: besides, I reckon you're right and the whole subject is very much involved ... it's a good thing to try to see the various aspects of the problem before jumping into the actual coding :) | 12:02 |
| wgrant | rvba: Yeah, it's a complex issue with unclear constraints. | 12:02 |
| wgrant | Nobody knows what they want. | 12:02 |
| wgrant | Particularly us. | 12:02 |
| rvba | :) | 12:03 |
| Ursinha | bug 757426 bug 750445 | 12:09 |
| _mup_ | Bug #757426: Distribution:+bugs timeout with combinator ALL <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/757426 > | 12:09 |
| _mup_ | Bug #750445: MaloneApplication:+bugs timeout on 'any tag {pcert, blockshwcert}' <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/750445 > | 12:09 |
| === almaisan-away is now known as al-maisan | ||
| bac | hi gmb, could you have a look at https://code.edge.launchpad.net/~bac/launchpad/bug-770248/+merge/59047 when you have a moment? | 13:06 |
| gmb | bac: Sure | 13:11 |
| gmb | bac: is FeatureFixture({'foo': 'bar'}) now our preferred way of doing things throughout LP? | 13:12 |
| gmb | (well, in tests, that is) | 13:12 |
| bac | gmb: last week benji and i looked at some tests using "with feature_flags" where some stuff was done in setUp inside a context manager that terminated. we were surprised at the way it worked. | 13:14 |
| bac | i find the FeatureFixture context manager to be unambiguous and unsurprising | 13:14 |
| gmb | Ah, right. Good to know. | 13:14 |
| bac | so i'd be +1 for making it the preferred way to do things | 13:14 |
| gmb | bac: It might be worth telling launchpad-dev about it, then (you may already have done this; I've been skipping over not to-me emails this morning). | 13:15 |
| bac | gmb: good point | 13:15 |
| gmb | bac: test_bug_mute_for_individual_structural_subscription() needs a comment explaining the expected behaviour. Otherwise, r=me. | 13:17 |
| bac | gmb: thanks, will do | 13:17 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| deryck | adeuring, I lost you? | 14:02 |
| adeuring | deryck: strange. I can see you in mumble | 14:02 |
| adeuring | I'll restart mumble | 14:02 |
| deryck | adeuring, ok | 14:03 |
| deryck | let me restart too | 14:04 |
| deryck | adeuring, I'm having issues, sorry | 14:05 |
| * adeuring too... | 14:05 | |
| wallyworld | gmb: hi. i have a large mp for review. the reason it's so many lines is that there's ~500 lines of new tests and cut'n'paste refactoring of some content. the actual real changes aren't too scary I hope | 14:30 |
| wallyworld | https://code.launchpad.net/~wallyworld/launchpad/filebug-loses-data/+merge/58410 | 14:30 |
| gmb | wallyworld: Hmm. Is there any way you can split that up? Does the refactoring have to happen in the same branch for the tests to pass? | 14:32 |
| gmb | 1700+ lines is more than I can get done today, I think. | 14:32 |
| wallyworld | gmb: sadly the tests won't pass without the refactoring. they were specifically written to check tat the new stuff works. the exisiting tests were relied on for regression testing. no prob about not doing it today. i just saw you as oc and thought i'd given you a reason why it is so long instead of you just seeing it and going wtf | 14:34 |
| gmb | wallyworld: Fair enough. You may be better off arranging with someone on your squad to review the branch, given its size (That's what we Yellow squadders did with the 1800-odd line chunks of JS that were written for the advanced structural subscriptions work). | 14:36 |
| wallyworld | gmb: good idea :-) i'll do that. thanks. | 14:37 |
| gmb | np | 14:37 |
| rvba | gmb: Hi, could you take a look at https://code.launchpad.net/~rvb/launchpad/deriv-ui-fixes/+merge/58793 ? | 15:02 |
| rvba | gmb: this is a tiny branch that fixes a few UI gliches on the pages related to the derivation work, I deliberately did not file a bug for every single one of these bugs because I'm not sure it's worth the bother, but tell me if you think otherwise | 15:03 |
| gmb | rvba: Sure, I'll take a look at that now. | 15:26 |
| rvba | thanks | 15:26 |
| gmb | rvba: I know that bigjools suggested it in the bug, but I think "Commence Initialization" isn't a good choice of wording for the button. It sounds pretty formal (and a bit silly). It would make more sense to have the help text read something like: | 15:32 |
| gmb | "Note that initialization is not instantaneous; initializing with many thousands of packages is likely to take hours to complete." | 15:33 |
| gmb | And leave the button as it is already. | 15:33 |
| gmb | rvba: How's that sound? | 15:33 |
| rvba | gmb: sound good to me! | 15:33 |
| rvba | s/sound/sounds | 15:33 |
| gmb | rvba: Cool. I'll comment in the merge proposal but otherwise this is r=me with that change. | 15:34 |
| rvba | gmb: thanks a lot, I'll make the change and land this. | 15:34 |
| MTecknology | hardest part about recipe builds..... versions | 15:52 |
| MTecknology | 1.0.0-0ppa1 is the latest LP but the next version could be 1.1.0 or 1.0.1 or 2.0.0... either way, this snapshot will always be ahead of that.. | 15:53 |
| MTecknology | 99.0.0-0~{revno}+{time} seems kinda reasonableish | 15:53 |
| MTecknology | or s/99/10/ ? | 15:53 |
| MTecknology | idk... | 15:53 |
| sinzui | jcsackett: do you have time to mumble? | 15:57 |
| jcsackett | sinzui: sure. | 15:57 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === deryck is now known as deryck[lunch] | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| jcsackett | sinzui: have a moment to mumble again? | 16:39 |
| benji | gmb: I have a quick review for you when you get a chance: https://code.edge.launchpad.net/~benji/launchpad/bug-771269/+merge/59090 | 16:41 |
| gmb | benji: Sure | 16:41 |
| gmb | benji: r=me. | 17:01 |
| benji | thanks | 17:03 |
| === al-maisan is now known as almaisan-away | ||
| gary_poster | gmb, https://code.launchpad.net/~gary/launchpad/bug731099/+merge/59098 if you have a chance, though I am running to lunch now. back in a bit | 17:19 |
| gmb | gary_poster: I'll take a look now. Nice way to finish my day. | 17:23 |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| MTecknology | When it comes to building recipes; why is there not a prebuilt environment with packages already installed that are always needed, and why are they removed on exit; would perhaps it not be best to just purge this rather than remove pieces from the chroot type system and then remove all the same? | 17:40 |
| MTecknology | just thoughts.. | 17:41 |
| gmb | gary_poster: r=me. | 17:50 |
| * gmb goes off call; EODs. | 17:50 | |
| === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === Ursinha is now known as Ursinha-lunch | ||
| === beuno-lunch is now known as beuno | ||
| NCommander | wgrant (or anyone knowable in Soyuz) how far implemented was NativeSourceSync? | 18:55 |
| LPCIBot | Project windmill build #219: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/219/ | 19:47 |
| allenap | Does anyone have 5 minutes to review a 38-line proposal, all Javascript? https://code.launchpad.net/~allenap/launchpad/deriveDistroSeries-json-weirdness-bug-753249/+merge/59120 | 20:41 |
| gary_poster | allenap, I'll do it. | 20:53 |
| allenap | Cheers gary_poster :) | 20:53 |
| gary_poster | allenap, r=me, with some maybe-lint blather | 21:00 |
| allenap | gary_poster: Thanks. | 21:00 |
| gary_poster | np :-) | 21:01 |
| lifeless | jcsackett: g'day | 21:04 |
| jcsackett | lifeless: 'ello. | 21:04 |
| lifeless | jcsackett: just touching base to make sure my follow-up on your bug-comments-seen-by-registry did reach you | 21:04 |
| lifeless | jcsackett: and to note that the same issue applies to questions & visibility ;) | 21:05 |
| jcsackett | lifeless: no i didn't see it. reading now. | 21:06 |
| jcsackett | lifeless: noted on the collection bit. i can see the possibility of follow up branches or bug report for this, but i think it's lower priority than finishing (an already falling out of scope) piece of work before we go off maintenance. | 21:08 |
| jcsackett | i *hope* to be in a place where all of this is shiny by the end of the week, in which case i'll be in a good spot to address the collection thing. | 21:09 |
| lifeless | jcsackett: I leave those calls to you and sinzui | 21:09 |
| lifeless | jcsackett: I don't intend to make the scope bigger | 21:09 |
| jcsackett | lifeless: oh, no worries. it did that all by itself. :-) | 21:09 |
| lifeless | jcsackett: can you make sure its captured one way or another though? | 21:09 |
| jcsackett | lifeless: absolutely. | 21:09 |
| lifeless | great, thanks | 21:09 |
| jcsackett | per the notes on the tests: good points, all, and thanks. | 21:10 |
| === almaisan-away is now known as al-maisan | ||
| lifeless | sinzui: how does one create a project group ? | 21:38 |
| sinzui | /projectgroups/+new | 21:38 |
| lifeless | sinzui: could we link that to <only authorised> folk in the links-to-new-pillars-portlet ? | 21:42 |
| sinzui | it isn't | 21:42 |
| sinzui | ? | 21:42 |
| * sinzui loods | 21:42 | |
| sinzui | looks | 21:42 |
| lifeless | its not in https://launchpad.net/ | 21:43 |
| sinzui | https://launchpad.net/projectgroups | 21:43 |
| sinzui | lifeless: The lp frontpage is an example of something posted to fail.blog | 21:43 |
| lifeless | ha, ok | 21:44 |
| lifeless | so | 21:44 |
| lifeless | https://launchpad.net/projects | 21:44 |
| sinzui | It does little that anyone need | 21:44 |
| lifeless | the portlets on the side are a little weird | 21:44 |
| lifeless | they *look* like the let you create anything | 21:44 |
| lifeless | but really its just teams + the collection-you-are-on ? | 21:44 |
| sinzui | such as locate project groups, users, teams, distributions, projects Or work with questions, bugs, blueprints, code, translations. | 21:45 |
| sinzui | We should throw that page away tomorow | 21:45 |
| sinzui | lifeless: We changed the front page days before releases 3.0. the intent before that page was to link to the top level collections on two axises. Apps and pillar/person collections. You would be able to move between the pillar/person collections once you were in one | 21:46 |
| lifeless | anyhow, Ihave helped our user and will remember I hope enough to do so next time | 21:46 |
| lifeless | sinzui: maybe its just me, but isn't a facet based search nicer for users? /?filter=projects&projectgroups | 21:47 |
| sinzui | Sure. Someone just need to commission the development. | 21:48 |
| sinzui | I wanted to extend the generic page search and object lookup with an expandable form that that revels specific search for pillar, person, an packages | 21:49 |
| lifeless | sounds useful | 21:50 |
| lifeless | I'm not sure we're allowed to do that :P | 21:50 |
| sinzui | I thinks so. That aspect was not in scope when we added google in 2009, but it was in our minds | 21:51 |
| sinzui | I am pretty sure such as feature needs user testing *before* we build it. That is a large barrier to JFDI | 21:52 |
| lifeless | I think user testing would be needed for some aspects of it | 21:53 |
| lifeless | but others - like a single filterable collection for people.teams.projects.groups.ppas.archives.builders would be jfdiable I think | 21:53 |
| === al-maisan is now known as almaisan-away | ||
| * maxb wonders if anyone actually uses the bzr-lpreview-body package? | 22:49 | |
| maxb | Given that it apparently has never actually installed in a way that it will work | 22:50 |
| === salgado is now known as salgado-afk | ||
| huwshimi | Morning | 23:20 |
| lifeless | lolololol | 23:52 |
| lifeless | https://bugs.launchpad.net/beeseek-peer/+bug/182821 | 23:52 |
| _mup_ | Bug #182821: Honeybee does not show some pages correctly <BeeSeek Peer (obsolete):Fix Released by andrea.corbellini> < https://launchpad.net/bugs/182821 > | 23:52 |
| lifeless | wallyworld: ^ | 23:52 |
| * wallyworld looks | 23:53 | |
| lifeless | wallyworld: I was looking at bug https://bugs.launchpad.net/launchpad/+bug/2672 | 23:54 |
| _mup_ | Bug #2672: Bug tasks are displayed against inactive upstreams <lp-bugs> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/2672 > | 23:54 |
| wallyworld | lifeless: i think the lp bug above is fixed with the mp i did recently. sounds like a dup. i'll check and can mark it as such | 23:55 |
| lifeless | wallyworld: I've closed the bug | 23:56 |
| lifeless | wallyworld: I was laughing at the display | 23:56 |
| lifeless | wallyworld: I *thought* we were going to show the tasks to registry admins | 23:56 |
| * wallyworld looks again | 23:56 | |
| lifeless | wallyworld: when I look at the bug, I see zero bugtask rows. | 23:56 |
| wallyworld | lifeless: ah i see now. we need a better display of info when there are no matching bug tasks don't we | 23:58 |
| lifeless | wallyworld: Well, I thought the idea was to show them to registry admins | 23:58 |
| lifeless | I'm not sure whats up ;) | 23:58 |
| lifeless | wallyworld: anyhow, I'm not suggesting you do anything, just lolllling | 23:58 |
| wallyworld | lifeless: the BugTaskSearch of whatever it's called is used and i don't think it does show them to admins | 23:59 |
| lifeless | yup | 23:59 |
| lifeless | separate problem, *if* we care to fix it | 23:59 |
| wallyworld | so whatever that bit of infrastructure does under the hood is what we get :-) i see the why you were amused | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!