[00:11] wgrant: So here's a problem with the approach taken in https://code.launchpad.net/~cjwatson/launchpad/bpph-source/+merge/255070 [00:12] wgrant: chaenomeles/launchpad-access60.log:91.189.89.30 - "91.189.90.217" "api.launchpad.net" [11/May/2015:16:55:19 +0000] "GET /devel/~ubuntu-security/+archive/ubuntu/ppa/+build/7403388?ws.op=getLatestSourcePublication HTTP/1.1" 401 480 14 0.106685876846 626 191 "Anonymous" "BinaryPackageBuild:EntryResource:getLatestSourcePublication" "" "lazr.restfulclient 0.12.0; oauth_consumer="ddeb-retriever"" [00:13] that's a build from a private archive copied into the primary Ubuntu archive; we can't do BPPH.build.getLatestSourcePublication() because that's constrained to return an SPPH in the same archive as the build, and that archive is private [00:15] I wonder, though, if we should have a similar exception for SPPH visibility as there is for BPB visibility [00:15] That is, if you can see the SPR you might as well be able to see the other thing [00:17] Though it might be a problem that SPPH URLs are under their archive [00:17] We should find some solution for this soon, as it's blocking ddeb-retriever right now [00:17] (Though fortunately ddeb-retriever can now catch up in a way that was awkward before) [00:23] bigjools: We could change the default if you know you're going to be exceeding it. [00:23] cjwatson: ugh, indeed, we really should just fix this to not be completely and utterly broken model-wise at some point :/ [00:27] So we could just implement your suggestion from that MP of exporting the source name as a stopgap [00:27] In the specific case of ddeb-retriever that's all it actually needs today [00:27] There are probably other users that will have issues, but ... [00:30] It's independently irritating that the source on https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/7403388 isn't linked, but that has nothing to do with privacy, it's because we never make that a link if the context archive is a PPA. Though in this case you don't get to see the archive either. [00:33] Yeah, I have a partially implemented fix for all that, but it's a reasonable amount of work. [00:33] (see my ArchiveBinaryPackageBuild series) [00:44] Ah yes, I think I've seen that before [00:49] Fixes a lot of performance issues as well. [00:51] In the short term I think exporting BPB.source_package_name is likely to be most practical, though. [00:54] Yep. [00:54] Most awkward bit is ensuring the correct preloading. [00:57] wgrant: self.source_package_release.name is already used by BPB.title, which is exported, so I don't think it needs anything new. [00:57] wgrant: cjwatson: what are your thoughts on changing the "Configure project branch" label under Config Progress to "Configure project code" or something that suits both git and bzr. [00:57] blr: Sounds sensible [00:58] "Code" is a reasonable term in existing use that covers both. [00:58] sounds good, thanks. [00:59] cjwatson: Ah, of course. [00:59] settings [00:59] settings dammit. [00:59] None of this "Change details" [00:59] Or "Configure" [00:59] god. damn. settings. [00:59] I was just thinking that "Configure ... code" does sound a bit like ./configure [01:00] It's also awkward and long :) [01:00] I think "settings" is the usual word nowadays just about everywhere else. [01:01] we certainly like saying configure a fair bit -> "Configuration progress ... Configuration options... Configure bug tracker" [01:02] Indeed. [01:02] we could drop configuration from everything save Configuration progress and it would all still make sense [01:02] In that portlet it probably makes sense, indeed. I'm not sure where else those links are used, though. [01:03] Other places (eg. https://blueprints.launchpad.net/launchpad) need something like the current text. [01:03] (or "settings"!) [01:04] The config portlet probably does want to override it. [01:04] it "options" even the right word in that portlet, they seems more like 'steps' [01:04] granted they are optional. [01:04] Except you don't have to carry them out in order. [01:04] And they never go away :/ [01:04] Or at all. [01:04] heh [01:05] The whole thing needs to be redesigned, but I'd be tempted to just have links named after the tabs without saying configure configure configure. [01:05] yep, let's do that for now. [01:06] * blr wanders off to de-yodawg. [01:07] will also add something to the UI asana board about the entire process being clunky generally [01:07] A good idea. [01:08] It's the first impression you get of LP (other than the adventure of finding out how to create a project, and then fill in the eleven thousand fields on ProjectSet:+new, which keeps going across multiple steps each with variants of the same fields), and it's a little dodgy. [01:09] right, I think if we could address this config process _and_ add more visibility to +new that would help new users a great dela. [01:09] or deal even. [01:10] Although careful with pushing ProjectSet:+new because people often hit that when they really meant to create a PPA. [01:10] Despite the warnings. [01:11] It's not clear whether it's really easier to find ProjectSet:+new than Person:+create-ppa, or if we just don't hear about the latter because you can do self-service PPA deletion. [01:11] sounds like another task for the UI board :) [01:30] wgrant: https://code.launchpad.net/~cjwatson/launchpad/bpb-source-package-name/+merge/258820 [01:34] cjwatson: You'll probably also need to fix xx-builds.txt [01:34] sassenfrassendoctests [01:34] yeah [01:46] * cjwatson lands that and sleeps [01:48] cjwatson: I had completely forgotten about the hidden copy-packages link! [02:04] cjwatson: buildd branches fixed. [02:36] have changed the order of the configuration options to reflect the top menu as well, code coming first. [02:38] wgrant: what's the best way to render the links on Bugs/Blueprints/Translations etc? They should still read 'Configure foo' on those views. [02:41] blr: I'd rather customise the links rendered by pillar-involvement-portlet.pt [02:42] blr: ProductInvolvementView.configuration_links already changes things up a bit. [02:46] ah I see, I'll leave the configure_foo methods as they are in that case. [03:04] wgrant: why is blueprints commented? [03:14] blr: I'm not quite sure. The revision that disabled it added the progress bar. [03:15] 3220eba or r11189.1.5 [03:15] But no rationale provided. [03:19] weird, seems a little odd not to have it enabled, given we're still supporting blueprints. [03:21] Indeed. [05:22] blr: Are you landing that DB branch? [05:30] wgrant: no, I'm still not entirely sure about windows. There's no hurry, I need the corresponding setup/setbranch branch working for it be of any use, unless it is useful for you or colin. [05:39] blr: What do you mean about windows? [05:39] blr: The column is useful even without the setbranch rework. [05:40] wgrant: windows for landing a db patch. [05:41] colin landed the last patch I wrote - can I lp-land it now? [05:42] blr: Yep, you can land as soon as there are no deployment blockers (eg. code on prod that depends on a column that you're removing). [05:42] There are traditionally *deployment* windows, but we tend to ignore them nowadays if that would be convenient. [05:42] ok, will do that after dinner. thanks :) [06:31] wgrant: ok to land the patch with no-qa? [06:40] blr: Yep [06:46] wgrant: assuming for the API export, vcs should be a Choice, but presumably that requires the creation of a new vocabulary? [06:48] blr: No, you can give Choice an enum directly. [06:48] For simple cases like this. [06:48] No filtering or restrictions required. [06:48] ah good [07:30] wgrant: fixed up the api export - regenerated the api docs which seem correct. [08:07] blr: Thanks, will look in a bit. [09:56] wgrant: buildd> r=me, thanks [09:57] cjwatson: Thanks. === danilos` is now known as danilos [12:33] Hm, are we OK with CSS3 selectors in LP? [12:33] I guess that not() is in use in several other places. [12:44] cjwatson, I think it's been a few years to be ok with them! [12:48] spot the person with a distro developer background, not web dev. :-) [12:50] cjwatson: http://caniuse.com/ [12:50] cjwatson: IE8 doesn't support it, but everything else of significance does. [12:51] cjwatson, beowulf is my go-to guy for these questions, FWIW [12:51] And we don't particularly care about IE8 any more, particularly for something so trivial. [12:51] he's usually happy to help [12:51] and in the UK [12:52] we'll soon get another FE-focused person on board in the CI team as well [12:53] disclaimer, he's on a mission to move away from YUI wherever possible/cheap/sensible [13:02] In this case it was just for https://code.launchpad.net/~rbanffy/launchpad/highlight_listing_tr/+merge/258766 rather than anything deeply involved [17:32] https://code.launchpad.net/~cjwatson/launchpad/git-activereviews/+merge/258910 - phew. EOD time. [17:32] (modulo team meeting)