| bigjools | wgrant: do recipes work with the new git repos? | 00:03 |
|---|---|---|
| wgrant | bigjools: Not yet. Recipes are implemented by a bzr plugin, so we have to pretty much rewrite them. | 00:03 |
| bigjools | darn, shame | 00:03 |
| bigjools | recipes are possibly the coolest thing in LP | 00:03 |
| wgrant | But it's fairly high on the priority list, as they're sort of useful. | 00:03 |
| bigjools | ok cheers, good luck :) | 00:04 |
| bigjools | wgrant: is it possible to mirror a remote private git repo into a private bzr one? | 00:43 |
| wgrant | bigjools: No, but we will probably support that for git. | 00:43 |
| wgrant | (and remember that bzr recipes don't work for private bzr branches today) | 00:43 |
| bigjools | bugger | 00:43 |
| bigjools | thanks | 00:44 |
| * mwhudson twitches | 00:45 | |
| wgrant | mwhudson: Hm? | 00:46 |
| mwhudson | i remember worrying about all these things, private code imports, recipes that consume private branches | 00:46 |
| mwhudson | is there anything at all like bzr builddeb already? | 00:49 |
| mwhudson | maybe that's not the thing i mean | 00:49 |
| mwhudson | the thing that interprets recipes | 00:49 |
| wgrant | bzr builder? Nothing quite the same. | 00:52 |
| mwhudson | so what i want to do is this: i want to build go tip from git into a ppa | 00:52 |
| mwhudson | the part that i can't remember at all about how this works from bzr recipes is the orig handling | 00:53 |
| wgrant | bzr-builddeb requires there to be pristine-tar metadata in one of the branches. | 00:53 |
| mwhudson | the diff from the most recent 1.4 release is (a) enormous and (b) can't be represented as a textual patch anyway | 00:53 |
| mwhudson | so the solutions seem to be build a native package or make orig tarballs myself | 00:54 |
| mwhudson | i can make a new orig every time there is an unrepresentable change, or for every build | 00:54 |
| mwhudson | the latter sounds more automatable | 00:54 |
| mwhudson | (the package version numbers will be hilarious i expect) | 00:55 |
| mwhudson | wgrant: so this situation wouldn't work very well even if go upstream was bzr hosted on lp? | 00:55 |
| wgrant | mwhudson: You'd just use a native package in that case, I expect. | 00:55 |
| mwhudson | ok | 00:57 |
| mwhudson | native packages are indicated by not having a - in the version, right? | 00:58 |
| wgrant | Ish. | 00:58 |
| wgrant | A non-native package must have a - | 00:58 |
| wgrant | Natives shouldn't, but it works. | 00:58 |
| mwhudson | ok | 00:59 |
| mwhudson | not having revnos sure makes for lovely lovely package versions | 01:45 |
| wgrant | +git20150512+deadbeef ftw | 01:47 |
| mwhudson | yeah | 01:50 |
| mwhudson | 2:1.5~pre-snap2~upstream201505131327git350fd548b331ubuntu1 <= 2:1.5~pre-snap1-0ubuntu1~7.gbpfbb499 | 01:51 |
| * mwhudson blinks | 01:51 | |
| mwhudson | apparently i don't know the rules quite by heart yet | 01:51 |
| mwhudson | oh wait | 01:53 |
| === danilos` is now known as danilos | ||
| blr | wgrant: would appreciate some clarification around the series_menu - I see that it takes a series/development_focus, but it isn't clear to me how the link target is set. | 03:49 |
| blr | productseries just uses ILink, in a well.. more obvious manner. | 03:50 |
| wgrant | blr: There is some magic in the menus that even I will have to read the code to understand, but let me see. | 03:50 |
| blr | the MenuAPI implementation has some concepts I'm not familiar with - facets? | 03:51 |
| wgrant | bugs/code/translations/etc. | 03:52 |
| blr | ah okay. | 03:52 |
| wgrant | Each facet can have a different menu, which used to define what appeared in various slots on the page automatically. | 03:52 |
| wgrant | That's used a lot less nowadays, as the templates position the links more explicitly. | 03:52 |
| wgrant | MenuAPI is a TALES traverser thingy, so it does some weird stuff to interpret paths. | 03:53 |
| wgrant | THe main weirdness being the colon-separated facet name. | 03:54 |
| wgrant | But MenuAPI basically just finds the relevant IMenu by looking for an IApplicationMenu or INavigationMenu adapter for the context object and the given facet. | 03:55 |
| wgrant | It's the IMenu that has the Links. | 03:55 |
| wgrant | You can see the context handling in lp.services.webapp.menu.MenuBase. | 03:56 |
| wgrant | The initLink method, specifically. | 03:56 |
| wgrant | So the MenuAPI TALES adapter is instantiated from your context/menu:blahblah. It uses a Zope adapter to get the relevant ApplicationMenu or NavigationMenu subclass, which constructs the Links. | 03:57 |
| blr | ok, trying to digest all that :) | 03:59 |
| wgrant | Basically: ignore MenuAPI, find the relevant I*Menu adapter and look at that instead. | 03:59 |
| blr | thanks, that's very helpful. | 04:01 |
| wgrant | blr: Will you have time to fix up product-vcs-default-attrib today? | 04:11 |
| wgrant | It's very close and would be handy to have. | 04:11 |
| blr | yep, will need to have a look at examples of permissions for other exports - haven't quite got to it yet. | 04:11 |
| wgrant | blr: It's actually just normal Zope permissions, so a one-liner in configure.zcml for each. | 04:16 |
| blr | ah the configure.zcml in registry, not browser. | 04:24 |
| wgrant | Yup | 04:25 |
| wgrant | The only part of browser that the API uses is the URL traversal bits. | 04:25 |
| blr | wgrant: done | 04:29 |
| wgrant | blr: The permission tests don't need fixing? | 04:29 |
| wgrant | Those are fortunately quick to run. | 04:29 |
| blr | ah right. | 04:29 |
| blr | I did add vcs earlier for View, but not Edit. thanks | 04:30 |
| wgrant | blr: One last thing: your interface attributes end with triple quotes, but start with singles. | 04:42 |
| blr | err so they do. | 04:46 |
| blr | consistently wrong, the best kind of wrong. | 04:47 |
| blr | wgrant: hmm where are the permissions tests for distribution? | 04:50 |
| wgrant | blr: There probably aren't any. They were only added for Product as part of the private projects project. | 04:50 |
| blr | ah right | 04:51 |
| blr | wgrant: ok, tests happy. | 05:03 |
| wgrant | blr: Yay | 05:03 |
| wgrant | blr: r=me | 05:06 |
| wgrant | Thanks. | 05:06 |
| blr | cheers | 05:09 |
| wgrant | blr: buildbot had failed, but you should be able to successfully land it now. | 05:18 |
| blr | wgrant: building now I think | 05:21 |
| blr | has that timeout cropped up before? | 05:21 |
| wgrant | On very rare occasion. | 05:21 |
| wgrant | blr: It's building because I forced it. | 05:22 |
| wgrant | blr: Your change hasn't landed. | 05:22 |
| blr | huh odd, no feedback from lp-land that it failed. | 05:23 |
| wgrant | lp-land just sends an email, so it can't tell whether it succeeded. | 05:23 |
| wgrant | PQM is meant to email you when it fails, but that's sort of broken. | 05:23 |
| wgrant | After an upgrade recently. | 05:23 |
| StevenK | I do not miss those horrid PQM failure e-mails. | 05:24 |
| wgrant | You miss them when they mean it silently fails instead :P | 05:24 |
| blr | ah I see | 05:24 |
| wgrant | But soon PQM will die. | 05:24 |
| lifeless | thats what deadmanswitch is for :) | 05:25 |
| StevenK | wgrant: Because switching to git? | 05:25 |
| wgrant | StevenK: Git and Tarmac, indeed. | 05:25 |
| wgrant | https://git.launchpad.net/launchpad/ | 05:25 |
| blr | wgrant: hmm still not seeing anything in the pqm queue | 05:26 |
| blr | nvm there now | 05:26 |
| blr | wgrant: hmm I didn't run the doctests :/ | 06:41 |
| wgrant | blr: That's what buildbot's for. | 06:41 |
| wgrant | They were easy fixes. | 06:41 |
| blr | thanks for that | 06:42 |
| === anthonyf is now known as Guest56189 | ||
| === anthonyf is now known as Guest84788 | ||
| === Spads_ is now known as Spads | ||
| blr | cjwatson: wgrant: any thoughts on the distinction between project and project code settings? Ideally should they be accessible from the same view? | 22:21 |
| blr | s/code/facet/ | 22:22 |
| blr | maybe I should do a mockup | 22:22 |
| cjwatson | blr: On the one hand, I dislike the pattern of lots of little tiny views where you have to guess which one the setting you care about is in. On the other, a gigantic view with everything isn't great either. I think ideally I'd like a tabbed settings page, but we should probably try to implement what we need for git without refactoring the *whole* world | 23:12 |
| cjwatson | (Or at least something that *feels* like a tabbed settings page, e.g. github's repository settings) | 23:14 |
| blr | cjwatson: oh certainly not suggesting one massive view, just a container with a sensible menu encapsulating all those small views | 23:23 |
| blr | cjwatson: if we could start in that _direction_ wrt to git, I think that would be positibve. | 23:23 |
| blr | just not certain how we can do that without changing eveything and the kitchen sink. | 23:24 |
| blr | will think about it a bit more. | 23:24 |
| cjwatson | I thought I remembered there being something like this once, maybe on Person, but I can't find it now - maybe it went away at some point | 23:32 |
| cjwatson | blr: I wonder if the VCS should (also) be an AJAX drop-down under "project information", which already has a little bit of code stuff in it | 23:34 |
| cjwatson | blr: Did you decide what to do about new projects? I mean, ideally if somebody creates a project and pushes a git repository to it, they shouldn't also have to go and select that their project uses git when it has no bzr stuff; ditto vice versa | 23:35 |
| cjwatson | blr: perhaps we can just default it on the first push of a repository/branch to a project that had neither | 23:36 |
| cjwatson | ? | 23:36 |
| cjwatson | that also suggests that the "your project has no code" case in the +branches view should have instructions for both | 23:36 |
| cjwatson | (which is probably easier if it's the same view for both cases with a big conditional in the template, as we discussed) | 23:37 |
| blr | cjwatson: sorry just trying to understand the context, Project Information on the main project view? | 23:40 |
| cjwatson | yeah | 23:40 |
| blr | cjwatson: that could work, yep. | 23:41 |
| cjwatson | of course it still has to live in a view somewhere, we try not to be totally reliant on ajax | 23:41 |
| cjwatson | so may not solve your dilemma per se | 23:41 |
| blr | would certainly be nice to set the default on first push | 23:41 |
| cjwatson | I suspect the place to do that would be BranchNamespace.createBranch / GitNamespace.createRepository | 23:42 |
| cjwatson | you might want to think about this before pushing the model code though | 23:43 |
| cjwatson | oh, possibly too late | 23:43 |
| blr | oh, did william implement that? | 23:43 |
| cjwatson | well, no I meant the enum | 23:44 |
| cjwatson | hmm | 23:44 |
| cjwatson | I guess this is a nullable column | 23:44 |
| blr | it is | 23:44 |
| blr | not following, is the enum problematic? | 23:44 |
| cjwatson | so null can be not-specified-yet, you don't need a separate enum value for that | 23:44 |
| blr | right | 23:45 |
| cjwatson | which was where my train of thought was going | 23:45 |
| cjwatson | ok, all good | 23:45 |
| blr | I wonder how we can provide feedback to the user that we've set the project default vcs for them | 23:45 |
| cjwatson | I don't know that we need to | 23:45 |
| blr | perhaps just having it visible under project information is sufficient | 23:45 |
| blr | yeah | 23:46 |
| cjwatson | it can just show up | 23:46 |
| cjwatson | alternatively to default-on-first-push, we have to think of all the existing rows *anyway* | 23:46 |
| blr | Should we however provide feedback if they push the converse repo type? | 23:46 |
| blr | after a default has been set | 23:47 |
| cjwatson | so perhaps {Product,Distribution}.vcs is reserved for explicitly specified, and otherwise the view has corresponding properties which will calculate a value on the fly based on whether any bzr or git things exist | 23:47 |
| cjwatson | that way we don't have to go through filling in values in existing rows, which is usually a good thing to avoid if we can | 23:47 |
| cjwatson | and in this case it's convenient because we don't have to actually write our magic default to the db | 23:48 |
| cjwatson | does that make sense to you? | 23:48 |
| cjwatson | we can't provide feedback to the actual VCS client, at least not with git. The best we can do, I think, would be for the choice widget (of whatever kind) to appear in the relevant views once there is more than one option | 23:49 |
| blr | I think so - project and distribution would need a new property to return the vcs type for the first pushed repo? | 23:49 |
| cjwatson | doesn't even need that | 23:49 |
| cjwatson | not IBranchCollection(project).getBranches().is_empty() | 23:50 |
| cjwatson | similarly for IGitCollection | 23:50 |
| blr | ah right | 23:50 |
| blr | that exists already? | 23:51 |
| cjwatson | we don't need to distinguish the first one | 23:51 |
| cjwatson | it does | 23:51 |
| blr | great | 23:51 |
| cjwatson | (it's getRepositories in the git case) | 23:51 |
| cjwatson | blr: in fact, just not I{Branch,Git}Collection(target).is_empty() - they have helper methods for that | 23:52 |
| blr | ah handy | 23:52 |
| cjwatson | that will compile down to something like SELECT 1 FROM GitRepository WHERE GitRepository.project = project_id | 23:54 |
| cjwatson | but with the adapters you don't have to worry about cases like Branch having distroseries rather than distribution | 23:55 |
| cjwatson | blr: if it's in a view, you should possibly do .visibleByUser(self.user).is_empty() to avoid leaking information about a private branch/repository on the target if there's nothing else, although that's certainly a corner case | 23:56 |
| blr | ok, will bear that in mind. | 23:58 |
| cjwatson | I got the pending diff indicator fixed today (well, in the review queue) - William was right that it was one of those things that was much more complicated in Branch, though some of that complexity is due to imports so may sneak back in later | 23:59 |
| blr | oh nice | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!