[00:12] can you use with_ on a storm select? [00:13] yes [00:13] yup [00:14] hmm... I'm wondering how though [00:15] well, maybe you mean something different than I do [00:15] I suggest starting with my use of it [00:15] lifeless: I have it working on the general store.find [00:15] but now I need a subselect for blueprint exclusion [00:15] I've got the underlying sql tested on staging [00:16] so I know that the syntax I want is allowed [00:16] just trying to get it into storm [00:25] wgrant: you mean stevenk's patch ? [00:25] lifeless: Yes. [00:26] thumper: I'm not sure what you're talking about here [00:26] lifeless: that's ok [00:26] thumper: but I wrote something to gary that /might/ be relevant so I'm going to forward it to you [00:26] ok [00:27] thumper: if it doesn't seem relevant, perhaps you can pastebin me some details about what you're trying to glue together [00:28] lifeless: I'm chatting with jamesh on #storm [00:38] now we're getting somehwere https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1899E29#repeatedstatements [00:46] lifeless: if I have problems, I'll poke you [00:46] thumper: I hope the reformulation of the subselect is useful to you [00:46] lifeless: it is actually [00:47] thumper: it will run faster because it doesn't need to look at specification [00:47] lifeless: yep, got that [00:47] cool [00:48] wgrant: were you going to tackle NBT this week ? wondering if I should ignore oopses on it [00:56] hmm [00:56] need to test [r=lifeless][bug=732481] [bug=732496] oops_middleware should call start_response for success, even if there is no body. [00:57] Isn't that a fix for the haproxy call? [00:57] n [00:57] no [00:57] its a fix for head [00:58] ... which haproxy calls? :-) [00:58] not at the moment [01:07] wgrant: Er, yes it is. [01:08] StevenK: Aren't the DSD scripts not running yet? [01:08] wgrant: DSD.new() calls update(), which calls _updateVersionsAndStatus(), which calls _updateBaseVersion()? [01:09] Ah, well, that is likely true [01:09] lifeless: I will probably get around to deleting it this week. [01:09] I was going to QA that on mawson, after I find a good victum [01:14] anyone know of a place in the code where we do "like" queries with storm? [01:21] thumper: registry.model.distribution.Distribution.searchSourcePackageCaches [01:26] OMG, this vocab was so... broken [01:26] which vocab? [01:26] note that we should not do like queries [01:26] they are slow [01:26] fti or exact matches only [01:28] lifeless: how do I find what text is indexed for blueprints? [01:28] look in database/schema/fti.py [01:28] name, title, summary, whiteboard [01:30] lifeless: how do we do a fti query in storm? [01:30] SQL(...) or use the fti helpers [01:31] lifeless: also, is the fti case insensitive? [01:31] I think it is [01:32] in which case the like queries that were used, were useless [01:32] as they were covered by the fti anyway [01:32] not surprising [01:34] yay lp.blueprints! [01:34] lifeless: in order to say "id not in (...)" we use Not(Table.Column.is_in(...)) ? [01:36] * thumper tries to remember left joins in storm [01:37] thumper: if you're looking at SpecificationDepCandidatesVocabulary, those LIKEs look completely pointless [01:37] mwhudson: yes, I've figured that out [01:37] for at least two reasons :) [01:37] wow [01:38] thought they might be so pointless that the query planner can turn them into = [01:39] thumper: I've not needed to say 'id not in' using storm syntax [01:39] thumper: and tbh, storm syntax vs literal sql is rarely an improvement IMO [01:40] thumper: other than the object deserialisation, I don't find writing the expressions using storm to be generally beneficial [01:40] thumper: I guess I mean: write it in the simplest way possible [01:41] * thumper doesn't need the left joins [01:41] d'uh [01:42] WTF do we have an __iter__ on our IHugeVocabulary? [01:42] that's just stupid [01:42] I know that we "technically" need it [01:42] we have __iter__ on Distribution [01:43] and thats equally bogus [01:43] but having to provide an implementation is fucked up [01:43] lifeless: I agree that __iter__ on any model class is bogus [01:43] it helps accidentally OOM the appservers? [01:43] thumper: we shouldn't have __iter__ on things that we don't expect actual complete iteration of [01:43] thumper: but removing it may be problematic [01:44] thumper: __iter__ on model classes is fine, *if* the model is a container [01:44] * mwhudson remembers a bug to do with materializing a list containing all Persons [01:44] lifeless: the reason we need it there is because IVocabulary defines an __iter__ [01:44] Distribution isn't obviously a container of any one specific thing [01:44] I'm pretty sure we don't use it though [01:44] thumper: yes, I know - IVocabulary is buggy [01:44] * thumper will raise not implemented [01:44] I thought HugeVocabulary existed mostly to avoid having __iter__ :./ [01:44] wgrant: yes, but we didn't fix zopes assumptions [02:32] anyone want to eyeball https://code.launchpad.net/~lifeless/launchpad/bug-711104/+merge/53188 before I land it ? [02:33] what's the magic command to run yui tests? [02:33] * wallyworld_ goes to look on the wiki [02:36] ah, it's manual - load it up in a browser [02:53] :( [02:53] * thumper skips fixing that design problem [03:23] part one: https://code.launchpad.net/~thumper/launchpad/blueprint-dependencies/+merge/53191 [03:23] thumper: Thanks [03:23] np [03:23] * lifeless gambles on lp-land [03:24] lifeless: Re facebook, PICTURES! [03:25] thumper: so my refactored clause was slightly wrong ? [03:25] thumper: ( I don't see why you need specification s there at all [03:25] lifeless: it is needed in the next bit :) [03:26] lifeless: https://code.launchpad.net/~thumper/launchpad/blueprint-dependency-vocabulary/+merge/53192 [03:26] * thumper afk for shopping and kids ice-skating [03:26] back later [03:27] thumper: still don't see it [03:27] lifeless: leave a comment, I'll get back to you [03:27] * thumper needs to go now [03:27] kk [03:27] lifeless: The last few days I've really noticed a speedup on Launchpad. Did you do something significant or am I only just noticing? [03:28] huwshimi: we've brought some more appserver instances online, and moved to an active-passive haproxy config, and we landed a bunch more fixes late last week [03:30] The latency on top of generation time and RTT is normally <100ms now, which is nice. [03:31] lifeless: It's awesome, I'm finding I'm waiting for pages now instead of clicking on links and going elsewhere while they load. [03:31] wgrant: That's great. That was like 2.5 seconds before right? [03:31] I frequently saw it up to 2s, yeah. [03:32] we still have queues [03:32] but its a lot better [03:32] it will be up to 2 weeks before we get the next stage of fixing this done [03:32] lifeless: It's been 5 years. [03:33] 2 weekse isn't that bad. [03:33] I feel like we might actually get there with our speed :) [03:34] lifeless and wgrant beat you with feeling that. [03:34] well [03:34] Eeh, 6 months ago I knew it was hopeless. [03:34] Now I'm not so sure. [03:35] here's a slightly interesting thing: [03:35] wgrant: we're a great team, as long as we give ourselves the space to do things, we can move mountains [03:35] google search results contain the url https://code.launchpad.net/bugs/490148 [03:35] <_mup_> Bug #490148: License details for "Other" are displayed even if not selected

< https://launchpad.net/bugs/490148 > [03:35] hi wgrant, huwshimi, lifeless [03:35] poolie: That's a bit interesting. [03:35] poolie: Hi! Are you back from holidays? [03:36] poolie: Hey mate [03:36] i am back [03:36] it was good [03:36] searching for {launchpad licence field} fwiw [03:37] poolie: hi [03:38] wgrant: Given DSD.base_source_pub() only searches the child for the SPPH, do you think there is value in having it also search the parent? [03:38] StevenK: It should search both archives. [03:38] It will normally only be in the parent. [03:39] Rarely the child. [03:39] Right, so I'll change it to search the parent first, and fall back to the child. [03:39] poolie: That's strange. It appears you can replace that subdomain with others and it still works (although I tried with blueprints.lp and it didn't load the subscribers list). [03:39] As it is today, I thought it was a little naive. [03:40] huwshimi, i would guess that we send a "moved temporarily" from that url to the real location [03:40] poolie: I think they must be indexing on the wrong url. For code.lp it redirects to bugs.lp (blueprints.lp didn't) [03:40] and google therefore caches the orginila [03:40] poolie: Yeah that was my guess [03:40] strange [03:40] huwshimi: most things are published in all domains [03:40] i wonder where they first found a link to that thing [03:40] huwshimi: only a few things aren't (and that results in bug reports) [03:40] perhaps someone made up that url by hand and google decided it was more important [03:41] lifeless: Which makes me think our subdomains are even more redundant :) [03:42] huwshimi: right [03:42] huwshimi: as I said, for me at least, its mainly a technical exercise for removing if/when jml wants us to [03:42] we'd certainly save on redundant ssl handshakes and js overhead [03:45] lifeless: Is this something we should start putting a LEP together for? [03:46] wgrant: Can haz help crafting a query? [03:46] huwshimi: only if we want to do it [03:46] StevenK: I'm not here, but OK. [03:47] lifeless: So do we need to talk to jml about it then? [03:47] huwshimi: I think there are three aspects to it [03:47] wgrant: I'd like to find all SPPHs that are in both Ubuntu and Debian that have changelogs set, 'AND spph.status IN (1, 2)' and have the same SPN. [03:47] 1) Kill them. [03:47] 2) Kill them. [03:47] 3) Kill them. [03:47] there is a political aspect: in the past mark was very pro this layout [03:47] Those are the three aspects. [03:48] StevenK: So you can find good things to test with? [03:48] there is a technical aspect: what exact actions are needed to /permit/ consolidation [03:48] and there is a design aspect: how should things that are currently different in the same relpath on different domains look [03:48] wgrant: Right. [03:49] lastly, there is the scheduling thing: how important is this : when should we do it [03:49] huwshimi: so, last I spoke to jml its not at the top of the roster - and I don't think its a one-man task (but I may be wrong) [03:50] huwshimi: I don't think putting a lot of effort into things that aren't schedule-next priority is sensible [03:50] if the schedulability of it is related to the size of the task, then investing long enough to figure out the size is worth doing [03:51] lifeless: Is this topic on a list of things that need to happen then? [03:52] huwshimi: we practice a LEAN approach of not queuing things up if we can avoid it [03:52] StevenK: SELECT spn.name FROM sourcepackagename spn JOIN sourcepackagerelease sprd ON sprd.name = spn.id JOIN sourcepackagepublishinghistory spphd ON spphd.sourcepackagerelease = sprd.id JOIN sourcepackagerelease spru ON spru.name = spn.id JOIN sourcepackagepublishinghistory spphu ON spphu.spr = spru.id WHERE spru.changelog IS NOT NULL AND sprd.changelog IS NOT NULL AND spphu.status IN (1, 2) AND spphd.status IN (1, 2); [03:53] s/spphu.spr/spphu.sourcepackagerelease/ [03:53] lifeless: OK, as long as we remember to talk about it :) [03:53] And you want to actually constrain the archives too. [03:53] wgrant: *and* I have to run it through sed? :-( [03:53] huwshimi: so no - its not on any list : because we're trying not to have such lists :) - I'm aware of the discussion, and jml /may/ have a list somewhere with it on it [03:53] AND spphu.archive = 1 AND spphd.archive = 3 [03:53] huwshimi: there may well be a bug saying 'this makes things slower' [03:54] huwshimi: (and if there isn't such a bug, such a bug would be reasonable to have) [03:55] ERROR: operator does not exist: name = integer [03:55] LINE 2: ... sourcepackagerelease sprd ON sprd.name = spn.id J... [03:55] grr testfix [03:55] wgrant: ^ [03:55] StevenK: nameID [03:55] StevenK: sourcepackagename, not name. [03:55] or yeah [03:56] I strongly encourage not using reference columns in queries. [03:56] this will help us when we start to detangle the layers [03:56] lifeless: This is SQL. [03:56] oh [03:56] :) [03:57] Failure in test /srv/buildbot/slaves/launchpad/lucid-devel/build/lib/canonical/lazr/tests/../doc/pidfile.txt [03:57] Traceback (most recent call last): [03:57] File "/usr/lib/python2.6/unittest.py", line 279, in run [03:57] testMethod() [03:57] File "/usr/lib/python2.6/doctest.py", line 2152, in runTest [03:57] raise self.failureException(self.format_failure(new.getvalue())) [03:57] AssertionError: Failed doctest test for pidfile.txt [03:57] File "/srv/buildbot/slaves/launchpad/lucid-devel/build/lib/canonical/lazr/tests/../doc/pidfile.txt", line 0 [03:57] wgrant: Ah, right. [03:58] anyone seen that before? [03:58] It could have said "This column doesn't exist, you berk." [03:58] StevenK: did you have 'name' or 'spr.name' ? [03:58] lifeless: I can't find a bug like that. I can report one, but you would be able to write a much better description of the problem if you want to and have the time. [03:59] huwshimi: sure, I can do that [03:59] lifeless: Thanks mate [03:59] lifeless: sprd.name, so it should be sprd.sourcepackagename, as wgrant pointed out. [04:00] StevenK: was wondering about the context the sql parser had [04:01] ... 14,000 rows. I don't believe you, SQL [04:01] huwshimi: its covered in https://bugs.launchpad.net/launchpad/+bug/703134 [04:01] <_mup_> Bug #703134: Launchpads SSL performance is substandard < https://launchpad.net/bugs/703134 > [04:03] I think we should edit the bug number to be 10 or something :-P [04:04] bug 10 ? [04:04] <_mup_> Bug #10: It says "displaying matching bugs 1 to 8 of 8", but there is 9 < https://launchpad.net/bugs/10 > [04:04] hah. 'are' [04:05] in the isf call on thursday we talked about the ssl cache sharing component - its a prerequisite for LVS, and LVS is up second on (IIRC) spads' queue [04:06] How is that a prereq? [04:07] Mm, I guess. [04:07] wgrant: browsers don't switch ip per-request with round-robin setups [04:07] Anyway, /me vanishes. [04:07] so its [relatively] rare to do ssl renegotiates [04:07] lvs would make it a common event unless we did source ip pinning (but you don't want to do that because of the impact of nat'd conferences) [04:22] huwshimi: I like that you've been writing up a bunch of docs [04:25] lifeless: Starting to. It's mostly just stubs and a collection of links to other places... but I have to start somewhere. [04:25] lifeless: I'm trying to add things as I think about them [04:28] huwshimi: one thing I'd like to suggest [04:28] huwshimi: more things to remember makes development harder [04:28] huwshimi: if possible, finding ways to make things automatic would be better than proscribing how things should be [04:28] huwshimi: e.g. if all popup forms automatically set their first entry widget as focus, that would be a no brainer win [04:31] lifeless: Yes, that was exactly my thought [04:31] lifeless: I do want to list the rules for the way things should behave though [04:34] huwshimi: it may be nitpicking, but its probably worth rephrasing from 'rule' to 'sane default which solve problem X' [04:35] huwshimi: this future proofs discussions: if problem X goes away, the default to solve it is clearly not relevant, whereas rules tend to age less gracefully IME [04:36] lifeless: Nitpick away :) [04:37] lifeless: So I want to have documentation with those guidelines about how to solve or how they are already solved within Launchpad [04:37] huwshimi: I basically think we're rule heavy: we /still/ have way to many nonfunctional review rules, and I'm jumping the gun trying to avoid the same problem in a different guise [04:41] sigh [04:41] lifeless: That makes sense, I wonder how we can make sure we have a consistent interface if we don't have a bunch of guidelines that should be followed though. [04:41] 10/33 POFile:+translate [04:42] lifeless: Or am I misunderstanding something [04:42] huwshimi: less code, more reuse [04:42] huwshimi: additionally, i don't think following guidelines results in a high quality interface: I find it extremely weird that consistency is axiomatic with ease of use and high quality [04:43] huwshimi: ease of use is directly measurable as is quality : clarity, performance, uptake of information are all measurable [04:44] huwshimi: time to perform task, time to learn task etc [04:47] huwshimi: as a for-instance on less-code,more-reuse: one of the genius things gnome's desktop stack did years ago was to ditch pixel positioning for widgets: instead it uses packing horizontally and vertically: the /default/ for a developer using the toolkit will be to be consistent with most other gnome apps [04:49] lifeless: What I'm trying to solve is that we don't really have enough docs on what we do or why we do them (for UI stuff). For example, I've been reviewing a form that rvba is working on. He would have know exactly how to create the form without a fair bit of back and forward over the last week if there was a doc he could have looked at that said "when creating a form don't use tables, use classes instead of inline [04:49] styles and here's where to look for appropriate styles". [04:51] huwshimi: so I think this breaks into a few issues [04:51] huwshimi: firstly, we're way to manual in our forms :( - long term issue [04:51] huwshimi: secondly, there isn't really a 'right place' to cargo cult from. [04:52] by which I mean its massively easier to take a good form from elsewhere and adjust than to start from scratch, but there isn't a 'known good' form that is fully ajaxified, uses all the right styles etc etc [04:52] there *are such forms*, but nothing guiding folk to them [04:52] I would have expected bigjools to guide rvba to the right place though [04:53] huwshimi: using classes seems like standard html-since-2005 to me though, rather than something we need to formally write down :) [04:54] lifeless: Actually this is just a small filter form, of which we have a few, but this one had an extra option which none of the others do, so this was a special case that ended up being quite a bit more complex. [04:55] lifeless: except that we do have a lot of inline styles. So when he wanted to know what to do he looked at our existing code and noticed a lot of inline styles and assumed that was ok [04:55] huwshimi: this correlates with what I am saying [04:55] huwshimi: its *easier* to copy existing stuff than to follow procedures about what we *should* do [04:56] huwshimi: so to get new contributions to be as we want them, its most effective to fix our existing stuff [04:56] huwshimi: cheat sheets can still be useful, but I guarantee the first step isn't read-the-cheat-sheet [04:57] lifeless: I totally agree with all that, I just think it is helpful to also have some docs to refer to. Maybe though I need think about having them very general rather than specific cases [04:58] huwshimi: lets say you retain 10% of stuff you read once [04:58] huwshimi: think about how much stuff you read when you started [04:58] huwshimi: and how much of the details you remember now :) [04:58] huwshimi: I'm not saying 'do not write docs' : I started saying I'm glad you are writing docs up [04:59] huwshimi: I am saying: rules that must be followed become a process burden, so we should demand *real value* from any rules we add. [04:59] huwshimi: *and* [05:00] huwshimi: making a few /really good/ forms and offering them up as 'copy this' examples (e.g. via the list, in your docs etc) would be a really good way to help your improvements propogate [05:00] lifeless: Alright that sounds good. [05:01] huwshimi: I've done something similar with my query scaling tests: I took a single example that was in the code base from a while back, generalised and reused it, and wrote it up on the mailing list - other folk are writing such tests now [05:01] huwshimi: and the infrastructure has incrementally improved to make writing them easier. [05:02] huwshimi: I simultaneously tried some rule-based improvements, which have had approximately zero impact on the code base: the communication, examples, and continual focus on the one thing have however had a massive impact. [05:06] lifeless: I guess really most people don't refer to docs unless they get stuck with something. [05:07] lifeless: Or they really don't know where to begin [05:09] Didn't Julian add a boolean that we can use to check if something returned any rows? I can't recall what it is called. [05:16] huwshimi: exactly [05:16] StevenK: its __nonzero__ and only on sqlobjecresultset : don't use it. [05:17] StevenK: storm result sets have .empty() [05:17] StevenK: but note that this is a query: *if* you are going to ask for any rows, just ask, don't check for emptiness [05:22] here stubby stubby stubby [05:23] StevenK: can you run a query on df for me [05:23] Certainly [05:23] I'd like an explain analyze of [05:23] https://bugs.launchpad.net/launchpad/+bug/734642/comments/3 [05:23] <_mup_> Bug #734642: POFile:+translate timeouts < https://launchpad.net/bugs/734642 > [05:23] I'm looking for cold cache performance [05:24] Can't get much colder than DF [05:24] right [05:24] it is about 30 times faster than the current hot performance [05:24] but if its not hotter cold, the win isn't very important [05:25] s/hotter/faster/ [05:26] lifeless: 1345.664 ms, do you want the output? [05:27] please [05:27] I wonder if we just need a tonne of ram [05:27] Let me apologise in advance, I didn't turn off the pager, so it's going to look like crap, and re-running it won't give the same values [05:28] thats fine [05:28] pastebomb away [05:28] http://pastebin.ubuntu.com/580007/ [05:29] thanks [05:29] so, no worse [05:29] but not substantially better [05:31] lifeless: I'd welcome your comments on https://code.launchpad.net/~stevenk/launchpad/dsd-base_source_pub-search-parent/+merge/53194 . Mostly interested in your thoughts re lines 27-51 of the diff [06:00] StevenK: commented [06:00] StevenK: not pubs.empty() would be better than using count() btw [06:01] StevenK: only use count() if you need a count and won't be querying all the rows. [06:07] lifeless: Thanks, I've taken your suggestion with a little tweak. === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews === jtv is now known as jtv-eat === almaisan-away is now known as al-maisan === jtv-eat is now known as jtv [07:36] jtv: you might like the new plan in bug 734642 [07:36] <_mup_> Bug #734642: POFile:+translate timeouts < https://launchpad.net/bugs/734642 > [08:21] stub: Hi Stuart. I've just done my first db changing branch and I'd like you to review it when you get a chance. [08:21] It's been approved by sinzui and the change is really not controversial but since I'm fairly new to the code (joined Canonical 2 weeks ago) please don't hesitate to give me any recommandation. [08:21] https://code.launchpad.net/~rvb/launchpad/db-add-distro-registrant/+merge/53001 [08:21] yup. [08:22] yer - this one looked trivial [08:22] stub: it is yes. [08:22] lifeless: Took me a while to decypher what you pasted there… do you think it's the WITH that does it? Or is it mostly that the "potmsgset <> $INT" check moved from the TM part to the POTMsgSet part? I'm pretty sure we had it in the POTMsgSet part at one point. [08:22] jtv: its the with [08:23] Just acting as an optimization barrier? [08:23] jtv: comment 2 is the first iteration of the with, and when I then move the potmsgset I cap the upper estimate too [08:23] rvba: So people decided to keep both owner and registrant, or will owner be dropped in the future? [08:23] Frankly I don't even see much reason to have the potmsgset <> $INT check… because we query the ones with potmsgset = $INT separately anyway. [08:23] with alone is 350->690 or whatever, with + move potmsgset is 350..350 [08:24] lifeless: are those numbers estimated costs? [08:25] jtv: yeah [08:25] stub: Owner will stay and be the field still used for perm checking (owner = maintainer for distributions). Registrant is just a historical record of who created the object. [08:25] https://code.launchpad.net/~thumper/launchpad/blueprint-dependency-vocabulary/+merge/53192 anyone? [08:25] jtv: actual execution with the with is ~ 30 times faster than the existing query [08:25] That's great. It's too hard to read so I'll just take your word for it. [08:25] jtv: :> [08:25] jtv: with seems to be a very useful thing, was the main point [08:25] So… any takes on implementing it? [08:26] jtv: I figured you'd be interested with your joint rosetta + postgresql interests [08:26] Of course I am! But I'm on feature rotation. :( [08:26] jtv: Its about 15 minutes to code up, I'll do it tomorrow morning if noone beats me to it [08:26] Great, thanks! [08:27] Can I take it the "with" mainly serves as a way to force the planner to materialize that subquery? [08:28] it creates a temporary table [08:28] so yes, in this context I think that that is what its doing [08:30] rvba: Is 'registry' actually a good default registrant of the existing Distributions? We might want to be more selective if it gives any genuine power. [08:30] the registrant is just to make our db work a bit harder rendering the thing [08:32] meep yesterday was busy [08:32] non-opstats pages: 7574479 [08:32] stub: AFAIK the whole idea (sinzui is the one driving this) was to separate clearly who registered the object (and this should not give real power) and who the maintainer is. The only use of the registrant field is to display inside the 'Registered by' slot. [08:32] Sounds fine. [08:33] this might sound silly (and only made to have an extra query) but I think it makes sense because the same thing will have to be done for distroseries. [08:33] Approved. Some things to change listed in the review. [08:35] here is sinzui's opinion on this (for distroseries): [08:35] sinzui "Since distros series do not have a direct owner, it seemed okay in the past to reuse the field for registrant. but owner is intended to be mutable. It is not possible BTW to change a series owner. We removed the field from edit forms" [08:35] It sounds silly if we will only ever have Distributions registered by the registry team (which is silliness we have done for years unfortunately). If random users can register distributions, fine. [08:36] heh, i just tried to use 'y' to archive this channel :P [08:39] I'm not sure it's very frequent for random users to register distributions... but AFAIK the whole thing is to cleanup the owner field for distro, distroseries (and also productseries and productrelease) which has been 'reused' in the past to store other things (sometimes the registrant) than what it should store. [08:44] lifeless: you're right when you say that the current displayed registrant for a distro is the owner. And if we want the changes to be without effect on existing distro we should use the owner instead of ~registry. But I think sinzui's point was that in order to normalise the registrant of objects we should set it to ~registry in the migration script. [08:49] rvba: why normalise it? [08:49] rvba: surely the existing data is more accurate than ~registry [08:50] lifeless: since this is a read-only field I guess it's really not a problem to set the registrant to user instead of ~registry. [08:50] and it might be more informative .... [08:50] lifeless: I think sinzui's argument of cleaning things up really makes sense. But as you can imagine, being still fairly new to the code, I can't say that I have a personal opinion on this. [08:50] lifeless: but I really understand your point [08:51] rvba: setting it to registry would discard what data we have [08:51] I think its wrong. [08:51] lifeless: right [08:51] if we want it to be registry it would be a lot easier to just hardcode that in the templates :) [08:51] lifeless: it wont be registry for newly created objects [08:52] henninge: Hi! Are you good to be OCR today? [08:52] good morning [08:52] rvba: I know, but if we don't want it to be registry for new ones, we don't need it to be registry for old ones :) [08:52] lifeless: again, I really understand your point. [08:52] StevenK: I am. === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews [08:53] henninge: Are you up for reviewing https://code.launchpad.net/~stevenk/launchpad/dsd-base_source_pub-search-parent/+merge/53194 ? [08:53] StevenK: sure ;) [08:54] rvba: where does that leave us? [08:54] lifeless: I'll just make sure with sinzui (he's really the one driving this) that there is no secret reason why he wanted to set the registrant to ~registry :-) [08:54] lifeless: but I think you're right [08:55] lifeless: where's that page that shows the revisions blocking the rollout? [08:55] lifeless: is that ok with you? [08:55] https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html [08:55] rvba: sounds great [08:55] ta [08:55] rvba: I suggest optimistically changing it now to get stubs ack on the update script change [08:56] lifeless: ok [08:56] lifeless: when is the next rollout? [08:56] I'm actually doing it right now. [08:56] thumper: I have one up on LPS [09:00] thumper: but we have no losa until US come on [09:01] StevenK: Sounds to me like there is a "not" missing somewhere in this comment: [09:01] 98 + # Passing in a base version to makeDistroSeriesDifference() creates [09:01] 99 + # it in both distroseries, so we need to do it ourselves. [09:02] henninge: the test is testing the case where one side is missing the base [09:02] henninge: so the statement is correct [09:02] :( [09:03] thumper: I enquired about gsa vg doing it, but they felt uncomfortable [09:03]