[01:13] wgrant: can BRANCH_TYPE_VOCABULARY in productseries return a more generic message? [01:13] i.e. "Link to a branch already on Launchpad" (removing the explicit mention of Bazaar) [01:34] blr: The form needs a bit of a redesign, I think, but we can't make the optimal changes until later on (eg. once we have Git mirroring). [01:34] It's all a bit weird, since you can (and, during migration, want to) have defaults for both Git and Bazaar. [01:34] So we can't just add an additional radio button for Git. [01:34] We need to have a Git section and a Bazaar section. [01:35] And the Git section can't currently allow an import. [02:21] wgrant: is there some voodoo required for importing yui styles for a given yui widget? [02:32] wgrant: assuming I need to customise those styles in style.css? [02:33] would prefer to overriding specific styles rather than copying them entirely into styles.css [02:51] wgrant: nvm, figured it out, appears everything under components is built [03:02] blr: Which widget are you using? [03:03] wgrant: tabview [03:03] which doesn't appear to be used anywhere [03:03] Indeed, I think it is not. [03:03] Where are you applying it? [03:04] wgrant: making bzr/git instructions more compact [03:04] a tab for each - think it will work, but need to tidy up the styles, the yui defaults are not particularly nice. [03:04] blr: Hmmmm. [03:05] blr: Except for Person:+branches, we should probably have separate pages for bzr and git listings, since only one's going to be active at a time. [03:05] context here is push instructions on +setbranch [03:05] And when there are separate pages there are obvious places for both sets of instructions. [03:05] Ah, right. [03:05] Worth a try for that, indeed. [03:05] but right, better if we don't generally have to have both! [03:06] wgrant: was pleasantly surprised how easy it was to add a new sprite btw, thanks [03:06] black magic. [03:06] Yeah, it's pretty well integrated. [03:07] So well integrated that I haven't bothered to look at how exactly it works. [03:07] the git logo is still recognisable at 14x14 thankfully [03:07] Where are you using it? [03:08] on the tabs e.g. | (logo) git | (logo) bzr | [03:08] I'll include a screenshot in the bmp [05:32] blr: Ah, hm, that looks great, except I've just realised it's not so simple, of course. [05:33] blr: There is no concept of a series-default git repository, because a series is a single branch, while the git repository is target-global. [05:34] We probably need to rethink the setup UI before we can do anything even vaguely sensible. [06:16] wgrant: argh, ok :( [06:24] wgrant: I've set it back to wip, perhaps some of it can be re-used later. [06:27] blr: I suspect we'll want to convert that into a project-wide default code setting page, which does what works for most projects (sets the project default for git, and the development series default for bzr). [06:27] So it can definitely be reused. [06:29] wgrant: not sure how things were left with cjwatson re: remaining UI tasks - any suggestions for tomorrow? [06:29] think I generally have a better grasp on the frontend now [06:31] blr: I don't know where Colin got up to with the repo listings, if anywhere. [06:31] Nobody knows exactly how they should be done. [06:32] It's mostly a matter of experimenting at this point [06:32] hopefully I'll have a window to catch up with him in the morning [06:36] Indeed. [06:36] (catching up is much easier if you can arrange to have your IRC client always connected, too) [08:12] morning> fwiw I'm off today, bank holiday [20:24] cjwatson: ping me if you're about please :) [20:39] interesting to see people asking for webhooks on that reddit thread. [21:35] cjwatson: for the UI work, are you finding it sufficient to use factories, or are you running turnip in dev as well? [21:59] blr: factories for unit testing, a dev turnip instance for in-browser experimentation [22:00] cjwatson: are you running turnip in a container? [22:01] blr: have done in the past, right now I'm using a juju-deployed instance [22:01] either works [22:01] well, that's deploying to a container [22:01] so "yes" [22:01] hah right [22:01] easiest is to set git.launchpad.dev to the appropriate IP address in /etc/hosts in your host system, the individual containers fall back to that by way of (I guess) dnsmasq