[09:48] wgrant: I'm looking into the reported (non-timeout) bug unsubscribe oops. [09:48] Unless you are already. [09:50] cjwatson: Fixed on DF already. [09:50] Just writing tests for the untested cod [09:50] e [09:50] Heh, OK. [09:59] wgrant: Did you have any thoughts on http://irclogs.ubuntu.com/2015/04/29/%23launchpad-dev.html#t16:48 ? [10:01] "Default" is ew, the rest makes some sense. [10:02] Mm, maybe I can just drop that and the singular is enough. [10:03] In an ideal world that would be where the repository selector was, I think. [10:03] But "default" should definitely not be the first word on the page! [10:03] repository selector> how do you mean? [10:04] Well, we need some way to see the other repositories, probably near the top of the page. [10:04] Right. [10:04] Maybe even above the "You can browse the source code" [10:04] Maybe just "Git branches". It's "branches associated with the default Git repository", but "Git repository branches" just sounds like we're confused. [10:04] That would make it clear which repo is selected. [10:04] Yeah, "Git branches" makes sense-ish. [10:06] The page is annoyingly spread out over product-branches.pt and product-branch-summary.pt right now, which makes it awkward. [10:26] dammit nvidia [10:27] number_of_duplicates [10:27] 1156 [10:27] other_users_affected_count_with_dupes [10:27] 2865 [22:14] cjwatson: https://code.launchpad.net/~wgrant/launchpad/git-fixes/+merge/257977 [22:18] wgrant: r=me [22:18] cjwatson: Thanks. [22:18] I think we can NDT without that, though - I was going to sort that out after this call [22:18] if that's OK [22:19] since at least ASCII-only MPs work [22:20] yep [22:20] sounds good to me [22:43] wgrant: LPSed/RTed; feel free to amend both if your rev is ready before webops take that [22:45] https://code.qastaging.launchpad.net/~cjwatson/grub/+git/qas/+ref/fstest-test/+merge/254312 was the ASCII-only case I mentioned, BTW [22:46] Yep, saw it in the OOPS. [22:46] I poked around locally and found all the obvious crashers and fixed them. [22:46] Yep. Thanks for that. [22:47] I think anything further from our side is gravy at this point. [22:48] Is there anybody at the sprint who might be able to help chase down the nova scheduling thing tomorrow? [22:49] If it's not solved overnight, I will harrass someone. [22:50] I'm talking to designy people tomorrow morning, will try to get something useful out of them. But I think we just need something like your screenshot, target/owner repo listings... [22:50] And GitRef:+activereviews would be nice and might be easy. [22:50] All of which are quick to do something roughly as dirty as the bzr equivalent. [22:51] Yeah, there's a huge pile of misc views to clean up. [22:51] Layouts of the worst cases of combining git and bzr listings that also show a useful set of information about git branches would be good. [22:52] In some ways I'd like to ram them all into a single table. [22:53] Partly because multiple similar-content tables on a single page look bad because their column widths don't match. [22:53] I haven't touched the package views yet. [22:53] The only place we really need to show both simultaneously is on Person:+branches [22:54] Since a target (or an owner-target) has a primary VCS defined. [22:54] The project and package views could get away with having a mode switch, indeed. [22:54] Once we model such a thing. [22:55] Person:+branches already has a relationship filter. [22:55] (it was several separate pages a few months ago, but it's all one now) [22:57] I'd been focusing on the target partly because I'd like to have a rule that the target page for a target with a default repository always shows at least something about the default repository, so that we can switch the canonical URL over to shortened_path rather than unique_name [22:57] since I really don't like the canonical URL for default project repositories being /~owner/project/+git/project [22:57] Yeah, definitely. And that's the only bit that really requires thought. [22:58] The others are, well, tables. [22:58] so I think that even if we have a mode switch we always need to show *something* about the non-default mode [22:58] (if there's any content for it) [22:58] yep [22:58] we could certainly have a radically different summary, though [22:59] very hard to get the summary right without a mode switch - I tried, it's a mess as you saw [22:59] "you can clone a git repository! oh and by the way you can push a bzr branch!" [22:59] Mhm. [23:01] but perhaps I could go and try Person:+branches for a while, because that involves a lot of the same kind of infrastructure but has a fairly minimal summary [23:01] and, I think, should probably just show repositories rather than refs [23:01] maybe? [23:02] although "last commit" is meaningless for repositories, so perhaps that's wrong [23:03] perhaps repositories should have an expander for branches [23:03] worth asking design if they have any thoughts there [23:04] I don't really know. I like seeing all the recent work, but it might get drowned out by eg. a push --mirror [23:04] Yeah. And status is meaningless for repositories *and* refs, too. [23:05] (To the extent that it's meaningful for branches ...) [23:05] I would not complain if the status column accidentally went missing tomorrow. [23:05] mm [23:05] I guess Merged is useful [23:05] But meh [23:06] In the default view, which excludes it :-) [23:06] yep [23:07] If we're using committer_date (which we do right now in ref listings), then push --mirror is less of a problem [23:07] One of my branches in progress fixes ref listings to sort by descending committer_date [23:07] Which makes them a lot more sensible [23:07] blr: Do you want to experiment with these couple of views and see if you can get something vaguely sensible? [23:08] http://paste.ubuntu.com/10956927/ is what I have today, if you want to crib anything from that [23:08] wgrant: sure - thanks cjwatson [23:09] (also I have http://paste.ubuntu.com/10956930/ lying around from an older branch that tried to do more with targets, but I suspect more of that branch is crap) [23:09] I'll work with designy people tomorrow, but it'll be a while before we have anything useful, and we just need something vaguely adequate for tomorrow. [23:09] cjwatson: will move push-instructions to a partial, it is used in two places [23:10] and add the git specific copy we discussed last night [23:10] The fixed sorting is the top bit of the patch to lib/lp/code/browser/gitrepository.py, and we likely want that regardless [23:10] (from the first paste) [23:11] I'm inclined to say that we may want to drift away from trying to have a single view for Person again [23:12] Yeah [23:12] Person:+branches is recent work, but there could also be a view that lists all your repositories [23:12] Then Person:+branches can just mix in refs with the committer date as "last modified" [23:12] A push --mirror with a billion branches seems not hugely likely. [23:12] Can always be adjusted if it doesn't work out. [23:12] right, but even if somebody does that, a lot of those branches are going to be old [23:12] Yep [23:13] in terms of committer date [23:13] So Person:+branches intersperses branches and refs. [23:13] we miiiight have a perf problem, but I don't think it's a fundamental UI problem if you end up with a bazillion branches off in batch 87 [23:13] Product:+branches shows one or the other, and additionally the default git repo if git is selected, plus a VCS switcher. [23:14] I don't see a perf problem here, though it will be awkward to implement. [23:14] GitCollection lalala [23:14] It may be better to have a VCS switcher for Person:+branches in the first iteration. [23:14] No fundamental perf problem, then :) [23:14] like another dropdown? [23:14] It's a simple matter of code. [23:14] Could be, yeah. [23:15] Or just Person:+repositories, if it's going to have totally different semantics anyway [23:15] We can't currently dynamically change the default view for a particular object. [23:15] Only an interface. [23:16] But I guess having it as a secondary page for the first iteration is OK. [23:16] right, but we could have another slot in PersonBranchesMenu [23:16] which already has "Branches", "Active reviews", "Source package recipes" [23:16] the only concern would be whether we're painting ourselves into a corner, but redirects are a thing ... [23:17] Right, it works short term. [23:18] Anyway, I need to sleep. [23:18] I'm not convinced we can fix the canonical URL of target default repos by tomorrow, but even making it possible to find them via a Person view would be a small step up [23:18] yeah, me too [23:19] blr: Experiment with what you can today, and Colin and I can hopefully bikeshed over whatever you have into something releasable in our morning. [23:19] (conceivably, Person:+repositories could list all the projects you've worked on in code terms, whether that be bzr or git - take advantage of the bzr repository metaphor even if it isn't precisely identical [23:19] ) [23:19] True [23:20] that sort of thing might help address people's issues with code [23:22] and after all e.g. https://code.launchpad.net/~cjwatson/launchpad is a thing, so we *sort of* have that notion already