[00:11] <cjwatson> wgrant: So here's a problem with the approach taken in https://code.launchpad.net/~cjwatson/launchpad/bpph-source/+merge/255070
[00:12] <cjwatson> 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] <cjwatson> 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] <cjwatson> I wonder, though, if we should have a similar exception for SPPH visibility as there is for BPB visibility
[00:15] <cjwatson> That is, if you can see the SPR you might as well be able to see the other thing
[00:17] <cjwatson> Though it might be a problem that SPPH URLs are under their archive
[00:17] <cjwatson> We should find some solution for this soon, as it's blocking ddeb-retriever right now
[00:17] <cjwatson> (Though fortunately ddeb-retriever can now catch up in a way that was awkward before)
[00:23] <wgrant> bigjools: We could change the default if you know you're going to be exceeding it.
[00:23] <wgrant> cjwatson: ugh, indeed, we really should just fix this to not be completely and utterly broken model-wise at some point :/
[00:27] <cjwatson> So we could just implement your suggestion from that MP of exporting the source name as a stopgap
[00:27] <cjwatson> In the specific case of ddeb-retriever that's all it actually needs today
[00:27] <cjwatson> There are probably other users that will have issues, but ...
[00:30] <cjwatson> 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] <wgrant> Yeah, I have a partially implemented fix for all that, but it's a reasonable amount of work.
[00:33] <wgrant> (see my ArchiveBinaryPackageBuild series)
[00:44] <cjwatson> Ah yes, I think I've seen that before
[00:49] <wgrant> Fixes a lot of performance issues as well.
[00:51] <cjwatson> In the short term I think exporting BPB.source_package_name is likely to be most practical, though.
[00:54] <wgrant> Yep.
[00:54] <wgrant> Most awkward bit is ensuring the correct preloading.
[00:57] <cjwatson> 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] <blr> 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] <cjwatson> blr: Sounds sensible
[00:58] <cjwatson> "Code" is a reasonable term in existing use that covers both.
[00:58] <blr> sounds good, thanks.
[00:59] <wgrant> cjwatson: Ah, of course.
[00:59] <wgrant> settings
[00:59] <wgrant> settings dammit.
[00:59] <wgrant> None of this "Change details"
[00:59] <wgrant> Or "Configure"
[00:59] <wgrant> god. damn. settings.
[00:59] <cjwatson> I was just thinking that "Configure ... code" does sound a bit like ./configure
[01:00] <wgrant> It's also awkward and long :)
[01:00] <wgrant> I think "settings" is the usual word nowadays just about everywhere else.
[01:01] <blr> we certainly like saying configure a fair bit -> "Configuration progress ... Configuration options... Configure bug tracker"
[01:02] <wgrant> Indeed.
[01:02] <blr> we could drop configuration from everything save Configuration progress and it would all still make sense
[01:02] <wgrant> In that portlet it probably makes sense, indeed. I'm not sure where else those links are used, though.
[01:03] <wgrant> Other places (eg. https://blueprints.launchpad.net/launchpad) need something like the current text.
[01:03] <wgrant> (or "settings"!)
[01:04] <wgrant> The config portlet probably does want to override it.
[01:04] <blr> it "options" even the right word in that portlet, they seems more like 'steps'
[01:04] <blr> granted they are optional.
[01:04] <cjwatson> Except you don't have to carry them out in order.
[01:04] <wgrant> And they never go away :/
[01:04] <cjwatson> Or at all.
[01:04] <blr> heh
[01:05] <wgrant> 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] <blr> yep, let's do that for now.
[01:06]  * blr wanders off to de-yodawg.
[01:07] <blr> will also add something to the UI asana board about the entire process being clunky generally
[01:07] <wgrant> A good idea.
[01:08] <wgrant> 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] <blr> 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] <blr> or deal even.
[01:10] <cjwatson> Although careful with pushing ProjectSet:+new because people often hit that when they really meant to create a PPA.
[01:10] <cjwatson> Despite the warnings.
[01:11] <cjwatson> 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] <blr> sounds like another task for the UI board :)
[01:30] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/bpb-source-package-name/+merge/258820
[01:34] <wgrant> cjwatson: You'll probably also need to fix xx-builds.txt
[01:34] <cjwatson> sassenfrassendoctests
[01:34] <cjwatson> yeah
[01:46]  * cjwatson lands that and sleeps
[01:48] <bigjools> cjwatson: I had completely forgotten about the hidden copy-packages link!
[02:04] <wgrant> cjwatson: buildd branches fixed.
[02:36] <blr> have changed the order of the configuration options to reflect the top menu as well, code coming first.
[02:38] <blr> 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] <wgrant> blr: I'd rather customise the links rendered by pillar-involvement-portlet.pt
[02:42] <wgrant> blr: ProductInvolvementView.configuration_links already changes things up a bit.
[02:46] <blr> ah I see, I'll leave the configure_foo methods as they are in that case.
[03:04] <blr> wgrant: why is blueprints commented?
[03:14] <wgrant> blr: I'm not quite sure. The revision that disabled it added the progress bar.
[03:15] <wgrant> 3220eba or r11189.1.5
[03:15] <wgrant> But no rationale provided.
[03:19] <blr> weird, seems a little odd not to have it enabled, given we're still supporting blueprints.
[03:21] <wgrant> Indeed.
[05:22] <wgrant> blr: Are you landing that DB branch?
[05:30] <blr> 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] <wgrant> blr: What do you mean about windows?
[05:39] <wgrant> blr: The column is useful even without the setbranch rework.
[05:40] <blr> wgrant: windows for landing a db patch.
[05:41] <blr> colin landed the last patch I wrote - can I lp-land it now?
[05:42] <wgrant> 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] <wgrant> There are traditionally *deployment* windows, but we tend to ignore them nowadays if that would be convenient.
[05:42] <blr> ok, will do that after dinner. thanks :)
[06:31] <blr> wgrant: ok to land the patch with no-qa?
[06:40] <wgrant> blr: Yep
[06:46] <blr> wgrant: assuming for the API export, vcs should be a Choice, but presumably that requires the creation of a new vocabulary?
[06:48] <wgrant> blr: No, you can give Choice an enum directly.
[06:48] <wgrant> For simple cases like this.
[06:48] <wgrant> No filtering or restrictions required.
[06:48] <blr> ah good
[07:30] <blr> wgrant: fixed up the api export - regenerated the api docs which seem correct.
[08:07] <wgrant> blr: Thanks, will look in a bit.
[09:56] <cjwatson> wgrant: buildd> r=me, thanks
[09:57] <wgrant> cjwatson: Thanks.
[12:33] <cjwatson> Hm, are we OK with CSS3 selectors in LP?
[12:33] <cjwatson> I guess that not() is in use in several other places.
[12:44] <beuno> cjwatson, I think it's been a few years to be ok with them!
[12:48] <cjwatson> spot the person with a distro developer background, not web dev. :-)
[12:50] <wgrant> cjwatson: http://caniuse.com/
[12:50] <wgrant> cjwatson: IE8 doesn't support it, but everything else of significance does.
[12:51] <beuno> cjwatson, beowulf is my go-to guy for these questions, FWIW
[12:51] <wgrant> And we don't particularly care about IE8 any more, particularly for something so trivial.
[12:51] <beuno> he's usually happy to help
[12:51] <beuno> and in the UK
[12:52] <beuno> we'll soon get another FE-focused person on board in the CI team as well
[12:53] <beuno> disclaimer, he's on a mission to move away from YUI wherever possible/cheap/sensible
[13:02] <cjwatson> 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] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/git-activereviews/+merge/258910 - phew.  EOD time.
[17:32] <cjwatson> (modulo team meeting)