| sinzui | wgrant, mumble? | 00:18 |
|---|---|---|
| LPCIBot | Project windmill-db-devel build #320: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/320/ | 00:21 |
| abentley | lifeless: re your service-based Launchpad idea, it would be really nice to eliminate branch scanning and just have a service to query the branches. | 00:31 |
| * wallyworld_ needs caffeine stat! | 00:40 | |
| * thumper passes wallyworld_ the IV | 00:41 | |
| lifeless | abentley: In principle yes | 00:56 |
| lifeless | abentley: I wonder if bzr is quite fast enough yet | 00:57 |
| lifeless | abentley: I think there are some things we'd want to have caches for - e.g. 'show me branches that have new work' might want a fast graph query | 00:58 |
| mwhudson | a nice thing about a SOA is that you can make that change independent of more or less everything else | 00:58 |
| lifeless | yes indeed! | 00:58 |
| LPCIBot | Project windmill-devel build #132: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/132/ | 01:37 |
| abentley | lifeless: I think that it probably is fast enough, considering there's no invocation time. Fast graph traversal is a service you were already going to provide, right? | 01:41 |
| abentley | lifeless: by invocation, I mean bzrlib import cost. | 01:42 |
| lifeless | abentley: right; I think it depends on the particular bit of bzrlib we're talking about | 01:42 |
| lifeless | abentley: things like extracting a file can still do substantial IO, grabbing a revision should be pretty quick | 01:43 |
| lifeless | abentley: and it will depend on what we're doing whether a particular thing works / doesn't. | 01:43 |
| lifeless | abentley: where it will, I think using the branches directly is a good idea. | 01:43 |
| abentley | lifeless: The data we currently retrieve from scans doesn't include files, though. It's mostly revision ids and a revision graph. | 01:44 |
| lifeless | abentley: given the complexity of bzrlib, memory footprint etc, I'd be inclined to have a webservice - say loggerhead :) - providing this, and it be backed by the raw branches | 01:44 |
| abentley | lifeless: Yes, this is what I meant by "a service to query the branches". I didn't mean using the bzr protocol. | 01:45 |
| lifeless | abentley: we may still need scanning to populate a graph cache for graph queries, but it could stop being relevant for viewing the recent commits in the web UI | 01:45 |
| lifeless | abentley: cool | 01:46 |
| lifeless | abentley: did you know loggerhead has a json API already? | 01:46 |
| abentley | lifeless: You did mention it before, but I hadn't thought about it. | 01:46 |
| wgrant | How complete is it? | 01:46 |
| lifeless | topically, gustavo wants an API to query branch revision tips for principia | 01:47 |
| abentley | lifeless: providing that service via loggerhead makes sense, *iff* we have a well-behaved, performant loggerhead. | 01:47 |
| lifeless | wants a collection of (branch url, revid) | 01:47 |
| lifeless | wgrant: its minimal; easy to extend though | 01:47 |
| wgrant | True. | 01:48 |
| lifeless | wgrant: we'd need to add something for private branch lookups if appservers do them | 01:48 |
| === mwhudson_ is now known as mwhudson | ||
| wgrant | Hm. | 01:53 |
| wgrant | Looks like staging updates are working fine, but the code isn't being synced beforehand? | 01:54 |
| lifeless | scripts/update-bzr-version-info.sh | 01:57 |
| lifeless | Creating bzr-version-info.py at revno 10574 | 01:57 |
| lifeless | I bet its the config-manager change on carob | 01:57 |
| lifeless | spm! | 01:57 |
| wgrant | successful-updates.txt shows it updated to 10574 for the second time several hours after a new rev was blessed. | 02:00 |
| wgrant | So I'm pretty sure that's it. | 02:00 |
| wgrant | sinzui: Sorry I missed the call this morning. | 02:00 |
| wgrant | sinzui: Did you make any progress on the picker issue? | 02:00 |
| wgrant | I think we basically need to completely rethink it before we can make any progress. | 02:01 |
| lifeless | wgrant: we had nothing blessed for 5 days ? | 02:01 |
| wgrant | lifeless: 10578 was only bleesed May 22 23:32 | 02:03 |
| lifeless | wgrant: which is still 3 days ago | 02:03 |
| wgrant | Sure. We've had stuff blessed since. | 02:04 |
| wgrant | But potentially only a single update has failed to update the code. | 02:04 |
| wgrant | Since the 2011:05:23 13:21 update could have started before 23:40 | 02:04 |
| lifeless | the update on the 24th | 02:06 |
| lifeless | saw rev 10574 | 02:06 |
| lifeless | on sourcherry | 02:06 |
| wgrant | Right. | 02:07 |
| wgrant | And that's the only failed update we have evidence of. | 02:07 |
| lifeless | cody-somerville: ping | 02:33 |
| lifeless | bug 787765 - can you tell me the figure you see under '79 queries/external actions issued in 0.85 seconds' on the page that was/is failing ? | 02:33 |
| _mup_ | Bug #787765: ProductSeries:+index timeouts <oem-services> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/787765 > | 02:33 |
| lifeless | cody-somerville: and can you reproduce it on qastaging | 02:33 |
| cody-somerville | lifeless, under? | 02:41 |
| lifeless | cody-somerville: what that text shows for you :) | 02:42 |
| cody-somerville | ah | 02:42 |
| cody-somerville | '4 queries/external actions issued in 0.14 seconds' | 02:42 |
| lifeless | cody-somerville: timeout though, right ? | 02:42 |
| cody-somerville | lifeless, yup | 02:42 |
| cody-somerville | lifeless, And it does load on qastaging. | 02:42 |
| lifeless | cody-somerville: can you get a profile on qastaging ? | 02:42 |
| cody-somerville | oh wait, my bad. Was loading wrong milestone on qastaging. | 02:44 |
| cody-somerville | It timesout on qastaging as well | 02:44 |
| lifeless | cody-somerville: can you add me as a driver on qastaging? | 02:44 |
| cody-somerville | lifeless, Sure. FYI, the project page is timing out on qastaging.launchpad.net as well but not every time. | 02:46 |
| cody-somerville | (https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1971QASTAGING19) | 02:46 |
| cody-somerville | lifeless, Done. Added 'lifeless' to oem-solutions-releng team on qastaging. | 02:47 |
| lifeless | 16 0 7.5976 0.1703 lp.bugs.browser.structuralsubscription:431(expose_user_administered_teams_to_js | 02:47 |
| lifeless | cody-somerville: you're in lots of teams aren't you ;) | 02:49 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| cody-somerville | lifeless, 225 | 02:50 |
| cody-somerville | (indirect + direct) | 02:50 |
| lifeless | do you know how many you have admin access over ? | 02:51 |
| cody-somerville | lifeless, Administrator of 15, Owner of 17. | 02:53 |
| cody-somerville | (cut, grep, and wc for the win!) | 02:53 |
| lifeless | heh | 02:53 |
| lifeless | that probably fails the indirect test | 02:53 |
| lifeless | anyhow | 02:53 |
| cody-somerville | ah, true, I could have used grep to instead of wc | 02:54 |
| cody-somerville | *to count | 02:54 |
| cody-somerville | And could have used a regular expression instead of cut to make sure I was looking at the right field | 02:55 |
| * StevenK hands cody-somerville a 'pointless pipe' award | 02:55 | |
| LPCIBot | Project windmill-db-devel build #321: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/321/ | 02:55 |
| wgrant | wallyworld_: How's your picker stuff going? | 02:57 |
| wallyworld_ | wgrant: been tied up doing other stuff - revising popup field name branch, doing a feature flag branch for disclosure, seperating out a separate branch for the irc nick formatter etc | 02:59 |
| wgrant | wallyworld_: Ah, right. | 02:59 |
| wgrant | wallyworld_: It seems to me that we're not going to get very far by treating the search/rank/affiliation issues separately. | 02:59 |
| lifeless | wow, slow | 02:59 |
| lifeless | 190530 0 3.2106 1.3876 +storm.properties:51(__get__) | 02:59 |
| wgrant | We have a set of requirements and seem to be jumping into designing these three things separately. | 03:00 |
| wgrant | Without actually really thinking about how they will work together. | 03:00 |
| lifeless | cody-somerville: so this is easy fixed | 03:00 |
| wallyworld_ | wgrant: did you know there's a FormattersAPI class which is supposed to handle escaping of invalid html ids. but it doesn't ensure uniqueness | 03:00 |
| lifeless | cody-somerville: care to put the patch up? | 03:00 |
| wgrant | wallyworld_: I didn't! | 03:00 |
| wgrant | wallyworld_: That's somewhat unpleasant. | 03:00 |
| lifeless | its probably the root cause for a half dozen timeouts | 03:00 |
| wallyworld_ | wgrant: curtis mentioned it in reviewing the mp | 03:01 |
| wallyworld_ | wgrant: with the picker stuff, i think we can do alliliation separately from search/rank. affiliation will be expensive, but we will only need to do it for each batch of 6 or whatever results | 03:02 |
| wallyworld_ | potentially expensive | 03:02 |
| wgrant | wallyworld_: I don't think that's the case. | 03:02 |
| wgrant | wallyworld_: We need to be able to filter by affiliation, or at least rank by it. | 03:03 |
| wgrant | Search for "william" on a Launchpad bugtask. | 03:03 |
| wgrant | That's clearly wrong. | 03:03 |
| wallyworld_ | hmmm. that will complicate things for sure | 03:03 |
| wgrant | Exactly. | 03:03 |
| cody-somerville | lifeless, Ugh, sure! :-) | 03:03 |
| wgrant | The search at the moment is useless. | 03:04 |
| wgrant | It finds the 100 most relevant results, then orders them by displayname. | 03:04 |
| wallyworld_ | we will need to consider denormalising the data model in that case to make affiliation easy to get | 03:04 |
| wgrant | Possibly, but we first need to consider what we *want*. | 03:04 |
| wallyworld_ | agreed | 03:04 |
| wgrant | Do we want ranking, do we want filtering, or what? | 03:04 |
| wallyworld_ | no question there | 03:04 |
| wallyworld_ | wgrant: that's what the product team needs to feed us - requirements :-) | 03:04 |
| lifeless | cody-somerville: we're doing 64K __eq__ calls | 03:05 |
| wgrant | wallyworld_: Are those requirements, or design? | 03:08 |
| StevenK | Can haz review from someone? | 03:08 |
| wgrant | wallyworld_: The only real requirement is that it returns "good" results. :) | 03:09 |
| StevenK | +13/-0 | 03:09 |
| lifeless | wgrant: wallyworld_: can I be of assistance? | 03:09 |
| wallyworld_ | requirements. ie what we need to deliver as opposed to how to do it | 03:09 |
| wgrant | wallyworld_: This is part-way between requirements and design, IMO. | 03:09 |
| wallyworld_ | lifeless: we are pondering the new search behaviour of the picker | 03:10 |
| wgrant | Because currently it is useless unless you type the full username or displayname. | 03:10 |
| wallyworld_ | wgrant: not sure i agree :-) i think we need to be clear about what we need to deliver, not how to do it | 03:10 |
| wgrant | wallyworld_: You have a branch to stop using Person.fti, right? | 03:11 |
| wallyworld_ | wgrant: yes, in ec2 now | 03:11 |
| wgrant | wallyworld_: Have you tested how that works in practice? | 03:11 |
| wgrant | wallyworld_: I think it will eliminate displayname matching. | 03:11 |
| wgrant | Which would be a very bad thing. | 03:11 |
| wallyworld_ | wgrant: well, i ran it locally and tried a couple of searches with and without the fti removed and they appear to behave the same | 03:11 |
| wgrant | wallyworld_: I don't see where it does a displayname search. | 03:12 |
| wgrant | Apart from fti (which is name, displayname) | 03:12 |
| wallyworld_ | i can't recall if i checked display name matching. i'll have another look | 03:12 |
| wallyworld_ | to be sure | 03:12 |
| wgrant | But the query is obscene, so it's a bit hard to tell :/ | 03:13 |
| * wgrant tries. | 03:13 | |
| cody-somerville | lifeless, I've got to take the garbage out and then I need to head to bed but I'll push a branch with a patch tomorrow morning if someone else hasn't gotten around to it. Kudos for looking into this. :-) | 03:13 |
| lifeless | cody-somerville: I've finished capturing my learnings | 03:16 |
| lifeless | cody-somerville: if you need a hand, just shout | 03:16 |
| * cody-somerville nods. | 03:16 | |
| wgrant | wallyworld_: So, back to affiliation for a sec: yes, it's easy to just show the affiliation of the current six, but that doesn't help if I have to scroll through 10 non-deterministic batches to find the right person :/ | 03:16 |
| wgrant | (yes, it is actually non-deterministic, it seems :/) | 03:17 |
| lifeless | wgrant: wallyworld_: is there a LEP ? | 03:17 |
| wgrant | TrustedPickers | 03:17 |
| wallyworld_ | wgrant: yes, i agree that we may want to sort by affilliation. that is not something i was previously considering | 03:17 |
| wgrant | https://dev.launchpad.net/LEP/TrustedPickers | 03:17 |
| wgrant | Ahh, https://dev.launchpad.net/LEP/TrustedPickersUseCases doesn't seem to be linked from anywhere. | 03:18 |
| wgrant | But is useful. | 03:18 |
| wgrant | It has a usecase like the one I raised | 03:19 |
| wgrant | StevenK: Can I revert your changes on DF? | 03:19 |
| wgrant | Looks like it's just that merge from yesterday. | 03:19 |
| lifeless | what defines affilate? | 03:20 |
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| lifeless | I'm worried about the use of irc handles, maybe I'm cracked | 03:21 |
| wgrant | lifeless: Probably membership in a team related to the project. | 03:21 |
| wgrant | But then we may well also want a Canonical affiliation, so that falls apart. | 03:21 |
| StevenK | wgrant: Sure | 03:27 |
| wallyworld_ | lifeless: getFeatureFlag. i want to add a variant which returns a user specified default value if features.getFlag() returns None. i'd like to add this to lp.services.features.__init__. but i think you disagree about doing that there? | 03:28 |
| StevenK | jtv: Can haz review? | 03:28 |
| jtv | StevenK: when I finish my current one, sure | 03:28 |
| lifeless | wallyworld_: why do you want to do that ? | 03:28 |
| lifeless | wallyworld_: what problem are you solving? | 03:28 |
| wgrant | StevenK: Thanks. | 03:29 |
| wallyworld_ | lifeless: i have an int feature flag and i don't want to do what was done in archive.py | 03:29 |
| wallyworld_ | limit = getFeatureFlag(FEATURE_FLAG_MAX_SYNCHRONOUS_SYNCS) | 03:29 |
| wallyworld_ | try: | 03:29 |
| wallyworld_ | limit = int(limit) | 03:29 |
| wallyworld_ | except: | 03:29 |
| wallyworld_ | limit = 100 | 03:29 |
| lifeless | wallyworld_: you'll still need that code | 03:29 |
| lifeless | wallyworld_: because crap might be entered in | 03:30 |
| wallyworld_ | not if i can specify a default as in myflag = getFeatureFlag('flagname', 1) | 03:30 |
| lifeless | wallyworld_: I'm totally happy with folk layering convenience functions; I'm unhappy with folk embedding schemas in it | 03:30 |
| lifeless | wallyworld_: thats not sufficient to remove the try:except: | 03:30 |
| wallyworld_ | sure, i'd do the try except inside the getFeatureFlag | 03:31 |
| wallyworld_ | and maybe name the function getIntFeatureFlag | 03:31 |
| lifeless | wallyworld_: I think thats a bad idea because it hides the ability to tell whats going on, and the casting you want isn't related to feature flags | 03:31 |
| lifeless | wallyworld_: I think you want a safe_int(value, default=0) function | 03:32 |
| wallyworld_ | hmmm. i think it is because we specify the type of feature flag - boolean, string, int etc - so there should be relevant methods to get flags cast to the expected type | 03:32 |
| wallyworld_ | safe_int works for me | 03:33 |
| wgrant | wallyworld_: That type is just documentation. | 03:33 |
| lifeless | well, the type is crufty and I'm not 100% on board with it being there | 03:33 |
| lifeless | but I support folk doing what they think makes sense ;) | 03:33 |
| wallyworld_ | not sure why you dislike it. it serves a good purpose | 03:34 |
| wallyworld_ | can i add safe_int to features __init__ ? | 03:34 |
| lifeless | wallyworld_: I don't think it belongs in features | 03:34 |
| lifeless | theres probably an implementation in the tree already | 03:34 |
| lifeless | in a util or misc or helpers or some such module alrady | 03:35 |
| lifeless | wallyworld_: i dislike it because typing drives the requirements -way- up for very little win. | 03:35 |
| wallyworld_ | fair enough. will look. i wasn't going to call it safe_int if it were in feaures init :-) | 03:35 |
| wallyworld_ | i can't yet bring myself agree with that :-) | 03:36 |
| lifeless | wallyworld_: I'm totally in favour of the documentation we have | 03:36 |
| wallyworld_ | i like the doco too. but if it makes sense to define a flag as an int, we should easily be able to treat it as such | 03:37 |
| wallyworld_ | s/treat/use | 03:37 |
| wgrant | wallyworld_: You may want to kill that ec2 instance before it lands. | 03:37 |
| wgrant | wallyworld_: Try searching for "william grant" in the assignee picker on https://bugs.dogfood.launchpad.net/launchpad/+bug/1234 | 03:38 |
| _mup_ | Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 > | 03:38 |
| wallyworld_ | wgrant: sure. i had retested yet. was on my todo :-) display name matching broken then i assume | 03:39 |
| wallyworld_ | ? | 03:39 |
| wgrant | wallyworld_: Yeah :( | 03:39 |
| wgrant | I'm not sure why it returns what it does, but it's certainly not right! | 03:40 |
| wallyworld_ | wgrant: bollocks. i'll look at modifying the query to specifcally match displayname | 03:40 |
| wgrant | wallyworld_: We probably still need FTI over that. | 03:40 |
| wgrant | wallyworld_: And Person.fti is already over just name and displayname. | 03:40 |
| wgrant | So we probably want an index on Person.fti instead. | 03:41 |
| wgrant | (which dev and DF already have, but production doesn't) | 03:41 |
| wallyworld_ | really? | 03:41 |
| wallyworld_ | why not production? | 03:41 |
| wgrant | Because production lacks it. | 03:41 |
| wgrant | It only exists on DF because I created it yesterday totest :) | 03:41 |
| wgrant | No idea why :/ | 03:42 |
| lifeless | we can add that now, losas are around | 03:42 |
| wgrant | True. | 03:42 |
| wallyworld_ | are we sure it wouldn't be better just to say (pseudo) 'xxxx where name like ? or displayname like ?' | 03:42 |
| lifeless | wgrant: how big is it on df ? | 03:42 |
| wgrant | lifeless: Most will only have three terms, so it should be small, but let's see. | 03:43 |
| lifeless | \di+ person_fti | 03:43 |
| lifeless | wallyworld_: there is no index on display name | 03:43 |
| wallyworld_ | doesn't seem worth the cost of creating and maintaining a fti over just two simple string fields? | 03:43 |
| wgrant | 49MB | 03:44 |
| lifeless | wallyworld_: fred bloggs should match fred J bloggs | 03:44 |
| wgrant | wallyworld_: But how do you propose to do a full-text search of displayname? | 03:44 |
| wgrant | Without an FTI index? | 03:44 |
| wgrant | Right, what lifeless said. | 03:44 |
| lifeless | wgrant: from the perspective of a user doing a search | 03:44 |
| lifeless | wallyworld_: and foo%bar style searches are terribly slow | 03:44 |
| wgrant | lifeless: Hm? | 03:44 |
| wallyworld_ | fair enough. | 03:45 |
| lifeless | wgrant: wildcard searches are not indexed | 03:45 |
| lifeless | wgrant: literal prefixes sometimes use indices | 03:45 |
| lifeless | ok on the LEP | 03:46 |
| lifeless | Must point 1 | 03:46 |
| lifeless | I think is over broad | 03:46 |
| lifeless | I would say that the information which lead to a *hit* must be shown | 03:46 |
| lifeless | which is not the same as showing all the possible things we search on on every hit | 03:46 |
| lifeless | secondly, point 2: will require a new cached data structure | 03:47 |
| wgrant | Agreed | 03:47 |
| lifeless | wgrant: agreed on 1 or 2 or both ? | 03:48 |
| wgrant | I don't agree that 2 needs a new datastructure, unless we want to search/rank on it, which we probably do. | 03:48 |
| lifeless | wgrant: ' previous bug assignee' | 03:49 |
| lifeless | wgrant: + Ubuntu | 03:49 |
| wgrant | Ah, missed that. | 03:49 |
| wgrant | Ubuntu? | 03:49 |
| lifeless | Ubuntu scope searches | 03:49 |
| wgrant | What about them? | 03:49 |
| lifeless | 400K bugs to consult to find previous bug assignees | 03:49 |
| wgrant | Right. | 03:49 |
| wgrant | I hadn't considered the assignee case. | 03:50 |
| lifeless | I suspect we want to expose whatever thing we have an let folk delete inappropriate things | 03:50 |
| lifeless | but thats a different discussion | 03:50 |
| wallyworld_ | lifeless: perhaps a case for a new service :-) | 03:51 |
| lifeless | perhaps | 03:51 |
| lifeless | I think it would fit well in a services model | 03:51 |
| wgrant | lifeless: Right, if we have assignees then we very probably want to permit manual administration. | 03:52 |
| wallyworld_ | yep, especially since there will likely need to be a (denormalised) data model to go with it | 03:52 |
| wgrant | lifeless: Shall we hijack a LOSA to 'CREATE INDEX person_fti ON person USING gist (fti);'? | 03:53 |
| wallyworld_ | lifeless: btw, found intOrZero() and friends in canonical.lp.helpers.py | 03:53 |
| lifeless | wallyworld_: hahahahaha :> | 03:53 |
| wgrant | canonical.lp buuuuuuuuuurn | 03:53 |
| StevenK | I've been trying to remove that, with little to no success | 03:54 |
| wallyworld_ | so how confident are we that creating that fti index will solve the picker timeouts? | 03:54 |
| wallyworld_ | StevenK: well, seems like i'm about to add another bit of code that uses it :-) | 03:55 |
| wgrant | wallyworld_: The queries execute in <3s on DF, and that's DF. | 03:55 |
| StevenK | wallyworld_: DIE | 03:55 |
| wgrant | wallyworld_: There's no other significant explanation for its slowness. | 03:55 |
| lifeless | wallyworld_: there may be other causes of slow, but we know that that is a cause | 03:55 |
| wallyworld_ | besides all the unions etc | 03:55 |
| StevenK | jtv: Still reviewing? | 03:55 |
| jtv | Yes | 03:55 |
| lifeless | wallyworld_: unions are not prima facie causes of slowness | 03:55 |
| wgrant | wallyworld_: Unions aren't slow unless the queries are slow. | 03:55 |
| StevenK | jtv: How large is this branch? :-) | 03:56 |
| jtv | StevenK: it's not the size that matters | 03:56 |
| jtv | it's the distractions of people going "hey jtv are you still reviewing that branch?" | 03:56 |
| wgrant | The emailaddress search seems to be the slowest now. | 03:56 |
| wallyworld_ | i agree about unions not being slow per se. i was more commenting on the number of queries. and when you consider our batcher does a count(*) and then a select it's doubly bad | 03:57 |
| wgrant | Yes, our batcher is stupid :( | 03:58 |
| lifeless | I really must finish that upgrade | 03:58 |
| wgrant | Yeah. | 03:58 |
| wallyworld_ | and in postgres a count(*) is just as bad as a select i'm told so in effect we are executing our queries twice | 03:58 |
| wgrant | The FTI is 100ms on DF. Still slow, but not timeoutfully so. | 03:58 |
| lifeless | wallyworld_: yes, thats true. | 03:59 |
| wgrant | MVCC FTW | 03:59 |
| wallyworld_ | i wonder if we can't fix that? | 03:59 |
| lifeless | its mostly fixed but not followed through on | 03:59 |
| wallyworld_ | ah, the non exact count stuff? | 04:00 |
| lifeless | three things | 04:00 |
| lifeless | using query estimates - function is in the tree | 04:00 |
| wallyworld_ | can you point to the function? | 04:01 |
| lifeless | making 'last' links cheap (batchnav fixed, need to merge into the tree and start updating collections to use it) | 04:01 |
| lifeless | and lastly making arbitrary offsets cheap (same code as point 2) | 04:02 |
| lifeless | oh | 04:02 |
| lifeless | and turning off estimates entirely for collections where we can do that | 04:02 |
| lifeless | wallyworld_: its in lib/canonical/database I think | 04:03 |
| wallyworld_ | ta | 04:03 |
| lifeless | estimateRowCount | 04:03 |
| lifeless | basically parses EXPLAIN | 04:04 |
| wallyworld_ | that's nice assuming it works well | 04:05 |
| lifeless | so one thing you can do is estimate and if the count is < 100 execute the count | 04:05 |
| lifeless | on the assumption we've appropriate indices for small datasets to be answered well | 04:05 |
| lifeless | wgrant: wallyworld_: on the LEP then | 04:08 |
| wgrant | I was about to say. | 04:08 |
| lifeless | what should I do with my feedback - leave it with you, add to the LEP ? | 04:08 |
| wallyworld_ | i haven't digested the comments yet. we can add them and discuss with the product team etc | 04:11 |
| wgrant | It seems slightly bad that we have a picker deliverable in 1.5 weeks but we don't actually know what we're doing. | 04:11 |
| wallyworld_ | lifeless: with the ff int thing, even if i use intOrZero(getFeatureFlag('foo')), that will be used all over the place and will pollute the code with stuff StevenK is trying to get rid of. sure wish i could just add a single helper to features __init__ and use that.... | 04:12 |
| lifeless | wallyworld_: what stuff is stevenk trying to get rid of ? | 04:12 |
| wallyworld_ | the helpers.py i think he said | 04:13 |
| lifeless | wallyworld_: and why do you need to use it all over the place? | 04:13 |
| lifeless | wallyworld_: totally unrelated efforts | 04:13 |
| spiv | wallyworld_: canonical.lp as a place I think rather than helpers.py specifically, I think | 04:13 |
| wallyworld_ | because anywhere we want to see the value if the ff in order hide a block of code, we need to do that test | 04:13 |
| lifeless | wallyworld_: I'm confused, if its an int you're not using it for hiding stuff | 04:14 |
| wallyworld_ | spiv: ah ok. makes more sense | 04:14 |
| lifeless | wallyworld_: for hiding stuff just use | 04:14 |
| lifeless | if getFeatureFlag('foo'): | 04:14 |
| wallyworld_ | lifeless: we will be. we will be incrementing the int each time a 2 week sprint is done | 04:14 |
| wallyworld_ | so pickers first | 04:15 |
| lifeless | please start from the beginning | 04:15 |
| wallyworld_ | we say "if ffvalue == 1" then show the picker stuff | 04:15 |
| wgrant | This sounds like a very strange use of flags. | 04:16 |
| lifeless | what does this do for you that 'if getFeatureFlag('newpicker'): does not ? | 04:16 |
| wgrant | Exactly. | 04:16 |
| wallyworld_ | ok. so we want to use the one feature flag value | 04:16 |
| wgrant | Why? | 04:16 |
| lifeless | why ? | 04:16 |
| wallyworld_ | feature flag name i mean | 04:16 |
| lifeless | why? | 04:16 |
| wgrant | What benefit does that provide? | 04:16 |
| wgrant | Besides no fewer LOSA requests and less flexibility? | 04:16 |
| wallyworld_ | so that we don't have to keep adding new flags each 2 weeks | 04:16 |
| lifeless | wallyworld_: flags are free | 04:16 |
| wgrant | Adding a new flag is not expensive. | 04:17 |
| lifeless | wallyworld_: /by design/ | 04:17 |
| lifeless | wallyworld_: you don't even need to document them. | 04:17 |
| wgrant | You just use them. | 04:17 |
| lifeless | wallyworld_: and for ephemeral ones I wouldn't bother documenting. | 04:17 |
| wgrant | And then ask an admin to add them. | 04:17 |
| wgrant | You'd have to ask an admin to change the int anyway. | 04:17 |
| wgrant | So no admin time saved. | 04:17 |
| wgrant | No coding time saved. | 04:17 |
| wgrant | Much flexibility lost. | 04:17 |
| wgrant | Transparency lost. | 04:17 |
| lifeless | and you'd be stuffed if you were not ready to flick the switch for one part but were for another | 04:17 |
| jtv | StevenK: moving on to yours… it's the copy-into-derived-series branch you want reviewed? | 04:18 |
| wallyworld_ | wgrant: we can talk tomorrow at teh standup. sinzuiand i discussed it today and sort of thought using an enum style flag was going to be ok | 04:18 |
| lifeless | wallyworld_: using a flag as an enum is fine | 04:18 |
| lifeless | wallyworld_: I don't think this is an enum situation though, do you ? | 04:18 |
| lifeless | wallyworld_: what problem are you trying to solve? | 04:19 |
| wgrant | It sounds like you're trying to put a whole lot of features as different stages on a single flag. | 04:19 |
| wallyworld_ | not having to change flags.py each time we incrementally deliver a new disclosure feature | 04:19 |
| wgrant | You don't have to change it, but changing it is roughly two lines. | 04:19 |
| lifeless | wallyworld_: so you don't ever change flags.py when you deliver a feature | 04:20 |
| lifeless | wallyworld_: you change flags.py when you *start* a feature. | 04:20 |
| lifeless | wallyworld_: *if* you chooes to change it. | 04:20 |
| wallyworld_ | lifeless: yes agreed. and since we are starting a new feature of disclosure each 2 weeks, that's a lot of editing to flags.py | 04:20 |
| lifeless | wallyworld_: I don't understand that | 04:21 |
| lifeless | wallyworld_: its *literally* 2 lines, with no tests needed. | 04:21 |
| wgrant | *And* it's optional, but encouraged. | 04:22 |
| wallyworld_ | lifeless: and if every sqaud added two lines each time, it will bloat. but i guess we remove old entries when a feature is delivered | 04:22 |
| lifeless | wallyworld_: yes | 04:22 |
| lifeless | wallyworld_: just imagine the help text you'd need to describe 8 weeks of work loaded onto one flag | 04:22 |
| lifeless | '1 means pickers, 2 means bug unsubscribe on mistakes, 3 means ...' | 04:23 |
| lifeless | wallyworld_: I wanted the help text to be federated across the codebase | 04:23 |
| lifeless | wallyworld_: but that got lost in translation | 04:23 |
| wallyworld_ | ok. you win :-) | 04:24 |
| lifeless | wallyworld_: KISS wins | 04:24 |
| wallyworld_ | i didn't realise adding to flags.py was optional but i sort of think it should be mandatory | 04:25 |
| lifeless | hell no | 04:26 |
| lifeless | :) | 04:26 |
| lifeless | the -whole- point of these things is to be ultra lightweight | 04:26 |
| wallyworld_ | why? it adds necessary doco | 04:26 |
| wallyworld_ | so devs can know wtf is going on | 04:26 |
| lifeless | it adds doco | 04:26 |
| lifeless | necessary is a matter of perspective | 04:26 |
| lifeless | not all things need prose to explain them. | 04:27 |
| lifeless | things that will only last a few days certainly don't | 04:27 |
| wallyworld_ | so how else can one quickly get an overview of what ff are used? i like being able to go lp.net/+feature-info | 04:27 |
| wallyworld_ | sure, ones that only last a few days re different | 04:28 |
| lifeless | so +feature-rules shows the live rules | 04:28 |
| lifeless | +feature-info includes all features evaluated during the appservers lifetime | 04:28 |
| wgrant | wallyworld_: Flags that have been queried but are undocumented are listed there. | 04:28 |
| jtv | StevenK: you're done | 04:28 |
| lifeless | wallyworld_: wgrant: on the LEP : I'll leave my feedback with the two of you. Does it help at all with your planning, or are you still in a state of stuck ? | 04:29 |
| wgrant | lifeless: I think we're going to be stuck for at least another couple of days. | 04:30 |
| wgrant | lifeless: We have been given usecases and that's it. | 04:30 |
| wallyworld_ | lifeless: i've got enough to do today. we need to talk to curtis though | 04:30 |
| lifeless | wgrant: I'd be delighted to help - as a sounding board or whatever - if you like. | 04:31 |
| lifeless | sinzui is still doing bug triage though :) so I know he's arund | 04:31 |
| sinzui | Am I needed? | 04:31 |
| wallyworld_ | wgrant: do we have the business rules for deciding affillation documented? that would be a good start | 04:32 |
| lifeless | sinzui: so, bug 696973 - what are we doing to satisfy the multi-tenant case? | 04:32 |
| _mup_ | Bug #696973: There are no roles that can see all private artifacts in (public or private) projects <disclosure> <projects> <teams> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/696973 > | 04:32 |
| lifeless | sinzui: (two proprietary organisations working on one public project) | 04:32 |
| sinzui | If we had business rules this feature would have been created in 2007 | 04:32 |
| wallyworld_ | sinzui: we sort of need them because htey will drive the design decisons we need to make | 04:33 |
| wgrant | wallyworld_: We don't even have requirements for affiliation. | 04:33 |
| wallyworld_ | eg do we need to sort of affilliation is a big issue and will affect to what extent we need a bdifferent data model | 04:33 |
| sinzui | lifeless: I believe that rule is supposition. Every person I interviewed assumed that the owners of the project had access to all private bugs. We want to make the rules work like the stakeholders assume they do | 04:34 |
| wallyworld_ | the stuff i've done so far is geared towards displaying affilliation info | 04:34 |
| wgrant | wallyworld_: eg. we clearly want to show affiliation with the project, but we might also want to show other organisational affiliation (eg. to identify Canonical employees). And we might want to filter by it, or rank by it, or just show it in search results. And what about on comments? Do we show all of them? Just the ones for the relevant tasks? Nothing at all? And how do we distinguish types of affiliation? Ubuntu developer vs. bugsquad ... | 04:34 |
| lifeless | sinzui: branch privacy is explicitly built to support the rule | 04:34 |
| wgrant | ... person vs whatever. | 04:34 |
| lifeless | sinzui: I don't care if we have it or not, but I do care if we half-have-it | 04:34 |
| lifeless | sinzui: because it will make implementing 696973 impossible. | 04:35 |
| wgrant | sinzui: I don't think Ubuntu desires that. | 04:35 |
| wallyworld_ | wgrant: yes, important questions | 04:35 |
| wgrant | sinzui: Ubuntu's owners shouldn't be able to see security bugs by default. | 04:35 |
| lifeless | sinzui: we want to deliver the stakeholders needs, which is different | 04:35 |
| wgrant | sinzui: They are embargoed. | 04:35 |
| sinzui | They can choose to speak against it then So sar they have not! | 04:35 |
| wgrant | sinzui: Erm, have we told them? :) | 04:35 |
| wgrant | sinzui: The pillar-owners-can-sort-of-see-all-bugs-except-it-doesn't-actually-work appeared one day and even I didn't notice. | 04:36 |
| wgrant | *And* it doesn't actually work. | 04:36 |
| lifeless | sinzui: whats the right way for me to help refine this? I can think of at least one other approach that doesn't break multi tenancy | 04:36 |
| lifeless | sinzui: and would deliver what the stakeholders want, reliably. | 04:36 |
| wgrant | I think we want something pretty much like branch visibility policies. | 04:36 |
| wgrant | Except a little less unpolished. | 04:36 |
| wgrant | We need to have multiple sets of visibility rules. | 04:37 |
| sinzui | The crux of poolie's bug was private bugs. And I really do mean everyone I spoke to in landscape, OEM, HWE, U1, Ubunyu, linaro thought their private bugs were getting to the developers...They want the bugs available to the developers...that is why they were reported | 04:37 |
| lifeless | sinzui: yes, I agree | 04:37 |
| wgrant | sinzui: Who are "the developers"? | 04:38 |
| wgrant | HWE needs private bugs in Ubuntu. | 04:38 |
| sinzui | PS. No one understand private branches except the authors of the code. User literally cannot use them without an admin and an interpreter. | 04:38 |
| wgrant | Does that means that we can have no community Ubuntu developers? | 04:38 |
| sinzui | Stakeholder believe the are the owners of the project registered in Lp | 04:39 |
| lifeless | and for some projects they are | 04:39 |
| sinzui | Maybe the LP contributes to the communication problem but not delivering the correct messages to the right people | 04:40 |
| wgrant | There are bugs which are to be worked on by "the developers". But there are others that aren't. | 04:40 |
| lifeless | so there are a few horribly intersecting things | 04:40 |
| lifeless | - shared workspaces | 04:40 |
| lifeless | - unique workspace names | 04:40 |
| sinzui | Our stakeholders do not report bugs on public projects if they do not want someone from that project to work on it! | 04:40 |
| lifeless | - branding | 04:41 |
| wgrant | sinzui: Why? | 04:41 |
| wgrant | sinzui: That sounds like it's because our privacy is terrible. | 04:41 |
| wgrant | sinzui: Not any real reason. | 04:41 |
| wgrant | sinzui: And that is clearly false. | 04:41 |
| wgrant | sinzui: Security bugs in Ubuntu. | 04:41 |
| sinzui | Because They beleive that if the bug on on that project, the owners can see it. This is a simple model | 04:41 |
| wgrant | sinzui: Are embargoed from everyone but the security team. | 04:41 |
| lifeless | one way we can address this is to ditch the shared workspace model | 04:42 |
| lifeless | and say 'a workspace is for one group/organisation/team' | 04:42 |
| lifeless | and provide a way to aggregate workspaces that are working on the same codebase | 04:43 |
| lifeless | this would greatly help OEM/HWE I believe | 04:43 |
| wgrant | It is upsetting that we are working on this feature and supposedly have a schedule but really have no idea what we are doing. | 04:44 |
| lifeless | one workspace per client, aggregate all the workspaces to see overall OEM work | 04:44 |
| wgrant | Right. | 04:44 |
| lifeless | each workspace would be a distro/project as appropriate | 04:44 |
| wgrant | That's already sort of what they do. | 04:44 |
| sinzui | This sounds like an effort to make something even more complicated than what was rejected by our stakeholders. We are not being asked to design a system with more rules, or to solve the worlds problems. | 04:44 |
| wgrant | But in workaroundish ways. | 04:44 |
| lifeless | this fits -very- well with the derived distro works. | 04:44 |
| wgrant | sinzui: What was rejected? | 04:44 |
| wgrant | sinzui: And who are the stakeholders? | 04:44 |
| lifeless | sinzui: this actually fits very tightly in with what you are proposing (owners can see everything) | 04:45 |
| wgrant | And was the issue communicated clearly? | 04:45 |
| sinzui | Please read the lep for names | 04:45 |
| wgrant | We have had major misunderstandings before. | 04:45 |
| lifeless | sinzui: I very strongly believe in building simple things that work well | 04:45 |
| sinzui | Yes, like how every thinks the can change the bug supervisor role. | 04:45 |
| wgrant | sinzui: I see no Ubuntu stakeholder there. | 04:46 |
| sinzui | If someone blogged about that we would be hunted down and clubbed like baby deals | 04:46 |
| lifeless | sinzui: I fear that we are in a half-way house at the moment with some very complex stuff (like branch privacy) mixed in with naive stuff (like inaccessible private bugs) | 04:46 |
| sinzui | s/deals/seals/ | 04:46 |
| lifeless | sinzui: we need to decide what the overall shape will be so that we can head towards it | 04:47 |
| lifeless | sinzui: if you've decided that we're not doing multitenancy | 04:47 |
| lifeless | sinzui: thats fine - I respect that | 04:47 |
| sinzui | lifeless: I agreed, and can only provide a UI that our stake holders can use. The UI does describe a simpler model than we have built in the past | 04:48 |
| lifeless | sinzui: but it implies we need to change the multitenancy things and address issues like name squatting when two folk would currently multi-tenant successfully. | 04:48 |
| lifeless | sinzui: the alternative is to multi-tenant correctly. | 04:48 |
| sinzui | I am relying on the team to do the implementation. The concerns everyone brings up are legitimate, but I think the weight of many users voices are being ignored for reasons that need revalidation | 04:49 |
| lifeless | sinzui: s/the/an/ | 04:49 |
| lifeless | sinzui: I don't understand the ignoring comment - I think everyone here is taking users confusion into account | 04:49 |
| wgrant | I agree that branch privacy is currently pretty and terribly confusing, but we have learnt from it. I think we know how to do multi-tenancy fairly well. | 04:50 |
| wgrant | s/pretty/pretty bad/ | 04:51 |
| lifeless | wgrant: I don't know that we do. I'm sure we can for private tenants (bug supervisor per tenant etc), but what about public bugs ? | 04:51 |
| sinzui | wgrant: stakeholders will not benefit if we do not fix it. Working on bug and branch privacy is not in scope | 04:51 |
| === nigelb_ is now known as nigelb | ||
| wgrant | Erm. | 04:52 |
| wgrant | what is in scope, then? | 04:52 |
| lifeless | sinzui: In which case I think its misscoped. I will raise this with francis & jml. | 04:52 |
| wgrant | How can we fix project privacy without fixing bug and branch privacy? | 04:52 |
| sinzui | We are working on project/distro privacy and allowing projects to state who they trust so that they do no need to manage subscriptions | 04:52 |
| wgrant | I don't think fixing the privacy of root objects is useful or practical unless we fix the privacy of the underlying artifacts too. | 04:52 |
| lifeless | sinzui: this is squarely in the space of tenancy as a concept. I'm hugely excited about this work. | 04:53 |
| wgrant | We are going to have a fourth privacy mechanism, and it will be an unprecedented mess. | 04:53 |
| sinzui | I was hoping to abandon it. Since we are not we are supporting those stories for legacy purposes. The principle means to control access will be on the porject | 04:53 |
| lifeless | that means we're dropping multi tenancy | 04:53 |
| wgrant | And that is a big change. | 04:53 |
| wgrant | Of the Launchpad model. | 04:54 |
| lifeless | which I'm ok with, but we should make sure we resource it properly | 04:54 |
| wgrant | I thought Launchpad was about keeping project communities together. | 04:55 |
| wgrant | Not forcing fragmentation because two parties want to have their own private artifacts. | 04:55 |
| sinzui | well I thought you were arguing other otherwise wgrant. If I reported a private bug on a public project that the owner of the project could no see, I am not collaborating. Our stakeholder do want those bugs seen | 04:56 |
| lifeless | wgrant: the way we do this is not necessarily the best | 04:56 |
| sinzui | wgrant: lifeless. There has been no conversation about transition from private to public. Private teams cannot do that. I assume that a commercial story will require that | 04:58 |
| lifeless | sinzui: I assume its a desired feature too. | 05:00 |
| wgrant | sinzui: Teams can work partly in private and partly in public. | 05:00 |
| wgrant | lifeless: Sure, but not doing it at all is also probably not the best. | 05:01 |
| wgrant | So, we don't know how privacy is going to work (we don't even know what's in scope), we don't know how pickers are going to work (we don't even have requirements for some parts)... | 05:03 |
| lifeless | sinzui: it must be late for you | 05:03 |
| lifeless | sinzui: perhaps you me and francis can talk after the TL meeting tomorrow ? | 05:03 |
| sinzui | Yes. I am in bed and my turned out the lights | 05:03 |
| sinzui | oh... | 05:03 |
| wgrant | Heh | 05:04 |
| sinzui | about shared and private workspaces. That may overlap with the request for 3 and 3 level nested projects | 05:04 |
| lifeless | it may indeed | 05:04 |
| sinzui | OEM wants projects that represent factories nested below a project that uses the parts. This is ugly though, because factory a cannot know about factory b | 05:05 |
| lifeless | yes | 05:05 |
| sinzui | I blew a gasket thinking about it | 05:05 |
| lifeless | this is a form of multitenancy | 05:05 |
| lifeless | its precisely the thing that the bug we're talking about will break - or if we do either aggregation of workspaces or stay with multitenancy it will enable it | 05:06 |
| sinzui | lifeless: The TL meeting is my only meeting tomorrow. I am available to talk most of the day | 05:06 |
| lifeless | sinzui: I would like to have some time with you and francis tomorrow on voice to tease things out, after the TL meeting | 05:07 |
| sinzui | wgrant: I do not believe we are going to get requirement that could work with agile development. Building the UI first to understand what stakeholders will accept allows us to discover what is needed in the months that are a lotted. | 05:10 |
| wgrant | sinzui: Sure, we can't spec it out fully from the start. | 05:11 |
| lifeless | I'm +1 on building the UI first, but we do need to have an idea of what it will look like | 05:11 |
| wgrant | But we really have very little idea what it's going to look like and again lifeless beats me. | 05:11 |
| sinzui | wgrant: The one consistent rule is the members of canonical must have access to all canonicals projects, the bug and branches too, without managing individual subscriptions | 05:11 |
| wgrant | sinzui: That is false. | 05:12 |
| sinzui | We have pictures that were we recieved | 05:12 |
| wgrant | Simple counterexample: Ubuntu security bugs are not to be seen by all Canonical employees,. | 05:12 |
| sinzui | I thought we aggeed in the past that security != private | 05:13 |
| wgrant | It is true for most things, but there are exceptions. | 05:13 |
| wgrant | Perhaps. | 05:13 |
| wgrant | But special-casing security seems like it may be overcomplex. | 05:13 |
| wgrant | We may see. | 05:13 |
| lifeless | other organisations may choose to fund security work in the ubuntu space | 05:14 |
| lifeless | multitenancy would suggest showing the entity that will get the bug rather than a plethora of checkboxes | 05:14 |
| lifeless | multiple workspaces would suggest that other organisations get their own workspace | 05:15 |
| lifeless | jml: if you can be around after the TL call that would be great too | 05:15 |
| wgrant | lifeless: Precisely! | 05:16 |
| wgrant | We had a bug filed this morning that ubuntu-security is not subscribed to some security bugs. | 05:16 |
| wgrant | I imagine that private projects would have a couple of visibility policies. | 05:16 |
| wgrant | eg. "Canonical" and "Security" | 05:16 |
| wgrant | Private artifacts would have one or the other. | 05:16 |
| lifeless | yes, I sketched something like this in prague | 05:17 |
| wgrant | No subscription fiddling, no security hardcoding. | 05:17 |
| wgrant | Better for everyone. | 05:17 |
| wgrant | And it is, to me, the obvious solution. | 05:17 |
| wgrant | Oh, we have designs around this? | 05:17 |
| lifeless | I do | 05:17 |
| wgrant | I'd not heard of this. | 05:17 |
| lifeless | or was it texas | 05:17 |
| lifeless | perhaps texas | 05:17 |
| sinzui | prague | 05:17 |
| lifeless | but they are merely options | 05:17 |
| lifeless | wgrant: I don't have answers for public multitenancy yet | 05:18 |
| lifeless | wgrant: github doesn't multitenant | 05:18 |
| wgrant | lifeless: Is public multitenancy a problem? | 05:18 |
| lifeless | wgrant: its inconsistent | 05:18 |
| wgrant | Yeah, I looked at GitHub yesterday. | 05:19 |
| wgrant | It is an interesting model. | 05:19 |
| sinzui | I was just doing UI at the time. I went to UDS N and told everyone that while I was working on the UI, I would not be involved in the implementation. Then we switched to squads and I am leading the implentation | 05:19 |
| wgrant | lifeless: What's inconsistent about it? | 05:19 |
| wgrant | lifeless: I'm not saying there isn't anything. | 05:19 |
| wgrant | I just want to know what you think. | 05:19 |
| lifeless | wgrant: there is one bug supervisor and one bugtask status | 05:19 |
| lifeless | wgrant: but potentially many organisations with differing triage and prioritisation rules | 05:20 |
| wgrant | Ah, right. | 05:22 |
| wgrant | Yes. | 05:22 |
| wgrant | That is slightly more awkward. | 05:22 |
| wgrant | It should be considered here. | 05:22 |
| wgrant | But I don't think it really requires resolution. | 05:22 |
| wgrant | But we should not design against it :) | 05:22 |
| lifeless | for example | 05:23 |
| lifeless | bazaar had/has another company doing consulting and contracting | 05:23 |
| wgrant | Yeah | 05:24 |
| lifeless | they would benefit from being able to say 'this matters to me' | 05:24 |
| lifeless | and in principle each user has their own prioritisation rules | 05:24 |
| lifeless | I'd be quite happy if users could mark all the bugs they care about critical and it didn't impact the LP team. | 05:24 |
| lifeless | For instance. | 05:24 |
| lifeless | This could either be a genuine discriminator | 05:24 |
| lifeless | or terrible | 05:24 |
| wgrant | Right, and splitting workspaces will not solve this. | 05:25 |
| lifeless | well it would | 05:25 |
| wgrant | MMm, I guess. | 05:25 |
| wgrant | But not in really useful ways. | 05:25 |
| lifeless | there are two issues there | 05:25 |
| lifeless | name squatting | 05:25 |
| lifeless | and aggregation | 05:25 |
| lifeless | if folk can fork the workspace easily and aggregate only what they trust easily | 05:26 |
| lifeless | then naming and the passion around that becomes the sole issue | 05:26 |
| lifeless | this is roughly the same as the single-blessed-tenant for public tenancy vs private multitenancy | 05:26 |
| lifeless | I mean - the two approaches have some common challenges | 05:28 |
| lifeless | but will tradeoff on things they do better | 05:28 |
| lifeless | the naming/branding thing is actually very important | 05:29 |
| wgrant | That's one reason I am reluctant to not multi-tenant. | 05:31 |
| lifeless | it may be a driving factor to choose one approach over the other | 05:33 |
| lifeless | however I don't know what side of the equation it sits on :) | 05:33 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | Anyway, I guess discussing this further here is pointless, so I shall await the outcome of your discussion with Francis and co tomorrow. | 05:38 |
| StevenK | wgrant: Do you want to look at refactor-notification again? | 05:43 |
| StevenK | wgrant: I've not done some of what you mentioned, however I think I've addressed most of your concerns. | 05:43 |
| wgrant | StevenK: Let me have a look. | 05:44 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | StevenK: Have you run the delayed copy tests over this? | 05:46 |
| wgrant | I'm pretty sure the announcement tests will fail. | 05:46 |
| wgrant | Although they may be crap enough that they don't. | 05:46 |
| * StevenK does so | 05:47 | |
| StevenK | wgrant: 88 tests, 0 failures and 0 errors | 05:50 |
| wgrant | Yay. | 05:50 |
| wgrant | spr.package_upload is not what you want. | 05:50 |
| wgrant | So the tests should fail :( | 05:50 |
| StevenK | Is that a sarcastic yay I see? | 05:50 |
| wgrant | Never! | 05:50 |
| StevenK | ITYM "Always!" | 05:51 |
| wgrant | Hm. | 06:01 |
| wgrant | Why does AJAX "Subscribe someone else" on a bug check whether I can unsubscribe the subscription before it creates it? | 06:01 |
| wgrant | * * Check if the current user can unsubscribe the person * being subscribed. * * This must be done in JavaScript, since the subscription * hasn't completed yet, and so, can_be_unsubscribed_by_user * cannot be used. | 06:02 |
| wgrant | But why? | 06:02 |
| lifeless | thats surprising | 06:02 |
| wgrant | It's an extra 5 requsets :( | 06:02 |
| lifeless | it may be about teams | 06:02 |
| wgrant | Howso? | 06:03 |
| wgrant | It should just be able to get can_be_unsubscribed from the subscription once it's created, AFAICT... | 06:04 |
| wgrant | It basically reimplements inTeam in JS :/ | 06:05 |
| wgrant | Buggily, too! | 06:05 |
| wgrant | Perhaps I should remove it and see what tests fail. | 06:06 |
| StevenK | wgrant: Did you get distracted? :-) | 06:09 |
| StevenK | Like I did ... | 06:10 |
| wgrant | StevenK: I was waiting for your responses on spr.package_upload. | 06:10 |
| StevenK | wgrant: I had no idea it was a question. It seems to work? | 06:11 |
| wgrant | StevenK: It's the wrong one. | 06:11 |
| wgrant | For delayed copies, at least. | 06:11 |
| StevenK | So I change it back to taking a packageupload and getting the spr from the PU? | 06:12 |
| === _thumper_ is now known as thumper | ||
| wgrant | I don't know. | 06:13 |
| wgrant | Possibly optionally taking a PackageUpload. | 06:13 |
| wgrant | But then what about binaries? | 06:13 |
| * StevenK tosses the entire soyuz tests at this branch | 06:13 | |
| StevenK | Let's see what blows up | 06:14 |
| wgrant | I suggested progressive refactoring to avoid this sort of dead-end. But that doesn't work so well if the tests don't exercise the stuff that is going to break :/ | 06:14 |
| thumper | does anyone know about poolie's script for making a kanban board? | 06:16 |
| wgrant | lp:kanban? | 06:16 |
| * thumper looks | 06:16 | |
| StevenK | wgrant: So I get questioned either way. Crumbs, this code sucks. | 06:17 |
| wgrant | StevenK: It sucks, and it's not clear how to solve this particular bit. We need to handle cases without an SPR, and cases without a PackageUpload. | 06:18 |
| wgrant | Fun for all! | 06:18 |
| wgrant | StevenK: That's why I suggsted an exploratory refactoring to minimise dependencies on SPR without changing behaviour. | 06:21 |
| wgrant | But we need to work this out somehow. | 06:21 |
| wgrant | Hmmm. | 06:21 |
| wgrant | s/SPR/PU/ | 06:21 |
| StevenK | wgrant: Which I attempted, and then you said I've gone too far. I've dialed it back a bit and it's still wrong. | 06:22 |
| StevenK | lib/lp/soyuz/doc/distroseriesqueue-notify.txt is utterly broken | 06:22 |
| wgrant | StevenK: The fact that you've gone too far is not a problem. The problem is that you've broken functionality! | 06:23 |
| wgrant | And your reversion is broken because SPR.package_upload is stupid and legacy :( | 06:23 |
| wgrant | Well, possibly more because delayed copies are stupid and hackish :( | 06:23 |
| wgrant | But we still have the binary upload problem which makes me cry. | 06:24 |
| wgrant | StevenK: Perhaps we announce on a set of packages. | 06:24 |
| wgrant | May have zero or one SPRs, zero or more BPRs, and zero or more baby-eating custom uploads. | 06:25 |
| StevenK | And then my explodes trying to keep track of changes files and content for each of those | 06:25 |
| StevenK | s/my explodes/my head explodes/ | 06:26 |
| wgrant | Sounds like it already may have :( | 06:26 |
| wgrant | Right. But each announcement has a single changes file. | 06:26 |
| wgrant | Which you can possibly pass in for now. | 06:26 |
| wgrant | Remember that changes files will be optional soon. | 06:26 |
| wgrant | Out of necessity. | 06:26 |
| wgrant | So the changes file stuff does not have to be pretty; it is going to be aggressively mutilated in a week or two. | 06:26 |
| StevenK | By whom? | 06:27 |
| wgrant | undef | 06:27 |
| StevenK | PERL! | 06:27 |
| wgrant | But it's needed for copies from Debian. | 06:27 |
| wgrant | So it has to be done. | 06:27 |
| wgrant | So it is left as an exercise to the Julian, and can be disregarded by us as a given. | 06:27 |
| wgrant | So. | 06:28 |
| wgrant | it looks like we are looking at sets again. | 06:28 |
| wgrant | Sets of SPRs and BPRs and pedovores. | 06:29 |
| wgrant | What still uses the changesfile.... | 06:35 |
| wgrant | Apart from too much. | 06:35 |
| wgrant | Hm. | 06:36 |
| wgrant | So we still parse Changed-By and Maintainer and Changes out of it. | 06:36 |
| wgrant | hmmmm. | 06:36 |
| wgrant | Difficult. | 06:36 |
| wgrant | :( | 06:36 |
| StevenK | Yes. | 06:37 |
| wgrant | The first two are easily replaced with looking at SPR. The last needs to be replaced anyway. | 06:37 |
| wgrant | So we can continue passing the content around for now, I think. | 06:37 |
| wgrant | And remove it eventually. | 06:37 |
| wgrant | But does that mean we can just use the string? | 06:38 |
| wgrant | And not a file object? | 06:38 |
| StevenK | The reason we use the file object is due to attaching the actual file to the mail | 06:38 |
| wgrant | Hm. We can't do that with a string? | 06:39 |
| StevenK | Ordering | 06:39 |
| wgrant | Even if we can't, let's just write that to a temporary file or stringio or something. | 06:39 |
| wgrant | Huh? | 06:39 |
| StevenK | Oh, string | 06:39 |
| StevenK | Not dict | 06:39 |
| wgrant | String. | 06:39 |
| wgrant | Right, not parsed. | 06:39 |
| wgrant | Although I guess we need the parsed version too, is that what we parse around niow? | 06:40 |
| wgrant | s/parse/pass/ | 06:40 |
| StevenK | Yes, we pass around a dict and a file-like object | 06:40 |
| StevenK | for build in packageupload.builds: | 06:41 |
| StevenK | AttributeError: 'NoneType' object has no attribute 'builds' | 06:41 |
| StevenK | For crying out loud | 06:41 |
| wgrant | Ah. | 06:41 |
| wgrant | sad. | 06:41 |
| StevenK | This is all broken | 06:41 |
| wgrant | Do we use the dict outside assemble_body? | 06:41 |
| wgrant | Or can we just parse it in there? | 06:41 |
| wgrant | And just pass the string around. | 06:41 |
| StevenK | Yes, in notify_spr_less() | 06:42 |
| wgrant | That doesn't count. | 06:42 |
| wgrant | It's a separate beast. | 06:42 |
| StevenK | _getRecipients wants the parsed dict too | 06:42 |
| wgrant | Why? :/ | 06:42 |
| wgrant | Ah | 06:43 |
| wgrant | Is that used by notify_spr_less too? | 06:43 |
| StevenK | No | 06:43 |
| wgrant | Hrmph. | 06:43 |
| StevenK | It is tied pretty tightly to packageupload, so I ignored it | 06:43 |
| wgrant | Anyway, let's try not to change that yet. | 06:43 |
| wgrant | We can continue passing around both the dict and file versions, I guess. | 06:43 |
| StevenK | Total: 1101 tests, 10 failures, 5 errors in 29 minutes 58.207 seconds. | 06:44 |
| StevenK | Those 15 are mostly doctests, so it's worse | 06:44 |
| wgrant | That's what I was hoping for. | 06:44 |
| wgrant | Failures, not worse. | 06:44 |
| StevenK | lp.soyuz.tests.test_packageupload.PackageUploadTestCase.test_realiseUpload_for_delayed_copies | 06:45 |
| StevenK | Damn it, I hate it when you're right. | 06:45 |
| StevenK | :-P | 06:45 |
| wgrant | :( | 06:45 |
| * StevenK looks at the failure and goes cross-eyed | 06:46 | |
| wgrant | StevenK: No point looking at the failure yet. | 06:47 |
| wgrant | Until you've fixed it to use the right BPRs and PUCs. | 06:47 |
| StevenK | So, stop tossing around SPR and go back to PU? | 06:47 |
| wgrant | Then we should have just about nearly almost slightly restored the original behaviour. | 06:47 |
| wgrant | And there will be reasonable failures. | 06:47 |
| wgrant | Given how far you've gone already, I think just take optional sets of BPRs and PUCs. | 06:48 |
| wgrant | In addition to the SPR. | 06:48 |
| wgrant | Don't take a PU. | 06:48 |
| wgrant | You don't need it. | 06:48 |
| wgrant | You just need the subordinate releases/uploads and the changesfile. | 06:48 |
| StevenK | You said the opposite for the subject | 06:48 |
| wgrant | We can sort of sourceless notifications after that. | 06:49 |
| wgrant | Hm? | 06:49 |
| StevenK | packageupload.displayname has behaviour we might still need | 06:49 |
| wgrant | Argh, forgot that bit. | 06:49 |
| wgrant | We need to reimplement that. | 06:49 |
| wgrant | Let me look at it. | 06:49 |
| wgrant | Ah. | 06:49 |
| wgrant | StevenK: You'll see you undo about half of what it does anyway. | 06:51 |
| wgrant | StevenK: I think just grab the names yourself from the packages you're given. | 06:51 |
| wgrant | Ignore the (delayed) bit. | 06:51 |
| wgrant | Which I filed a bug about years ago anyway. | 06:51 |
| StevenK | wgrant: If spr.package_upload is wrong, does that mean packageupload.sourcepackagerelease is also wrong? | 06:51 |
| wgrant | StevenK: No. PackageUpload.sourcepackagerelease is fine. | 06:52 |
| wgrant | But an SPR may have multiple PackageUploads. | 06:52 |
| wgrant | spr.package_upload is the original one. | 06:52 |
| wgrant | Which isn't the right one in the case of a delayed copy. | 06:52 |
| wgrant | StevenK: Do we use the PU for anything else? | 06:54 |
| wgrant | StevenK: Apart from getting the BPRs and PUCs, and displayname? | 06:54 |
| StevenK | _buildSummary, but I just ripped that out | 06:54 |
| wgrant | Great. | 06:54 |
| StevenK | Perhaps I should write a PUS to string function | 06:54 |
| wgrant | Hm? | 06:55 |
| wgrant | You're not going near PUS here... | 06:55 |
| wgrant | At least I hope not. | 06:55 |
| wgrant | PUC, sure. | 06:55 |
| wgrant | Because we have no other way to represent custom uploads. | 06:55 |
| wgrant | But not PUS. | 06:55 |
| StevenK | wgrant: A lot of the new code I've written takes an action as a string | 06:55 |
| wgrant | Oh. | 06:55 |
| wgrant | PackageUploadStatus. | 06:56 |
| StevenK | PUS being PackageUploadStatus | 06:56 |
| wgrant | Not PackageUploadSource. | 06:56 |
| wgrant | Right! | 06:56 |
| wgrant | But not quite. | 06:56 |
| wgrant | Since you need 'announcement' as a separate thing. | 06:56 |
| wgrant | Or maybe not. | 06:56 |
| StevenK | I do, but that's only called once | 06:56 |
| wgrant | If you can separate that out somehow, by all means use PUStatus instead. | 06:56 |
| wgrant | Much cleaner. | 06:56 |
| StevenK | Er? I'm advocating *not* using it | 06:56 |
| wgrant | Oh, you want a map (no need for a function) to turn a PUS into a string to pass into notify? | 06:57 |
| wgrant | Mm. | 06:57 |
| wgrant | I guess. | 06:57 |
| wgrant | Doesn't make much difference. | 06:57 |
| StevenK | Not really | 06:57 |
| StevenK | Right, assemble_body still uses spr.package_upload | 06:58 |
| StevenK | And calculate_subject | 06:58 |
| StevenK | That's it | 06:58 |
| wgrant | What do they use them for? | 06:59 |
| wgrant | s/them/it/ | 06:59 |
| StevenK | assemble_body wants the signing key | 06:59 |
| StevenK | calculate_subject wants displayname | 06:59 |
| wgrant | signing key is OK for now. calculate_subject doesn't really want displayname... it's exactly 6 lines to reimplement the part of it that it requires. | 07:00 |
| StevenK | So calculate_subject also wants builds and customfiles? | 07:01 |
| wgrant | BPRs and PUCs, but yes, it will need to know about them. | 07:03 |
| wgrant | StevenK: I think we may actually have a reasonable solution here! | 07:04 |
| StevenK | It doesn't look reasonable yet | 07:06 |
| wgrant | Well, a reasonable *vision* of a solution. | 07:06 |
| StevenK | wgrant: Did you want spr.package_upload.signing_key usage to die too? | 07:06 |
| wgrant | More than my "refactor mercilessly and see what falls out" started with. | 07:06 |
| wgrant | StevenK: I think that's OK for now. | 07:07 |
| wgrant | StevenK: Eventually it will be the requestor instead. | 07:07 |
| StevenK | Yes | 07:07 |
| wgrant | StevenK: But for now all we have is the SPR signer. | 07:07 |
| wgrant | And that's on the original package_upload. | 07:07 |
| wgrant | So spr.package_upload.signingkey is OK. | 07:07 |
| StevenK | wgrant: Commit and push? | 07:07 |
| wgrant | Ideally run a couple of the failing tests first. | 07:08 |
| wgrant | But then, sure :) | 07:08 |
| StevenK | Right, one is because I can't code | 07:10 |
| StevenK | Another is due to the exact thing I just questioned | 07:10 |
| wgrant | :O | 07:10 |
| wgrant | Heh. | 07:10 |
| wgrant | Which? signingkey? | 07:10 |
| StevenK | if spr.package_upload.signing_key is not None: | 07:11 |
| StevenK | AttributeError: 'NoneType' object has no attribute 'signing_key' | 07:11 |
| wgrant | Guard it with a spr.package_upload None check. | 07:11 |
| wgrant | And see what happens. | 07:11 |
| wgrant | I suspect the test is dodgy. | 07:11 |
| wgrant | Not creating a valid initial PackageUpload. | 07:11 |
| wgrant | Or not invalidating a cache. | 07:11 |
| wgrant | Or something like that. | 07:11 |
| StevenK | Oh, BAH | 07:15 |
| StevenK | set.add(string) is not helpful! | 07:15 |
| StevenK | + '[ubuntu/breezy-autotest] a, e, l, n, p, t 0.99.6-1 (New)' | 07:15 |
| wgrant | Heh. That should work. | 07:16 |
| wgrant | But set(string) won't. | 07:16 |
| StevenK | Ah | 07:17 |
| StevenK | Which is what I do exactly | 07:17 |
| StevenK | :-( | 07:17 |
| StevenK | set([string]) makes me sad | 07:17 |
| wgrant | We'll move to 2.7 within a few months. | 07:17 |
| wgrant | Where you can just do {string} | 07:17 |
| StevenK | Grumble. I think PackageUpload.sourcepackagerelease is also None for dist-upgrader uploads | 07:24 |
| wgrant | It is :D | 07:24 |
| wgrant | Don't worry about sourceless uploads right now. | 07:24 |
| wgrant | Get delayed copy and mixed upload announcements working first. | 07:25 |
| wgrant | Let me glance over that, then we can strategise on sourceless. | 07:25 |
| jtv | Hey everyone, an American just told me I had to learn about sarcasm! | 07:27 |
| wallyworld_ | jtv: noooo, really? surely you jest | 07:49 |
| wgrant | StevenK: How's it going? | 07:51 |
| StevenK | wgrant: test_realiseUpload_for_delayed_copies sucks | 07:52 |
| wgrant | Surely not? | 07:52 |
| StevenK | Hah | 07:52 |
| jtv | wallyworld_: see, there, what you said there? I can spot sarcasm! | 07:55 |
| StevenK | wgrant: Right, delayed_copies fixed | 07:55 |
| wgrant | StevenK: Excellent! | 07:56 |
| wgrant | StevenK: Hopefully this only leaves sourceless uploads broken. | 07:56 |
| StevenK | wgrant: I dunno. :-) | 07:56 |
| StevenK | wgrant: http://pastebin.ubuntu.com/612607/ are the failing tests | 07:57 |
| wgrant | Ye of even less faith than me, if that is possible. | 07:57 |
| StevenK | wgrant: I've fixed test_realiseUpload_for_delayed_copies | 07:57 |
| wgrant | OK, that's not too bad. | 07:58 |
| StevenK | wgrant: What else do you think I should look at before pushing? | 07:58 |
| wgrant | You might want to have a look at TestQueueTool next. | 07:58 |
| wgrant | Since it's likely to be more understandable than the doctests. | 07:58 |
| wgrant | I hope.; | 07:58 |
| * StevenK peers at it | 07:58 | |
| StevenK | Not sure if I've broken nascentupload-mumble.txt either | 07:59 |
| wallyworld_ | StevenK: wgrant: you guys are watching SOO tonight, right? | 07:59 |
| wgrant | Mumble integration in archiveuploader sounds like a critical bug. | 07:59 |
| wgrant | SOO? | 07:59 |
| StevenK | State of Origin | 07:59 |
| wgrant | I have heard of it but can't remember to which sport it relates. | 08:00 |
| wallyworld_ | wgrant: sad that you have to ask :-) | 08:00 |
| wgrant | Possibly rugby. | 08:00 |
| StevenK | Thugby league | 08:00 |
| wallyworld_ | heathens! | 08:00 |
| wgrant | Victorians :P | 08:00 |
| wgrant | AFL is all the rage here. | 08:00 |
| wallyworld_ | and you call yourselves australian | 08:00 |
| wgrant | Although I hate it with passion :) | 08:00 |
| wgrant | No, I'm Canadian ! | 08:00 |
| StevenK | I don't really like the thought of watching grown men grop each other for 80 minutes | 08:00 |
| wallyworld_ | grop? is that a kinky version of grep? | 08:01 |
| wallyworld_ | or maybe grok? | 08:01 |
| StevenK | groupe | 08:01 |
| StevenK | Sigh | 08:01 |
| wgrant | Groupé? | 08:01 |
| StevenK | grope | 08:01 |
| wallyworld_ | ah well, i won't bother talking about the gaem tomorrow then | 08:02 |
| StevenK | wgrant: 4 of the 5 errors are fixed by side-effect, the other is due to the test tossing in stringio | 08:02 |
| StevenK | wgrant: (For TestQueueTool) | 08:02 |
| wgrant | StevenK: Great, we're getting there :) | 08:02 |
| wgrant | wallyworld_: Did you see that ludicrous display last night? | 08:03 |
| wallyworld_ | wgrant: no, didn't watch much tv last night | 08:03 |
| wallyworld_ | what happened? | 08:03 |
| wgrant | Bah. | 08:03 |
| wgrant | Does nobody watch The IT Crowd? | 08:03 |
| wallyworld_ | wgrant: yes, but i think i've seen them all | 08:04 |
| StevenK | I've seen up until the end of season 4 | 08:04 |
| wgrant | "Did you see that ludicrous display last night?" is the opening of the responses they use from bluffball.co.uk. | 08:04 |
| wgrant | To cope with colleagues discussing the game the following day :) | 08:05 |
| wallyworld_ | hey, how do i use addCleanup() in a doc test? ie how do i get a reference to the test case being run? | 08:05 |
| lifeless | wallyworld_: you don't | 08:05 |
| thumper | wallyworld_: you don't | 08:05 |
| StevenK | wgrant: Commit and push, or fix more? | 08:05 |
| thumper | wallyworld_: unless someone fixed it | 08:05 |
| wgrant | StevenK: Commit and push and then fix more! | 08:05 |
| lifeless | wallyworld_: However it is possible to add a cleanup facility to the globals that our doctests have | 08:05 |
| StevenK | wgrant: I don't like that idea. I think it's your turn. :-P | 08:06 |
| lifeless | wallyworld_: this is yet another fail of doctests | 08:06 |
| wallyworld_ | so i want to use a feature flag. i can set it up but i need to be able to discard it afterwards | 08:06 |
| StevenK | wallyworld_: with FeatureFixture? | 08:06 |
| wgrant | wallyworld_: If you must use it in a doctest, can you use a FeatureFixture with a with block? | 08:06 |
| wallyworld_ | StevenK: yes | 08:06 |
| lifeless | wallyworld_: or | 08:07 |
| StevenK | wgrant: distroseriesqueue-views.txt | 08:07 |
| StevenK | Sigh | 08:07 |
| lifeless | feature = FeatureFixture(...) | 08:07 |
| wallyworld_ | wgrant: well, the stuff that needs it is spread throughout | 08:07 |
| StevenK | wgrant: distroseriesqueue-views.txt also fixed by side effect | 08:07 |
| lifeless | feature.setUp() | 08:07 |
| wgrant | wallyworld_: :( | 08:07 |
| lifeless | ... | 08:07 |
| lifeless | feature.cleanUp() | 08:07 |
| wgrant | StevenK: Excellent! | 08:07 |
| wgrant | StevenK: Do you use testr? | 08:07 |
| * StevenK runs soyuz-set-of-uploads, but that crap fails if the wind is blowing the wrong way | 08:07 | |
| wallyworld_ | lifeless: that will work. i was hoping not to have to spread that stuff from one end to the other | 08:07 |
| StevenK | wgrant: I do not | 08:08 |
| wgrant | StevenK: It's handy for stuff like this. | 08:08 |
| wgrant | testr run --failing, done! | 08:08 |
| LPCIBot | Project db-devel build #578: FAILURE in 5 hr 16 min: https://lpci.wedontsleep.org/job/db-devel/578/ | 08:10 |
| wgrant | zomg, it works. | 08:10 |
| wgrant | Got rid of that hideous pre-subscription inTeam reimplementation. | 08:10 |
| StevenK | wgrant: Pushed | 08:11 |
| wgrant | StevenK: Great. Will check in a sec. | 08:11 |
| wgrant | StevenK: Is anything left failing except for sourceless uploads? | 08:11 |
| wgrant | Also, will my eyes survive the diff? | 08:12 |
| wgrant | Our JS infrastructure is fairly nice. | 08:12 |
| StevenK | wgrant: Running -vvm soyuz again ... | 08:12 |
| wgrant | See you in 50 minutes :( | 08:12 |
| StevenK | 29, on this machine | 08:13 |
| wgrant | Hmm. | 08:13 |
| wgrant | Oh, right 50 was with archiveuploader and archivepublisher too. | 08:14 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| danilos | oh, jtv, StevenK: I've removed you from the topic as OCRs, are you still "on duty"? (I thought that was from yesterday) | 08:21 |
| jtv | danilos: I still am, on request. | 08:21 |
| StevenK | danilos: I am, for another 35-ish minutes | 08:21 |
| jtv | (But have done about all the backlog I was going to) | 08:21 |
| * StevenK drops two from the backlog | 08:25 | |
| danilos | StevenK, I assume you need not go back on OCR anymore then, and as for you jtv, please re-add yourself to the topic if appropriate :) | 08:26 |
| jtv | danilos: you broke it, you fix it. Or just take over OCR. Your pick. :) | 08:27 |
| danilos | jtv, heh, ok, ok | 08:27 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv, danilos | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| StevenK | danilos: *shrug* :-) | 08:28 |
| StevenK | I attempted to review benji's drop feature flag branch, but my eyes glazed over at about line 600 | 08:29 |
| jtv | And I limited myself to one backlog review per person, on grounds of fairness (as in, it's not fair to an engineer to give the poor bastard multiple jtv reviews on the same day) | 08:31 |
| StevenK | Haha | 08:31 |
| wgrant | StevenK: 'for build in builds' should be 'for bpr in bprs', right? | 08:34 |
| StevenK | Probably | 08:34 |
| wgrant | "build.build" is slightly nonsensible. | 08:34 |
| StevenK | wgrant: Fixed locally | 08:35 |
| wgrant | StevenK: Thanks. So packageupload is entirely gone now (apart from spr.packageupload.signingkey), and it appears to work for everything except sourceless uploads? | 08:35 |
| StevenK | wgrant: def notify() depends on it | 08:36 |
| StevenK | wgrant: And _sendSuccessNotification | 08:36 |
| wgrant | That's rather antisocial of them. | 08:37 |
| StevenK | send_mail() needs to be weaned off, but that is simple, since it expands all of them from packageupload anyway | 08:38 |
| wgrant | Ah, right, I was hoping they'd all just be passed down from notify(). | 08:39 |
| wgrant | Is that easy enough? | 08:39 |
| wgrant | It's a lot of arguments, but meh. | 08:39 |
| StevenK | It can worked out inside _sendSuccessNotification or inside notify | 08:39 |
| wgrant | We need to pull it up high enough that we can send notifications without a PU. | 08:40 |
| wgrant | I don't know how high that is. | 08:40 |
| StevenK | wgrant: Currently, notify() | 08:41 |
| wgrant | You'd best take it all the way to the top, then :( | 08:41 |
| StevenK | I can't easily wean notify off PU | 08:41 |
| wgrant | Why not? | 08:41 |
| StevenK | _send{Success,Rejection}Notification is fine | 08:42 |
| StevenK | wgrant: Because nearly everything notify() does is in relation to packageupload | 08:42 |
| StevenK | wgrant: http://pastebin.ubuntu.com/612620/ | 08:43 |
| wgrant | Ah. | 08:43 |
| adeuring | good morning | 08:48 |
| StevenK | wgrant: I've pushed it all up to def notify() | 08:51 |
| wgrant | StevenK: Great. | 08:51 |
| StevenK | _sendSuccess and such need to grow an action, now | 08:51 |
| wgrant | StevenK: So, that's enough refactoring for now... we just have to get sourceless announcements working. What crashes? | 08:51 |
| wgrant | Or that. | 08:51 |
| StevenK | Since it wants the PackageUploadStatus | 08:52 |
| wgrant | Right. | 08:52 |
| wgrant | That's all that's keeping packageupload anywhere other than notify()? | 08:52 |
| StevenK | I *think* so | 08:52 |
| wgrant | Great. | 08:52 |
| wgrant | This is a really good first step. | 08:53 |
| StevenK | wgrant: Almost | 08:58 |
| StevenK | packageupload.isAutoSyncUpload(changed_by_email=changes['Changed-By']): | 08:58 |
| wgrant | Can that be a class method? | 08:58 |
| wgrant | No. | 08:59 |
| wgrant | Still, easy to move across. | 08:59 |
| wgrant | But what a dirty, dirty piece of code :( | 09:00 |
| StevenK | Can't we just kill it and replace it with if not bprs and spr and changed_by == katie? | 09:00 |
| wgrant | That was my intention. | 09:00 |
| StevenK | But yes, makes me vomit | 09:00 |
| wgrant | And check signingkey and stuff, yeah. | 09:00 |
| wgrant | That's the only place it's used, except for tests. | 09:01 |
| wgrant | (yes, it's tested!) | 09:01 |
| wgrant | ... but only in distroseriesqueue-translations.txt. | 09:01 |
| wgrant | Yay | 09:01 |
| StevenK | Haha | 09:01 |
| StevenK | Fail | 09:01 |
| StevenK | If not signing_key, from_addr is None. Otherwise, it's Changed-By. | 09:02 |
| StevenK | Shoot me now | 09:02 |
| StevenK | wgrant: Actually, it's *worse* | 09:03 |
| StevenK | No, it isn't. | 09:04 |
| StevenK | distroseriesqueue-translations.txt's isAutoSync... is a re-implementation | 09:04 |
| wgrant | Hahahaha | 09:04 |
| StevenK | It's not bad, so I'll leave it be | 09:04 |
| StevenK | It's in the interface :-( | 09:05 |
| wgrant | Is that a problem? | 09:06 |
| StevenK | Checking if it is | 09:06 |
| === almaisan-away is now known as al-maisan | ||
| StevenK | wgrant: I was worried it was exported | 09:12 |
| wgrant | PU is exported rather minimally, fortunately. | 09:12 |
| StevenK | Indeed | 09:12 |
| StevenK | I think I've run out of steam, but with one grave hack, packageupload is contained in notify() only | 09:13 |
| wgrant | Excellent. | 09:13 |
| StevenK | Sigh, and _getRecipients | 09:14 |
| wgrant | Hmm. | 09:15 |
| wgrant | This is slightly entertaining. | 09:15 |
| wgrant | "Subscribe someone else" makes four AJAX requests to work out where to put the spinner, then three more to perform the action once the spinner is there. | 09:16 |
| StevenK | Haha | 09:16 |
| wgrant | This means there's more lag between the picker closing the and the spinner appearing than there would be if the spinner was just not used at all. | 09:16 |
| StevenK | wgrant: Do you want to claw your eyes out with this diff? | 09:16 |
| wgrant | StevenK: With pleasure. | 09:16 |
| wgrant | I think I will instead place a static spinner on the "Subscribe someone else" link. | 09:18 |
| mrevell | Hello devotrons | 09:19 |
| lifeless | wgrant: ---hah--- | 09:20 |
| wgrant | lifeless: Rather. | 09:20 |
| henninge | oh, jtv left us :( | 09:34 |
| henninge | danilos: Hi! | 09:34 |
| henninge | danilos: Can I bother you for a very quick review, please? | 09:35 |
| henninge | https://code.launchpad.net/~henninge/launchpad/bug-753387-ajax-bug-subscription/+merge/62256 | 09:35 |
| danilos | henninge, if you must | 09:35 |
| henninge | danilos: suffer it to be, I pray thee | 09:35 |
| danilos | ;) | 09:36 |
| henninge | :) | 09:36 |
| danilos | henninge, btw, have you thought of using the actual feature flag check? that makes it so much easier to find it when removing the feature flag | 09:38 |
| henninge | danilos: oh, we have that in js? | 09:39 |
| * henninge reads up on feature flags | 09:39 | |
| lifeless | we don't | 09:39 |
| henninge | ah | 09:39 |
| lifeless | we generally export a value to the js for the js to consult | 09:39 |
| lifeless | or export custom js based on the flag | 09:39 |
| lifeless | usually the former | 09:39 |
| danilos | henninge, we do have it in that particular JS file | 09:39 |
| henninge | ;-) | 09:40 |
| henninge | danilos: use_advanced_subscriptions | 09:40 |
| henninge | danilos: sorry, I was blind | 09:40 |
| danilos | henninge, nothing a pair of glasses won't fix :) | 09:40 |
| henninge | otoh, it always makes sense to check is something is null before you use it | 09:40 |
| wgrant | I've just moving that same code around, and was wondering why that isn't all one function. | 09:41 |
| danilos | wgrant, henninge: fwiw, we expect a lot of that code to be refactored with the one final big bug our team is still working on | 09:41 |
| jml | lifeless: I'm not around for the TL call | 09:42 |
| danilos | henninge, as for the null check, sure | 09:42 |
| wgrant | danilos: Which bug is that? | 09:42 |
| danilos | henninge, also, note that I'd move the null check to update_mute_after_subscription_change() then to encapsulate it properly | 09:42 |
| wgrant | I'm refactoring the subscribe someone else stuff at the moment. | 09:43 |
| wgrant | Which is hopefully mostly unrelated. | 09:43 |
| danilos | wgrant: it's not, it's very much related :( | 09:43 |
| danilos | wgrant: bug 772754 | 09:44 |
| _mup_ | Bug #772754: After better-bug-notification changes, list of bug subscribers is confusing <story-better-bug-notification> <Launchpad itself:In Progress by gary> < https://launchpad.net/bugs/772754 > | 09:44 |
| lifeless | jml: ok | 09:44 |
| danilos | wgrant: basically, we are changing the subscribers list in a big way, and that means that these links are going to change as well | 09:45 |
| danilos | wgrant: mock-up we are going for: https://launchpadlibrarian.net/71552495/all-in-one.png | 09:45 |
| henninge | danilos: that was actually my first solution | 09:45 |
| henninge | danilos: but I thought "Well, usually there is no reason to do that" | 09:45 |
| henninge | and I'd think it is the caller's responsibility to provide correct parameters, is it not? | 09:46 |
| wgrant | danilos: How can you separate them like that when the "Other bug subscribers" might include teams of which the user is a member? | 09:46 |
| wgrant | danilos: Anyway, I think my refactor is pretty much necessary for that. And I hope to be done with it tomorrow. | 09:47 |
| wgrant | danilos: (at the moment it tries to predict where the new subscriber node will end up, which looks like it'll be just about impossible) | 09:47 |
| wgrant | But if you are working on this imminently, I can drop this and leave you to it. | 09:48 |
| danilos | wgrant: yeah, we're already in the process of changing that all | 09:49 |
| wgrant | Ah, OK. | 09:49 |
| danilos | henninge, r=me, your call on this, you've got good arguments, and I am not strongly tied to any of the sides | 09:49 |
| wgrant | It seems odd that the feature was declared done on Monday with a massive change still underway... | 09:49 |
| jml | was it? | 09:50 |
| danilos | wgrant: I agree | 09:50 |
| henninge | danilos: I'use the feature flag check and leave out the null check. | 09:50 |
| henninge | ll | 09:50 |
| lifeless | jml: the squad roster was changed | 09:50 |
| lifeless | jml: which is slightly different, but closely related | 09:50 |
| jml | lifeless: oh ok. | 09:51 |
| wgrant | It was also intended to release on Monday. | 09:51 |
| lifeless | jml: as you aren't around for the tl meeting, can we have a brief call in ~20 minutes time ? | 09:51 |
| wgrant | And it was only decided on Monday that that would not happen... | 09:51 |
| wgrant | :/ | 09:51 |
| jml | wgrant: don't frown. agility! | 09:51 |
| lifeless | jml: new stuff | 09:51 |
| danilos | jml, well, kind of, we left the subscribers list (bug 772754) for maintenance as well, and the "restore subscription on unmute" will only be released with db-deploy | 09:51 |
| _mup_ | Bug #772754: After better-bug-notification changes, list of bug subscribers is confusing <story-better-bug-notification> <Launchpad itself:In Progress by gary> < https://launchpad.net/bugs/772754 > | 09:51 |
| wgrant | jml: Heh, maybe. | 09:52 |
| danilos | I do concede that this didn't require full team to work on this one remaining bug, so switching to maintenance was a practical solution | 09:52 |
| jml | but, in case you were curious, the whole "moving from feature squad to maintenance" thing is a bit of a mystery to me. flacoste has ideas that I don't quite follow. | 09:53 |
| jml | lifeless: ok. I've got to arrange some stuff, might be a little longer. | 09:53 |
| danilos | henninge, if you use the use_advanced_subscriptions check, perhaps you should wrap the get_mute_subscription() call in it as well | 09:53 |
| lifeless | jml: a little longer is fine | 09:53 |
| danilos | henninge, also, note that you might see a merge conflict with db-devel where entire get_mute_subscription was removed | 09:53 |
| henninge | :-P | 09:54 |
| henninge | danilos: err | 09:54 |
| lifeless | btw | 09:54 |
| henninge | danilos: I did wrap | 09:54 |
| lifeless | expose_user_administered_teams_to_js is causing timeouts | 09:54 |
| danilos | henninge, cool, I haven't checked the diff, just responding to your comment, seeing now that you did :) | 09:54 |
| lifeless | (to anyone that recognises that function name) | 09:54 |
| danilos | lifeless, sounds familiar to me | 09:55 |
| danilos | is that +subscriptions page perhaps? | 09:55 |
| lifeless | danilos: its being called into from milestone view initialisation, and it causes about 5K sqlobject object comparisons (quadratic on number of teams) | 09:56 |
| lifeless | danilos: which turns out to be moderately inefficient, and when multiplied by the number of milestones series pages show (and others may show) it becomes pretty huge | 09:57 |
| henninge | danilos: do I have your r= for merging into db-devel as well? | 10:01 |
| henninge | danilos: I just tried out the conflict and would like to fix it now and foget about it ;-) | 10:01 |
| lifeless | jml: that said, because the tl call is crazy early, sooner is better ;) | 10:01 |
| lifeless | allenap: jml: bigjools: https://dev.launchpad.net/LEP/NotificationService | 10:02 |
| lifeless | flacoste: ^ | 10:02 |
| allenap | lifeless: Cool. | 10:02 |
| danilos | henninge, yes, you do :) | 10:03 |
| lifeless | allenap: I've just updated the servicesrequirements page, if you were already reading it | 10:04 |
| allenap | otp | 10:05 |
| henninge | danilos: thanks a lot | 10:06 |
| henninge | danilos: for reference, this is the resolved diff against db-devel. | 10:07 |
| henninge | http://paste.ubuntu.com/612645/ | 10:07 |
| danilos | henninge, cool, thanks | 10:08 |
| lifeless | stub: hi | 10:09 |
| lifeless | stub: I wonder, branchsummary, could I ask you to do the sqlobject/storm bits, enough that it can have some tests wrapped around it? | 10:10 |
| jtv | allenap: somewhat sad news—we'll have to stick to single-package PlainPackageCopyJobs for the time being. | 10:21 |
| jtv | Which means that the "collate by archive" code that both of us wrote in our own ways go out the window. | 10:22 |
| bigjools | it may come in useful later | 10:23 |
| wgrant | Is this for PackageUpload integration? | 10:26 |
| wgrant | Or is there some other consideration? | 10:26 |
| wgrant | eg. error reporting | 10:26 |
| allenap | jtv: :_( | 10:29 |
| jtv | wgrant: yes, it's basically error reporting & handling. | 10:30 |
| jtv | Not related to PackageUpload work. | 10:31 |
| jtv | bigjools: I doubt it'll be useful to keep any of that code—it's basically 3 lines. | 10:32 |
| jtv | And while I'm looking at this… can we really only copy from a series' main archive? | 10:33 |
| LPCIBot | Project windmill-devel build #133: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/133/ | 10:33 |
| wgrant | :( | 10:35 |
| jtv | Oh, to _and from_ main archives. | 10:36 |
| wgrant | jtv: Doesn't PackageCopyJob store the source and target archive? | 10:40 |
| wgrant | Possibly only in the JSON. | 10:40 |
| wgrant | But still. | 10:40 |
| jtv | wgrant: store, yes. | 10:40 |
| jtv | But those values get set to the respective main archives for the source and target distroseries. | 10:40 |
| * jtv mumbles about forgetting non-primary archives altogether and modeling "partner" as an additional distroseries parent instead | 10:41 | |
| wgrant | Are we considering partner here? | 10:42 |
| wgrant | It is meant to be demolished soon. | 10:42 |
| bigjools | partner can go to hell | 10:42 |
| stub | lifeless: EPARSE | 10:42 |
| wgrant | :) | 10:42 |
| wgrant | I am glad we agree. | 10:42 |
| wgrant | So it doesn't matter. | 10:42 |
| bigjools | partner has no place in DDs | 10:43 |
| wgrant | If a derivative wants partner, they are stupid. | 10:43 |
| wgrant | Right. | 10:43 |
| bigjools | I'm simply not supporting it so they have no option | 10:43 |
| wgrant | Heh, good policy. | 10:43 |
| * stub tries to recall BranchSummary | 10:44 | |
| wgrant | bigjools: I guess creating a new distro doesn't even create the archive, does it... that's handy. | 10:44 |
| wgrant | May 534 be the only purpose 4 archive that ever exists :) | 10:44 |
| bigjools | with any luck | 10:44 |
| lifeless | stub: bug 758587 | 10:45 |
| _mup_ | Bug #758587: summarising bugs is expensive <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/758587 > | 10:45 |
| wgrant | bigjools: I might point out that rabbit isn't usable in the test suite yet :/ | 10:50 |
| wgrant | bigjools: It was disabled yesterday, reenabled yesterday, and is failing again today but I haven't disabled it again yet. | 10:50 |
| wgrant | allenap: Did you see that? :( | 10:51 |
| allenap | wgrant: No, I haven't seen that yet :-/ | 10:51 |
| wgrant | It's failed twice. | 10:52 |
| wgrant | On lucid_lp | 10:52 |
| stub | lifeless: Ahh... confused me by saying 'BranchSummary', not BugSummary | 11:04 |
| stub | lifeless: sure | 11:04 |
| lifeless | hhhha 0- yes | 11:05 |
| lifeless | thanks! | 11:05 |
| lifeless | gnight all | 11:05 |
| jtv | I guess we're not actually putting anything in Job.requester yet? | 11:34 |
| jtv | bigjools: Job.requester isn't hooked up yet. :( | 11:36 |
| bigjools | jtv: cock | 11:36 |
| jtv | See how useful a Launchpad Person would be sometimes? Even as a stopgap? | 11:36 |
| bigjools | jtv: did you see how much work it would be to add? | 11:36 |
| bigjools | jtv: I'd not be averse to using the Janitor | 11:37 |
| jtv | Probably not a lot of work… just a matter of adding it to the interface, the model class, & the utility. Just not sure whether that might interfere with abentley's ongoing Job work. | 11:37 |
| jtv | The Janitor as a bug reporter? Heaven help us. | 11:38 |
| bigjools | jtv: it's just going to be adding comments on DSDs ... | 11:38 |
| bigjools | it already adds comments on bugs elsewhere | 11:38 |
| jtv | But only along the lines of "you left this open overnight so I threw it away," no? | 11:38 |
| bigjools | jtv: no, when uploads close bugs, for example | 11:39 |
| jtv | Well it's a bit of a metaphorical stretch but that to me is still "you left this open so I threw it away." | 11:39 |
| bigjools | it's nothing like that! | 11:39 |
| jtv | "It was starting to smell funny." | 11:39 |
| bigjools | :) | 11:39 |
| jtv | Although... true, an upload is different from a regular time-based closing. | 11:40 |
| jtv | So we've already got the Janitor filling in for that Launchpad persona I suggested. | 11:40 |
| jtv | Great. | 11:40 |
| jtv | Maybe I'll just make the problem worse to drive the point home. | 11:40 |
| bigjools | jtv: the janitor is not actually *doing* anything, it's a fake persona that we just stamp onto things | 11:44 |
| bigjools | perhaps that was the point that nobody understood in your email? | 11:44 |
| jtv | Yes, perhaps. | 11:46 |
| jtv | I thought the examples of "be the owner of things" and "be the author of messages" would exemplify that, but I suppose they didn't. | 11:46 |
| jtv | (As opposed to "create things" and "post messages"). | 11:46 |
| jml | henninge: I notice that https://code.launchpad.net/~chrisjohnston/launchpad/197793/+merge/61053 hasn't landed. Any special reason? | 11:48 |
| jml | also https://code.launchpad.net/~chrisjohnston/launchpad/483373/+merge/61042 | 11:49 |
| henninge | jml: actually, three of his branches havn't landed. | 11:50 |
| henninge | jml: test failures, simple to fix | 11:50 |
| henninge | jml: I emailed him to ask if he wanted to fix these himself | 11:50 |
| henninge | jml: if don't here back from himi I'll JFDI myself | 11:50 |
| jml | henninge: thanks! | 11:50 |
| henninge | I consolidated them in one branch to land: lp:~henninge/launchpad/land-chrisjohnston-187013-197793-483373 | 11:51 |
| StevenK | wgrant: packageupload ripped out of _getRecipients | 12:10 |
| wgrant | StevenK: ! | 12:11 |
| wgrant | Excellent. | 12:11 |
| wgrant | So it's in notify() only now? | 12:11 |
| StevenK | I think so. I'll check once I fix this pyflakes issue | 12:11 |
| === henninge is now known as henninge-lunch | ||
| StevenK | wgrant: Yes, it's just notify() | 12:13 |
| wgrant | Excellent. | 12:13 |
| wgrant | So now we just need to deal with sourcelessness. | 12:13 |
| wgrant | ... and test fallout. | 12:13 |
| StevenK | wgrant: I've been thinking about this while cooking dinner. We can probably just re-implement notify() as notification() with spr, bprs and customfiles | 12:14 |
| wgrant | StevenK: If you call it that your apartment will collapse. | 12:14 |
| wgrant | But yes, something along those lines. | 12:14 |
| StevenK | wgrant: notification() was what we agreed to before? :-) | 12:14 |
| StevenK | wgrant: And then the packageupload gubbins can be held inside queue.py | 12:15 |
| wgrant | notification() isn't a verb. | 12:15 |
| wgrant | But yeah. | 12:15 |
| StevenK | Oh well, we just fix notify() | 12:15 |
| wgrant | Yes. | 12:15 |
| wgrant | Fix notify() to not take a PU, moving that into PU.notify. | 12:15 |
| === al-maisan is now known as almaisan-away | ||
| jtv | Why, oh why does LaunchpadScriptLayer.switchDbConfig sabotage my database connection? | 12:46 |
| jtv | "Connection is closed." | 12:46 |
| stub | If it was deliberate, maybe to ensure a rollback? | 12:49 |
| jtv | Well the one test for this does switchDbConfig, then opens a cursor and does a query,. | 12:49 |
| jtv | So I suspect it's something that broke when we went to Storm. | 12:50 |
| jtv | "Test that […] we end up connected as the right user." | 12:50 |
| jtv | It actually queries current_user. | 12:51 |
| jtv | I try commit / switchDbConfig / access-the-db and it fails in that last step. | 12:52 |
| jtv | switchDbConfig is implemented as a call to reconnect_stores | 12:53 |
| jtv | …which actually accesses the database through the main store. | 12:54 |
| jtv | I tried passing the same config name as the layer test did, but no change. | 12:56 |
| wgrant | You know that switchDbConfig is called once in the whole codebase, right? | 12:58 |
| wgrant | What are you doing with it? | 12:58 |
| wgrant | Everyone tends to use switchDbUser normally... | 12:58 |
| === benji is now known as Guest53291 | ||
| === henninge-lunch is now known as henninge | ||
| === almaisan-away is now known as al-maisan | ||
| === matsubara-afk is now known as matsubara | ||
| LPCIBot | Project windmill-devel build #134: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/134/ | 13:21 |
| abentley | henninge: bug #419531 | 14:06 |
| _mup_ | Bug #419531: project name picker search / vocabulary is hard/impossible to use (too many results on exact searches) <disclosure> <regression> <vocabulary> <Launchpad itself:Triaged> < https://launchpad.net/bugs/419531 > | 14:06 |
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| jcsackett | jtv: you still having a problem with the switchDb stuff? | 14:21 |
| jtv | jcsackett: no, I dropped it. | 14:22 |
| benji___ | danilos: if you're looking for a somewhat big branch to review, I have just the thing for you: https://code.launchpad.net/~benji/launchpad/bug-784575-flags/+merge/62175 | 14:23 |
| === benji___ is now known as benji | ||
| jcsackett | jtv: dig. i was about to suggest the helpers in lp.testing.storm but i just realized those are for switchDbUser, not *Config, so no help anyway. | 14:23 |
| danilos | benji, ha, sounds just like the thing I've been missing in my life today :) | 14:23 |
| benji | heh | 14:23 |
| danilos | benji, though it's measly 2627 lines, not up to my standards :) I'll take it, but it's going to be the last one for today then; also, you've got a conflict | 14:24 |
| benji | danilos: thanks; I'll look at the conflict now | 14:24 |
| danilos | thank you | 14:25 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| danilos | benji, you might want to prepare a merged branch with db-devel as well since that one has more changes to the code you are touching, so it will raise conflicts when your branch hits stable and is attempted to be merged to db-devel (saying because I've seen the changed code :) | 14:27 |
| LPCIBot | Project windmill-db-devel build #322: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/322/ | 14:31 |
| danilos | benji, lines 112, any reason not to make this an actual property defined on the class level? (i.e. field_names = ['bug_notification_level']) | 14:31 |
| benji | danilos: well, we wouldn't want a list as a class attribute (shared mutables are bug magnets), but we could make it a tuple -- assuming no one tries to append to it | 14:33 |
| danilos | benji, sure, a tuple would be nicer | 14:33 |
| benji | if you would, note that in your review and I'll see if the tuple works | 14:34 |
| danilos | benji, sure, though do note that we've mostly used lists for these in a bunch of LaunchpadFormViews | 14:34 |
| benji | that's unfortunate; mutable class attributes have cost the universe many an hour | 14:39 |
| danilos | benji, perhaps worth filing a tech-debt bug and mailing the -dev list to warn of the problem? | 14:40 |
| benji | could be, I'll think about doing that | 14:40 |
| danilos | thanks | 14:40 |
| LPCIBot | Project devel build #749: FAILURE in 5 hr 34 min: https://lpci.wedontsleep.org/job/devel/749/ | 14:45 |
| jcsackett | sinzui: i am trying to qa bug 228355, and it occurs to me that qastaging uses the same signup service as lpnet; i'd rather not create a throwaway account on the service to test the change. thoughts? | 14:48 |
| _mup_ | Bug #228355: Unique name reveals hidden email address <disclosure> <lp-registry> <qa-needstesting> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/228355 > | 14:48 |
| sinzui | hmm | 14:48 |
| wgrant | I have a couple of test accounts on prod SSO. | 14:49 |
| wgrant | At least one of which I haven't used on qastaging lately. | 14:49 |
| sinzui | Isn't this about one that has never been used | 14:50 |
| wgrant | Well, I have two SSO accounts that don't have LP people on qastaging. So they will do. | 14:50 |
| sinzui | yes, thanks | 14:51 |
| wgrant | (I created them back when, er, experimenting with U1) | 14:51 |
| wgrant | https://qastaging.launchpad.net/~me+ubuntuonetest | 14:51 |
| wgrant | That looks qa-ok. | 14:52 |
| danilos | benji, around lines 1224-1254, you remove a test that I believe is still useful to keep around, even if it needs to update for the new +subscribe page (eg. selecting appropriate radio box) | 14:54 |
| * benji looks | 14:55 | |
| danilos | I am mostly concerned because it's related to private bugs | 14:55 |
| benji | I don't think so. My reading of that test is that it's about the unsubscribe and then redirect behavior, which the new code doesn't have. | 14:57 |
| sinzui | thanks wgrant | 14:57 |
| jcsackett | thanks, wgrant. | 14:58 |
| danilos | benji, uhm, ok, but what happens with the new code when someone unsubscribes from the private bug using +subscribe page? | 14:59 |
| benji | do you mean the +subscription page? or are you really taking about +subscribe? | 14:59 |
| benji | my understanding is that +susbcribe will be phased out | 15:00 |
| danilos | I mean +subscribe, it's there for non-JS browsers, we are not breaking it even if we were not focusing on it | 15:00 |
| benji | if you think it's worth testing, I'll rejigger the test to use the new UI | 15:01 |
| danilos | benji, the test was actually testing +subscribe page for these things, with advanced features, it offers slightly different options, but still works for non-JS browsers | 15:01 |
| benji | right | 15:02 |
| danilos | benji, ok, I guess it's best to check with gary when he comes back if we want to keep +subscribe working for non-JS browsers (I assume we do), and then reinstate the tests if true (that includes most of xx-bug-personal-subscriptions.txt that you are removing as well, imo) | 15:05 |
| danilos | benji, also, this is about Bug:+subscribe, not Product:+subscribe page I think, I am not sure about the latter | 15:08 |
| LPCIBot | Project windmill-devel build #135: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/135/ | 15:17 |
| danilos | benji, other than the +subscribe situation which I am unsure about, my other big concern with the branch is keeping the feature flag in the JS, and removing a third feature flag conditional in one place | 15:29 |
| danilos | benji, thus, needs-fixing for now | 15:30 |
| benji | it sounds like you found some good stuff, I'll take a look in a while | 15:31 |
| === al-maisan is now known as almaisan-away | ||
| LPCIBot | Project windmill-db-devel build #323: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/323/ | 15:53 |
| jcsackett | sinzui: chat? | 16:03 |
| sinzui | yes | 16:04 |
| jcsackett | i believe i have the empathy stuff all set up right. | 16:04 |
| sinzui | I am told you are not available? were you calling me? | 16:05 |
| jcsackett | i was trying to. | 16:05 |
| sinzui | try again | 16:06 |
| jcsackett | huh. empathy just crashed. | 16:06 |
| deryck | Hi, everyone. | 16:14 |
| henninge | deryck! ;-) | 16:14 |
| LPCIBot | Project windmill-devel build #136: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/136/ | 16:17 |
| gary_poster | danilos, benji, yeah, until told otherwise by LP leadership, I suspect we should keep previously-working non-JS functionality around. I'm thinking of Bug:+subscribe here. | 16:17 |
| benji | gary_poster: the discussion was more about the tests for the new +susbcribe (the one that exists with the feature flag on/removed), I removed some tests for the old +subscribe and need to verify that the new +subscribe has annalogous tests and (I suppose) implement them if not | 16:19 |
| benji | (I haven't (intentionally) removed any functionality.) | 16:19 |
| gary_poster | benji, huh. i'm not sure i'm on the right track then' | 16:20 |
| gary_poster | gimme a few and we can have a call, to make sure, if that is alright | 16:20 |
| benji | that's ok, I wasn't on the right track when Danilo and were discussing it earlier :) I've since found enlightenment. | 16:21 |
| benji | sure | 16:21 |
| cjohnston | henninge: ping | 16:31 |
| henninge | Hi cjohnston! | 16:31 |
| cjohnston | Hey! Just checking the status of my MPs | 16:31 |
| cjohnston | ;-) | 16:31 |
| henninge | cjohnston: The tests failed, I forwarded the email. | 16:37 |
| henninge | cjohnston: I just wanted to give you a chance to fix the tests yourself but I can do that, too. | 16:38 |
| henninge | cjohnston: they are simple to fix | 16:38 |
| cjohnston | When did you send the email | 16:38 |
| henninge | cjohnston: yesterday, 9:37 UTC | 16:39 |
| cjohnston | found ti | 16:41 |
| cjohnston | it | 16:41 |
| cjohnston | was hidden | 16:41 |
| jml | henninge: out of curiosity, did you run the tests with 'ec2 land'? | 16:49 |
| henninge | jml: yes, I believe so | 16:50 |
| jml | henninge: I ask because it's supposed to email the patch author with the test results as well the lander. | 16:50 |
| jml | henninge: if it's not, maybe it's buggy. | 16:50 |
| henninge | jml: I created a new branch an merged three of cjohnston's branches and landed that branch | 16:50 |
| jml | ahhh | 16:50 |
| jml | that'll do it. | 16:50 |
| cjohnston | jml just wants me to get more mail since I want to throw the pie :-P | 16:52 |
| jml | cjohnston: heh | 16:52 |
| jml | cjohnston: it's actually that I have a deep and abiding belief in automating the processing of information using computers | 16:53 |
| jml | call me crazy | 16:53 |
| cjohnston | ;-) | 16:54 |
| deryck | henninge, well done on plowing through some bugs the last couple days. | 16:54 |
| === matsubara is now known as matsubara-lunch | ||
| henninge | deryck: ;-) | 16:55 |
| cjohnston | henninge: I'm not completely sure how to fix this.. Got time to help me learn? | 17:01 |
| === matsubara-lunch is now known as matsubara | ||
| henninge | cjohnston: sure | 17:03 |
| henninge | well, actually, time is the problem | 17:04 |
| cjohnston | Want to try tomorrow? | 17:04 |
| cjohnston | I think your nearing your EOD? | 17:05 |
| henninge | cjohnston: I am. | 17:05 |
| henninge | cjohnston: yes, let's do it tomorrow, if that's ok. | 17:05 |
| cjohnston | Sure.. Do you have a time frame that may be good? Its morning over here, so I'd just like to make sure I'm about. | 17:06 |
| henninge | cjohnston: what's your timezone? | 17:07 |
| * henninge is at UTC+2 | 17:07 | |
| cjohnston | -4 | 17:07 |
| henninge | oh, not too bad | 17:08 |
| cjohnston | anytime after 1130 UTC should be good for me. | 17:09 |
| henninge | cjohnston: you should just ping me whenever you come online | 17:09 |
| henninge | ok | 17:09 |
| cjohnston | Ok.. Sounds great. Thanks | 17:10 |
| henninge | cjohnston: actually, I might be at lunch at 1130, make it 1200. See you tomorrow ;) | 17:11 |
| henninge | UTC | 17:11 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| jml | g'night all | 17:57 |
| bigjools | nn from me too | 17:58 |
| nigelb | I'm curious, what's the difference in the two options on the survey? | 18:12 |
| nigelb | jml: ^^ | 18:16 |
| LPCIBot | Project windmill-devel build #137: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/137/ | 18:36 |
| LPCIBot | Yippie, build fixed! | 18:53 |
| LPCIBot | Project db-devel build #579: FIXED in 5 hr 42 min: https://lpci.wedontsleep.org/job/db-devel/579/ | 18:53 |
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews | Critical bugs:214 - 0:[######=_]:256 | ||
| LPCIBot | Project windmill-db-devel build #324: STILL FAILING in 1 hr 16 min: https://lpci.wedontsleep.org/job/windmill-db-devel/324/ | 19:33 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| cr3 | if I get married, I'm registering my marriage as a project on launchpad so that we can track bugs, write blueprints, etc. | 19:54 |
| LPCIBot | Yippie, build fixed! | 20:08 |
| LPCIBot | Project devel build #750: FIXED in 5 hr 22 min: https://lpci.wedontsleep.org/job/devel/750/ | 20:08 |
| bac | cr3: remember we don't have private projects yet, so this will all have to be open source. | 20:08 |
| cr3 | bac: I'll make sure the project is under a GPL license so that others getting married have to do the same | 20:11 |
| beuno | I'd be worried about people forking the project with GPL | 20:15 |
| LPCIBot | Project windmill-db-devel build #325: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-db-devel/325/ | 20:21 |
| lifeless | cody-somerville: hi :) | 20:31 |
| lifeless | flacoste: btw - https://dev.launchpad.net/LEP/NotificationService#preview | 20:32 |
| cody-somerville | lifeless, Hi. :) Besides creating a new branch, I haven't had a chance to start tackling the bug we discussed last night - have been unfortunately been unexpectedly preoccupied today with other matters. I'm still hoping to get around to it today however. | 20:33 |
| LPCIBot | Project windmill-devel build #138: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/138/ | 20:38 |
| lifeless | cody-somerville: no worries | 20:42 |
| lifeless | cody-somerville: its rather low hanging, so I might stab at it myself. | 20:42 |
| lifeless | I have one more (phew) email from tuesday to send | 20:42 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| jkakar | Does Launchpad use PostgreSQL partitions for large tables? | 21:12 |
| lifeless | no | 21:12 |
| jkakar | Ah, okay, I've been wondering at what point it makes sense to think about it. | 21:12 |
| lifeless | selena would be a good person to ask, I think | 21:14 |
| lifeless | she did a 'managing TB's' talk at pgcon last week | 21:15 |
| cjohnston | Is LP slow for anyone else or is it just me | 21:17 |
| cjohnston | I'm up to over a minute trying to load a bug report | 21:17 |
| lifeless | which bug | 21:17 |
| cjohnston | https://bugs.launchpad.net/bugs/787914 | 21:18 |
| _mup_ | Bug #787914: Bottom of "Why use Ubuntu?" has "download 11.04" with an 10.10 logo. <Ubuntu Website:New> < https://launchpad.net/bugs/787914 > | 21:18 |
| lifeless | loaded in 3 seconds for me | 21:18 |
| lifeless | 0.91 seconds render time | 21:18 |
| cjohnston | must be me.. what abot loading the attachment? | 21:18 |
| sinzui | It is slow for me, still laoding | 21:19 |
| sinzui | and still loading | 21:19 |
| cjohnston | ok.. so im not the only one | 21:19 |
| * sinzui thinks a server is going belly up | 21:19 | |
| lifeless | attachment loaded | 21:19 |
| sinzui | still loading | 21:19 |
| cjohnston | It's seemed slow to me for a day or two now, but this is bad. | 21:19 |
| lifeless | while thats slow | 21:20 |
| lifeless | please check - | 21:20 |
| lifeless | ping launchpad.net | 21:20 |
| lifeless | we want no packet loss over 10 pings | 21:20 |
| cjohnston | From eth0.chenet.canonical.com (91.189.88.133) icmp_seq=25 Destination Host Unreachable | 21:21 |
| lifeless | ahha | 21:21 |
| sinzui | I can get to qastaging very quickly, but neither browser is loading lpnet pages | 21:22 |
| lifeless | 223 works | 21:22 |
| lifeless | 222 does not | 21:22 |
| lifeless | goig to our ops channel to grab a network guy | 21:22 |
| lifeless | sinzui: could you perhaps tweet on identi.ca? I'll start escalation stuff | 21:23 |
| lifeless | I have to go out soon for a medical appointment | 21:23 |
| sinzui | okay | 21:23 |
| cjohnston | I feel better that I'm not imagining things | 21:24 |
| LPCIBot | Project windmill-devel build #139: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/139/ | 21:24 |
| lifeless | when I put 91.189.89.222 launchpad.net into my hosts | 21:25 |
| lifeless | I cannot browse the site | 21:25 |
| lifeless | its failing fast now | 21:26 |
| lifeless | should be happier now | 21:28 |
| lifeless | sinzui: front end is back | 21:29 |
| sinzui | thanks | 21:29 |
| cjohnston | lifeless: sinzui 0% packetloss in 14 packets | 21:34 |
| cjohnston | this ones from nutmeg | 21:35 |
| === mwhudson_ is now known as mwhudson | ||
| sinzui | deryck: gary_poster: If one of you can confirm that we really do not need to store wiki names any more, we can close about 6 bugs: bug 186660 is the root issue | 21:47 |
| _mup_ | Bug #186660: Launchpad shouldn't store wiki names <lp-registry> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/186660 > | 21:47 |
| gary_poster | sinzui, cool. deryck, I'm happy to promote that one on my team, or do you want to call it? | 21:47 |
| deryck | gary_poster, you can take that one since I got the downtime action earlier. ;) | 21:48 |
| gary_poster | deryck, +1 :-) | 21:48 |
| lifeless | gary_poster: hi | 21:50 |
| gary_poster | lifeless, hi | 21:50 |
| lifeless | gary_poster: I need a very quick code check with you | 21:50 |
| gary_poster | ok lifeless | 21:50 |
| lifeless | gary_poster: can you do voice? its near your EOD so I want to be as prompt as possible | 21:50 |
| gary_poster | sure; lemme close a door :-)_ | 21:50 |
| lifeless | say when | 21:51 |
| gary_poster | lifeless, I assume you'd prefer mumble. I'm in yellow one-on-one; join me or drag me | 21:52 |
| gary_poster | Skype is also fine | 21:52 |
| lifeless | gary_poster: mumble is terrible for me from NZ :) | 21:52 |
| lifeless | skype is better, sadly. | 21:52 |
| lifeless | gary_poster: bug 787765 | 21:53 |
| _mup_ | Bug #787765: ProductSeries:+index timeouts <oem-services> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/787765 > | 21:53 |
| === matsubara is now known as matsubara-afk | ||
| === micahg_ is now known as micahg | ||
| cjohnston | lifeless: I'm getting between 5 and 11% packet loss on 222 again | 23:05 |
| NCommander | StevenK or wgrant: if you have an opportunity, I'd like you to review my test case for arch any/all skew. (I got sidetracked on working it this and last week due to specs) | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
