bigjoolswgrant: do recipes work with the new git repos?00:03
wgrantbigjools: Not yet. Recipes are implemented by a bzr plugin, so we have to pretty much rewrite them.00:03
bigjoolsdarn, shame00:03
bigjoolsrecipes are possibly the coolest thing in LP00:03
wgrantBut it's fairly high on the priority list, as they're sort of useful.00:03
bigjoolsok cheers, good luck :)00:04
bigjoolswgrant: is it possible to mirror a remote private git repo into a private bzr one?00:43
wgrantbigjools: 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
* mwhudson twitches00:45
wgrantmwhudson: Hm?00:46
mwhudsoni remember worrying about all these things, private code imports, recipes that consume private branches00:46
mwhudsonis there anything at all like bzr builddeb already?00:49
mwhudsonmaybe that's not the thing i mean00:49
mwhudsonthe thing that interprets recipes00:49
wgrantbzr builder? Nothing quite the same.00:52
mwhudsonso what i want to do is this: i want to build go tip from git into a ppa00:52
mwhudsonthe part that i can't remember at all about how this works from bzr recipes is the orig handling00:53
wgrantbzr-builddeb requires there to be pristine-tar metadata in one of the branches.00:53
mwhudsonthe diff from the most recent 1.4 release is (a) enormous and (b) can't be represented as a textual patch anyway00:53
mwhudsonso the solutions seem to be build a native package or make orig tarballs myself00:54
mwhudsoni can make a new orig every time there is an unrepresentable change, or for every build00:54
mwhudsonthe latter sounds more automatable00:54
mwhudson(the package version numbers will be hilarious i expect)00:55
mwhudsonwgrant: so this situation wouldn't work very well even if go upstream was bzr hosted on lp?00:55
wgrantmwhudson: You'd just use a native package in that case, I expect.00:55
mwhudsonnative packages are indicated by not having a - in the version, right?00:58
wgrantA non-native package must have a -00:58
wgrantNatives shouldn't, but it works.00:58
mwhudsonnot having revnos sure makes for lovely lovely package versions01:45
wgrant+git20150512+deadbeef ftw01:47
mwhudson2:1.5~pre-snap2~upstream201505131327git350fd548b331ubuntu1 <= 2:1.5~pre-snap1-0ubuntu1~7.gbpfbb49901:51
* mwhudson blinks01:51
mwhudsonapparently i don't know the rules quite by heart yet01:51
mwhudsonoh wait01:53
=== danilos` is now known as danilos
blrwgrant: 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
blrproductseries just uses ILink, in a well.. more obvious manner.03:50
wgrantblr: There is some magic in the menus that even I will have to read the code to understand, but let me see.03:50
blrthe MenuAPI implementation has some concepts I'm not familiar with - facets?03:51
blrah okay.03:52
wgrantEach facet can have a different menu, which used to define what appeared in various slots on the page automatically.03:52
wgrantThat's used a lot less nowadays, as the templates position the links more explicitly.03:52
wgrantMenuAPI is a TALES traverser thingy, so it does some weird stuff to interpret paths.03:53
wgrantTHe main weirdness being the colon-separated facet name.03:54
wgrantBut 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
wgrantIt's the IMenu that has the Links.03:55
wgrantYou can see the context handling in lp.services.webapp.menu.MenuBase.03:56
wgrantThe initLink method, specifically.03:56
wgrantSo 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
blrok, trying to digest all that :)03:59
wgrantBasically: ignore MenuAPI, find the relevant I*Menu adapter and look at that instead.03:59
blrthanks, that's very helpful.04:01
wgrantblr: Will you have time to fix up product-vcs-default-attrib today?04:11
wgrantIt's very close and would be handy to have.04:11
blryep, will need to have a look at examples of permissions for other exports - haven't quite got to it yet.04:11
wgrantblr: It's actually just normal Zope permissions, so a one-liner in configure.zcml for each.04:16
blrah the configure.zcml in registry, not browser.04:24
wgrantThe only part of browser that the API uses is the URL traversal bits.04:25
blrwgrant: done04:29
wgrantblr: The permission tests don't need fixing?04:29
wgrantThose are fortunately quick to run.04:29
blrah right.04:29
blrI did add vcs earlier for View, but not Edit. thanks04:30
wgrantblr: One last thing: your interface attributes end with triple quotes, but start with singles.04:42
blrerr so they do.04:46
blrconsistently wrong, the best kind of wrong.04:47
blrwgrant: hmm where are the permissions tests for distribution?04:50
wgrantblr: There probably aren't any. They were only added for Product as part of the private projects project.04:50
blrah right04:51
blrwgrant: ok, tests happy.05:03
wgrantblr: Yay05:03
wgrantblr: r=me05:06
wgrantblr: buildbot had failed, but you should be able to successfully land it now.05:18
blrwgrant: building now I think05:21
blrhas that timeout cropped up before?05:21
wgrantOn very rare occasion.05:21
wgrantblr: It's building because I forced it.05:22
wgrantblr: Your change hasn't landed.05:22
blrhuh odd, no feedback from lp-land that it failed.05:23
wgrantlp-land just sends an email, so it can't tell whether it succeeded.05:23
wgrantPQM is meant to email you when it fails, but that's sort of broken.05:23
wgrantAfter an upgrade recently.05:23
StevenKI do not miss those horrid PQM failure e-mails.05:24
wgrantYou miss them when they mean it silently fails instead :P05:24
blrah I see05:24
wgrantBut soon PQM will die.05:24
lifelessthats what deadmanswitch is for :)05:25
StevenKwgrant: Because switching to git?05:25
wgrantStevenK: Git and Tarmac, indeed.05:25
blrwgrant: hmm still not seeing anything in the pqm queue05:26
blrnvm there now05:26
blrwgrant: hmm I didn't run the doctests :/06:41
wgrantblr: That's what buildbot's for.06:41
wgrantThey were easy fixes.06:41
blrthanks for that06:42
=== anthonyf is now known as Guest56189
=== anthonyf is now known as Guest84788
=== Spads_ is now known as Spads
blrcjwatson: wgrant: any thoughts on the distinction between project and project code settings? Ideally should they be accessible from the same view?22:21
blrmaybe I should do a mockup22:22
cjwatsonblr: 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* world23:12
cjwatson(Or at least something that *feels* like a tabbed settings page, e.g. github's repository settings)23:14
blrcjwatson: oh certainly not suggesting one massive view, just a container with a sensible menu encapsulating all those small views23:23
blrcjwatson: if we could start in that _direction_ wrt to git, I think that would be positibve.23:23
blrjust not certain how we can do that without changing eveything and the kitchen sink.23:24
blrwill think about it a bit more.23:24
cjwatsonI 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 point23:32
cjwatsonblr: 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 it23:34
cjwatsonblr: 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 versa23:35
cjwatsonblr: perhaps we can just default it on the first push of a repository/branch to a project that had neither23:36
cjwatsonthat also suggests that the "your project has no code" case in the +branches view should have instructions for both23: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
blrcjwatson: sorry just trying to understand the context, Project Information on the main project view?23:40
blrcjwatson: that could work, yep.23:41
cjwatsonof course it still has to live in a view somewhere, we try not to be totally reliant on ajax23:41
cjwatsonso may not solve your dilemma per se23:41
blrwould certainly be nice to set the default on first push23:41
cjwatsonI suspect the place to do that would be BranchNamespace.createBranch / GitNamespace.createRepository23:42
cjwatsonyou might want to think about this before pushing the model code though23:43
cjwatsonoh, possibly too late23:43
blroh, did william implement that?23:43
cjwatsonwell, no I meant the enum23:44
cjwatsonI guess this is a nullable column23:44
blrit is23:44
blrnot following, is the enum problematic?23:44
cjwatsonso null can be not-specified-yet, you don't need a separate enum value for that23:44
cjwatsonwhich was where my train of thought was going23:45
cjwatsonok, all good23:45
blrI wonder how we can provide feedback to the user that we've set the project default vcs for them23:45
cjwatsonI don't know that we need to23:45
blrperhaps just having it visible under project information is sufficient23:45
cjwatsonit can just show up23:46
cjwatsonalternatively to default-on-first-push, we have to think of all the existing rows *anyway*23:46
blrShould we however provide feedback if they push the converse repo type?23:46
blrafter a default has been set23:47
cjwatsonso 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 exist23:47
cjwatsonthat way we don't have to go through filling in values in existing rows, which is usually a good thing to avoid if we can23:47
cjwatsonand in this case it's convenient because we don't have to actually write our magic default to the db23:48
cjwatsondoes that make sense to you?23:48
cjwatsonwe 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 option23:49
blrI think so - project and distribution would need a new property to return the vcs type for the first pushed repo?23:49
cjwatsondoesn't even need that23:49
cjwatsonnot IBranchCollection(project).getBranches().is_empty()23:50
cjwatsonsimilarly for IGitCollection23:50
blrah right23:50
blrthat exists already?23:51
cjwatsonwe don't need to distinguish the first one23:51
cjwatsonit does23:51
cjwatson(it's getRepositories in the git case)23:51
cjwatsonblr: in fact, just not I{Branch,Git}Collection(target).is_empty() - they have helper methods for that23:52
blrah handy23:52
cjwatsonthat will compile down to something like SELECT 1 FROM GitRepository WHERE GitRepository.project = project_id23:54
cjwatsonbut with the adapters you don't have to worry about cases like Branch having distroseries rather than distribution23:55
cjwatsonblr: 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 case23:56
blrok, will bear that in mind.23:58
cjwatsonI 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 later23:59
blroh nice23:59

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