[00:01] haven't quite decided what to do tomorrow, I might do the two-haproxy-units thing, maybe fix tech debt of GitNamespace tests, maybe do the LP side of repository deletion [00:01] let me know if there's anything particular that would be helpful for me to attack [00:02] but for now, sleep [00:02] night [00:02] ok, thanks for the suggestions, night :) === wgrant_ is now known as wgrant [00:08] cjwatson: The old tabbed person +edit was abolished with 3.0. [00:09] cjwatson: I definitely want a single Settings button per object which takes you to a tabbed (or GitHub-like) view with everything under it. We still have something similar on Person:+edit, except the tabs are at the very bottom of the page and not tabs. [00:09] The Settings button the Code page then takes you directly to the code tab, but in the same tab hierarchy. [00:10] wgrant: any way we could carve off a bit of that for git ui - concerned that moving all the settings will be non-trivial. [00:11] blr: Oh, certainly, we're not doing that rework now. [00:11] blr: I don't understand what you mean by "any thoughts on the distinction between project and project code settings" [00:13] wgrant: yeah, I didn't express that very well. I was suggesting that we should have settings for the project and facets under the same view. [00:13] as you say, like github. [00:14] The same *page* is impractical (Product:+edit is several times too long today), but it should be possible to navigate sensibly between the settings pages. [00:14] But we don't have that capability today, so I'd just have the link in the involvement portlet and somewhere on the code page. [00:15] pains me to be adding yet another yellow pencil icon. [00:15] Heh, indeed, but such is life. [00:16] hah yes. Did you like colin's suggestion on infering a default in views? [00:16] inferring the default from is_empty() [00:17] still setting product/distribution.vcs from project setbranch [00:20] Mmm. [00:20] I think that'll do for now. [00:20] It's possibly not ideal long-term, but it's easy to work out which projects are affected, as they all have vcs = NULL, so we can easily fix it. [00:28] yep [03:04] wgrant: any reason why we don't render attached images inline on bugs? [03:05] blr: No particular reason. [03:05] might be nice? [03:05] It needs appropriate resizing stuff etc., and there may be spam concerns, but there's no good reason not to do it eventually. [03:06] will assign to myself to work on at some point. [03:38] wgrant: how can I get the default series for a product? [03:39] is that product.series [03:42] forbidden attr on product.series.branch which seems odd. [03:45] blr: Product.series is the list of all series. [03:46] You probably want Product.development_focus [03:46] (the Distribution equivalent is Distribution.currentseries, which is a bit easier to find) [03:46] ah I see series is a storm result collection [03:46] Yep [03:46] bin/iharness is invaluable here. [03:49] s/ here// [04:14] wgrant: is there a good reason why branch name and owner are at the bottom of setbranch? [04:15] seems they should be at the top, but I may be missing something. [04:16] blr: That's the weirdness I mentioned, yeah. They should be somewhere in the "Import a branch hosted somewhere else" section, as they only apply when a new branch is created. [04:16] right [04:16] It probably makes sense to have them at the top of that section; it certainly makes more sense than where they are now. [04:18] unrelated, but do you like the 0 padding on input elements? [04:18] It's not too bad when they're surrounded by a name at the top and a description underneath. [04:19] oh I mean padding within the elements [04:20] Ah, not particularly. [04:20] It makes the overlarge forms slightly more compact, though :) [04:21] true, but even 1.5px there helps the forms ..err 'breath'? [04:21] should have a look at a large form [04:44] wgrant: unless you have any objections, would like to suggest we use fieldsets in preference to tables for forms. [04:50] widget_row is used all over the place however [05:04] blr: if it's not too much work to get the styling right, by all means === beuno_ is now known as beuno [12:57] wgrant: I still don't properly understand the BPPH.binaryFileUrls failure bdmurray reported. Using BPFP seems weird, but BPFP rows aren't actually deleted when a package is e.g. deathrowed, are they? [12:57] cjwatson: hahah [12:57] cjwatson: BPFP is a view [12:58] wgrant: oh! light dawns [12:58] https://code.launchpad.net/~wgrant/launchpad/i-really-do-hate-views creates a non-DB-backed version of it. [12:58] But it's, uh, sorta out of date. [12:58] little bit. [12:59] I haven't looked at the method recently, but it probably uses it to get an archive-wrapped LFA or something. [12:59] If not, then I have no idea. [12:59] ok, now I at least know how to write a test for this. [12:59] yes, it does. [12:59] so my initial instinct was probably correct, it can just be self.binarypackagerelease.files instead. [12:59] Yeah, as long as you wrap them. [12:59] right, same as before [13:00] Oh. [13:00] It wraps them manually. [13:00] So no reason to use BPFP at all. [13:00] Exactly [13:01] Sorry, misread you above. [13:01] And SPPH.binaryFileUrls is fine too. [13:01] I think it just uses .files because it was there and looked seductively correct. [13:01] Yep [13:02] I'd forgotten that .files used it. [13:02] Rather than just forwarding. [20:40] wgrant: excellent branch name [23:19] wgrant: any docs you could point me towards that clarify how the form processing works (e.g. @action(_('Update'), name='update')) - not clear to me how the data dict is composed. [23:34] nvm, found the zope.formlib docs [23:43] wgrant: I'm curious, whats the current 99th% request time on LP (prod), and requests/day.