| === danilos` is now known as danilos | ||
| blr | wgrant: cjwatson: if we can add tags to make it clear which part of the UI a given task refers to in the Launchpad:UI asana project, suspect that will be helpful (e.g. User Profile) | 05:01 |
|---|---|---|
| cjwatson | blr: ack | 09:35 |
| blr | cjwatson: context/getCodebrowseUrl is rendering with '?h=master', is there any way to just get the root? | 10:31 |
| cjwatson | blr: context/repository/getCodebrowseUrl | 10:36 |
| cjwatson | blr: I expect context in this case is a ref ... | 10:37 |
| cjwatson | so getCodebrowseUrl on a repository gives you the root, on a ref takes you straight to that ref, otherwise it ends up a bit strange | 10:38 |
| blr | cjwatson: awesome, that works nicely thanks | 10:42 |
| cjwatson | cool | 10:44 |
| wgrant | cjwatson: What do you think of the {Product,Distribution}.vcs design? | 11:12 |
| cjwatson | so I'd been sort of hoping that it could be avoided or made implicit somehow | 11:13 |
| cjwatson | we shouldn't be able to end up in states where the flag says git and there are only bzr branches, or vice versa | 11:14 |
| cjwatson | and I also think it should be possible to run both bzr dev focus and git default repo in parallel, for migration, which means that we need to be able to show both | 11:14 |
| cjwatson | at that point it is not clear to me what the vcs enum actually governs | 11:14 |
| wgrant | What value does showing both provide? | 11:14 |
| wgrant | eg. look at https://code.launchpad.net/launchpad | 11:14 |
| wgrant | It's confusing and I can't see a case where it would ever be desirable. | 11:15 |
| wgrant | The column probably just selects whether the code page shows bzr or git stuff by default. | 11:15 |
| cjwatson | I think if we aren't going to show both, we need some way to get at the default git repository for a project in the web UI that isn't /target | 11:16 |
| cjwatson | or, perhaps better, it should be impossible to set a default git repository for a target that doesn't have its vcs set to git | 11:16 |
| cjwatson | or something like that | 11:16 |
| cjwatson | we need to think through the migration path for a project | 11:17 |
| wgrant | Or someone has to click the git link if they run into a git default URL on a bzr-defaulting project. | 11:17 |
| cjwatson | the git link that doesn't exist yet, but yes | 11:17 |
| wgrant | Well yeah, once the page is split there will presumably be a link between the two halves :) | 11:17 |
| cjwatson | this ties into my hope to be able to make the canonical url for a default repo be (target, rootsite="code") | 11:18 |
| cjwatson | this only works if it's reliably shown there. although I suppose we could do that only if vcs==git, but that starts being messy ... | 11:18 |
| wgrant | Is it as messy as showing both? | 11:18 |
| cjwatson | perhaps not | 11:19 |
| wgrant | The URLs already vary based on whether the repo is the default or not. | 11:19 |
| wgrant | Varying slightly further based on whether the *VCS* is the default doesn't seem out of the question. | 11:19 |
| cjwatson | this is true | 11:19 |
| cjwatson | so what's the URL for the default git repository on a bzr-defaulting project? | 11:19 |
| cjwatson | I suppose we could just send you to the unique name | 11:19 |
| wgrant | Right, I think the web URL is just the full URL in that case. | 11:20 |
| wgrant | But switching the +branches to the git view using the link at the top will also show it. | 11:20 |
| cjwatson | can you explain that last bit? | 11:20 |
| cjwatson | link at the top of where? | 11:20 |
| wgrant | There's some widget on the project code index which switches between the git and bzr views, defaulting to target.vcs. | 11:21 |
| wgrant | If target.vcs is bzr and you click on the git link, you'll presumably get the view you would get if the default was git. | 11:21 |
| cjwatson | I'd been working on Person:+repositories; perhaps that makes sense as a view name elsewhere as well | 11:22 |
| cjwatson | (or it could just be +git, but I wasn't sure if that would cause ambiguity problems) | 11:22 |
| wgrant | +repositories is a) realllly long and b) poor apt :( | 11:23 |
| wgrant | I'm not sure if +git can currently be implemented. | 11:23 |
| wgrant | I *think* it works, and there is one example somewhere, but I can't think what. | 11:23 |
| wgrant | +bug vs +bugs is just stupidity, not a technical limitation. | 11:23 |
| cjwatson | The only case where there's potential ambiguity is on Person itself, and the traversal there is sufficiently manual that we could probably manage to say zero remaining path elements => PersonGitView | 11:24 |
| wgrant | Yeah. | 11:24 |
| cjwatson | The reason I'd been going a little more general is that I was thinking of it as a good way to simplify things for bzr too | 11:24 |
| wgrant | Howso? | 11:24 |
| cjwatson | You could reasonably look as PersonProduct etc. as metaphorically a repository | 11:25 |
| wgrant | aaaaa | 11:25 |
| cjwatson | In the bzr sense too | 11:25 |
| cjwatson | And then code pages could suck a bit less | 11:25 |
| cjwatson | But I don't know if it's worthwhile | 11:25 |
| wgrant | I'm not quite sure. | 11:25 |
| cjwatson | Because you could see people who'd worked on a project recently, and then drill down from there to look at individual branches, rather than just getting a sea of branches | 11:26 |
| wgrant | So, convince me about your plan for eg. the project code index. | 11:26 |
| wgrant | Hm, true. | 11:26 |
| wgrant | But that's less interesting in the git future. | 11:26 |
| cjwatson | I think that should be approximately the git view, though. | 11:27 |
| wgrant | Yep. | 11:27 |
| cjwatson | So, I think I'm fine with the project code index being switchable; the dual view was admittedly (in the MP description) a stopgap | 11:27 |
| wgrant | Oh yeah, and it's a fine stopgap, because it still isn't quite clear how to do it properly. | 11:28 |
| cjwatson | It needs to be switchable on "Configure code hosting" or whatever replaces it (since +setbranch is series-specific) | 11:28 |
| wgrant | Do you have an idea on how to obviate Product.vcs, though? | 11:29 |
| wgrant | Ah yeah | 11:29 |
| wgrant | We discussed this on the call last week, sorry. | 11:29 |
| wgrant | Kit's working on a Product-wide +setbranch equivalent. | 11:29 |
| cjwatson | Right | 11:29 |
| cjwatson | So it's not so much that I have a clear plan as that I'm trying to understand how we avoid inconsistencies in yours :) | 11:29 |
| cjwatson | If the view switches then at least people have a clear incentive to set it to the right thing | 11:30 |
| wgrant | The default git repo URL is the only serious issue I see. | 11:30 |
| wgrant | And that's only an issue during migration. | 11:30 |
| cjwatson | If you're happy with a conditional canonical URL that depends on the vcs enum, I think that satisfies my concerns. | 11:30 |
| cjwatson | I just don't want to be stuck with the canonical URL being ugly forever. | 11:31 |
| wgrant | So, the canonical URL itself can't be that. | 11:31 |
| wgrant | We'll have to do something a bit magical. | 11:31 |
| wgrant | because eg. the API | 11:31 |
| wgrant | But maybe the web canonical_url can be different. | 11:31 |
| cjwatson | So, what's the preferred migration path for a project? We have docs somewhere (say, a help popup) giving some advice on migrating to git (maybe an auto-importer in the magical future, but I remain to be convinced about the tractability of that for an entire set of branches without manual gardening). You do that and push to the default repository path. Product:+branches notices and gives you a view for git stuff, and maybe an AJAX ... | 11:34 |
| cjwatson | ... switcher to change over. What do the view names become here? | 11:34 |
| wgrant | The easiest way is a query string on the end of +branches. | 11:34 |
| cjwatson | Or perhaps Product:+branches and Product:+git, and the default view depends on vcs? | 11:34 |
| wgrant | It's awkward, but currently we have no way to configure default view name very eaisly. | 11:34 |
| cjwatson | Hm. | 11:35 |
| wgrant | We could do it, though. | 11:35 |
| wgrant | It would require a small amount of infrastructure work. | 11:35 |
| wgrant | Auto-importer is difficult due to various gardening that can be required. | 11:36 |
| wgrant | eg. for LP I have to replace two whoamis to get something that git fsck is happy with (and thus GitHub will accept, for example). | 11:36 |
| cjwatson | I think my latest prototype reimplemented BranchListingView etc., but it would probably be possible to crowbar it all into the same view in order to support both. | 11:37 |
| cjwatson | Right, my experiences with converting stuff to git have all employed various bits of manual gardening. | 11:37 |
| cjwatson | Mostly using http://www.catb.org/~esr/reposurgeon/ once I discovered that it existed. | 11:38 |
| cjwatson | (Because this is the sort of job where having a DSL can really improve your life) | 11:38 |
| cjwatson | So I think I'm OK with the vcs plan; now that we've talked through it it makes a bit more sense to me. | 11:39 |
| wgrant | I think you click the code settings link, where you can get instructions on pushing to the other VCS. | 11:40 |
| wgrant | Once a repo exists for the other VCS, the default code listing grows a switcher. | 11:40 |
| cjwatson | Yeah, probably shouldn't clutter the default view with that sort of instructions. | 11:40 |
| wgrant | (what this doesn't handle is hiding the switcher once both types exist, but meh) | 11:48 |
| cjwatson | You could do that by deleting all the bzr branches. | 11:52 |
| cjwatson | Or something. | 11:52 |
| cjwatson | Except you probably wanted to keep MP history. | 11:52 |
| cjwatson | (I occasionally refer to years-old MP history in Launchpad ...) | 11:53 |
| wgrant | That's why we did git MPs a bit more sensibly, indeed. | 11:55 |
| cjwatson | "meh" seems like a reasonable disposal. | 11:58 |
| wgrant | Quite. | 11:58 |
| wgrant | I'm just thinking about where to put the default widget. | 11:58 |
| wgrant | I think ti would make sense to have it behind a link at the bottom of +edit, below the submit button, in what looks like an ignorable footer. | 11:59 |
| wgrant | Similar to the team ownership change view. | 11:59 |
| cjwatson | Shouldn't it be on Product:+setbranch? | 12:01 |
| wgrant | Yes, I was just thinking of the most obtuse and Launchpaddy place to put it. | 12:01 |
| wgrant | Product:+setbranch or equivalent is indeed where it should go in the real world. | 12:02 |
| === mwhudson_ is now known as mwhudson | ||
| bigjools | wgrant: what's the default size limit for P3As nowadays? | 22:13 |
| cjwatson | bigjools: 2 GiB for both public and private | 22:14 |
| bigjools | cjwatson: can that be upped for P3As? | 22:15 |
| bigjools | and hi :) | 22:15 |
| cjwatson | bigjools: wgrant generally processes tickets to raise limits on request pretty quickly | 22:18 |
| bigjools | cjwatson: the guys I work with say that it's annoying to have to do that and want to up the default | 22:18 |
| cjwatson | I'm sure it's possible, I think we should look at some stats for archive usage plotted against whether they're public or private, though | 22:19 |
| cjwatson | there might be a few possible fixes to that annoyance | 22:21 |
| bigjools | that would be nice :) | 22:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!