[00:32] * mwhudson lunches [01:12] poolie: Is it really that odd to support only OpenID? Most Canonical web services exclusively use Ubuntu SSO. [01:12] There's little point have a webapp-specific username and password. [01:12] i meant among other web apps generally [01:13] mwhudson: do you know anything about ampoule? [01:13] they seem to at least present the impression of letting you enter the username/password directly [01:13] through a web page or over a machine interface [01:13] even if in the backend it's going to a generalized db [01:13] don't you think so? [01:14] Right -- but what's the point? [01:15] Er, wait, are you talking about webapps in general, or Canonical webapps? [01:15] generally [01:15] Ah. [01:16] Well, what benefit does this provide? [01:17] In this case there is a default OpenID provider that makes a little bit of sense but not really, so it makes sense in the minds of people who want to associate Launchpad even further with Ubuntu to delegate all authentication to that. [01:17] Hopefully LP will soon be able to auth against any provider, which might make it less completely unacceptable to most distro-agnostic upstreams. [01:17] Forcing upstream projects through an Ubuntu-branded page is *not* going to make people happy. [01:18] But I think dropping the internal authentication is a good move. [01:18] (phone) [01:18] i think it's useful to be able to do "curl https://user:pass@launchpad.net/something" [01:21] I haven't had to do that in ages, thanks to the API. [01:22] or similarly for the api [01:22] which is where we started [01:30] The only supported auth mechanism for API requests is OAuth. The workflow for getting an OAuth token can be easily streamlined. [01:30] * thumper stabby [01:30] :( [01:39] thumper: only in general terms [01:39] mwhudson: I'm stuck and would like help [01:39] thumper: ok [01:39] thumper: skype? [01:39] please [01:40] oh right, it's not running... [01:45] lp:~thumper/launchpad/all-code-review-email-using-jobs === bjf is now known as bjf-afk [01:51] In general, how bad of an idea is it to count the number of rows in SRP? [01:51] * NCommander is working on the importer now that I have some time [02:02] My postgresql is rusty, how do you select columns where an integer column is unset (but not null, the parser doesn't seem to like '') [02:02] bah,nm [02:03] NCommander: unset *is* NULL [02:03] NCommander: '' is not NULL [02:04] NCommander: SRP? You mean SPR? [02:07] wgrant: er, yeah [02:07] lifeless: yeah, I had a bad flashback to mysql, and forgot that postgresql doesn't suffer that much braindamage [02:08] NCommander: Why do you want to? [02:08] wgrant: to give a total and an overall progress (this is probably going to take days run), but I also found count(*) does a sequential scan thus, may not be the best to run on such a large table :-) [02:09] Possibly. Hard to say. [02:09] Just do it, I think. If it becomes a problem, it can be fixed. [02:09] Premature optimisation, and all that. [02:12] wgrant: fair enough, I'm thinking I can't do this as one giant transaction, but break it into batches [02:14] NCommander: stub would come and strangle you if you did it in one transaction. [02:15] wgrant: yes, well :-), I dunno how much ot run in a batch [02:16] There is DBLoopTuner, but I don't think that handles committing for you. [02:16] 21:15:08 < NCommander> wgrant: yes, well :-), I dunno how much ot run in a batch [02:16] 21:15:42 < wgrant> There is DBLoopTuner, but I don't think that handles committing for you. [02:16] argh [02:16] wgrant: what's DBLoopTuner [02:16] It handles batching and automatically tunes the batch size to meet a target time. [02:17] Not sure how applicable it would be to this case, though. [02:20] wgrant: ah [02:21] mwhudson: skype fail [02:23] thumper: wifi fail [02:29] http://pastebin.ubuntu.com/406280/ [02:31] anyone know how to debug postgres deadlocks? [02:33] using pg_locks and all that [02:54] mwhudson: I've done so in the past [02:54] mwhudson: still need help ? [02:54] lifeless: nah, we found it [02:54] ta though [03:25] Stupid question, but is there a good example on how to retrieve a file via librarian? [03:27] * NCommander is trying to figure out how to sanely download all the bits of a source package giving a SPR record [03:30] NCommander: via the api or ... ? [03:32] mwhudson: I'm writing a script to handle migration for raw_source_changelog but my inexperience with LP's internal APIs are making it difficult, i.e., how to get a file from librarian, or getting all the bits of a source package, etc. [03:37] NCommander: getting a file from the librarian is quite easy [03:37] NCommander: it's just librarianfilealias.open() [03:37] source packages i'm less sure of [03:38] mwhudson: well, I already have a function that spits out all the id numbers and filenames of the source package :-) [03:39] mwhudson: I'm not sure I can determine that given a specific LFA though if its in the restricted librarian or in the primary one [03:39] NCommander: i think lfa.open() dtrt [03:40] dtrt? [03:44] NCommander: does the right thing [03:44] mwhudson: ahhhhhh [04:21] * thumper afk for urgent shopping for dinner [04:26] NCommander: LFA.restricted should tell you whether it's restricted. [04:26] wgrant: can I just lfa.open() or do I have to do something special if its restricted? [04:26] NCommander: LFA.open() should work fine. [04:27] wgrant: perfect! [04:30] is hackberry the staging db or the real one? [04:32] poolie: it's a slave not one of the masters [04:32] but a slave of the production db? [04:32] iow scripts running there see up-to-date data? [04:32] poolie: looks like a slave of production, yeah [04:39] thanks [04:40] poolie: https://devpad.canonical.com/~spm/launchpad-sec-levels.png hackberry is a slave; is < 5 minutes behind in replication or I get sms'd. [04:41] nice [04:44] hrm. dated too. missing soybean for 1. [04:44] bleh. and pear. === Ursinha is now known as Ursinha-afk [06:34] * thumper back later to finish submitting proposals [07:27] henninge: Morning. [07:27] Hi wgrant! ;) [07:28] henninge: With https://code.edge.launchpad.net/~wgrant/launchpad/get-translations-jobs-working, translation template jobs work completely. [07:28] Just needed a few tweaks in untestable code. [07:28] wgrant: Great to hear! [07:28] let me look at it [07:28] Is there a PPA with basic Python 2.4 for Lucid? Lost 2.4 during the upgrade. [07:29] stub: You should be able to drag it in from Karmic [07:29] henninge: It has a few prereqs, one of which been rejected, so it will have to wait for the data model rework. [07:29] stub: Why would you want 2.4? [07:29] Because I build pytz for Python 2.3+ [07:30] Ah. [07:30] henninge: But it was encouraging to see that it actually pretty much works. [07:30] And doesn't break the UI any more. [07:31] (and also gave me a crash course in Rosetta, which I'd not used before!) [07:31] wgrant: yes, that is an important step forward. [07:31] ;-) [07:31] welcome! [07:33] henninge: What's going to happen during an update when new POs are scraped from the branch and uploaded before the new POT finishes building? [07:34] wgrant: POs without a template will not be imported until the template has been imported. [07:34] henninge: Things aren't going to break strangely if POs with new strings are uploaded before the POT with those strings, though? [07:39] wgrant: let me look at this but I think not [07:39] good morning [07:51] Hallo. [07:51] wgrant: yes, all messages are stored in the database, even those that don't have a matching template entry (yet). [07:51] henninge: Ah, great. [07:51] wgrant: they are marked as obsolete. [07:51] but will be un-obsolleted once the template comes in. [07:51] noodles775: moin! [07:52] Hi henninge [07:52] henninge: Just thought it might be a bit of a new situation, since existing bzr imports are synchronous. [07:53] wgrant: well, we have always had manual uploads and they would come in any order the uploader chooses .... ;) [07:54] henninge: True. [08:43] * wgrant looks for a reviewer for the RC candidate https://code.edge.launchpad.net/~wgrant/launchpad/bug-540819-fix-builder-list-icons/+merge/22288 [08:53] * thumper EODs [09:02] Morning [09:08] * wgrant ponders removing ViewByLoggedInUser (the default IAuthorization adapter) and seeing what breaks. [09:09] It is dangerous. [09:10] g'day [09:10] Morning bigjools. [09:11] what's broken today? [09:12] SPRB permissions are bogus. [09:12] But not an actual problem yet, of course. [09:47] gary_poster, [09:47] good morning [09:50] wgrant, there's a default adapter? I think I knew that. [09:50] wgrant, I'm surprised the default is something like that though. [09:51] jml: Yes :( [09:51] It is perhaps the most silly default possible. [09:51] Except perhaps for allowing unauthenticated users and forbidding authenticated ones. [09:59] bigjools: Thanks. I've filed a bug and added it to the XXX. [10:00] ta [10:18] wgrant: mind if I mark bug 549340 as invalid? [10:18] Bug #549340: BuildQueue.destroySelf erroneously assumes that all jobs are Storm objects [10:18] bigjools: Go ahead. [10:19] wgrant: thanks [10:20] Although I still believe that it's an interface violation, we'll see what happens once the model changes are shaken out. [10:21] yep [10:25] stub: dogfood has got a load of pg backends running that we can't cancel (mainly connecting to sso_main and launchpad_auth), what's the best thing to do? [10:28] bounce postgres probably. [10:28] pg_ctlcluster -force 8.3 main restart [10:29] Need a losa I guess [10:30] actually, that'd need a GSA, losas don't have perms on dogfood (because we don't manage it) [10:33] stub: also, lazr.config.interfaces.ConfigErrors: ConfigErrors: database does not have a main_slave key. [10:33] database does not have a main_master key. [10:33] wtf? [10:33] bigjools: Perhaps you should request access as the postgres user? You can escalate your privs if you try hard anyway so it doesn't make much sense from a security point of view. [10:33] yeah sounds sane [10:33] well - I can do some stuff as postgres already [10:34] bigjools: It changed to rw_main_master I believe for read only mode stuff. [10:34] stub: does this mean we need a database refresh or what? [10:34] Its a config file change. I don't think you need to rebuild your database for that. [10:35] thought we'd changed that, hmm [10:38] yes we had, it got reverted [10:45] stub: there was a bin/run knocking around for some reason, killing that removed all the backends [11:03] Morning, all. [11:10] deryck: gosh, if you're online it must be time to go to bed [11:11] mwhudson, heh. yup. I have some more western lying Europeans that serve as that marker for me. :-) [11:31] soyuz: Are you aware of a failure in buildd-slave.txt ? About 20 minutes ago I also saw it break with a "Connection reset by peer" instead of "Connection refused", but I can't seem to replicate that now. [11:32] It's started failing spuriously in various ways lately :( [11:34] wgrant: Ah, well, at least you know, and it's not something I've broken for you. [12:51] bigjools: I don't think it's GPL-safe to remove sources that are still referenced by binaries. [12:52] As for the stay of execution... I'm not sure of the purpose of that, unless it's to leave old indices working for a while. [12:58] GPL2 is rather handwavy about it, but GPL3 is much more specific. [12:58] wgrant: I wasn't suggesting to do that [12:58] I'm talking about getting rid of "stay of execution" [12:59] It is handy if you don't want to apt-get update every publishing cycle. [12:59] I don't think we remove sources referenced by binaries right now do we? [13:00] wgrant: how does it make any difference to apt-get? [13:00] the index changes, that's what apt-cares about [13:00] s/-/ / [13:01] bigjools: We deindex them, but they are not removed from disk. [13:01] yes, and how does that affect apt-get if we remove them from disk at the same time? [13:02] bigjools: If I have a machine that updates its indices once a day (the default) and a package gets superseded some time between updates, I will get a 404 and installations and upgrades will fail. That is ugly. [13:03] I'd say that is desirable behaviour [13:03] your index is out of date [13:03] We have that behaviour for deletions, when removal is obviously desired. [13:05] But 404s look bad. And they will happen in released versions. To lots of users. [13:06] The behaviour is different (the stay of execution is set at 24 hours) for PPAs; maybe the PPA spec has some rationale? [13:07] hmmm [13:07] oh fuck sake, email crash, I hate that [13:08] wgrant: I guess we have to suck it up then, updating indices hours before downloading the files is crack IMO but there you go :/ [13:09] bigjools: Indices are huge. [13:09] unfortunately so [13:13] Ideally we'd have something like (or better than) pdiffs: publishing could take less than a second rather than a couple of minutes, and updating before downloading would be easy. [13:14] But pdiffs just sucks [13:14] StevenK: what's better? [13:15] pdiffs suck, yes. [13:15] It would be much better to just allow additional files which provide additional entries. [13:15] Much quicker to generate, and probably to apply too. [13:15] bigjools: When you have a large delta, just redownloading the file. If the delta is small, rsync? [13:16] But that is hard to determine, and most of the smarts are on the client and it means the server must provide rsync, so that sucks more. [13:16] I'd rather we didn't provide pdiffs, they annoy me. [13:16] it would be nice to shake this all up a bit [13:17] * jml shuts down email [13:22] bigjools: What's going to happen with the apt-ftparchive test failures? [13:22] We are getting close to Lucid. [13:22] hello, how often is there synchronization between different translation templates of a project? So how long does it take that a change is visible in another template? [13:22] wgrant: we either get them fixed, or block the lucid upgrade in the DC [13:22] I prefer the former of course :) [13:23] bigjools: Or we could accept them as better behaviour, of course... [13:23] my dns is down [13:24] wgrant: fixing can include that definition, yes [13:24] True. [13:24] is there a bug filed? [13:25] I need to get it scheduled for the next cycle so we don't miss it [13:25] Bug #526826 [13:25] Bug #526826: test_ftparchive failing on Lucid

[13:25] fanks [13:25] Although it's also affecting soyuz-upload.txt now that I've reenabled it. [13:26] bleh [13:26] * jml does the modprobe dance, maybe that'll help. [13:26] it does. [13:29] bigjools, I'm going to get back on that poppy stuff now [13:29] \o/ [13:29] people will send you chocolate [13:30] As in SFTP poppy? [13:30] wgrant, yeah. [13:30] wgrant, although this is more "get the juicy non-codehosting ssh bits out of codehosting so I can think straight about sftp poppy" [13:30] jml: Ah. [13:30] jml: did you see https://dev.launchpad.net/LEP/GeneralBuildHistories ? Later, when you want a break from poppy, can you take a look? [13:31] noodles775, no, I didn't. [13:31] noodles775, I'll check it out later. [13:32] jml: yeah, do some coding for a change :D [13:35] I wonder when I'll be able to land the zope.testing change. [13:46] wgrant: /w 5 [13:46] woops [13:48] I really need to configure my shell to make a noise when long-running commands complete [13:48] I wonder if that's at all possible [13:50] jml: Some terminal emulators have a "wait for silence" option. [13:50] GNOME has probably removed it, though. [13:50] Maybe I'm think of Konsole. [13:51] Konsole has "monitor for silence" [13:51] it also has "monitor for activity" [13:51] Yeah, that's the one. [13:51] isn't KDE cool :) [13:51] terminator doesn't :) [13:55] Is it just me, or does make take an awful long time these days? [13:56] it's not just you [13:56] see all the junk it keeps doing over and over for each branch, when it could do it once in a common area [13:56] With all this mailman building and WADL generation and apidoc compilation and JS combination. [13:57] Some of which is done on every single build; not just in the 5-minute initial tree build. [13:58] and that [13:59] It feels like all the JS stuff is what's got slower recently [13:59] Maybe we should have a test which asserts on "make; time make" :-) [14:00] See, I just ran 'time make' in devel. [14:00] It spends a few seconds bootstrapping for no good reason. [14:00] Then rebuilds mailma. [14:00] The jsbuild/jssize/combine-css take a while. [14:00] But it seems that rebuilds only take around 45 seconds. [14:00] Ah, no apidoc in that run. [14:01] 45s for a rebuild with no changes? [14:01] the make target dependencies suck donkey balls [14:02] jml: That was with a cold cache. 20s with it hot. [14:02] wgrant, that's still quite a long time spent achieving nothing. [14:02] Yes. [14:03] Now let's see if I can get it to trigger an apidoc build... [14:03] Hm, maybe it does only do that on clean builds. [14:04] yes the dependency is set up right for that [14:05] fixing the make stuff wouldn't be too hard, I bet. [14:05] I mean, the full on right thing to do is make a list of standard bits of a developer's cycle and optimise the crap out of all of them [14:06] but just getting 'make' to do less for the 90% case and then putting some strongly-worded documentation to stop it from creeping again wouldn't be that hard. [14:08] * jml accidentally pissed some time away apt-get upgrading when apt-get install python-apt was all that was necessary [14:09] jml: + [a lot] [14:09] can you make it happen? [14:10] bigjools, I'm not going to make the change myself, most likely. [14:11] jml: well that's not quite what I meant :) [14:11] bigjools, and I've already been trying really really hard to let everyone know that I want them to stop what they are doing and make development faster [14:12] bigjools, but maybe I'm trying in the wrong way, or something. [14:12] jml: Bonus points if you convince people to make Launchpad faster, too. [14:12] real 4m38.942s [14:12] Awesome. That is a great way to encourage branching. [14:12] wgrant, yeah, that's a separate problem that I'm tackling. [14:13] wgrant, or rather, gary_poster's team are already making LP faster. [14:13] jml: at our upcoming Epic, I want us to schedule time to make development better. Stuff like this. [14:13] jml: I made the mistake of using Github for a while earlier today. [14:13] and I think you expressed that is a good idea in the past [14:14] it is so fast, and the code browser is part of the application and doesn't time out constantly. [14:14] bigjools, I think that would be a good idea. but I don't really see why we need to wait until July. [14:17] jml: we don't, but there's nothing like a concerted group effort to effect real change [14:18] bigjools, as long as it's organized to be _doing_ and not talking. [14:19] bigjools, I also advocated that we have someone work full time on making development faster. The build engineer role hasn't been as successful as I hoped. [14:19] bigjools: should bug 551579 be moved to launchpad-buildd or to soyuz? [14:20] Bug #551579: Unable to build a PPA package with locked down permissions [14:20] kfogel: let me lookl [14:20] jml: yes - I think our time is being squeezed too much between different things [14:20] kfogel: It's a bug in the package. [14:20] But otherwise launchpad-buildd. [14:20] bigjools, the list of developer bugs hasn't really moved much https://bugs.edge.launchpad.net/launchpad-foundations/+bugs?field.tag=build-infrastructure [14:21] wgrant: oh! (but thanks, that info is helpful for next time) [14:21] (it's the same bug that is being discussed in #launchpad at the moment) [14:21] s/bug/thing/ [14:21] wgrant: actually, it should still be moved to launchpad-buildd then (though I'll wait for bigjools to come back) [14:21] kfogel, wgrant: hmmm [14:21] so basically it wants to be run as root [14:22] I don't like that [14:22] bigjools: while I care somewhat about the big picture, I care mainly about getting it out of the "Launchpad Itself" queue (I'm CHR today) :-). [14:22] I think it's a package bug [14:22] No, it's a bug in the package that it breaks fakeroot. [14:22] me too [14:22] kfogel: it's invalid [14:24] bigjools: *nod* Want me to mark it as such, and quote this IRC conversation for why? [14:24] kfogel: yep [14:24] thanks [14:25] bigjools, how does "too many different things" apply to the build engineer role? [14:26] jml: I suspect that role has not been given the attention it deserves [14:27] bigjools, yeah, I'd agree with that. [14:29] jml: what I mean is, the pressure to get the team work done has probably usurped it [14:31] bigjools, ahh, I see. Do you have any ideas as to what we can do about that? [14:31] jml: schedule less work? :) [14:32] bigjools, you mean, like we did already? [14:32] I don;t see that personally [14:32] bigjools, well, I don't know what scheduling less would look like in that case [14:32] we went from each team having a list of 10+ things to do for 3.0 [14:33] to having less than ten things in total [14:33] jml: well I'm still guessing here - it would be better to talk to the build engineers [14:35] ricotz: did you get an answer to your question? [14:35] bigjools, that's certainly a good thing to do :) [14:35] * henninge is too lazy to read all the backscroll ... ;-) [14:36] * jml goes off to perform the "is toast food" experiment [14:36] I am highly confident of a successful result. [14:36] jml: anyway in soyuz world we get a lot of emergencies [14:36] hence my feeling of lots of work still [14:37] fail. cleaner is still occupying all the kitchen === Ursinha-afk is now known as Ursinha [15:01] henninge, not yet [15:02] ricotz: there is no synchronization between templates within a series, if you are referring to that. [15:02] ricotz: templates of the same *name* in different series of a project will share translations. [15:02] And that instantly, no snychroniation time. [15:03] ricotz: can you point me to where it is you are expecting the synchronisation to happen? [15:05] henninge, ok, i see it now they are in sync, but the colors arent right [15:05] https://translations.edge.launchpad.net/docky/trunk/+pots/docky [15:05] https://translations.edge.launchpad.net/docky/2.0/+pots/docky [15:06] henninge, hm, they are not in sync ;-), have a look at Icelandic [15:07] * henninge looks [15:09] ricotz: how different (or similar) are the templates, though? [15:09] ricotz: oh, are you just looking at the numbers on the overview page? [15:10] ricotz: they may be outdated. [15:10] henninge, i am relying on the graphics [15:10] * ricotz brb [15:15] henninge, all strings which are included in series 2.0 are also in series trunk [15:33] * jml makes another attempt at toast === pgquiles__ is now known as pgquiles_ === pgquiles_ is now known as pgquiles [16:03] ricotz: comparing the Icelandic files gives this: http://paste.ubuntu.com/406575/ [16:04] ricotz: only additions in the trunk file, just like in the template. So the files are in sync. [16:04] ricotz: looks like the PO file statistics are still messed up, sorry about that. [16:05] ricotz: we have the daily script disabled because of performance issues. The weekly script should fix them, hopefully. === deryck is now known as deryck[lunch] === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch === deryck[lunch] is now known as deryck === matsubara is now known as matsubara-lunch [17:11] adeuring: in my branch's Makefile, it still says "PYTHON_VERSION=2.5", but of course Lucid has 2.6. What's the "clean" way to update that (i.e., I assume editing it directly and having a local mod is not how this is done?) [17:11] adeuring: https://dev.launchpad.net/Running/Lucid doesn't seem to address this point [17:11] kfogel: I haven't yet upgraded. [17:12] last week I was sprinting, and now we are quite closed to the rollout ;) [17:12] so, no idea... [17:12] adeuring: np [17:12] barry: have you upgraded to lucid? If so, please see my above question to adeuring :-). [17:13] Oh, maybe answer is (re)install Launchpad PPA. [17:20] wgrant: ping === beuno-lunch is now known as beuno [17:53] gary_poster: are you developing on Lucid? I've run into a small prob. [17:53] kfogel: I have various attempts half-made, which effectively means "no". It's conceivable I can still help. What's up. [17:54] gary_poster: my /etc/apt/sources.list has "deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu lucid main", and I have done 'sudo aptitude update'. Nevertheless, 'sudo aptitude install launchpad-dependencies' just says "no such package". Yet https://dev.launchpad.net/Running/Lucid implies this is the way I should get Python 2.5 back on my system (Lucid has 2.6) so I can develop Launchpad. [17:57] kfogel: I don't think chromium has anything to do with it. Try [17:57] deb http://ppa.launchpad.net/launchpad/ppa/ubuntu lucid main [17:57] deb-src http://ppa.launchpad.net/launchpad/ppa/ubuntu lucid main [17:57] gary_poster: hmm, that may be the wrong ppa [17:58] gary_poster: thanks, yeah, just got there at the same time I think. [17:58] :-) === salgado-lunch is now known as salgado === matsubara-lunch is now known as matsubara [18:08] man I've written some abysmal code in my time [18:11] jml: so, uh, what prompted you to say that? :-) [18:11] kfogel, lib/lp/codehosting/sshserver/accesslog.py [18:11] jml: (though I'll bet I can win that contest: http://red-bean.com/cvs2cl/cvs2cl.pl) [18:11] * kfogel looks [18:11] kfogel, that URL says basically everything I need to know. [18:12] jml: wow, that's a lot of classes [18:12] :-) [18:12] oh right, you are looking at the "old" version [18:12] jml: (responding to accesslog.py, not cvs2cl.pl, about which your comment is very sensible) [18:12] mostly I'm looking at LoggingManager, since I've put all of the other classes in a box [18:14] jml: hunh. weird that setUp() isn't __init__(); and something similar with tearDown(). Or is that your point? [18:15] kfogel, not specifically, since both setUp and tearDown mutate global state and I hate it when objects do that on construction [18:15] jml: ah, gotcha [18:16] Hmmm: "ImportError: No module named tickcount" looks like lp may still have some lucid issues [18:16] kfogel, it's getting stuff from config that should be parametrized, it mixes up codehosting bits and generic logging bits, the oops stuff in there is pointless, the mangle_stdout parameter is unused and unnecessary [18:16] the docstring is wrong [18:17] a thing that's core to what the class does is a top-level function elsewhere in the module [18:18] and I still don't really know what the code is doing (even though I kind of do because I wrote it) [18:18] deryck: if you go to https://bugs.edge.launchpad.net/launchpad right now, it says: "There are currently no hot bugs filed against Launchpad itself." While that's true, it's true because there are no bugs at all. What has heat got to do with it? [18:19] kfogel, actually, it is true, thank you very much. :-) [18:19] incoming [18:19] https://bugs.edge.launchpad.net/launchpad/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&f [18:19] ield.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search [18:19] well, that didn't work. [18:20] kfogel, all the other bugs are closed. See: http://tinyurl.com/y8jc8rs [18:20] deryck: ah. IOW, going to that page now no longer shows a list of "recently filed" bugs or whatever. It shows hot bugs, and if there are no bugs with heat, it shows none. [18:21] deryck: s/recently filed/open and recently filed/ [18:21] hmmm, actually.... [18:21]