=== danilos` is now known as danilos
blrwgrant: 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
cjwatsonblr: ack09:35
blrcjwatson: context/getCodebrowseUrl is rendering with '?h=master', is there any way to just get the root?10:31
cjwatsonblr: context/repository/getCodebrowseUrl10:36
cjwatsonblr: I expect context in this case is a ref ...10:37
cjwatsonso getCodebrowseUrl on a repository gives you the root, on a ref takes you straight to that ref, otherwise it ends up a bit strange10:38
blrcjwatson: awesome, that works nicely thanks10:42
wgrantcjwatson: What do you think of the {Product,Distribution}.vcs design?11:12
cjwatsonso I'd been sort of hoping that it could be avoided or made implicit somehow11:13
cjwatsonwe shouldn't be able to end up in states where the flag says git and there are only bzr branches, or vice versa11:14
cjwatsonand 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 both11:14
cjwatsonat that point it is not clear to me what the vcs enum actually governs11:14
wgrantWhat value does showing both provide?11:14
wgranteg. look at https://code.launchpad.net/launchpad11:14
wgrantIt's confusing and I can't see a case where it would ever be desirable.11:15
wgrantThe column probably just selects whether the code page shows bzr or git stuff by default.11:15
cjwatsonI 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 /target11:16
cjwatsonor, perhaps better, it should be impossible to set a default git repository for a target that doesn't have its vcs set to git11:16
cjwatsonor something like that11:16
cjwatsonwe need to think through the migration path for a project11:17
wgrantOr someone has to click the git link if they run into a git default URL on a bzr-defaulting project.11:17
cjwatsonthe git link that doesn't exist yet, but yes11:17
wgrantWell yeah, once the page is split there will presumably be a link between the two halves :)11:17
cjwatsonthis ties into my hope to be able to make the canonical url for a default repo be (target, rootsite="code")11:18
cjwatsonthis 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
wgrantIs it as messy as showing both?11:18
cjwatsonperhaps not11:19
wgrantThe URLs already vary based on whether the repo is the default or not.11:19
wgrantVarying slightly further based on whether the *VCS* is the default doesn't seem out of the question.11:19
cjwatsonthis is true11:19
cjwatsonso what's the URL for the default git repository on a bzr-defaulting project?11:19
cjwatsonI suppose we could just send you to the unique name11:19
wgrantRight, I think the web URL is just the full URL in that case.11:20
wgrantBut switching the +branches to the git view using the link at the top will also show it.11:20
cjwatsoncan you explain that last bit?11:20
cjwatsonlink at the top of where?11:20
wgrantThere's some widget on the project code index which switches between the git and bzr views, defaulting to target.vcs.11:21
wgrantIf 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
cjwatsonI'd been working on Person:+repositories; perhaps that makes sense as a view name elsewhere as well11: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
wgrantI'm not sure if +git can currently be implemented.11:23
wgrantI *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
cjwatsonThe 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 => PersonGitView11:24
cjwatsonThe 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 too11:24
cjwatsonYou could reasonably look as PersonProduct etc. as metaphorically a repository11:25
cjwatsonIn the bzr sense too11:25
cjwatsonAnd then code pages could suck a bit less11:25
cjwatsonBut I don't know if it's worthwhile11:25
wgrantI'm not quite sure.11:25
cjwatsonBecause 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 branches11:26
wgrantSo, convince me about your plan for eg. the project code index.11:26
wgrantHm, true.11:26
wgrantBut that's less interesting in the git future.11:26
cjwatsonI think that should be approximately the git view, though.11:27
cjwatsonSo, I think I'm fine with the project code index being switchable; the dual view was admittedly (in the MP description) a stopgap11:27
wgrantOh yeah, and it's a fine stopgap, because it still isn't quite clear how to do it properly.11:28
cjwatsonIt needs to be switchable on "Configure code hosting" or whatever replaces it (since +setbranch is series-specific)11:28
wgrantDo you have an idea on how to obviate Product.vcs, though?11:29
wgrantAh yeah11:29
wgrantWe discussed this on the call last week, sorry.11:29
wgrantKit's working on a Product-wide +setbranch equivalent.11:29
cjwatsonSo 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
cjwatsonIf the view switches then at least people have a clear incentive to set it to the right thing11:30
wgrantThe default git repo URL is the only serious issue I see.11:30
wgrantAnd that's only an issue during migration.11:30
cjwatsonIf you're happy with a conditional canonical URL that depends on the vcs enum, I think that satisfies my concerns.11:30
cjwatsonI just don't want to be stuck with the canonical URL being ugly forever.11:31
wgrantSo, the canonical URL itself can't be that.11:31
wgrantWe'll have to do something a bit magical.11:31
wgrantbecause eg. the API11:31
wgrantBut maybe the web canonical_url can be different.11:31
cjwatsonSo, 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
wgrantThe easiest way is a query string on the end of +branches.11:34
cjwatsonOr perhaps Product:+branches and Product:+git, and the default view depends on vcs?11:34
wgrantIt's awkward, but currently we have no way to configure default view name very eaisly.11:34
wgrantWe could do it, though.11:35
wgrantIt would require a small amount of infrastructure work.11:35
wgrantAuto-importer is difficult due to various gardening that can be required.11:36
wgranteg. 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
cjwatsonI 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
cjwatsonRight, my experiences with converting stuff to git have all employed various bits of manual gardening.11:37
cjwatsonMostly 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
cjwatsonSo 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
wgrantI think you click the code settings link, where you can get instructions on pushing to the other VCS.11:40
wgrantOnce a repo exists for the other VCS, the default code listing grows a switcher.11:40
cjwatsonYeah, 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
cjwatsonYou could do that by deleting all the bzr branches.11:52
cjwatsonOr something.11:52
cjwatsonExcept you probably wanted to keep MP history.11:52
cjwatson(I occasionally refer to years-old MP history in Launchpad ...)11:53
wgrantThat's why we did git MPs a bit more sensibly, indeed.11:55
cjwatson"meh" seems like a reasonable disposal.11:58
wgrantI'm just thinking about where to put the default widget.11:58
wgrantI 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
wgrantSimilar to the team ownership change view.11:59
cjwatsonShouldn't it be on Product:+setbranch?12:01
wgrantYes, I was just thinking of the most obtuse and Launchpaddy place to put it.12:01
wgrantProduct:+setbranch or equivalent is indeed where it should go in the real world.12:02
=== mwhudson_ is now known as mwhudson
bigjoolswgrant: what's the default size limit for P3As nowadays?22:13
cjwatsonbigjools: 2 GiB for both public and private22:14
bigjoolscjwatson: can that be upped for P3As?22:15
bigjoolsand hi :)22:15
cjwatsonbigjools: wgrant generally processes tickets to raise limits on request pretty quickly22:18
bigjoolscjwatson: the guys I work with say that it's annoying to have to do that and want to up the default22:18
cjwatsonI'm sure it's possible, I think we should look at some stats for archive usage plotted against whether they're public or private, though22:19
cjwatsonthere might be a few possible fixes to that annoyance22:21
bigjoolsthat would be nice :)22:22

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!