[00:01] <cjwatson> 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] <cjwatson> let me know if there's anything particular that would be helpful for me to attack
[00:02] <cjwatson> but for now, sleep
[00:02] <cjwatson> night
[00:02] <blr> ok, thanks for the suggestions, night :)
[00:08] <wgrant> cjwatson: The old tabbed person +edit was abolished with 3.0.
[00:09] <wgrant> 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] <wgrant> The Settings button the Code page then takes you directly to the code tab, but in the same tab hierarchy.
[00:10] <blr> 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] <wgrant> blr: Oh, certainly, we're not doing that rework now.
[00:11] <wgrant> blr: I don't understand what you mean by "any thoughts on the distinction between project and project code settings"
[00:13] <blr> 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] <blr> as you say, like github.
[00:14] <wgrant> 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] <wgrant> 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] <blr> pains me to be adding yet another yellow pencil icon.
[00:15] <wgrant> Heh, indeed, but such is life.
[00:16] <blr> hah yes. Did you like colin's suggestion on infering a default in views?
[00:16] <blr> inferring the default from is_empty()
[00:17] <blr> still setting product/distribution.vcs from project setbranch
[00:20] <wgrant> Mmm.
[00:20] <wgrant> I think that'll do for now.
[00:20] <wgrant> 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] <blr> yep
[03:04] <blr> wgrant: any reason why we don't render attached images inline on bugs?
[03:05] <wgrant> blr: No particular reason.
[03:05] <blr> might be nice?
[03:05] <wgrant> 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] <blr> will assign to myself to work on at some point.
[03:38] <blr> wgrant: how can I get the default series for a product?
[03:39] <blr> is that product.series
[03:42] <blr> forbidden attr on product.series.branch which seems odd.
[03:45] <wgrant> blr: Product.series is the list of all series.
[03:46] <wgrant> You probably want Product.development_focus
[03:46] <wgrant> (the Distribution equivalent is Distribution.currentseries, which is a bit easier to find)
[03:46] <blr> ah I see series is a storm result collection
[03:46] <wgrant> Yep
[03:46] <wgrant> bin/iharness is invaluable here.
[03:49] <StevenK> s/ here//
[04:14] <blr> wgrant: is there a good reason why branch name and owner are at the bottom of setbranch?
[04:15] <blr> seems they should be at the top, but I may be missing something.
[04:16] <wgrant> 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] <blr> right
[04:16] <wgrant> 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] <blr> unrelated, but do you like the 0 padding on input elements?
[04:18] <wgrant> It's not too bad when they're surrounded by a name at the top and a description underneath.
[04:19] <blr> oh I mean padding within the elements
[04:20] <wgrant> Ah, not particularly.
[04:20] <wgrant> It makes the overlarge forms slightly more compact, though :)
[04:21] <blr> true, but even 1.5px there helps the forms ..err 'breath'?
[04:21] <blr> should have a look at a large form
[04:44] <blr> wgrant: unless you have any objections, would like to suggest we use fieldsets in preference to tables for forms.
[04:50] <blr> widget_row is used all over the place however
[05:04] <wgrant> blr: if it's not too much work to get the styling right, by all means
[12:57] <cjwatson> 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] <wgrant> cjwatson: hahah
[12:57] <wgrant> cjwatson: BPFP is a view
[12:58] <cjwatson> wgrant: oh!  light dawns
[12:58] <wgrant> https://code.launchpad.net/~wgrant/launchpad/i-really-do-hate-views creates a non-DB-backed version of it.
[12:58] <wgrant> But it's, uh, sorta out of date.
[12:58] <cjwatson> little bit.
[12:59] <wgrant> I haven't looked at the method recently, but it probably uses it to get an archive-wrapped LFA or something.
[12:59] <wgrant> If not, then I have no idea.
[12:59] <cjwatson> ok, now I at least know how to write a test for this.
[12:59] <cjwatson> yes, it does.
[12:59] <cjwatson> so my initial instinct was probably correct, it can just be self.binarypackagerelease.files instead.
[12:59] <wgrant> Yeah, as long as you wrap them.
[12:59] <cjwatson> right, same as before
[13:00] <wgrant> Oh.
[13:00] <wgrant> It wraps them manually.
[13:00] <wgrant> So no reason to use BPFP at all.
[13:00] <cjwatson> Exactly
[13:01] <cjwatson> Sorry, misread you above.
[13:01] <wgrant> And SPPH.binaryFileUrls is fine too.
[13:01] <cjwatson> I think it just uses .files because it was there and looked seductively correct.
[13:01] <wgrant> Yep
[13:02] <wgrant> I'd forgotten that .files used it.
[13:02] <wgrant> Rather than just forwarding.
[20:40] <blr> wgrant: excellent branch name
[23:19] <blr> 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] <blr> nvm, found the zope.formlib docs
[23:43] <lifeless> wgrant: I'm curious, whats the current 99th% request time on LP (prod), and requests/day.