[00:01] lifeless: It's actually much easier than that. [00:02] Use self.request.stepstogo.consume() [00:05] wgrant: mumble? [00:06] sinzui: I'm there. [00:06] ... but in the wrong room. [00:06] I think my audio is buggered again. I will leave and return [00:06] I can hear you. [00:28] lifeless: QuestionMessage doesn't have indices in the DB. [00:29] wgrant: well then. [00:29] wgrant: it needs them or spam marking is racy [00:33] wgrant: any idea why the df app server wasn't running? [00:34] jtv: None. [00:34] Oh well, I started it. [00:34] Well, unless "bigjools" is an idea. [00:34] Also, it's 9:30am here, you should not be here. [00:35] jetlag [00:38] 'zcly [00:38] Plus, my UPS can't sleep. [00:41] lifeless: Try to assign/unassign a private bug on qastaging. [00:41] wgrant: why? [00:42] lifeless: Because it crashes for me. [00:42] what bug were you trying on [00:43] 1234 [00:43] Indirect subscribers found on private bug. A private bug should never have implicit subscribers! [00:43] Yes. [00:44] Can you change status/importance? [00:44] win [00:44] They OOPS for me without a traceback. [00:44] But it's possibly just a timeout. [00:44] OOPS-1955QASTAGING103 [00:44] ID:OOPS-1955QASTAGING104 [00:44] Yeah, been waiting for a sync for a while :( [00:44] 3 seconds, not a timeout [00:44] Thanks. [00:44] uhm [00:45] is ~launchpad in malone-alpha [00:45] no [00:45] But I am. [00:46] so i'm getting this with the 'normal' notification stuff [00:46] On qas. [00:46] yes [00:46] It works fine on dev. [00:46] I wonder if a custom filter has to exist. [00:48] I also wonder if it's related to the fix for bug creation subscribers. [00:48] If I can find it... [00:49] No. [00:50] now, is indirect 'via a team' or 'via a pillock' ? [00:50] Pillar. [00:50] Not team. [00:50] fuuu [00:50] ECONFUSINGTERMINOLOGY [00:50] lazr.restful suppresses the traceback. [00:50] Let's use non-AJAX... [00:50] theres a bug on that [00:50] OOPS-1955QASTAGING107 [00:51] Module lp.bugs.subscribers.bug, line 151, in add_bug_change_notifications [00:51] level=BugNotificationLevel.METADATA) [00:51] Module lp.bugs.model.bug, line 1050, in getBugNotificationRecipients [00:51] "Indirect subscribers found on private bug. " [00:51] AssertionError: Indirect subscribers found on private bug. A private bug should never have implicit subscribers!
[00:51] Not too helpful. [00:51] But it's something. [00:51] Surely not. [00:51] This would have been broken for weeks. [00:52] I envy you; you're getting to code. [00:52] You're not? [00:53] I'm architecting at the moment [00:53] https://dev.launchpad.net/ArchitectureGuide/Services [00:53] which is harder than you might think [00:53] Ah, yes. [01:02] * wgrant comes dangerously close to deleting bug heat. [01:02] \o/ [01:02] which reminds me [01:03] to do an analyse of bug heat top-20 or whatever with and without decay [01:03] I'm totally convinced that in successful projects the sort order is identical [01:03] but ENEEDSDATA [01:17] Project windmill-devel build #56: STILL FAILING in 1 hr 15 min: https://lpci.wedontsleep.org/job/windmill-devel/56/ [01:31] StevenK, perhaps you would care to review a small fix for automatic index creation in publish-ftpmaster? https://code.launchpad.net/~jtv/launchpad/bug-780214/+merge/60444 [01:36] Project db-devel build #531: FAILURE in 5 hr 20 min: https://lpci.wedontsleep.org/job/db-devel/531/ [01:40] Or wgrant maybe? Need a small fix reviewed. [01:47] No antipodeans in the review market today? [01:48] * wgrant returns. [01:49] jtv: What creates that normally? [01:50] wgrant: I don't even know tbh [01:50] Also, why always PRIMARY, never PARTNER? [01:51] generateConfigForPocket does this. [01:51] As long as it's given some components. [01:51] I presume this failed on DF? [01:51] There are no separate PARTNER runs for this, as far as this script is concerned, so it uses PRIMARY as the place to keep track. [01:51] Project windmill-db-devel build #255: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/255/ [01:51] Yes. [01:52] Do you still have the traceback? [01:52] I can make one. Hang on. [01:54] wgrant: http://librarian.dogfood.launchpad.net/71105515/hyYRRP1nMvTD9b3OKTaVtUZy789.txt [01:54] jtv: querulous hasn't been initialised, has it? [01:54] Nope [01:54] It has no components. [01:54] There's a bug for that. [01:55] But why are you writing out indices before initialisation? [01:56] Skipping a few steps in testing, I guess. [01:57] So this won't be the case in production? [01:57] what triggers the index generation? [01:57] publish-ftpmaster. [01:57] That's what runs it. [01:57] In what case does it run? [01:59] wgrant: little accident with chat window here... index generation is triggered by publish-ftpmaster being run on the distro and seeing that one or more suites in a frozen series do not have indexes yet. [01:59] jtv: Hmm, that's too early. [01:59] It needs to wait until it's been populated. [02:00] Bug #675042 covers the bug that you've fixed here, but it reveals that it's being run too early. [02:00] <_mup_> Bug #675042: Release file generation fails for series without components

< https://launchpad.net/bugs/675042 > [02:00] tsekci times [02:00] Pardon? [02:00] just being silly [02:01] a riff on other interpretations of 'populated' [02:01] wgrant: you are taking into account that publish-ftpmaster will not be running around the time a new series is created? [02:02] jtv: Hm, why not? [02:02] He's good at that. [02:03] 11:02:06 < wgrant> jtv: Hm, why not? [02:04] We currently stop the publisher so the manual index generation can be run. [02:05] If we're doing the manual index generation automatically, there's not much point stopping the publisher. [02:06] My understanding is that stopping the various cron jobs was still needed for other reasons as well. [02:07] That sounds like a temporary situation that we don't want to add more reasons to. [02:07] * wgrant invokes StevenK. [02:12] wgrant: when we get close to the point where the cron jobs no longer need to be disabled, we'll also have a better view of what else is needed to manage the various jobs that need to be done. [02:13] wgrant: Oh? [02:13] StevenK: Why do we still have the publisher off during initialisation? [02:14] I hadn't done any work on it -- but we don't want to publish a half-initialised series [02:14] jtv: Regardless, this fix should probably be in ftparchive.py. And it's almost tempting to keep the crasher to indicate that something has gone wrong. [02:14] StevenK: Sure, but that's probably better handled by IDS signaling that it's finished and enabling publication of the series. [02:15] Agreed [02:16] How do you enable publication of a series? I thought that was per-distro. [02:16] Perfect may be the enemy of good and all that, but perfect is not difficult here, and making it easier to silently do things wrong is also the enemy of good. [02:17] jtv: Indeed, but that doesn't make much sense. [02:17] What is "that" in this case? [02:18] jtv: DistroSeries needs an "initialised" flag or so. At the moment we have series like p-series sitting around and only not being published because they have nothing to publish. [02:18] The publisher should only consider initialised series. [02:18] And that solves this problem. [02:18] This is separate from the "initialised" flag on DSP, I take it. [02:18] I don't think that flag should exist. [02:19] But perhaps it should. [02:19] That's actually a recurring problem here, I think. [02:19] Oh? [02:19] A proliferation of status flags for what is really a process flow. [02:19] That's why I think it should be a DBEnum [02:19] The larger problem is that it is apparent nobody has though about how this is all going to work. [02:19] s/though/thought/ [02:19] Exactly. [02:20] thinking is overrated [02:20] * lifeless goes back to thinking [02:20] I don't think it belongs on IDistroSeries, but only because it's enormous. [02:20] I have thought about fixing DS.status. [02:20] It is possible taht we could reuse that. [02:21] We need to think how it will interact with Debian. [02:21] But it seems reasonable. [02:21] StevenK: I don't think thats a good reason not to do it [02:22] StevenK: thats a good reason to make it smaller, but if you hold of on genuine improvements because its not [yet] small, you hamstring yourself. [02:22] StevenK: you could say 'we won't make it bigger' and go yak shaving to make it smaller to let you put this field in and keep it hte same size [02:22] jtv: I am really worried that there is no design for any of this. [02:22] jtv: It's just a set of cards. [02:22] jtv: With people working it out as they go. [02:22] but that seems like saying 'making the class smaller is more important than making this part of the process reliable' - which I wouldn't agree with. [02:23] wgrant: same here, but I'm not a big fan of chucking in an enum right away either. [02:23] jtv: Sure, we should actually talk about this. [02:23] With Julian and stuff. [02:23] Yes. [02:23] I think we're sort of racing past an underlying problem, [02:23] Rather than just piling more hacks onto the pile of hacks that is already a significantly larger pile than before DDs. [02:23] which is that we don't have a clear map of the dependencies between actions. [02:24] We have the current Ubuntu process, which is a serialization of actions--out of some set of possible ones. [02:24] Riht. [02:25] So I'm thinking: the first thing we ought to do is figure out what the dependencies are. [02:25] Which is hard, and involves goat sacrifice. [02:25] That sounds dangerously close to planning ahead of time... [02:25] Or some other way of seeing into the nether realm of soyuz. [02:26] Planning what ahead of what time? [02:26] A feature. [02:26] Or development thereof. [02:27] ? [02:28] I'm saying we should understand what it is that we're already doing. That doesn't strike me as premature feature development planning. [02:28] jtv: wgrant is showing his bitterness again. [02:28] He's too young to be bitter. [02:28] (For a non-Windows user, that is) [02:28] It was a derogatory implication that much of this work lately has been quickly patching over immediate problems without considering the underlying problems. [02:30] Some post-release updates need to go to -updates? Hardcode -updates when datereleased is set! We need to create distroseries indices after a series has been initialised? We turn the publisher off during initialisation because we haven't quite fixed that yet, so we can just assume the publisher will be off! [02:30] etc. [02:30] The feature was initially planned well, but the issues that have cropped up during development have had no planning at all. [02:30] And this is how Soyuz got as bad as it is now. [02:31] I think these are two separate issues though. [02:31] The new requirements were thrown into the design in a hurry. Very bad. [02:32] But what we were discussing is old design, and there a few hackish small steps may actually bring us to a better ultimate situation. [02:33] But there has been no consideration of the ultimate solution before implementing the hackish small steps. [02:33] So we don't know if we're going in the right direction. [02:33] Or if we're going the direction soyuz did for its first three or so years. [02:34] Part of the problem is that we don't know what the ultimate initialisation procedure for a new series will look like. [02:34] (which was possibly not unreasonable, due to time constraints, but that's not the case here) [02:34] jtv: We need to sit down and work that out, I guess. [02:35] But I suspect trying to design that up front may lead us to decisions that turn out to be wrong at a later stage. In which case it's more effective to let a pattern emerge first, and then design for the pattern. [02:36] What is in question? [02:37] wgrant: this isn't how soyuz got to its current state [02:37] lifeless: Oh? [02:38] Parts of it are very clear layers of hacks. [02:38] yes [02:38] Much moreso than the rest of LP. [02:40] wgrant: there was a lot of BDUF done early on [02:40] wgrant: and it was wrong and never corrected [02:40] Sure. [02:40] I'm not asking for BDUF on that scale. [02:40] I am asking for a minimal amount of design. [02:40] wgrant: I'm arguing that that is the root cause of many of the hacks [02:40] Not 5-year speculative design like Soyuz. [02:40] Hmm. [02:41] Partly, yes. [02:41] But not entirely. [02:41] now, subsequent work hasn't fixed the root issues, and has yes papered over stuff [02:42] I'm all for aiming for a good design and root cause fixes [02:42] I don't think you're wrong to argue that some more analysis is needed [02:42] I think its false to say that incremental development got us here [02:42] what got us here was overly focused designs that didn't address the root causes which /made/ the basic facilities hard to reuse. [02:43] for instance, picking something arbitrary we publish archives in two different ways for no good reason [02:44] That's because Celso got cold feet about NMAF. [02:44] No. [02:44] PPAs need to be done, NMAF wasn't fast or complete enough for primary. [02:44] Completion never happened. [02:44] Nothing about getting cold feet. [02:45] Ah. And since it worked fine for PPAs, it was good enough. [02:45] or we could have used apt-ftp for ppas [with different tradeoffs] [02:45] It turns out it didn't work fine, but the minor additional fixes were made. [02:45] But yes. [02:45] but the choice to bring in a different stack was done with sprints and design; the underlying issue wasn't, and hasn't been addressed. [02:46] lifeless: For big stuff like that, yes, incremental development is not at fault. But there are so many special-cases and other gross hacks throughout Soyuz which are labelled as temporary hacks that will be discussed at $nextsprint, dated 2005 or 2006. [02:47] wgrant: I think that shallower stuff is due to the overall 'we don't get to finish things' issue. [02:47] wgrant: I give you e.g. blueprints [02:47] :) [02:47] lifeless: And we still don't get to finish things. [02:47] Even with feature squads. [02:47] thats interesting [02:47] I thought we were doing a lot better [02:48] We set a deadline for feature completion weeks beforehand. [02:48] Then the last couple of weeks are very conservative. [02:48] I think you should raise this on one of the two lp dev lists [02:48] Feature completion is not based on completion of the feature. [02:50] we have a glass display case for well, glasses [02:50] it has a bottom draw thats wood [02:50] so the glass starts about 25/30cm from the floor [02:51] our newest kitten tries to jump into the cabinet [02:51] so there is this patter patter patter ... THUMP [02:51] Ahaha. [02:51] as he propels himself up that 30cm gap aiming at where he can see stuff... and whacks into the glass front [02:51] Smaaart. [02:52] Wait, newest kitten? You have acquired multiple now? [02:52] we have 2 (the desired number) now [02:52] And then shakes himself off and goes to lay in the sun? [02:52] Sun in NZ? lol. [02:52] Oh. Right. [02:52] s/sun/slightly warmer bit/ [02:52] sun, no. chases the other cat, then tries again a bit later [02:53] (although it was around 0 here this morning, so I guess I can't really talk) [02:53] It was 10 degrees when I went to bed [02:53] That's cold enough [02:54] Yay, bug heat timeouts on production now. [02:55] OOPS-1956BA33 [02:56] * StevenK waits the 30 seconds that OpenID seems to take [02:57] Sigh, searching for oops makes me sigh [02:59] wgrant: some prolonged disconnectivity there... What is in question? Well currently, how we trigger and track the various steps in setting up a new series. [03:01] jtv: Right, but why can this not be determined now? [03:03] I'm on thin ice there, but perhaps because so many things are shifting: we're generalizing beyond Ubuntu, IFP is becoming a job, we're introducing multiple parent relationships. [03:04] Right. [03:04] And the LEP basically only specifies +localpackagediffs UI. [03:05] You'll hear no argument from me there... [03:05] Oh! [03:05] ? [03:05] Someone agrees that the design is insufficient :) [03:06] I've been saying that for quite a while now I think. You may not have heard all of it because it was on team calls. [03:07] I have seen nothing other than a continuous stream of branches that reveal woefully inadequate design. [03:07] I am glad that there has been some discussion or at least realisation that this is the case :() [03:07] But again, I see different considerations for the design we inherited and the one we're trying to implement. [03:07] *:) [03:08] I don't think anyone particularly disagrees that we have a hurried design and it's not exactly a work of fine art. But what we _do_ about it is another kettle of fish altogether. [03:10] * wgrant sighs and lunches. [03:22] 3 rollbacks in 24 hours :( [03:23] new record? [03:23] I think so, yes. [03:23] We've had two a couple of times. But not three. [03:30] silver lining - is new record in our QA process to ensure that quality code lands on the LP prod branch. We're not afraid to rollback bad versions on discovery! [03:32] Heh [04:04] waheeee [04:04] 548 KeyError: 56589 [04:08] that's expressing just plain disdain for humans [04:08] lifeless: That's the send-bug-notifications crap. [04:08] You might have noticed there were tens of thousands of them yesterday. [04:09] It is happy now. [04:14] kk [04:14] thanks [04:16] is wallyworld doing uds? [04:20] lifeless: The first couple of days, I think. [04:21] Ian Booth [04:21] 2011-05-09 till 2011-05-10 [04:21] thanks [04:21] jtv: Hi. [04:22] https://answers.launchpad.net/launchpad/+questions?field.search_text=&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status=NEEDSINFO&field.status-empty-marker=1 has four questions assigned to Launchpad Translations Administrators/Coordinators. Who is meant to handle that sort of thing now? [04:23] aren't we all rosetta admins now? [04:23] Yes [04:23] hi wgrant... my life is so nice and interruption-free now that I'm no longer notified of messages [04:23] Some of these are policy. [04:23] Heh. [04:24] * jtv looks [04:25] By the way, Launchpad Translations Coordinators are a very different team. They run our reference translation group. [04:26] Of the ones for rosetta admins, one is in Needs Information. [04:27] Another actually should have been un-assigned. [04:30] jtv: Right, I know they're a different group, which is why I was asking about them :) [04:30] Because I doubt they watch LP questions. [04:31] Good point. [04:34] I need a proof reader [04:34] Someone that will read a doc and make a list of wtf moments to give to me [04:40] wgrant: tag, you're it ^, if you have time. [04:41] I'm not going to get any useful code done today, so I might as well. [04:41] * wgrant looks. [04:44] wgrant: you were right by the way--IFP fixed my directories problem. [04:45] jtv: Great. [04:45] jtv: Are bug #55211 and bug #777941 deployable? [04:45] <_mup_> Bug #55211: shouldn't require careful publisher run when cloning new released distrorelease

< https://launchpad.net/bugs/55211 > [04:45] <_mup_> Bug #777941: Create distroseries indexes from regular publisher run

< https://launchpad.net/bugs/777941 > [04:45] wgrant: yes, because we're not using that script yet anyway. [04:46] That's what I thought. Thanks. [04:46] Also, I just got it working on df. :) [04:46] Excellent! [04:48] Now to fake those marker files for O. [04:49] Or rather, figure out whether we need to. [04:50] Well, what's it going to do? A no-op index publication when we set it to frozen? [04:51] Project windmill-devel build #57: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/57/ [05:11] wgrant: I was told that doing a publish-distro -A on the suites at such a later stage would be harmful. [05:13] StevenK: where is IDerivedDistro as mentioned in bug 643369? [05:13] <_mup_> Bug #643369: IDistroSeries.deriveDistroSeries() should use the security adapter

< https://launchpad.net/bugs/643369 > [05:13] jtv: I don't believe that to be the case. [05:13] It's not ideal. [05:14] But it shouldn't break anything. [05:14] Undesirable, but not harmful beyond possibly wasting a few minutes. [05:14] * jtv suffers a mild gust of despair from hearing these contradictory requirements [05:15] It's safe to run publish-distro -A on a series (and suites) that has already been published? [05:15] Yes. It will do bad things if it's released, but frozen is not release. [05:15] +d [05:16] All it does it forces the pockets to be dirty. [05:21] wgrant: that doesn't sound so bad, for a one-off migration issue [05:21] Hmmm this looks useful: http://justinhalpern.tumblr.com/post/5135237870/office-e-mail-translator [05:24] jtv: I hoped it would be something to de-Outlook HTML. [05:25] Alas. [05:25] wgrant: I'll ignore the marker files issue then, but leave it on the table for a double-check with jools. [05:26] jtv: Sounds good. [05:26] Meanwhile, trying to make sense of bug 643369, which is marked as a high priority. What is this IDerivedDistro it speaks of, and why should Ubuntu not count as one once it's marked as derived from Debian? [05:26] <_mup_> Bug #643369: IDistroSeries.deriveDistroSeries() should use the security adapter

< https://launchpad.net/bugs/643369 > [05:26] jtv: Because 2005, that's why. [05:27] Ah yes, 2005, the explanation for everything. :) [05:28] wgrant: still, what would determine whether a distro is an IDerivedDistro? [05:28] I think the owner is a more sensible check, but using IDerivedDistro is stupid and wrong. [05:28] IDerivedDistro itself is stupid and wrong. [05:29] In its current definition, at least. [05:29] I believe it's currently != ubuntu. [05:29] Which is obviously crap. [05:29] So... debian would be an IDerivedDistro!? [05:29] Yes. [05:29] When it is in reality the only non-derived distro. [05:29] if self.name == 'ubuntu': [05:29] alsoProvides(self, IBaseDistribution) [05:29] else: [05:29] alsoProvides(self, IDerivativeDistribution) [05:30] IDerivedDistro is effectively "Any distro which isn't Ubuntu" [05:30] (From Distribution._init) [05:30] jtv: I think that bug is hard to fix, too [05:31] Ah, "Derivative." That's why I got no hits for "Derived." [05:31] Ah, IDerivativeDistribution is, in its current form, used for Ubuntu-specific permissions. [05:31] So you might want to rename it to IHaveBadlyDefinedUbuntuDrivers. [05:32] Heh [05:33] Maybe I shouldn't be working on this bug then, especially since it doesn't say why the change is needed. [05:34] It's certainly not pressing. [05:34] It's marked as a high priority. [05:34] Unlike all other pending tasks. [05:34] It's needed because currently you need to be a member of soyuz-team or an admin to derive a series. You should be a driver or owner of the destination d [05:35] Oh, that [05:35] *distribution (since the series may not exist) [05:35] That's much clearer, thanks. [05:59] StevenK, wgrant: how weird to have deriveDistroSeries on DistroSeries... I would have expected it to be on the derivative distribution. [05:59] Project windmill-devel build #58: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/58/ [06:00] jtv: The DistroSeries you call it from is the one you're deriving from? [06:00] Yes. [06:00] But ISTM you only need read permissions on that. The derivative distro is what you're appending to. [06:00] Yes ... [06:02] And then it checks if the derived series you want to create may already exist, and if it does, initialize it. [06:02] jtv: Completly seperate. [06:03] jtv: We use the object were calling deriveDistroSeries() on as the parent series -- so it doesn't need to be fed into the argument list. [06:03] And deriveDistroSeries() is happy enough to create the series if it can't find it. [06:04] Frightening. [06:04] * StevenK goes back to fixing tests [06:05] ISTM this wants to be a method on the parent Distribution plus a method on the derived DistroSeries, rather than a single method on the parent DistroSeries. [06:06] What?! You're making no sense, and I'm getting cross. [06:14] wgrant: ping [06:28] wallyworld: Hi. [06:29] jtv: Possibly, but it may be sensible to do them in one operation sometimes. [06:29]