| mwhudson | the 503 page change was the one that uses flash for xdr? | 00:00 |
|---|---|---|
| wgrant | mwhudson: Yes. | 00:00 |
| mwhudson | boggle | 00:00 |
| wgrant | mwhudson: To get at identi.ca/twitter feeds. | 00:00 |
| mwhudson | oh | 00:00 |
| wgrant | Yes, the Web is broken... but Flash is not a solution :) | 00:01 |
| lifeless | mwhudson: wgrant: it uses flash as a fallback, not by default | 00:11 |
| lifeless | modern browsers with javascript enabled will just work without the flash | 00:11 |
| lifeless | however failing tests is a good reason to rollback :) | 00:11 |
| wgrant | I wonder if those profiling changes weren't meant to land at all. | 00:17 |
| wgrant | They seem somewhat insane and irrelevant. | 00:17 |
| * wgrant rolls it all back. | 00:17 | |
| huwshimi | wgrant: How did you figure out which js was using mochikit? Or did you just remember? | 00:19 |
| wgrant | huwshimi: I remembered seeing some bits of it around... grepping for it is going to be difficult :/ | 00:20 |
| lifeless | heh | 00:22 |
| lifeless | explain select * from oops_oops; | 00:23 |
| lifeless | QUERY PLAN | 00:23 |
| lifeless | ------------------------------------------------------------------------ | 00:23 |
| lifeless | Seq Scan on oops_oops (cost=0.00..1922179.42 rows=27723142 width=464) | 00:23 |
| lifeless | 27M rows. | 00:23 |
| wgrant | Hmm. | 00:23 |
| mwhudson | ah, i was wondering why you needed to see the query plan for that statement :-) | 00:23 |
| lifeless | mwhudson: faster than count(*) :) | 00:24 |
| mwhudson | different answer too, i guess? | 00:24 |
| mwhudson | statistics vs actual | 00:25 |
| lifeless | the stats at last update know the total live row count | 00:25 |
| lifeless | vs instantaneous row count | 00:25 |
| * mwhudson slams head into desk about interactions in lp's tests | 00:25 | |
| lifeless | mwhudson: welcome ! | 00:25 |
| wgrant | Sensible interfaces? What are they? | 00:26 |
| lifeless | mwhudson: what got you onto this? | 00:26 |
| mwhudson | https://bugs.launchpad.net/launchpad/+bug/631884 basically | 00:27 |
| _mup_ | Bug #631884: multiple variables pointing to FeatureController get out of sync easily <feature-flags> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/631884 > | 00:27 |
| lifeless | ah yes | 00:27 |
| lifeless | there is another one about get_request_timeline | 00:27 |
| lifeless | same issue | 00:27 |
| mwhudson | yeah, features are a bit simpler, more localized | 00:28 |
| mwhudson | so attacking them first | 00:28 |
| lifeless | I like the sound of that | 00:28 |
| mwhudson | and my change isn't directly related to the problem i was head desking about, or at least my change doesn't make any difference | 00:29 |
| mwhudson | but for example, it doesn't seem we make any systematic effort to ensure that an interaction doesn't outlive a testcase | 00:29 |
| mwhudson | also, TestCaseWithFactory sets up an interaction, TestCase doesn't | 00:30 |
| mwhudson | which is a bit ... dunno, something | 00:30 |
| mwhudson | anyway! | 00:30 |
| lifeless | doesn't suprise me | 00:30 |
| lifeless | if I may make a suggestion | 00:30 |
| lifeless | a fixtures.Fixture to push and pop interactions would be very useful | 00:30 |
| mwhudson | yes probably | 00:31 |
| lifeless | s/suggestion/observation/ | 00:31 |
| mwhudson | i think also a pithy email and wiki page along the lines of "10 things every launchpad developer absolutely positively has to know about interactions and participations or else" is forthcoming | 00:31 |
| lifeless | \o/ | 00:32 |
| lifeless | https://code.launchpad.net/~lifeless/python-oops/docs/+merge/77849 | 00:34 |
| lifeless | wgrant: mwhudson: can has review? ^ | 01:02 |
| mwhudson | oh right, profiling tests are/were broken on devel, right? | 01:20 |
| lifeless | yes | 01:21 |
| mwhudson | and guess what! | 01:21 |
| mwhudson | thread local variables are involved | 01:21 |
| lifeless | orly | 01:21 |
| mwhudson | yrly | 01:22 |
| mwhudson | def assertCleanProfilerState(self, message='something did not clean up'): | 01:22 |
| mwhudson | """Check whether profiler thread local is clean.""" | 01:22 |
| * mwhudson chucks his feature flag thing into ec2 | 01:25 | |
| lifeless | ok pgsql, thats just daft | 01:29 |
| lifeless | or rather, like queries really really suck | 01:30 |
| wgrant | Howso? | 01:30 |
| lifeless | explain select pathname from oops_oops where pathname like '/srv/launchpad.net-logs/production/wampee/2010-05-24/%' order by pathname; | 01:31 |
| lifeless | QUERY PLAN | 01:31 |
| lifeless | ------------------------------------------------------------------------------------------------------ | 01:31 |
| lifeless | Sort (cost=2000294.79..2000301.89 rows=2841 width=68) | 01:31 |
| lifeless | Sort Key: pathname | 01:31 |
| lifeless | -> Seq Scan on oops_oops (cost=0.00..2000131.82 rows=2841 width=68) | 01:31 |
| lifeless | Filter: ((pathname)::text ~~ '/srv/launchpad.net-logs/production/wampee/2010-05-24/%'::text) | 01:31 |
| lifeless | possibly too-few statistics for the table size | 01:31 |
| wgrant | Is there an index? | 01:31 |
| lifeless | yes | 01:31 |
| lifeless | "oops_oops_pathname_key" UNIQUE, btree (pathname) | 01:31 |
| lifeless | of course, its 5.5GB due to bloat. | 01:32 |
| lifeless | wow, disk sorts. funky. | 01:35 |
| lifeless | explain select pathname from oops_oops where pathname like '/srv/launchpad.net-logs/production/wampee/2010-05-24/%' and date between '2010-05-24'::timestamp - '1 day'::interval and '2010-05-24'::timestamp + '1 day'::interval order by pathname; | 01:40 |
| lifeless | seems to do whats needed. | 01:40 |
| lifeless | we may be better offer with an IN statement or a temp table. | 01:41 |
| lifeless | though they can degrade to seq scans horribly quickly. | 01:41 |
| lifeless | temp table is at leat reasonabl | 01:43 |
| lifeless | e | 01:43 |
| lifeless | any reviewers in the house ? 8 liner ... | 01:44 |
| mwhudson | lifeless: ah yes, my machine crashed after you pasted the link | 01:52 |
| mwhudson | lifeless: link me up again? | 01:52 |
| lifeless | https://code.launchpad.net/~lifeless/python-oops/docs/+merge/77849 | 01:53 |
| lifeless | thanks! | 01:53 |
| mwhudson | done | 01:55 |
| mwhudson | er, lunch time | 01:55 |
| wgrant | lifeless: So, do we have any plans to fix all these timeouts? | 02:23 |
| lifeless | wgrant: yes. | 02:23 |
| wgrant | lifeless: Any *specific* plans? :) | 02:42 |
| lifeless | wgrant: yes :) | 02:43 |
| * StevenK waits for "* wgrant shakes lifeless until some plans fall out." | 02:44 | |
| wgrant | Pretty much! | 02:44 |
| wgrant | 'cause we haven't made any progress in quite a while. | 02:45 |
| wgrant | Apart from the batchnav thing. | 02:45 |
| lifeless | bug search is a prime candidate for solr | 02:45 |
| wgrant | And that's at least 18 months away. | 02:45 |
| lifeless | thats a different discussion | 02:45 |
| wgrant | Is it? | 02:46 |
| lifeless | broad strokes: - tune implementations now (e.g. denorm, search schemas etc), and do a dedicated search engine if/when we reach the limits of that approach | 02:46 |
| wgrant | We have some debilitating, embarrassing timeouts. We're making little to no progress on them. | 02:47 |
| === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 253 - 0:[#######=]:256 | ||
| lifeless | we have no engineers currently hacking on them | 02:48 |
| lifeless | thats the proximate cause of no progress | 02:48 |
| lifeless | francis is analysis *why* thats happening | 02:48 |
| wgrant | That's been happening for months now. | 02:48 |
| lifeless | analysing. | 02:48 |
| wgrant | We have not made critical bug progress for 4.5 months now. | 02:48 |
| wgrant | We adopted the new critical bug process 8.5 months ago. | 02:49 |
| wgrant | More than half the time the new process has been working, it has been failing,. | 02:49 |
| lifeless | . | 02:49 |
| lifeless | yes, thats the evidence. | 02:50 |
| lifeless | now, do you have an analysis of causes? | 02:50 |
| wgrant | Well, the evidence points to one. | 02:51 |
| wgrant | It's not all of it. | 02:51 |
| wgrant | But it is something. | 02:51 |
| lifeless | too many new criticals? | 02:51 |
| wgrant | No. | 02:52 |
| lifeless | <...> | 02:52 |
| wgrant | The maintenance squad configuration. | 02:52 |
| lifeless | please expand on that :) | 02:52 |
| wgrant | In particular, the week Teal stopped taking criticals, the downward trend stopped. | 02:52 |
| wgrant | http://webnumbr.com/launchpad-critical-bugs | 02:52 |
| wgrant | We stopped taking criticals just after the middle of May. | 02:52 |
| lifeless | the problem started earlier | 02:53 |
| wgrant | Certainly. | 02:53 |
| lifeless | so, that simply speaks to our ability to tread water | 02:53 |
| wgrant | Sure, but we're no longer even close to treading water. | 02:53 |
| lifeless | right | 02:53 |
| lifeless | the key question is where are all the criticals coming from | 02:53 |
| wgrant | It was clear we were in a terrible situation 3 months. | 02:54 |
| wgrant | 3 months ago | 02:54 |
| lifeless | until we rule out maintenance efforts, we can't even thing about things like 'add more maintenance folk' | 02:54 |
| wgrant | How long is this going to take? | 02:54 |
| wgrant | We are getting into a steadily worse situation. | 02:54 |
| wgrant | And I've seen no acknowledgement that we actually have a crisis here. | 02:54 |
| lifeless | I don't think its a run around in circles crisis | 02:55 |
| lifeless | its a significant issue | 02:55 |
| wgrant | What is a run around in circles crisis, then? | 02:55 |
| lifeless | and francis is working on the analysis | 02:55 |
| lifeless | wgrant: one where stopping and thinking will not help the outcome | 02:55 |
| wgrant | The new definition and process are clearly not working. Reasonable functioning of the new structure of the LP team depends entirely on the critical queue being exhausted. | 02:55 |
| wgrant | The critical queue is being the opposite of exhausted. | 02:56 |
| lifeless | wgrant: yes, yes. Yes. | 02:56 |
| wgrant | Therefore the new structure of the LP team will not provide reasonable response and functionality. | 02:56 |
| wgrant | It's been nearly a year. | 02:56 |
| lifeless | uhm | 02:56 |
| wgrant | Something needs to be done. | 02:56 |
| lifeless | so, lets detangle some things | 02:56 |
| lifeless | firstly, the delta from old structure to new is *still*, even with this issue, positive: we -are- progressing both maintenance and development efforts with less scheduling headaches. | 02:57 |
| wgrant | Hmm? For some definitions of maintenance, perhaps. | 02:57 |
| lifeless | we haven't solved /all/ the issues we hoped to, but we have some. | 02:57 |
| wgrant | I would posit that maintenance is, on the whole, substantially worse than it was. | 02:57 |
| wgrant | Unless you restrict "maintenance" to "fixing timeouts and OOPSes" | 02:58 |
| lifeless | wgrant: and escalated bugs, which previously were a real headache, we are doing them more reliably and with less delay than previously. | 02:58 |
| wgrant | In some cases, yes. | 02:58 |
| lifeless | wgrant: welcome to statistics. | 02:59 |
| lifeless | now, | 02:59 |
| lifeless | as for doing something. | 02:59 |
| wgrant | Now, I'm not saying that the new structure is bad. I'm saying that the current implementation is objectively not working. | 02:59 |
| lifeless | Do you propose we go off half cocked without analysing the situation ? | 02:59 |
| wgrant | No, we need analysis. | 02:59 |
| wgrant | But we needed analysis 3 months ago. | 02:59 |
| wgrant | There is no analysis :( | 02:59 |
| lifeless | francis is doing one. | 02:59 |
| lifeless | Whats your beef with it ? | 02:59 |
| lifeless | I posit that you want it complete yesterday. | 03:01 |
| wgrant | Is it going to come to a conclusion? | 03:01 |
| lifeless | of course | 03:01 |
| wgrant | It has been several weeks. | 03:01 |
| lifeless | of course | 03:01 |
| lifeless | its not a trivial undertaking, and the person doing it has other things (like .e.g qbr prep) that are higher priority | 03:01 |
| wgrant | Sure. | 03:01 |
| lifeless | it took 4 or so months to do the analysis around the restructure | 03:02 |
| wgrant | But it's something that needs to be done quickly, so perhaps the terribly busy person isn't the ideal person to do it :) | 03:02 |
| wgrant | We have a serious problem here, and the longer we take to analyse it, the worse it is getting. | 03:02 |
| wgrant | It took months for people to admit that we had a problem. | 03:03 |
| lifeless | the scale is changing slowly, the structure isn't. | 03:03 |
| wgrant | And now it is going to take months to analyse. | 03:03 |
| lifeless | well, it may not take months, but its going to take more than a couple of days :) | 03:03 |
| wgrant | It has already taken months. | 03:03 |
| lifeless | What is your objective in this discussion? To convince me its drop-dead urgent? It doesn't seem to be to me. Important - yes. Important enough that its being done right now? Yes. Run-with-knives urgent? no. | 03:04 |
| lifeless | the situation we're in is broadly 'too much to do and not enough hands to do it with'; thats -normal-. Whats interesting here is that we have things we believe we -must- do, which we don't have enough hands to do. | 03:05 |
| wgrant | And the number of hands is decreasing :) | 03:06 |
| lifeless | And that looks abnormal when you consider the definition of the things we -must- do is pretty modest [plug regressions, plug scaling issues, do escalated tasks] | 03:06 |
| wgrant | Indeed. | 03:06 |
| lifeless | the stuff francis has noted so far is that its mainly self inflicted | 03:07 |
| lifeless | IIRC > 1/2 the bugs analysed so far have been caused by feature work | 03:07 |
| lifeless | but he hasn't analysed enough to be confident that its indicative in the big picture | 03:08 |
| lifeless | *IF* it is, then the thing to point at is cost of change: particularly hidden costs. | 03:08 |
| wgrant | Hm, is this analysis progress visible somewhere? | 03:08 |
| lifeless | And that will come back to code structure, which gets back to what reviews are [perhaps failing] to do. For instance. | 03:09 |
| wgrant | I'd not heard any of this. | 03:09 |
| lifeless | I don't know where his working notes are | 03:09 |
| wgrant | It was not clear that any progress had been made whatsoerver. | 03:09 |
| lifeless | I talk with him weekly | 03:09 |
| lifeless | StevenK: ++ | 03:10 |
| StevenK | Hm? | 03:10 |
| lifeless | nuking sampledata. Love it. | 03:10 |
| StevenK | I'd remove all of it if I think it had any hope in hell of passing ec2. | 03:11 |
| lifeless | oops-tools is truely painful to hack on | 03:12 |
| lifeless | slow tests + no way (that I can see) to run just one. | 03:12 |
| lifeless | wgrant: StevenK: I need a brief teddy bear about removing oops prefixes and the impact on fauly analysis | 03:20 |
| lifeless | could either of you spare 10 minutes? | 03:20 |
| wgrant | lifeless: Sure. | 03:20 |
| StevenK | Public holiday and about to brave the daystar | 03:20 |
| lifeless | wgrant: skype ? | 03:21 |
| huwshimi | wallyworld: Do you know much about the names of the permission levels on the +managedisclosure page (e.g. Observer, Restricted Observer)? Are they used elsewhere in Launchpad? | 03:56 |
| wallyworld | huwshimi: no, this is new terminology afaik | 03:57 |
| huwshimi | wallyworld: OK, I'm just trying to figure out if there are any better labels we could come up with. Something a bit more descriptive. E.g. Restricted Observer can only view subscribed so they could be labelled "Subscriber" | 03:59 |
| huwshimi | wallyworld: Any suggestions? | 03:59 |
| wallyworld | huwshimi: i think we are trying to get away from conflating visibility with subscriptions | 04:00 |
| huwshimi | wallyworld: OK, that makes sense. I think I mostly have reservations about the word "observer". | 04:01 |
| wallyworld | it's hard to come up with a one or two word label that conveys the intended meaning | 04:01 |
| huwshimi | yeah | 04:01 |
| wgrant | Same with "disclosure" | 04:01 |
| wallyworld | i think though that once the terminology becomes socialised, it will be understood | 04:02 |
| wgrant | We're very good at using bad terminology. | 04:02 |
| lifeless | you could just not label them. | 04:02 |
| lifeless | and instead describe their rights | 04:02 |
| wallyworld | perhaps we need good inline or popup help to explain what it means | 04:02 |
| lifeless | [full access]\n* person\n* person ... | 04:02 |
| lifeless | [access to listed objects only]\n* person\n* person | 04:03 |
| wallyworld | labels are needed if we want to do a choice list selection widget though | 04:03 |
| huwshimi | wallyworld: Yeah I was working on that when I decided I really wanted to think about the labels | 04:03 |
| huwshimi | wallyworld: Yeah that's right | 04:03 |
| lifeless | wallyworld: do we need a label for 'class of role' really? | 04:03 |
| huwshimi | wallyworld: Or for things like "Add an Observer" links | 04:03 |
| wgrant | "Grant access"? | 04:03 |
| lifeless | wallyworld: or just a phrase that explains | 04:03 |
| lifeless | right | 04:03 |
| wallyworld | i think we need 3 things: 1. a good label, 2. a short sentence that can go in brackets after, and 3. verbose popup help text | 04:04 |
| wallyworld | there are 2 role classes that can see stuff because of access being explicitly granted, vs one access class that can implicitly see everything because of the project role | 04:06 |
| wallyworld | so that makes it a bit harder to come up with concise labels | 04:06 |
| lifeless | there are? | 04:06 |
| wgrant | "Project role => access" is a myth that I hope to dispell soon. | 04:07 |
| lifeless | sorry, thats opaque | 04:07 |
| wallyworld | observer and restricted observer are granted access roles | 04:07 |
| lifeless | wallyworld: so is e.g. driver, and owner. | 04:07 |
| wallyworld | but if you are a project owner, then you can see stuff | 04:07 |
| lifeless | wallyworld: for performance we almost certainly want the owner etc in the one system, with checks that they are in sync. | 04:07 |
| wallyworld | but if you register a project, you are the owner without it being granted | 04:07 |
| wallyworld | ie visibility is implicit in that case | 04:08 |
| lifeless | wallyworld: there is a difference between 'the user does not click to grant it' and 'it is not granted' | 04:08 |
| wallyworld | i know ownership can be assigned | 04:08 |
| wgrant | I think it should be the default, but it should not be implicit. | 04:08 |
| wallyworld | lifeless: agree on the difference | 04:08 |
| wallyworld | but if i register a project, i want to implicitly be able to see everything by default | 04:09 |
| lifeless | wallyworld: its my understanding that owners etc won't be checked during lookup: if its not in the table, access denied. | 04:09 |
| lifeless | wallyworld: no, you want to see everything by default. The word implicit isn't needed for the use case :) | 04:09 |
| lifeless | wallyworld: I am asserting that your needs are met by: | 04:09 |
| lifeless | - defaulting project owner to full access (much like we default team owners to administrator status) | 04:10 |
| wallyworld | lifeless: the balsamiq mock ups imply implicit visibility due to project roles | 04:10 |
| lifeless | - possibly having a rule that the owner must retain full access | 04:10 |
| wgrant | Old mockups are not gospel :/ | 04:10 |
| wallyworld | sure, but they are the current starting point | 04:11 |
| wallyworld | if we decide to do things differently so be it | 04:11 |
| wgrant | Mm, I think they are hints. | 04:11 |
| wgrant | Nothing more. | 04:11 |
| wallyworld | sure | 04:12 |
| wallyworld | now we have an interactive demo based on the mockups which can be used to try and help clarify these sorts of requirements | 04:13 |
| wgrant | Yep. | 04:13 |
| lifeless | anyhow, my point is this: you are saying its complex to describe because you have multiple implicit accesses + granted access. | 04:13 |
| wallyworld | yes, that's my current understanding | 04:14 |
| lifeless | one way to address that, and a way I would encourage for reliability and performance in the system, is to drop implicit access. Instead use business rules to populate granted access when something should be automatic. | 04:14 |
| wallyworld | no problem with that, i agree | 04:14 |
| wallyworld | but we may still want to distinguish to the user that is the case | 04:14 |
| wallyworld | ie someone has access due to automatic propogation based on business rules | 04:15 |
| wallyworld | rather than an explicit grant of access by an authorative user | 04:15 |
| lifeless | thats an interesting case | 04:15 |
| wallyworld | so that if someone needs to be removed from the bug supervisors team, they ca nbe' | 04:16 |
| lifeless | I think that the authoritative user still exists (they added someone to the role) | 04:16 |
| wallyworld | what about the case where a team is assigned as bug supervisor. | 04:16 |
| wallyworld | and someone in the team should be cut iff | 04:16 |
| wallyworld | cut off | 04:16 |
| lifeless | and the grant is a consequence of being added to the role - but that doesn't imply revoking when removed from the role | 04:16 |
| wallyworld | but not the whole team | 04:16 |
| lifeless | wallyworld: I don't think we should support that | 04:17 |
| lifeless | wallyworld: let me be more clear: supporting that will be extremely hard. | 04:17 |
| wgrant | You can't just remove them from the team? | 04:17 |
| lifeless | wallyworld: either remove them from the team, or use a team that accurately models the supervisors desired. | 04:17 |
| wallyworld | wgrant: yes, but you need to see why and how someone has acess so you know what you need to do to remove visibility | 04:17 |
| wallyworld | lifeless: see above | 04:17 |
| lifeless | wallyworld: so in this situation,it would show 'user FOO has access because they are in team BAR which has FULL ACCESS' | 04:18 |
| wgrant | wallyworld: Sure, you'll see that they're a member of Ubuntu Bug Control, and that team is granted access. | 04:18 |
| lifeless | I presume there is a free text field related to each observer, for explanations ? | 04:18 |
| wallyworld | not that i am aware, but i could be wrong | 04:18 |
| lifeless | e.g. 'fred is auditing us for iso9008:2000 status' | 04:18 |
| wallyworld | that may be something to add | 04:19 |
| wallyworld | if it is not already there | 04:19 |
| lifeless | that would supply a way to explain business rule added access too - 'BAR added when set as bug supervisor' | 04:19 |
| wallyworld | lifeless: with your example above, it may be that we want to say ".. in team BAR which has FULL ACCESS because team BAR is the bug supervisor" | 04:20 |
| wgrant | Of course, ideally all access control would be managed through this view... | 04:20 |
| lifeless | that isn't enough to support automatically removing BAR when changing bug supervisor (but that may be undesirable anyway) | 04:20 |
| wgrant | So it would show the bug supervisor privilege for that team as well. | 04:20 |
| lifeless | wallyworld: understood, I can't comment about whether we need that or not :) | 04:20 |
| lifeless | wallyworld: I will comment that for teams we started with implicit stuff for owners | 04:21 |
| lifeless | wallyworld: and have slowly, to great rejoicing, removed it. | 04:21 |
| lifeless | wallyworld: so my *hunch* is that it will be a problem. | 04:21 |
| wgrant | As Curtis and I discussed last week about bug supervisors. | 04:21 |
| wallyworld | i agree 100% that the model will be much simpler to have one access lookup meachanism, and that owners etc should be put there via business rules | 04:22 |
| wallyworld | but i think we need to record that, is all | 04:22 |
| wallyworld | so we can show it to the users | 04:22 |
| wallyworld | to explain *why* | 04:22 |
| wallyworld | someone has access | 04:22 |
| wgrant | You might recall that we discussed this on maybe Wednesday's call. The thought was that ideally the roles would not be conflated at all, but the initial project setup wizard would guide you through setting probably the same people into each role. | 04:24 |
| wgrant | The explanation only needs to exist if the roles are configured in separate places and somewhat conflated. | 04:24 |
| wgrant | Ideally they would be separated. | 04:24 |
| wgrant | And manageable from the same place. | 04:24 |
| wgrant | So it's obvious what's what. | 04:24 |
| wgrant | Rather than having the bug supervisor on one page, security contact on another, and then a huge list of (restricted) observers. | 04:25 |
| wgrant | All separated. | 04:25 |
| wallyworld | yes, i recall. but relying on the setup wizard is not enough. | 04:25 |
| wgrant | With no single view of access control. | 04:25 |
| wallyworld | they would be separated | 04:25 |
| wallyworld | not | 04:25 |
| wallyworld | all users with access would be shown on one page | 04:25 |
| wallyworld | regardless of how they got that access | 04:26 |
| wgrant | I speak of more than just project-wide observer access | 04:26 |
| wgrant | The same page really should list everyone with bug supervisor access, security contact membership, etc. | 04:26 |
| wgrant | It probably won't in the first iteration. | 04:26 |
| wgrant | But we should certainly not design ourselves into a corner. | 04:27 |
| wallyworld | you mean for a given project though? | 04:27 |
| wgrant | Yes. | 04:27 |
| huwshimi | ... and this is why I should just JFD things instead of asking questions on IRC :P | 04:27 |
| wallyworld | and that's what the mockups do now | 04:27 |
| wgrant | wallyworld: Hm? | 04:27 |
| huwshimi | wallyworld: Is "member" a confusing word to use? | 04:27 |
| wgrant | wallyworld: They list everyone *with observer access through those roles*. | 04:27 |
| wgrant | wallyworld: They don't take into account the privileges that those roles actually exist to grant. | 04:27 |
| huwshimi | wallyworld: Actually on second thoughts I guess it probably is | 04:28 |
| wallyworld | huwshimi: i can't think of a better term now | 04:28 |
| wallyworld | wgrant: what page mockup are you looking at? | 04:28 |
| huwshimi | wallyworld: Better than "Observer"? | 04:28 |
| wgrant | wallyworld: None. | 04:28 |
| wallyworld | huwshimi: maybe i don't have the context - you talking about team members? | 04:29 |
| wallyworld | wgrant: when you said "they list everyone.....", what does "they" refer to then? | 04:29 |
| wgrant | wallyworld: The last version of the mockups that I saw. | 04:30 |
| huwshimi | wallyworld: definitely confusing then... I'll try and come up with something else | 04:30 |
| wgrant | They only deal with observer access. | 04:30 |
| wgrant | Not any other kind of access, like, say, bug supervisor write privileges. | 04:30 |
| wallyworld | wgrant: and restricted observer, and access via a project role | 04:30 |
| wgrant | They're just different paths to the same privilege. | 04:31 |
| wallyworld | not really? restricted observer != observer | 04:31 |
| wgrant | Restricted observer is the same sort of privilege, just over a smaller scope. | 04:31 |
| wgrant | The privilege is visibility. | 04:31 |
| wgrant | There are other privilegs. | 04:31 |
| wallyworld | like ability to assign/triage bugs? | 04:32 |
| wallyworld | you mean? | 04:32 |
| wgrant | Right. | 04:32 |
| wgrant | Which is what bug supervisor really means. | 04:32 |
| wallyworld | sure, but that stuff we didn't do for this first cut | 04:32 |
| wgrant | Indeed. | 04:32 |
| wgrant | But it's very relevant for if you want to describe why someone has a permission. | 04:33 |
| wgrant | Because then their access management page will say that they are the owner and an observer. | 04:33 |
| wallyworld | yes, so there is a project role filter | 04:33 |
| wgrant | Rather than just an observer because they are the owner. | 04:33 |
| wallyworld | i think we sort of agree | 04:34 |
| wgrant | So, your explanation suggestion is only needed because A) I haven't convinced you yet that project roles have nothing to do with observer privileges, except for being sensible defaults during the setup wizard; and B) the UI that is in scope right now will only cover observer privileges. | 04:35 |
| wgrant | If A becomes no longer the case, then "PRIVILEGE because ROLE" is no longer the case. | 04:36 |
| wgrant | If B becomes no longer the case, then the team's access management page will list ROLE anyway. | 04:37 |
| huwshimi | wallyworld: So is an Observer part of a team or are they just directly connected to a project somehow? | 04:43 |
| wallyworld | huwshimi: an observer is a person or a team who have been granted access to view a project's private artefacts | 04:44 |
| wallyworld | so a person may be an Observer via their team membership | 04:44 |
| wallyworld | huwshimi: a Restricted Observer can just see private bugs and branches | 04:45 |
| wallyworld | huwshimi: an Observer can also see milestones, blueprints etc etc | 04:45 |
| wallyworld | make sense/ | 04:45 |
| wallyworld | ? | 04:45 |
| lifeless | wallyworld: thats temporary | 04:46 |
| huwshimi | wallyworld: But an Observer can also see a projects private artefacts without being part of a team that gives them that permission right? | 04:46 |
| lifeless | wallyworld: long term restricted will be able to be granted milestones blueprints etc | 04:46 |
| lifeless | wallyworld: there is no intention to arbitrarily limit the things restricted observers can be given access to see | 04:46 |
| wallyworld | ok | 04:47 |
| wallyworld | huwshimi: yes, a person may be individually made an observer | 04:47 |
| huwshimi | wallyworld: OK great thanks | 04:47 |
| lifeless | huwshimi: or a team they are in (standard LP idiom there) | 04:47 |
| wallyworld | lifeless: i said that above :-) | 04:48 |
| lifeless | ah ll | 04:48 |
| lifeless | kk | 04:48 |
| wallyworld | lifeless: i assume the long term then is to allow projects to define what 'restricted' means | 04:49 |
| lifeless | wallyworld: I don't know what you mean | 04:53 |
| wallyworld | lifeless: so you said "restricted = bugs and branches only" is temporary | 04:53 |
| wallyworld | and that later | 04:54 |
| wallyworld | restricted would be gratned access to blueprints etc | 04:54 |
| lifeless | restricted would *permit* granting access to blueprints etc | 04:54 |
| lifeless | the limitation to bugs and branches is an implementation limit | 04:54 |
| wallyworld | yes, that's what I was asking, thanks | 04:54 |
| wallyworld | just wanted to be sure i understood | 04:55 |
| lifeless | AFAIK there is no intent for restricted to ever change its meaning: you will always need restricted *to a concrete thing* | 04:55 |
| lifeless | its just that the things we can put in the concrete list will expand as we implement more | 04:55 |
| wallyworld | yes, that's how i understood it from what you said | 04:55 |
| lifeless | kk | 04:56 |
| lifeless | we're synced then :) | 04:56 |
| wallyworld | thanks | 04:56 |
| wallyworld | for now until more people start to discuss it :-) | 04:56 |
| * wallyworld runs off tp pick up kid from school | 04:58 | |
| huwshimi | wallyworld: haha | 04:58 |
| lifeless | can has review? https://code.launchpad.net/~lifeless/oops-tools/nomoreprefix/+merge/77858 | 05:07 |
| lifeless | wgrant: diff is there, if I can tempt you :) | 05:09 |
| wgrant | lifeless: prefix.upper? | 05:13 |
| wgrant | That seems unnecessary, and will break eg. SSO. | 05:13 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| wgrant | Ah. | 05:39 |
| wgrant | It turns out that cloning a container works better if you don't have the MAC overridden in the config to a constant value. | 05:39 |
| lifeless | wgrant: its moved lines, it is necessary | 05:39 |
| wgrant | lifeless: Ugh, so it is. That's horrible. | 05:40 |
| wgrant | lifeless: Can we try using a sensible one first? | 05:41 |
| wgrant | Then fall back to the uppercase one. | 05:41 |
| wgrant | Then create one in sensible case. | 05:41 |
| lifeless | wgrant: thats a rabbit hole and orthogonal | 05:42 |
| lifeless | wgrant: e.g. searches probably do upper() at the moment. | 05:42 |
| lifeless | I'd love to fix oops tools up in general, but I don't fancy cascading tweaks when working on a different focus | 05:45 |
| wgrant | lifeless: Yeah, I get what you're doing now. | 05:50 |
| wgrant | (sorry, lightdm decided that sharing was caring, so it donated lots of my keystrokes to the underlying getty) | 05:50 |
| lifeless | :) | 05:51 |
| lifeless | win | 05:51 |
| lifeless | wgrant: I take it my cover letter wasn't helpful enough ? | 05:53 |
| wgrant | lifeless: I don't understand your req_vars and statements changes in models.py, or your second hunk in oops.txt. | 05:55 |
| wgrant | Was it creating a duplicate QSMMX? | 05:56 |
| lifeless | higher up in oops.txt it calls load_oopses | 05:56 |
| lifeless | and loaded them all | 05:56 |
| lifeless | the sameple QSMMX oops was previously silently ignored (due to the prefix not existing) | 05:56 |
| wgrant | Ah! | 05:56 |
| wgrant | Of course. | 05:56 |
| lifeless | so this change makes it get loaded by that call (line 8 I think) | 05:56 |
| lifeless | the req_vars and statements changes are future proofing for oopses from scripts that don't have req_vars, or statements. | 05:56 |
| wgrant | So they're unrelated? | 05:57 |
| lifeless | snuck in by testing with a minimal plausible oops. | 05:57 |
| wgrant | k | 05:57 |
| lifeless | totally. | 05:57 |
| wgrant | Thought I must have been missing something. | 05:57 |
| lifeless | nah, I failed to write that up. mea culpa | 05:57 |
| wgrant | Approved. | 05:57 |
| lifeless | thanks! | 05:57 |
| wgrant | Oh right, HA librarian tonight. | 06:06 |
| lifeless | btw | 06:09 |
| lifeless | want something scary? | 06:09 |
| wgrant | I am terrified. | 06:09 |
| lifeless | oops-tools will discard oopses if rsync write them to disk out of order & loading runs during the rsync | 06:09 |
| lifeless | out of order being what ext3 dirindex does, of course. | 06:09 |
| wgrant | Heh. | 06:10 |
| wgrant | "discard" meaning "not see", or actually delete? | 06:10 |
| lifeless | not load | 06:10 |
| wgrant | Right. | 06:10 |
| lifeless | if there are 10 oopses when it finishes a run, but they are not range(1,11), then when it backfills, the optimiser which records len() will skip the early numbers | 06:11 |
| wgrant | Yep. | 06:11 |
| lifeless | and this is why I was looking at getting set data from the db :) | 06:11 |
| === almaisan-away is now known as al-maisan | ||
| * StevenK hopes his last ec2 run finishes quickly. | 07:46 | |
| StevenK | Given it started first, it's a little worrying. | 07:46 |
| * nigelb wonders if buildbot will also be public. | 07:48 | |
| StevenK | I'm hoping for our CI infrastructure to be public, be it buildbot or jenkins. | 07:51 |
| StevenK | But I'd prefer the latter. | 07:52 |
| bigjools | good morning all | 08:45 |
| nigelb | Good morning bigjools | 08:46 |
| lifeless | bigjools: 'lo | 08:46 |
| bigjools | howdy hackers | 08:47 |
| lifeless | bigjools: hey, so what was wrong with that backported option ? | 08:48 |
| bigjools | lifeless: it's awful | 08:48 |
| bigjools | for starters, referring to python functions on a command line option is evil | 08:48 |
| lifeless | with you so far | 08:49 |
| bigjools | 2nd, you have to hard code the log name in the function. I wrote code to work around that but again it's evil | 08:49 |
| lifeless | urgle, so you can't pickup the twistd option normally? | 08:49 |
| bigjools | in the end --logfile=/dev/null is much easier :) | 08:49 |
| bigjools | nope, remember that there's 2 sets of options | 08:50 |
| bigjools | one for twisd, the others for the plugin | 08:50 |
| lifeless | bigjools: ah, headdesk. Separately... I closed the bug you filed, but wanted to touch base with you to make sure you understand why | 08:50 |
| bigjools | twistd* | 08:50 |
| bigjools | which bug? | 08:50 |
| lifeless | on oops-twisted | 08:50 |
| bigjools | not read my email yet | 08:50 |
| bigjools | oh, the fallback | 08:50 |
| lifeless | yeah | 08:50 |
| bigjools | I must admit, that way of doing it surprised me | 08:50 |
| lifeless | because twisted's log mechanism sends to all observers, having one observer be a log file and another be the oops system causes failures to be logged twice - once in the log as a default thing, and once as an oops | 08:51 |
| lifeless | so you have to have only one observer - the oops one, and have it *translate* the failures for logging as 'oops id XXX created' | 08:51 |
| bigjools | that's not how I expected it to work either | 08:52 |
| bigjools | I was expecting that the oops observer would *only* add the oops info | 08:52 |
| bigjools | why does it need to translate? | 08:52 |
| lifeless | Yeah, I can see how you might expect that - but can you see how its constrained by the broadcast setup they have ? | 08:52 |
| bigjools | not really :) but I am listening | 08:53 |
| lifeless | ok, so the default is to log the backtrace | 08:53 |
| bigjools | yup | 08:53 |
| lifeless | 30 or 40 lines or whatever. | 08:53 |
| lifeless | we don't want that, we want to log 'created oops id XXX ValueError: foobar' | 08:53 |
| bigjools | why don't we want that? | 08:53 |
| lifeless | because it destroys readability of the log, and the exception and all its data is in the oops | 08:53 |
| bigjools | I'd say that was subjective, but ok, it would be consistent with what LP does already | 08:54 |
| lifeless | of course, if oops reporting is disabled, we want the traceback | 08:54 |
| lifeless | I'll agree that its subjective | 08:55 |
| * bigjools 's inner KDE user is screaming "make it configurable!" | 08:55 | |
| bigjools | anyway it all works hunky dory now | 08:56 |
| lifeless | ok great | 08:56 |
| bigjools | if we get time we'll add another buildout recipe to wrap all this up into a nicer single script | 08:56 |
| lifeless | \o/ | 08:56 |
| bigjools | since the "--logfile /dev/null txlongpoll" is always required | 08:57 |
| lifeless | headdesk. We really should lock down old fixed bugs. | 08:58 |
| lifeless | (bug 7 comment..) | 08:58 |
| _mup_ | Bug #7: Need help for novice translators <lp-translations> <Launchpad itself:Fix Released by danilo> <Launchpad Documentation:Fix Released by matthew.revell> < https://launchpad.net/bugs/7 > | 08:58 |
| nigelb | *headdesks* | 09:00 |
| bigjools | at least it's not pornspam | 09:08 |
| nigelb | although the more fun one was - "Dear bug, I'd like to add you to my network" | 09:09 |
| lifeless | \o/ | 10:06 |
| lifeless | wgrant: care for a follow on review to the prior ? | 10:14 |
| lifeless | wgrant: https://code.launchpad.net/~lifeless/oops-tools/outoforder/+merge/77887 | 10:14 |
| lifeless | the diff is there, the warning is bogus | 10:14 |
| wgrant | lifeless: Not right now, sorry. | 10:15 |
| lifeless | who else is around, not on leave, and a reviewer.... | 10:16 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | oh look, stub. | 10:16 |
| stub | shhh..... | 10:16 |
| stub | lifeless: private branch? | 10:17 |
| lifeless | stub: private project, pending some feedback I've asked for today from various folks | 10:17 |
| lifeless | stub: open sourcing it should happen soon, when we will blind anyone that reads it ;) | 10:18 |
| lifeless | think men in black, done via the code. | 10:18 |
| lifeless | stub: you should have access though | 10:20 |
| bigjools | lifeless: your change to the title on https://bugs.launchpad.net/launchpad/+bug/297471 is not English! | 10:23 |
| _mup_ | Bug #297471: PPA upload notifications always and only go to the signer <email> <lp-soyuz> <oem-services> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297471 > | 10:23 |
| * bigjools fixorates | 10:25 | |
| wgrant | bigjools: It was fine! | 10:34 |
| stub | lifeless: Do we cope with partial OOPS files now, such as an rsync in progress or being killed midrun? | 10:34 |
| wgrant | bigjools: They always go to the signer, and they only go to the signer. | 10:34 |
| bigjools | wgrant: well I misread it a few times, so no it wasn't | 10:34 |
| bigjools | the English is awkward | 10:35 |
| wgrant | Heh | 10:35 |
| lifeless | stub: rsync does a tempfile + rename | 10:35 |
| lifeless | stub: so we ... probably do see the tempfile, which will barf a oops parsing error, which is silently caught and discarded | 10:36 |
| stub | We might do it that way... | 10:36 |
| nigelb | wgrant: I just found out the reason for Ubuntu Mono being smaller :| | 10:36 |
| wgrant | nigelb: Oh? | 10:36 |
| stub | lifeless: Yer, but now when we rescan the file that previously barfed should complete. | 10:36 |
| nigelb | wgrant: bug 727733 | 10:36 |
| lifeless | stub: yes | 10:36 |
| lifeless | stub: it takes 3.5 seconds to get 10K rows (for a moderately busy day, one appserver) out of the db on carob | 10:37 |
| stub | Which we do every 10 minutes, as that is how often the files get synced | 10:38 |
| wgrant | nigelb: Hmm. | 10:38 |
| lifeless | well, no, there is a cronscript, and it walks all active (cronscripts + appservers) at once | 10:38 |
| lifeless | but -most- dirs are much much much smaller | 10:38 |
| lifeless | much | 10:38 |
| lifeless | and a rabbit injector won't need to walk dirs at all | 10:39 |
| lifeless | (which is what this is all leading up to) | 10:39 |
| nigelb | wgrant: Launchpad now looks much smaller and there's no clean way I can think of to fix it that falls back gracefully. | 10:39 |
| wgrant | nigelb: Yeah, it's pretty small :( | 10:39 |
| nigelb | by 2 pts! :( | 10:40 |
| wallyworld_ | stub: there was going to be a restore of the qas db from prod over the weekend i think. Do you know if it succeeded? | 10:52 |
| wgrant | wallyworld_: It did. | 10:52 |
| wgrant | wallyworld_: I finished it off with bradm this morning. | 10:52 |
| wallyworld_ | wgrant: cool. i'll land that db patch | 10:53 |
| wallyworld_ | thabnks | 10:53 |
| wgrant | It is now nice and shiny from a Thursday or Friday backup. | 10:53 |
| stub | If landing a db patch was blocked on refreshing production data, does that mean we are not running garbo jobs on qastaging? Or was it a manual fix of production data? | 10:53 |
| wallyworld_ | stub: we were running garbo but i landed a branch to delete it a bit too soon. cause i didn't realise we ran garbo on qas | 10:55 |
| wallyworld_ | i thought we used a db restore to update qas | 10:55 |
| wallyworld_ | i think until recently we did indeed not run garbo on qas? | 10:55 |
| stub | We do use a db restore to update qas. If we are not running garbo jobs on qas, we should be. | 10:56 |
| wgrant | We do run them on qas. | 10:56 |
| wallyworld_ | stub: we are running them now. but i thought we weren't | 10:57 |
| stub | yup | 10:57 |
| wallyworld_ | i *think* it was a recent server upgrade which know allows us to | 10:57 |
| stub | I dunno what was. | 10:57 |
| wallyworld_ | now | 10:57 |
| wallyworld_ | or at least that's what i think i was told | 10:57 |
| wgrant | garbo's been running for a while. | 10:58 |
| wgrant | But most other stuff doesn't. | 10:58 |
| wallyworld_ | ok | 10:58 |
| lifeless | stub: thanks! | 11:09 |
| === almaisan-away is now known as al-maisan | ||
| bigjools | wgrant: I am starting to look at bug 34086, if you have any thoughts already let me know | 11:49 |
| _mup_ | Bug #34086: removal of arch-all packages while there are arch-specific packages dependent on it results in uninstallable binaries <escalated> <feature> <lp-soyuz> <rls-mgr-o-tracking> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34086 > | 11:49 |
| wgrant | bigjools: Urgh. | 11:50 |
| bigjools | indeed | 11:50 |
| bigjools | when I say "starting to look" I mean evaluate what can be done | 11:51 |
| wgrant | This is pretty related to the sources thing. | 11:51 |
| bigjools | similar | 11:51 |
| wgrant | We should probably approach them in similar ways. | 11:51 |
| bigjools | the key part is working out what the dependent packages are | 11:52 |
| wgrant | Well. | 11:52 |
| wgrant | There are two ways. | 11:52 |
| wgrant | I mean, two ways to approach this. | 11:52 |
| wgrant | 1) Don't remove packages if something is dependent on them. | 11:53 |
| wgrant | 2) Remove all binaries for a source and arch at once. | 11:53 |
| wgrant | Method 1 is just about guaranteed to drive you to insanity and terrible, terrible code. | 11:53 |
| wgrant | And terrible, terrible cruft. | 11:53 |
| wgrant | And won't catch other uninstallability cases. | 11:54 |
| wgrant | So is mostly pointless. | 11:54 |
| wgrant | 2 is easy, has been listed as a TODO since 2005, and I believe it fixes the important cases here. | 11:54 |
| bigjools | yes | 11:54 |
| bigjools | "Need to make binaries go in groups" is the comment in the code :) | 11:54 |
| wgrant | So, talking about dependent packages is probably going to lead you nowhere good. | 11:55 |
| wgrant | Best to ignore that line of investigation, I think. | 11:55 |
| bigjools | well, no | 11:56 |
| bigjools | I am considering all avenues, we'll use the best one | 11:56 |
| wgrant | Well, I consider 1 to be not much better -- but significantly harder -- than 0) Don't ever remove anything at all. | 11:57 |
| bigjools | you don;t understand my point | 11:57 |
| bigjools | anyway, lunch calls | 11:59 |
| === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 253 - 0:[#######=]:256 | ||
| nigelb | Is jtv off/away today? | 12:30 |
| jelmer | nigelb: Yep | 12:31 |
| nigelb | aha, that explains that | 12:31 |
| rvba | Hi benji. Would you be kind enough to mentor 2 of my reviews? (I've done the first branch and I'm currently reviewing the second one) | 12:52 |
| benji | rvba: sure, what can I do fo you? | 12:53 |
| rvba | benji: Thanks, here is the first one: https://code.launchpad.net/~allenap/launchpad/longpoll-associate-consumer-not-now/+merge/77894 | 12:54 |
| jelmer | benji: hi | 13:15 |
| benji | hi jelmer | 13:15 |
| jelmer | benji: I've got a fairly long merge proposal that's already been reviewed by a couple of others. I think I've now adressed all issues that were raised, can you have another look at it? | 13:19 |
| benji | jelmer: sure | 13:19 |
| jelmer | it is https://code.launchpad.net/~jelmer/launchpad/bzr-code-imports-ui/+merge/73153 | 13:19 |
| jelmer | benji: great, thanks :) | 13:19 |
| rvba | benji: Here is the second review if you still have time to mentor it https://code.launchpad.net/~allenap/launchpad/longpoll-finish-read-only-request/+merge/77915 | 13:56 |
| benji | rvba: sure | 13:56 |
| rvba | ta | 13:57 |
| allenap | rvba, benji: Thank you for the reviews :) | 14:36 |
| benji | np | 14:36 |
| === al-maisan is now known as almaisan-away | ||
| deryck | abentley, I saw you marked bug 758896 OPINION. Have we started using this status for ourselves now? | 15:00 |
| _mup_ | Bug #758896: Checklist items and flashes send mixed messages <exploratory-testing> <upstream-translations-sharing> <Launchpad itself:Opinion> < https://launchpad.net/bugs/758896 > | 15:00 |
| abentley | deryck: I think OPINION describes the status better. When jml was product strategist, his opinion had more weight, but I think he was wrong then, too. | 15:01 |
| deryck | abentley, well, OPINION is a closed bug though. I don't think this bug should be closed. | 15:02 |
| deryck | abentley, OPINION says, "closing this bug acknowledging we have a difference of opinion." I don't think you mean that, do you? | 15:03 |
| abentley | deryck: No, I meant "We have a difference of opinion about whether this is a bug". | 15:03 |
| abentley | deryck: The implication that this is a closed bug escaped me. | 15:04 |
| deryck | abentley, hmmm, so you're reading of the status isn't far off, but I think it being closed means it shouldn't be an opinion bug. | 15:04 |
| abentley | deryck: Are you saying the opinion status shouldn't imply a closed bug? | 15:05 |
| deryck | abentley, no, I'm saying opinion status shouldn't be used here because it is a closed bug. | 15:05 |
| deryck | sorry, I wasn't clear | 15:05 |
| abentley | deryck: it was a triaged bug, not a closed one. | 15:06 |
| deryck | abentley, again, not being clear, sorry. :) please change it back to triaged so the bug will not be closed. :) | 15:07 |
| deryck | I don't think we should close this bug. | 15:07 |
| abentley | deryck: I follow. | 15:07 |
| deryck | abentley, but I wanted to understand your thinking and not come along and change it back without chatting with you about it. | 15:08 |
| abentley | deryck: ISTM that opinion is actually neither open or closed. It is "closed to some, open to some, depending on their opinion". | 15:10 |
| deryck | abentley, yes, no one is clear on what OPINION means as a status. | 15:12 |
| jelmer | I've only seen "Opinion" being used as a polite format of "Won't Fix". | 15:12 |
| jelmer | s/format/form/ | 15:12 |
| abentley | jelmer: That kind of applies here. | 15:14 |
| benji | jelmer: I just finished with https://code.launchpad.net/~jelmer/launchpad/bzr-code-imports-ui/+merge/73153. I included a lint report for you. | 15:19 |
| jelmer | benji: Thanks! | 15:19 |
| benji | np | 15:20 |
| jelmer | benji: any chance you can repeat your comment and vote at https://code.launchpad.net/~jelmer/launchpad/bzr-code-imports-ui/+merge/77961 ? I resubmitted the MP while you were reviewing, it seems (no new revisions). | 15:20 |
| benji | jelmer: done | 15:22 |
| jelmer | benji: Teh awesome. Thanks again. | 15:23 |
| deryck | Hi, benji. I have a branch for review if you're available. | 15:29 |
| benji | deryck: sure | 15:30 |
| deryck | benji, thanks! https://code.launchpad.net/~deryck/launchpad/target-series-bug-834082/+merge/77966 | 15:30 |
| === deryck is now known as deryck[lunch] | ||
| deryck[lunch] | benji, I'm lunching early but here if you have questions about that branch. | 15:36 |
| benji | deryck[lunch]: ok | 15:36 |
| jcsackett_ | sinzui: you around/free to chat? | 15:42 |
| sinzui | I am | 15:42 |
| benji | deryck[lunch]: your branch looks good | 15:43 |
| deryck[lunch] | benji, awesome, thanks! | 15:44 |
| sinzui | jcsackett_, https://bugs.launchpad.net/launchpad/+bug/865467 | 15:47 |
| _mup_ | Bug #865467: bug task missing from affects table because bug supervisor is not subscribed <disclosure> <regression> <Launchpad itself:Triaged by jcsackett> < https://launchpad.net/bugs/865467 > | 15:47 |
| sinzui | jcsackett_, bug 375331 is a similar permission issue. bug 113825 describes the ambiguity in the ui. I doubt the later is in scope, but it does help explain the confusion about this issue | 16:17 |
| _mup_ | Bug #375331: Some extra filebug options don't show up for projects not having a bug supervisor <bugs> <projects> <Launchpad itself:Triaged> < https://launchpad.net/bugs/375331 > | 16:17 |
| _mup_ | Bug #113825: Null bug supervisor is confusing <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/113825 > | 16:17 |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| barry | gary_poster: ping | 17:59 |
| === beuno-lunch is now known as beuno | ||
| lifeless | morning | 18:33 |
| nigelb | woah | 18:34 |
| nigelb | Its not that late yet. | 18:34 |
| nigelb | lifeless: early start? | 18:34 |
| lifeless | 0734 | 18:35 |
| lifeless | a little late | 18:35 |
| * nigelb hasnt seen 6 am to 8 am in a while :P | 18:35 | |
| === jcsackett_ is now known as jcsackett | ||
| gary_poster | barry, hi! | 18:52 |
| barry | gary_poster: hi! i *think* i've answered my own questions, re: autoppa and doing a storm release. or let's say, i've worked around my issues :) | 18:52 |
| gary_poster | barry, ok cool-ish :-) sorry wasn't around | 18:53 |
| barry | gary_poster: no worries. at least it's python code so i can always trace what it thinks it should be doing and then make it dtrt :) | 18:53 |
| gary_poster | :-) cool | 18:53 |
| lifeless | flacoste: hi; call timeish ? | 19:37 |
| lifeless | sinzui: medium bugs down to < 1 page | 19:39 |
| sinzui | fab | 19:40 |
| flacoste | lifeless: sure | 19:45 |
| flacoste | lifeless: skype me when ready | 19:50 |
| mwhudson | hm, bin/retest appears not to work with ec2 mails any more? | 20:14 |
| === al-maisan is now known as almaisan-away | ||
| === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 253 - 0:[#######=]:256 | ||
| * mwhudson smacks head again | 22:15 | |
| mwhudson | why do the feature flag context manager thingies install a new feature controller? afaics it's only because of the caching | 22:15 |
| mwhudson | that FeatureController does | 22:15 |
| cjwatson | hmm, so I was wondering about an issue relating to writing the Debian->Ubuntu mass-sync API script on top of the new Archive.copyPackages method | 22:41 |
| wgrant | What in particular concerns you? | 22:42 |
| cjwatson | when we did this with 'sync-source.py -a', the syncs showed up as having been performed by "Ubuntu Archive Auto-Sync <archive@ubuntu.com>" | 22:43 |
| cjwatson | this was generally a good thing - crediting to the admin who performed the auto-sync would give them way too much credit and end up with people assuming they knew things about particular packages and such | 22:44 |
| wgrant | Yep. | 22:44 |
| cjwatson | I'm wondering how we can do that with the new method, given that: | 22:44 |
| cjwatson | (a) bug 827555 isn't done yet | 22:44 |
| _mup_ | Bug #827555: native syncs have no way to indicate sponsorship <derivation> <Launchpad itself:Triaged> < https://launchpad.net/bugs/827555 > | 22:45 |
| cjwatson | (b) the ~katie user apparently no longer exists? | 22:45 |
| wgrant | katie is suspended. Still exists, but can't be browsed to. | 22:45 |
| StevenK | And she is still a celebrity, right? | 22:45 |
| cjwatson | (c) I'd prefer auto-syncs to be performable by any archive admin without having to pass around credentials for an LP account | 22:45 |
| wgrant | Still a celebrity, unfortunately, yes. | 22:45 |
| cjwatson | (yes, I should have thought of all this ages ago) | 22:46 |
| wgrant | cjwatson: Indeed. I don't think Red was really aware of how syncs are used. | 22:46 |
| cjwatson | I don't want to apportion blame ... | 22:46 |
| wgrant | Some could say that this is a problem that comes from having random people develop software like this :P | 22:46 |
| cjwatson | I'd rather solve the problem | 22:47 |
| lifeless | cjwatson: so, one option is to implement (a) | 22:47 |
| cjwatson | right | 22:47 |
| wgrant | I think that's the best option. | 22:47 |
| lifeless | cjwatson: I suspect its tractable | 22:47 |
| cjwatson | if people think that's the best option, and if it doesn't have too many tentacles, I'd be happy to have a go | 22:47 |
| cjwatson | I wouldn't mind advance advice on the likely tentacles, though | 22:47 |
| lifeless | avoid the blue ones, they itch. | 22:48 |
| cjwatson | so we'd then basically do copyPackages(person=lp.people['katie'], ...), yes? | 22:48 |
| lifeless | so things to think about | 22:48 |
| lifeless | should there be limits on who you can credit ? | 22:49 |
| cjwatson | The last time I thought about that, I decided it wasn't a problem since any uploader can already write random crap into the changelog trailer line if they like, and this should be just the same. | 22:49 |
| lifeless | cjwatson: I think you'd want to lookup the person by email rather than hardcoding katie in there. | 22:49 |
| cjwatson | I was abbreviating, but OK :) | 22:49 |
| * StevenK kicks HE and Fremont 1. | 22:50 | |
| wgrant | StevenK: v6 is working fine. | 22:50 |
| lifeless | uhm, you will need to care for backwards compat when you change the job metadata (because we don't rollout atomically) | 22:50 |
| wgrant | v4 seems to still not have routes. | 22:50 |
| StevenK | wgrant: Indeed. | 22:50 |
| StevenK | Which is how I'm connecting. | 22:50 |
| wgrant | But v6 was down for ages too :( | 22:50 |
| cjwatson | lifeless: sorry, is that to me? | 22:50 |
| lifeless | other than that, I presume the output fields already exist | 22:50 |
| lifeless | cjwatson: yes | 22:50 |
| lifeless | cjwatson: jobs run via a json blob of instructional metadata | 22:50 |
| wgrant | So, this whole thing is pretty awful. | 22:50 |
| cjwatson | I hadn't got as far as looking at the existing schema | 22:50 |
| cjwatson | ah | 22:50 |
| wgrant | Because it's only partially implemented. | 22:51 |
| StevenK | PCJs is .. sort of horrible | 22:51 |
| wgrant | Build notifications etc. still only take the SPR's properties into account. | 22:51 |
| StevenK | But it's better than what we had before. | 22:51 |
| wgrant | It's not. | 22:51 |
| wgrant | It's the same as we had before, just for the third time. | 22:51 |
| lifeless | cjwatson: that persists in the db between submission and completion, so changes to the code need to assume (A) old submissions are yet to be processed and (B) new submissions may get picked up by an old processor | 22:51 |
| cjwatson | compat both ways, ok | 22:51 |
| StevenK | At least it isn't delayed copies madness. | 22:52 |
| lifeless | cjwatson: does the output field you want to put the sponsor into already exist ? | 22:52 |
| lifeless | cjwatson: if so I think that that is the entire list of tentacles | 22:52 |
| StevenK | I doubt it. | 22:52 |
| cjwatson | it should do | 22:52 |
| wgrant | It doesn't. | 22:52 |
| wgrant | It's not clear what the sponsor actually means. | 22:52 |
| cjwatson | I think it should act the same as citing somebody else's name in the changelog and then signing it yourself | 22:52 |
| StevenK | There is requestor, but not sponsor | 22:52 |
| wgrant | What does it mean? :) | 22:52 |
| lifeless | well, how does the older sync do its job ? | 22:52 |
| cjwatson | why isn't that the same? | 22:52 |
| wgrant | cjwatson: Heh heh heh. | 22:52 |
| wgrant | cjwatson: That's implemented as properties of the SPR. | 22:53 |
| cjwatson | lifeless: the older sync is admin-only and can pretend to be whoever it likes | 22:53 |
| wgrant | SPR.creator and SPR.signing_key | 22:53 |
| cjwatson | wgrant: oh right | 22:53 |
| cjwatson | and of course now we have the same SPR as Debian | 22:53 |
| wgrant | cjwatson: This should have been fixed as part of DDs, but was conveniently swept under the carpet. | 22:53 |
| StevenK | Indeed. | 22:53 |
| wgrant | So much so that until last week we didn't even track who did syncs. | 22:53 |
| cjwatson | bugger. then this is actually quite hard. | 22:53 |
| wgrant | Yes, it needs new modelling. | 22:53 |
| lifeless | ok, so a schema change as well, and a little code to treat NULLs there as the current behaviour. New uploads to set the field, and the sync change to let it be controlled. | 22:53 |
| wgrant | Schema changes are cheap now, but we need to actually think about it. | 22:54 |
| cjwatson | I might just have to keep using sync-source.py -a for a while in P | 22:54 |
| lifeless | cjwatson: doing the schema change is now straight forward | 22:54 |
| cjwatson | which I'd hoped not to do, but isn't the end of the world | 22:54 |
| wgrant | (and because it wasn't done as part of the project, we can't now have a simple, coherent model... we have to hack this together on top of existing crap :D) | 22:54 |
| StevenK | If it's just a JSON field, it requires no schema change. | 22:54 |
| wgrant | StevenK: We can record it in the job. | 22:54 |
| wgrant | But that's all. | 22:54 |
| cjwatson | lifeless: right, but trying to do data remodelling at the same time as an Ubuntu release may be a little beyond my cognitive capacity | 22:54 |
| wgrant | And recording it in the job isn't very useful. | 22:54 |
| StevenK | Hopefully having MOTUs and core devs do their own syncs hasn't been horrible. | 22:57 |
| cjwatson | that's been largely fine | 22:57 |
| wgrant | StevenK: Depends on your definition of horrible... | 22:57 |
| StevenK | Hah | 22:57 |
| wgrant | It seems to be working OK now. | 22:57 |
| cjwatson | some teething trouble but the basic facility is great | 22:57 |
| wgrant | And we even have some form of auditing as of a week ago. | 22:57 |
| cjwatson | can't switch over completely to it until sponsorship is there though | 22:57 |
| * cjwatson gets dragged off by toddler, brb | 22:58 | |
| wgrant | sinzui: No call? | 23:02 |
| jelmer_ | has anybody seen spurious failures in lib/lp/registry/browser/tests/poll-views_0.txt ? | 23:03 |
| wallyworld_ | sinzui: wgrant: unity issues, be on call soon | 23:03 |
| wgrant | jelmer_: I haven't. | 23:03 |
| sinzui | my audio appears to be knackered again | 23:05 |
| wgrant | sinzui: I think we heard you for a moment. | 23:05 |
| StevenK | I did. | 23:05 |
| jelmer_ | wgrant: guess it might be something else, I'll look further | 23:06 |
| === Guest16725 is now known as StevenK | ||
| sinzui | StevenK, 853710 | 23:57 |
| sinzui | StevenK, bug 853710 | 23:57 |
| _mup_ | Bug #853710: Teams that have ever had a PPA cannot be renamed <Launchpad itself:Triaged> < https://launchpad.net/bugs/853710 > | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!