[00:56] Trivial review for someone: https://code.launchpad.net/~wgrant/launchpad/prettier-private-build/+merge/84415 [01:05] wgrant: Btw, this fixed my lp-land issues: https://lists.launchpad.net/launchpad-dev/msg07986.html [01:06] A trivial review for someone: https://code.launchpad.net/~huwshimi/launchpad/expired-status-colour/+merge/84417 [01:08] huwshimi: Thanks, approved. [01:08] wgrant: :) [01:08] huwshimi: I'm not a huge fan of the importance colour scheme, but apart from that the new listings are awesome. [01:08] wgrant: Thanks for noticing [01:09] wgrant: Yeah, it's really hard with the status colours being so bright I was trying to find a way to not make the colours fight too much. Any suggestions on how to improve them? [01:10] Not really, no :/ [01:10] The status colours are pretty nice. [01:34] huwshimi: You're on your two bit of QA? [01:34] wgrant: Ah right, thanks I'll do that now [01:34] strange, must have missed those emails [01:34] Thanks. [01:39] wgrant: Done [02:08] lifeless: Could you review https://code.launchpad.net/~wgrant/launchpad/prettier-private-build/+merge/84415? You are the only other reviewer in APAC this week. [02:11] this is very much a self review candidate... [02:12] theres no possible way a review could improve this :) [02:13] Reasonable point. [04:36] A small css/js review for someone: https://code.launchpad.net/~huwshimi/launchpad/order-arrows-894535/+merge/84432 [04:41] huwshimi: What's wrong with the current importance direction? [04:42] eg. if I order by size descending in Nautilus, the arrow points up. [04:42] If I order by importance descending on Launchpad.net, the arrow points up. [04:44] wgrant: Are you sure [04:45] ? [04:46] wgrant: I guess it depends what ascending descending means for the importance [04:47] http://people.canonical.com/~wgrant/launchpad/nautilus-sort.png [04:49] wgrant: Yeah, that's how my branch makes the arrows work in Launchpad. The problem I believe is in how Launchpad interprets how to ascend or descend [04:50] Seems to work that way for id/status/importance at least already. [04:54] wgrant: Something is very wrong then. All the js presentation code that talks about ascending/descending is doing the right thing now, whatever is telling the js what order the items are in must be wrong [04:54] I think [04:54] Heh [04:54] I'm just reviewing now [04:58] wgrant: Hmm... so there's a attribute that's passed to the ordering controls which looks like it might be statically set to "sort_order: 'desc'" which, if not updated might be wrong depending on what these queries default to [04:59] huwshimi: That would be quite amusing. [05:02] wgrant: I might be wrong, but I can't see what else might be doing it [05:03] wgrant: Although there does seem to be a bug which is causing my branch not to work perfectly too [05:03] it defaults to descending for everything, so I guess it could be connected [05:20] wgrant: So I fixed my issue [05:21] wgrant: And it looks like the definition of a few things is off [05:22] wgrant: But I'm very confused as to what [05:27] huwshimi: Howso? [05:27] wgrant: I don't know, I'm confused :) [05:28] Morning Launchpaders [05:28] Heh [05:28] Morning nigelb. [05:29] Sig, yet another Monday. [05:29] *Sigh. [05:32] wgrant: For one I don't know how the arrows point in the correct direction for some ordering when the presentation code says it shouldn't [05:33] wgrant: My guess is it's back to everything default to 'desc' [05:35] wgrant: Oh I see it wasn't actually following the ordering label. The actual direction of the arrow was based on what direction the arrow was pointing previously [05:35] Hah [05:35] wgrant: My branch incidentally fixes [05:35] *fixes that [05:37] (as I determine the direction with ".hasClass") [06:10] Another trivial html review: https://code.launchpad.net/~huwshimi/launchpad/checkbox-label-labels-894209/+merge/84437 [06:12] huwshimi: That's not going to create duplicate IDs? [06:14] wgrant: The same identifier is being used for the checkbox name property. The properties for that have to be unique so I assume it will be fine [06:16] Well, IDs are meant to be document-wide, but I guess it'll do. [06:17] wgrant: I see what you mean [06:17] wgrant: What do we normally do to namespace our forms? [06:18] lol [06:18] wgrant: I see :( [06:19] But if you're unconcerned, then I shall approve. [06:20] wgrant: I'm a little concerned [06:21] wgrant: Both name and id should be namespaced on a form, I kind of assumed that would have already been taken care of, but maybe I need to add something [06:24] wgrant: I don't want to mess with the name as that will have larger ramifications so I might just append "_id" to the ids. I think we do that elsewhere [06:24] I don't think we have currently; we certainly have some forms that have special casing to deal with the form being reused on one page (specifically batching facilities( [06:27] wgrant: OK, I've pushed that change [06:31] huwshimi: Approved, thanks. [06:31] wgrant: :D [06:33] huwshimi: In your arrow branch, the last hunk duplicates the HTML. Is that deliberate? [06:33] wgrant: Erm, let me check [06:35] wgrant: Oh, no that's not deliberate. I had intended to go back and fix that. Actually I didn't know where to store that html. [06:39] wgrant: This is the file: http://bazaar.launchpad.net/~huwshimi/launchpad/order-arrows-894535/view/head:/lib/lp/app/javascript/ordering/ordering.js [06:40] wgrant: And the html needs to be used by the renderUI and _updateSortArrows methods. Any suggestions? [06:41] huwshimi: Store it in a constant like LI_TEMPLATE, maybe? [06:41] I don't know if we have any conventions for this sort of thing. [06:41] wgrant: That would work [06:49] huwshimi: The margin around the icon is also pretty huge here. [06:50] Looks a lot better with margin-left: 3px instead of 5px, and padding: 0 0 0 12px instead of 0 0 0 18px. [06:51] wgrant: I'll fiddle with that a bit [06:51] Ah, the 18px is from the normal sprite styles, I see. [06:52] wgrant: Yeah, I was balancing that out [06:52] wgrant: but I should fix it up a little [07:01] wgrant: OK, just pushed those changes [07:07] huwshimi: That's much better, thanks. [07:07] wgrant: No problems. Thank you! [07:08] Approved. [07:08] wgrant: Cheers [07:11] * huwshimi will be back later [08:44] good morning [08:54] Morning [09:09] Morning development squadrons! [09:09] Morning mrevell! === Guest37602 is now known as jpds [09:15] Everyone, I'd like to introduce frankban, who has joined the Launchpad team at Canonical. [09:17] Hi frankban! [09:17] Is he the new danilos? ;) [09:17] Welcome frankban! [09:18] Hi all! [09:18] nigelb, Kinda [09:18] mrevell: heh [09:28] If we ever add a kanban-style feature to Launchpad, perhaps we should call it frankban's kanban. [09:29] haha [09:30] :-) [09:45] welcome to the team frankban [09:48] bigjools, thanks! [09:50] frankban: Hello! Welcome to Launchpad :) [09:55] wgrant: mawson> is this something I can reasonably ask people to do, or should I be looking to QA germinate changes some other way? [09:55] cjwatson: We could do it this weekend. [09:56] bigjools is probably the person to talk to. [09:56] mawson is the only place [09:56] allenap, good morning and thank you! [09:57] Well, by some other way, I mean perhaps without a DB restore [09:58] I don't know quite how old and crufty mawson is right now; perhaps it's recent enough not to matter [09:58] as long as I can run cron.germinate and have it succeed [09:58] its dump is from just before precise opened [09:58] It's from September 22, with a locally initialised Precise, IIRC. [10:01] Oh, that's not so bad. That would be fine for this testing then. [10:01] I was confused by the last cron.germinate run saying natty. === almaisan-away is now known as al-maisan [10:29] Anyone willing to pick up a near-trivial review? https://code.launchpad.net/~jtv/launchpad/bug-884599/+merge/84400 [10:32] adeuring, I don't suppose I could trouble you for yet another one? === jtv1 is now known as jtv [10:32] jtv: I'll look [10:32] Great, thanks [10:38] jtv: r=me [10:38] thanks adeuring! [10:54] hmm... ec2 test errors I can safely ignore? http://paste.ubuntu.com/760285/ [10:55] huwshimi: That's a new one... but not your fault, clearly [10:55] Ignore. [10:55] wgrant: Thanks. I'm never sure if it's something that means that my branch hasn't been fully tested or something [10:58] huwshimi: It used to mean that sometimes, but it's reliable nowadays. [10:58] The test time and count at the top are a good indication. [10:58] They both increase over time :/ [10:59] wgrant: OK sure, I guess I'm find ignore things that aren't errors the look like they related to my branches then? [10:59] Pretty much. [11:00] wgrant: Great :) [11:00] ec2 list, why are you hanging? [11:03] huwshimi: An instance has probably just terminated and it's trying to ssh into it. [11:03] strace it [11:04] StevenK: Oh, how do I do that? [11:04] huwshimi: 'which strace', first of all [11:05] StevenK: '/usr/bin/strace' [11:05] huwshimi: Okay, run 'strace bin/ec2 list' [11:05] That will produce a *LOT* of output [11:05] It should hang near a connect() line [11:05] That will tell you if it is trying to connect to a downed instance [11:07] StevenK: It doesn't seem to have hung [11:07] huwshimi: It has exit(0) or something similar at the end? [11:08] StevenK: It sporadically adds more output on the end, but not terminating [11:08] huwshimi: Can you pastebin the last screen full? [11:08] Adding a --debug flag to bin/ec2 would be awesome [11:09] StevenK: http://paste.ubuntu.com/760295/ [11:15] huwshimi: That last line is attempting to connect to an ec2 instance on port 80 [11:16] StevenK: Is that normal? [11:17] huwshimi: Yes, that's the magic that ec2 list does in the background. [11:18] huwshimi: However, the magic isn't working since Amazon still lists the instance as terminating (I guess), but ec2 list still wants to talk to it. Wait about ten minutes and try again without the strace. [11:18] StevenK: Sure, thanks :) [11:24] ah, working now [11:42] morning [11:42] Morning rick_h_ === matsubara_ is now known as matsubara [11:51] jelmer: any idea what's going on here? http://launchpadlibrarian.net/85989025/nvervelle-jmol-12.2.log [11:51] all imports fail https://code.launchpad.net/~nvervelle/jmol/12.2 [11:52] bigjools: sourceforge's SVN server isn't very reliable, so it randomly hangs up on us [11:52] hurray [11:52] bigjools: there's an open bug about it, trying to find it.. [11:52] ah ok thanks [11:53] bug 891887 [11:53] <_mup_> Bug #891887: sourceforge imports fail due to connection hangup < https://launchpad.net/bugs/891887 > [11:53] the associated branch reduces the number of revisions we process in each batch, which will hopefully reduce the effect of the hangups [11:56] jelmer: ok thanks [12:03] jelmer: any idea with this one too? https://code.launchpad.net/~vcs-imports/xine-lib/trunk [12:15] bigjools: mercurial imports unfortunately aren't very reliable yet - bug 889530 [12:15] <_mup_> Bug #889530: mercurial imports should be marked 'beta' < https://launchpad.net/bugs/889530 > [12:17] jelmer: thanks agin [12:17] again === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugtasks: 3*10^2 [14:06] gary_poster: Hi Gary. frankban had no questions for me, so I assume either the wiki pages are keeping him busy, or his broadband is down. [14:07] gary_poster: I wondered if you would be up for reviewing a change to LaunchpadSecurityPolicy, following on from Raphael's work last week. I have taken a much different approach to his. Even if you don't have time for a full review, you might be interested in looking at it. https://code.launchpad.net/~allenap/launchpad/delegated-permission-caching-bug-890927/+merge/84473 [14:10] allenap, hi. yeah, wiki pages kept him busy, and he doesn't have accounts & his new dev box shows up at about 1400 UTC. Thank you [14:11] allenap, I'd be happy and interested in reviewing it thanks. I'll start in 5 min [14:15] gary_poster: Thank you! [14:15] of course :-) [14:16] benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/bug-supervisor-labels/+merge/84343 [14:17] sinzui: gladly [14:25] I'm writing test code for my new germinate runner, and (for the time being; fixing this is future work) some of the tests are going to need to have a published archive to work with, at least the dists/ part. Should I just run the PublishFTPMaster script to arrange for this, or is there something a bit more targeted I could be using instead? [14:27] cjwatson: you want published packages in a test? === matsubara is now known as matsubara-lunch [14:28] or is this just for playing around [14:31] rick_h_, ping for standup [14:33] allenap, yay, this is nice. I like IRC reviews, so you can tell mw when I'm wrong more quickly. :-) is that ok with you, and if so, may I start now? [14:36] bigjools: in a test [14:36] I at least need Packages and Sources files; the pool doesn't matter [14:36] But I'd rather generate those by publishing rather than manual test data if possible [14:36] cjwatson: ok, I'd recommend generating some data in the tree [14:37] You mean hand-writing Packages and Sources files? [14:37] it's too slow to publish for unit tests [14:37] ah, OK [14:37] generating :) [14:37] * cjwatson fixes his reading comprehension [14:37] there may be some helpers around [14:38] under lib/lp/archivepublisher/tests/ [14:38] yeah, I was just looking [14:38] otherwise I guess I'll write my own [14:38] I don't see any [14:38] some of the tests generate these files already but it's just single packages IIRC [14:38] gary_poster: Yes, that's fine. I'll put my headphones on though so that I hear pings :) [14:38] allenap, heh ok [14:39] allenap, I'll start with what I expect to require the least discussion and work up from there. [14:39] easy one: authorization.py: "breath-first" -> "breadth-first" [14:39] Hehe, oops. [14:39] :-) [14:39] cjwatson: lib/lp/archivepublisher/tests/apt-data/ contains some static data already, I'd recommend adding to it [14:40] bigjools: How about the getPubSource stuff in lib/lp/soyuz/tests/test_publishing.py? Would that be fast enough? [14:40] allenap, this is a micro-optimization of pre-existing code, but I want us to rip out those two setdefault usages in authorization.py (lines 21 and 25 in diff). The current code makes us always create a weakkey dictionary every time, even if it is thrown away. We can easily make an idiomatic and readable version that performs better, so I suggest we go ahead and do it for such a central piece of code. [14:40] adeuring, you lost sound? [14:41] adeuring, ok, we hear you. [14:41] cjwatson: that just adds to the database [14:41] it is fast-ish [14:41] It has a getIndexStanza which a couple of tests use [14:41] adeuring, we're wrapping up, so no worries. did you have anything else? [14:41] but doesn't write files [14:41] * bigjools looks [14:42] or rather it returns an spph which has that [14:42] gary_poster: Strangely enough, I tried doing that, and got an error that a weakref could not be created in one of the tests I ran. I couldn't figure out why. [14:42] would save actually hand-coding the rfc822 data [14:42] allenap, eek. [14:43] Maybe it's too complicated for this though, I'm not sure [14:43] allenap, I have no idea. I guess I'll back off on it then. [14:43] cjwatson: yes you can use that. In fact it would be quicker to call factory.makeSourcePackagePublishingHistory() although that cuts a lot of corners [14:43] aha [14:43] the Test Publisher does it "right" but it's slower [14:43] That sounds perfect actually; I'll look into that (and corresponding BPPH) [14:44] because it doesn't add librarian files [14:44] rick_h_, ping me when you have a screenshot of that issue. [14:44] does, even [14:44] allenap, in authorization.py, why only leaf-node cacheing? What's the argument? If you keep that, I'd suggest changing the description: I wasn't quite sure what you meant until I read the code. [14:44] deryck: will do, getting back from the reboot. [14:45] bigjools: thanks, that saved me a lot of time [14:45] cjwatson: my pleasure [14:47] when I get round to teaching this to suck pre-apt-ftparchive data straight out of the database, it will probably fit that model better too, since I'd need [SB]PPHs for that as well [14:47] gary_poster: The first reason is that my implementation didn't make it easy to cache the non-leaf results. But I also realised that I was uncomfortable doing it; too broad a result to cache. [14:47] allenap, you should only cache the top, right? [14:47] allenap, I mean in addition to the leaf [14:47] well, no [14:47] gary_poster: I could add that, but it doesn't right now. [14:48] allenap, I don't agree with the discomfort. I'm ok with practically putting it aside for now. [14:48] deryck: http://uploads.mitechie.com/lp/ppa_inline_edit_current.png http://uploads.mitechie.com/lp/ppa_inline_current_second_line.png and http://uploads.mitechie.com/lp/ppa_using_resizing.png [14:49] deryck: so the first shot is the 1em "start" style in effect, and then it gets over ridden on any resize event after that. [14:49] gary_poster: Okay. I am worried that we could end up with cached permissions based on 10s or even 100s of delegated permissions. [14:49] rick_h_, let's jump back to mumble, cool? [14:50] sure [14:52] allenap, it would be trivial to also cache the checked object's permissions [14:52] allenap and that would alleviate your explosion concerns [14:53] (which I don't think are going to happen for us, but understand in theory) [14:53] allenap, and that would mirror the existing behavior [14:53] gary_poster: Do you mean the top-level object, objecttoauthorize? [14:53] allenap, yes [14:53] gary_poster: Okay, I can do that. [14:54] cool allenap [14:54] thx [14:57] allenap, you write "# XXX: GavinPanella 2011-12-03 bug=???: Surely for delegated checks...". I don't think this is pertinent. The security machinery calls into this code, after already having done a lot of this stuff--especially zope.Public, for instance. Can you elaborate on your concern? [15:00] gary_poster: When checking delegated permissions, should we not check if it's requesting zope.Public? That's a silly example... I'm more worried about the block of code that calls LSP.checkPrivacy(). Should we do that for each delegated check? [15:02] jelmer: http://launchpadlibrarian.net/86683207/vcs-imports-xine-lib-trunk.log is a known bug that, iirc, you're working on, right? [15:03] allenap, mm, ok. I want to dig into this. So, I'm familiar with the zope.Public check so I'll start there. Your thought there is "what if checkAccountAuthenticated returns (something, zope.Public)?" right? [15:03] gary_poster: Yes. [15:03] I see [15:03] That seems like a daft thing to do, but it might happen. [15:04] yeah, that one seems daft; I won't worry about it too much. I'm more interested in LSP.checkPrivacy. I'm not sure how that works, and that seems like it might be more serious. Lemme take a look (unless you already know the details and can get me up to speed quickly here or on a call) [15:04] allenap ^^ [15:05] allenap: hi [15:05] allenap: yeah, the hg imports aren't very reliable yet [15:05] gary_poster: No, I don't know the details; I have skimmed the code and it looks serious :) [15:06] jelmer: Okay. I'm answering https://answers.launchpad.net/launchpad/+question/178945. Shall I just say that, or is there a bug I can point him to? [15:06] allenap, ok :-) I'll look and report back [15:07] gary_poster: Thank you :) [15:07] allenap: I'd suggest just saying that, I don't think linking a particular bug is useful [15:07] jelmer: Okay, cool. Thank you! [15:08] allenap: I beat you to it I think [15:08] bigjools: Ah ha :) [15:09] allenap: I shall leave you to it and finish my branch :) [15:15] benji, gary_poster: have you seen bug 899388? [15:15] <_mup_> Bug #899388: Some translation statistics are not up to date < https://launchpad.net/bugs/899388 > [15:17] flacoste: I have ("Reported by Benji York on 2011-12-02") ;) [15:17] Hm, there may be a dupe there [15:18] benji: yeah, just saw that :-) [15:18] sorry for the noise [15:18] i got confused by the email [15:18] flacoste: no worries [15:18] i thought it was reported by a user, but it was only follow-ups comments [15:19] yep; I'm really confused by the behavior and don't think it's related to the recent changes in the way statistics are updated (but I could be wrong) [15:19] oh...so this is different from the "jobs are not working" bug benji? [15:20] which you closed [15:20] right [15:20] gary_poster: yep; I believe the job is working (because statistics are being updated) but the bug is that the statistics aren't right [15:20] Oh, I see :-( [15:21] that's inconvenient! [15:21] the only changes we (intended) to make were to change the timing of the calculations, not the calculations themselves, so we shouldn't have introduced any new behavior [15:21] indeed [15:22] benji, so the user comments indicate that the workaround you describe is insufficient? [15:23] gary_poster: yep, and it indicates that the statistics are indeed being updated (presumably by the cron job) [15:23] benji, I see [15:24] benji, if you want pairing from somebody, ask [15:24] gary_poster: will do === salgado is now known as salgado-lunch [15:37] sinzui: https://code.launchpad.net/~sinzui/launchpad/bug-supervisor-labels/+merge/84343 looks good [15:37] thank you benji [15:38] my pleasure === al-maisan is now known as almaisan-away [15:59] allenap, I had other stuff to quickly review but now I am back. I'll look more at that LSP.checkPrivacy stuff later today but I want to make sure to bring up the other questions I had for you while we still overlap. I have three more things, only one of which probably requires much discussion. [15:59] 1) isinstance(result, Iterable) does not strike me as a good pattern for checking [15:59] oh wait, that was the one we had to talk about :-P [16:00] gary_poster: ? [16:00] So try that again: 1) lib/lp/app/interfaces/security.py: In docstrings, please specify that all delegated results must be True in order for it to be considered True. [16:01] allenap ^^ [16:01] Okay. [16:01] allenap, 2) Am I correct that there are no tests for this change? Is that because there are no tests for this generally? [16:04] I see the tests for the new behavior in the authorization [16:10] gary_poster: There are no tests for the new caching behaviour. All the existing tests pass unmodified, but I ought to test for caching of delegated auths. Fwiw, a follow-on branch from this does check (indirectly) that delegated auths are cached, so they're working. [16:14] allenap, I was going to be concerned about isinstance(.., Iterable) but I see it is an ABC, so nm. :-) [16:14] (and I see it experientially works for what I would want it to in the common case) [16:14] gary_poster: Yeah. It's not great from a micro-optimization standpoint, but it'll do for now :) [16:14] yeah, cool [16:15] benji: hi - can I bother you with a review please? [16:16] bigjools: absolutely [16:16] allenap, ok cool. So, this is conditionally approved with the comments I've given, and with some reading I intend to do today on checkPrivacy. I'll plan to approve this today, probably after your EoD [16:16] benji: it's https://code.launchpad.net/~julian-edwards/launchpad/sponsor-syncs-bug-827555/+merge/84287 [16:16] thanks [16:16] gary_poster: Woohoo \o/ thank you :) [16:17] allenap, btw, I really like your approach. Thanks for pulling this along to the finish line in such a nice way. [16:18] gary_poster: Thanks, I appreciate that. === mtaylor_ is now known as mtaylor [16:33] bigjools: I added a comment to https://code.launchpad.net/~julian-edwards/launchpad/sponsor-syncs-bug-827555/+merge/84287 that I couldn't phrase well for IRC, but you might want to discuss it here [16:34] benji: my docstring is correct [16:34] in other words, I misunderstand? [16:34] the sponsored person overrides the requesting user [16:35] benji: yes, but must not have been clear enough for that to happen [16:35] oh! you're considering the requesting use as the sponsor [16:35] with an "I" in there somewhere [16:35] yep [16:35] gotcha, yeah, if you add a statement to that fact, I think it'll clear it up [16:36] righto === salgado-lunch is now known as salgado [16:59] morning [17:01] flacoste, ping. Do you have time to talk about users, team, interfaces, and security? [17:02] sinzui: sure [17:02] skype me [17:06] benji: thanks for the approval [17:06] bigjools: my pleasure === deryck is now known as deryck[lunch] [17:12] allenap: sinzui is da god of series, but AIUI downloads show 'newest' full stop, and latest series is done by a built in sort. Probably need to check the code to be sure. [17:15] lifeless: Ta, I'll take a look. Looks like you got woken early :) [17:16] apparently ;) [17:22] allenap, lifeless the downloads page is a mess. we show the released for current development series at the top or the page (current development series is pulled out of naming sequence and shown first). Backport releases are show with their respective series series, but may fall off the page because of batching. [17:22] sinzui: https://answers.launchpad.net/launchpad/+question/180693 [17:23] allenap, lifeless downloads exists to let packagers see the latest releases, but 7 people muddled the page to serve users and developers, which make it impossible to do the right thing [17:23] thumper: can you please list the queues on production ? [17:24] bah [17:24] ECHANNEL [17:24] ahh the downloads portlet [17:25] allenap, lifeless :that too is very ignorant of reality and we have too community of equal weight in contention. Let me find the bugs for that mess [17:27] sinzui: I have to go now to collect kids, but I'll be back later. Are you happy to answer that question in the meantime, or would you prefer me to do it later? [17:27] allenap, bug 419733 and bug 669668 describe the fact that Lp really guess at what to show and users fight over what is the correct behaviour. I report the latter bug as a suggestion from UDS...which mightg addess the issue [17:27] <_mup_> Bug #419733: new Downloads portlet should show latest stable release as well as latest

< https://launchpad.net/bugs/419733 > [17:27] <_mup_> Bug #669668: permit projects to specify the series that current release are made from < https://launchpad.net/bugs/669668 > [17:28] \o/ instant OOPSes on production. [17:29] * lifeless dances the happy dance of a plan coming together [17:30] Awesome! [17:35] sinzui: you free to mumble? i'm trying to figure out what needs tackling the most on our board. [17:35] okay [17:39] allenap, I answered the question [18:04] jcsackett, I think I am mistaken about the pre-req bugs. There are several bugs about editing project/distro information inline, but none about the roles. I suspect the bug was rewritten to solve one use case. I think you should report bugs are you need to make pillar roles editable in the page via ajax [18:06] G'night all [18:09] statik: I have a CT scan on thursday thats going to play havoc with the day; we're booked for that morning for catchup- can we reschedule ? [18:09] benji: could you please review https://code.launchpad.net/~abentley/launchpad/remove-hot-bugs/+merge/84503 ? === deryck[lunch] is now known as deryck [18:19] abentley: I was eating lunch; looking now [18:19] benji: thanks. [18:28] abentley: https://code.launchpad.net/~abentley/launchpad/remove-hot-bugs/+merge/84503 looks good, I had one idea for simplyfying a template, but that's it [18:32] lifeless: sure, rescheduling is fine with me, my calendar is pretty accurate for open slots [18:32] benji: cool, thanks for the suggestion. [18:32] abentley: my pleasure [18:36] statik: how about later today after I catch up with flacoste? [18:36] flacoste: also, we can call anytime, I am awake and around :) [18:37] lifeless: i'll have to postpone a bit, i hurt my back yesterday and have an appointment for it in 1h [18:37] flacoste: ow! [18:37] flacoste: ping me anytime [18:41] statik: how about now then ? === matsubara is now known as matsubara-afk [19:02] hmm, no gary [19:27] allenap: this is the thing I was looking at previously - https://code.launchpad.net/~lifeless/storm/bug-618019/+merge/34715 [19:27] allenap: (centering around whether we ever pay network / db server latency for result set rows) [19:50] lifeless: I'm doing some reviews and noticed that https://code.launchpad.net/~mbp/launchpad/show-timeline/+merge/80166 looks like it wants a comment from you before I review it [19:56] lifeless: I'm assuming that message wasn't really for me? [20:06] So.. in working on the juju charm distro .. I'd like to open up a new series and copy all the contents of the old one into the new one.. [20:06] I was hoping this would do that [20:06] https://launchpad.net/charm/precise/+initseries [20:06] But apparently thats some of the ubuntu-only magic. [20:06] thumper: it wasn't [20:07] I'll write up an email but wondering if anybody can shed some light on how this is supposed to work? [20:07] thumper: failed tabcomplete for thedac who isn't lurking here [20:07] SpamapS: make a new series, and probably run the branch-new-distro script should do it fo ryou [20:08] lifeless: in what package/bzr tree/multiverse does branch-new-distro reside? [20:08] lp source I think [20:08]