| === skaet_ is now known as skaet | ||
| StevenK | wgrant: I thought bug supervisor turned up on IProduct:+edit ? | 02:16 |
|---|---|---|
| StevenK | Ah | 02:17 |
| StevenK | Configure bug tracker | 02:17 |
| StevenK | IE, UI trainwreck | 02:17 |
| cjwatson | NCommander: but the trend in Launchpad itself is to start trying to split things out into microservices where possible, rather than embedding them all in a single giant webapp | 03:11 |
| cjwatson | (and for those to be affiliated to Launchpad in the necessary ways) | 03:12 |
| NCommander | cjwatson: er, wasn't one of the motivations of writing launchpad in the first place to prevent having a million microapps (i.e., bugzilla+dak) | 03:52 |
| NCommander | I don't personally care one way or another, but having centralized one-stop place for packages/images/builds/archives makes a lot of sense to me | 03:53 |
| lifeless | what did I miss ? | 03:55 |
| wgrant | 13:10:00 -!- lifeless [~robertc@125.7.18.100] has quit [Ping timeout: 252 seconds] | 03:57 |
| wgrant | 13:11:24 < cjwatson> NCommander: but the trend in Launchpad itself is to start trying to split things out into microservices where possible, rather than embedding them all in a single giant webapp | 03:57 |
| wgrant | 13:12:18 < cjwatson> (and for those to be affiliated to Launchpad in the necessary ways) | 03:57 |
| wgrant | 13:23:44 -!- lifeless [~robertc@125.7.18.100] has joined #launchpad-dev | 03:57 |
| lifeless | wgrant: thanks | 04:02 |
| lifeless | NCommander: separate codebase != separate UI || siloed behaviour | 04:03 |
| lifeless | NCommander: LP set out to create an integrated set of behaviours | 04:03 |
| NCommander | Which it succeeded at | 04:03 |
| lifeless | NCommander: separate services provide natural scaling and HA boundaries, assuming the services are well defined | 04:03 |
| lifeless | NCommander: bugzilla vs dak is not the same as microservices making up the whole product. | 04:03 |
| NCommander | Fair enough | 04:04 |
| lifeless | NCommander: for an example of another microservice approach, look at s3 + ec2 + cloudscaling etc | 04:04 |
| NCommander | THat being said, I stilla rgue that ISO mastering would fall under Launchpad; image builds are already dependent on the LP service and this provides ways for flavors to control their own respins/etc. | 04:04 |
| lifeless | consistent feel, integrated management consoles and so on, but very focused facilities that are orthogonal | 04:04 |
| lifeless | I think iso mastering should move onto the regular buildds. | 04:05 |
| cjwatson | No. | 04:05 |
| cjwatson | The live filesystem component should move onto the regular buildds. | 04:05 |
| cjwatson | It doesn't make sense for the whole of ISO mastering to do so. | 04:05 |
| lifeless | cjwatson: whats the difference there, and why? | 04:06 |
| cjwatson | The line I'm drawing is the part that can be run architecture-independently, and that benefits from being on a machine with a full local mirror etc. | 04:06 |
| cjwatson | The live filesystem component is the part that must be run on a system of the target architecture. | 04:07 |
| cjwatson | And that certainly belongs on the buildds. | 04:07 |
| lifeless | cjwatson: you need to run the arch indep part one per arch though, right ? | 04:07 |
| cjwatson | Yes, but there are useful economies of scale. | 04:08 |
| lifeless | cjwatson: from bandwidth access to the mirror ? | 04:08 |
| cjwatson | For example. | 04:08 |
| cjwatson | More like same filesystem, since some ISOs use hardlink trees. | 04:09 |
| lifeless | cjwatson: ah, interesting. I haven't climbed into that code. | 04:09 |
| lifeless | cjwatson: thanks. | 04:09 |
| cjwatson | Maybe the importance of this will change as more things move to live CDs, but I don't want that to entirely dominate the design. | 04:09 |
| lifeless | cjwatson: do you reuse the hardlink trees for things on different days ? | 04:10 |
| cjwatson | I'm not sure I understand the question. | 04:10 |
| lifeless | IIUC you build N > 1 ISOs using hardlink trees for common content ? | 04:10 |
| cjwatson | We reuse the mirror. But hardlink trees are cheap to build so we just do that afresh for each image build. | 04:11 |
| lifeless | When you build the same targets the next day, do you build fresh hardlink trees, or evolve the prior one ? | 04:11 |
| cjwatson | The former, then. | 04:11 |
| lifeless | anyhow. I'm actually arguing for horizontal scalability and automated from-scratch provisioning of the build system, rather than 'use the buildds' per se. | 04:12 |
| lifeless | closer to stateless etc etc etc | 04:12 |
| cjwatson | In terms of scaling, building live filesystems massively dominates; we're a long way off the point where the central system has any trouble keeping up with the extra bits and pieces of ISO mastering it does at the rate that separate builders can deliver live filesystems. | 04:13 |
| cjwatson | Obviously that changes at some point horizontally but it's quite some distance away. | 04:14 |
| lifeless | kk | 04:14 |
| NCommander | I was more considering the possibility of removing squashfs builds are a seperate step and merely master an entire ISO in a single go on a buildd | 04:16 |
| NCommander | */2 cents* | 04:16 |
| cjwatson | I know you were, but I don't think that's desirable at this point. | 04:16 |
| lifeless | cjwatson: what downside do you see? | 04:17 |
| cjwatson | See above. | 04:17 |
| cjwatson | In any case I don't think this should even need to be considered for livefs-in-LP work. | 04:18 |
| cjwatson | As far as that's concerned, the build job should be calling BuildLiveCD or some equivalent. | 04:18 |
| lifeless | cjwatson: above you discussed efficiencies, but unless you hit a bottleneck that doesn't translate to a specific or even necessary downside. | 04:18 |
| cjwatson | What it outputs is the business of the job and the consumer, not of LP. | 04:18 |
| cjwatson | lifeless: The downside is that we should be moving to livefs-in-LP without having to refactor the entire cdimage build system along the way. | 04:18 |
| cjwatson | And it's actually really quite a considerable amount of code to move around. | 04:19 |
| lifeless | cjwatson: so, two separate [potential] migrations, rather than one that moves + rearranges? If so I concur. | 04:19 |
| * NCommander agrees with that, as moving the squashfs building is considerably less diserpative ATM | 04:20 | |
| NCommander | and as I said in the beginning, long-term [potential] goal | 04:20 |
| lifeless | cjwatson: also, wth are you awake? | 04:21 |
| cjwatson | *You're* asking me that? :-) | 04:22 |
| * NCommander is dealing with a rather mysterious issue that the buildd complains UNKNOWNSUM | 04:22 | |
| NCommander | WOrks with a precise chroot sha1sum, breaks with a lucid one | 04:22 |
| cjwatson | (Random insomnia) | 04:22 |
| NCommander | grep "No URL" -r * | 04:23 |
| NCommander | er | 04:23 |
| NCommander | oh | 04:24 |
| NCommander | the only reason my trigger code worked was the precise chroot was cached in the filecache for the buildd | 04:24 |
| NCommander | cjwatson: do we have any images that still require livecd.sh? (I have a handler that calls that, live-build, and ubuntu-defaults-image) | 04:28 |
| === jtv1 is now known as jtv | ||
| StevenK | lifeless: I see your iwl is as stable as ever. | 04:50 |
| lifeless | StevenK: I'm on ethernet | 04:53 |
| lifeless | StevenK: Hotel ethernet. | 04:53 |
| StevenK | That's as stable as iwl | 04:53 |
| StevenK | wgrant: What sort of cruft is sinzui talking about it bug 1036189? | 04:54 |
| wgrant | StevenK: eg. if I set my project to only use Proprietary bugs and branches, and I change all the Private and Private Security artifacts to Proprietary, there's no need to keep Private and Private Security around | 05:02 |
| wgrant | The APs and APGs can be deleted. | 05:02 |
| StevenK | That sounds more like a job Job rather than a garbo | 05:04 |
| wgrant | StevenK: We'd have to trigger it on every transitionToInformationType | 05:05 |
| wgrant | So no | 05:05 |
| StevenK | Right | 05:06 |
| StevenK | wgrant: So if it's a garbo what do I search on? | 05:06 |
| wgrant | StevenK: Hm? | 05:06 |
| StevenK | wgrant: So if I want to pick products that need AP{,G}s deleted, how do I do it? | 05:08 |
| wgrant | StevenK: Find APs that are forbidden, and then find the subset that are unused | 05:09 |
| StevenK | wgrant: Right, so find APs that do not make sense given what the product is set up for. | 05:10 |
| wgrant | StevenK: Right | 05:11 |
| lifeless | wgrant: StevenK: and you won't let folk file bugs that noone-can-see? | 05:25 |
| wgrant | lifeless: We will, but the project owner would have to explicitly revoke the permission | 05:26 |
| wgrant | The default is always that the owner can see each type | 05:26 |
| lifeless | note too the race conditions at the time of revoking | 05:26 |
| wgrant | (and the owner gets a warning on +sharing if they do that) | 05:26 |
| wgrant | Oh? | 05:26 |
| lifeless | new bug of the type the permission is being revoked for | 05:27 |
| lifeless | owner may think there are none, but \/ races | 05:27 |
| wgrant | We don't prevent filing a bug that nobody can see | 05:27 |
| lifeless | sure | 05:27 |
| wgrant | If the project owner wants to do stupid things, we let them do stupid things, but they can easily recover | 05:27 |
| lifeless | saying that doesn't mean humans won't assume ... | 05:27 |
| lifeless | same race exists for setting the project to only proprietary, if you do stuff inline, of course. | 05:28 |
| wgrant | Changing the allowed types (eg. setting the sharing policy to Proprietary only) doesn't affect existing artifacts. | 05:29 |
| wgrant | But it does stop you from making new ones of the illegal types | 05:29 |
| lifeless | cool | 05:29 |
| * StevenK tries to cook a query | 05:29 | |
| StevenK | wgrant: So I'm looking for projects where bug_sharing_policy or branch_sharing_policy isn't PUBLIC and they have APs for PRIVATESECURITY and USERDATA. I'm guessing it's a little more complicated, but it seems those are the only policies that are excluded. | 05:40 |
| StevenK | wgrant: Right? | 05:52 |
| wgrant | StevenK: If you look near the top of lib/lp/code/model/branchnamespace.py you'll need the dict of allowed types | 05:53 |
| wgrant | s/need/see/ | 05:53 |
| StevenK | Does that also follow through for bugs? | 05:54 |
| wgrant | There's a similar one for bugs in a branch that I haven't landed yet. It's basically identical. | 05:54 |
| wgrant | wallyworld_: In the sharing_policy = PUBLIC garbo branch, would it be better to check that the project is set to public already (ie. not private_bugs and not exists branchvisibilitypolicy) rather than checking for the lack of a commercial subscription? If we're landing this now, it'll also mean that commercial project setup changes now. | 05:56 |
| wgrant | I'd suggest we defer landing it until new projects are being set up using sharing_policy | 05:56 |
| wallyworld_ | wgrant: i'm not sure why commercial project setup would change? the job only updates non commercial projects | 05:57 |
| wallyworld_ | we discussed the need to do this in the call - we wanted to ensure that the many projects were migrated for people before beta | 05:58 |
| wgrant | wallyworld_: If a project happens to accidentally be created non-commercial and only made commercial later, the old commercial setup procedure will appear to work, but do nothing | 05:58 |
| wgrant | private_bugs will be set, but bugs will be public | 05:59 |
| wallyworld_ | sure, but if a project is made commercial, it would need to have it's sharing policy set at the same time | 05:59 |
| wgrant | Right, so we'd need to advise the people who do commercial setup (probably just czajkowski and us nowadays?) to unset sharing policies | 06:00 |
| wgrant | That may be acceptable, but we need to say that first :) | 06:00 |
| wallyworld_ | yes, curtis is all over it | 06:00 |
| wgrant | Sounds good, then. But we do need to check that the project is actually configured to be public, not just that it has no commercial subscription. | 06:01 |
| wgrant | Or we may be in for a nasty surprise if anything's misconfigured. | 06:01 |
| wgrant | Since commercial admins can set private_bugs and BVPs without a commercial sub | 06:01 |
| wgrant | So who knows what madness lies out there today... | 06:01 |
| wallyworld_ | by "public" you mean check the licence? | 06:01 |
| czajkowski | wgrant: morning | 06:01 |
| spm | heya czajkowski | 06:02 |
| wgrant | wallyworld_: Needs to have private_bugs = false, and there must be no BranchVisibilityPolicies at all | 06:02 |
| wgrant | czajkowski: Hi | 06:02 |
| spm | gentles all; is it still possible for people and/or teams to have name aliases? I can't seem to find any such UI modification for same any more? possibly it was only for projects?? | 06:02 |
| wallyworld_ | wgrant: so theoretically only commercial projects can have private_bugs = true right? | 06:02 |
| wgrant | spm: People/teams never could | 06:02 |
| wgrant | spm: Projects can | 06:02 |
| czajkowski | I believe myself and mrevell will be talking to people who have commercial projects next weeek and going over the new setup with them once myself and mrevell know more and know fully about the set up | 06:02 |
| spm | wgrant: right. ta. I misrecall. thanks mon | 06:03 |
| wgrant | wallyworld_: Sort of | 06:03 |
| wgrant | wallyworld_: "theoretically" in that "in an ideal world, there's no reason for it to be any other way" | 06:03 |
| wgrant | wallyworld_: But it's by no means enforced or even suggested anywhere in LP that that should be the case | 06:03 |
| wgrant | As a commercial admin, I can go over to Random Open Source Project and set private_bugs and make all branches private only to canonical. | 06:03 |
| wgrant | In the old model | 06:04 |
| wallyworld_ | and that would be a mistae, no? | 06:04 |
| wgrant | By policy, yes. | 06:04 |
| wgrant | But it will work absolutely fine. | 06:04 |
| wgrant | And LP won't warn you that you've done something that doesn't make sense. | 06:05 |
| wgrant | And isn't meant to be supported. | 06:05 |
| wallyworld_ | so if it's not supported then the garbo job can do what makes sense, or? | 06:05 |
| wgrant | wallyworld_: It's not supported, but it may well exist and if it does then the current garbo algorithm will cause private stuff to become public. | 06:06 |
| wallyworld_ | "unsupported" private stuff | 06:06 |
| wgrant | s/it may well exist/there is no reason it wouldn't exist/ | 06:06 |
| wgrant | Sure | 06:06 |
| wgrant | But someone making a silent misconfiguration when touching privacy is not a valid reason to make all their stuff public quietly :) | 06:07 |
| wallyworld_ | ie if people don't have a commercial subscription, can they reasonably expect their stuff to be private? | 06:07 |
| wgrant | wallyworld_: If they set private_bugs to true and created private BVPs and LP didn't complain and it worked for 5 years, then yes. | 06:08 |
| wallyworld_ | how would they set private bugs to true? i thought only an admin could do that? | 06:08 |
| wgrant | wallyworld_: We have admins all over the company | 06:08 |
| wgrant | (commercial admins, not just full admins) | 06:08 |
| wgrant | OEM, HWE, and even non-Canonical groups like Linaro have commercial admins | 06:09 |
| wgrant | LP doesn't make the supposed rules clear, so assuming that they've been followed is... not exactly reliable. | 06:09 |
| wallyworld_ | hmmm, ok. i initially saw the issue as "freeloaders" no longer getting something they hadn't paid for | 06:10 |
| wgrant | Well, there's that side of the issue. | 06:10 |
| wgrant | But that's relatively minor | 06:10 |
| wgrant | compared to the risk of making confidential information public without telling anyone | 06:11 |
| wallyworld_ | i can do a followup branch then to tighten the rules for what projects are migrated. custis seemed happy with the current approach when we discussed it during the call | 06:11 |
| wgrant | launchpad_dogfood=# SELECT COUNT(*) FROM product WHERE private_bugs AND NOT EXISTS (SELECT 1 FROM commercialsubscription WHERE commercialsubscription.product = product.id); | 06:14 |
| wgrant | count | 06:14 |
| wgrant | ------- | 06:14 |
| wgrant | 8 | 06:14 |
| wgrant | (1 row) | 06:14 |
| wgrant | That branch is dangerous :) | 06:14 |
| wallyworld_ | fsvo | 06:14 |
| wgrant | They're all canonical/linaro projects | 06:15 |
| wgrant | So by definition not freeloaders | 06:15 |
| wallyworld_ | do i really need to check bvp or is private_bugs sufficient? | 06:15 |
| StevenK | wgrant: I've been staring at this query for like ten minutes and still doesn't make sense. I know what I'm trying to say, but not how to say it. :-( | 06:17 |
| czajkowski | welcome to my world StevenK :) | 06:18 |
| wgrant | StevenK, wallyworld_: gimme a sec | 06:19 |
| wgrant | wallyworld_: There are 30 projects with private, private only, or forbidden BVPs and no commercial subscription | 06:20 |
| StevenK | czajkowski: Haha | 06:20 |
| wallyworld_ | wgrant: ok, i'll add in bvp checks also | 06:20 |
| czajkowski | bvp? | 06:20 |
| wgrant | wallyworld_: Thanks. | 06:20 |
| wgrant | wallyworld_: I didn't think there'd be this many, tbh :/ | 06:21 |
| wallyworld_ | branch visibility policy | 06:21 |
| czajkowski | ahh yes *headdesk* | 06:21 |
| wallyworld_ | czajkowski: they're going away soon so don't even bother to try and understand them :-) | 06:21 |
| wallyworld_ | wgrant: i'd be ok to ignore bvp = public? | 06:36 |
| wgrant | wallyworld_: Yeah, projects that have become public afterwards can't have their BVPs removed, so they're just all set to public | 06:37 |
| wgrant | wallyworld_: A project behaves as if it has no BVPs if it only has public BVPs | 06:37 |
| wallyworld_ | ok, so bvp > 1 in my query | 06:37 |
| wgrant | A single Private, Private Only or Forbidden rule means it's not public | 06:37 |
| wallyworld_ | yep | 06:37 |
| czajkowski | have folks come acorss liciencing choices/discussions before on LP https://bugs.launchpad.net/launchpad/+bug/1037685 | 06:58 |
| StevenK | wgrant: So no help for me? :-( | 07:03 |
| wgrant | StevenK: Sorry, what do you have so far? | 07:04 |
| StevenK | wgrant: Roughly 'store.find(Product).find(Product, ' because I've trying to figure out how the next bit should look. :-( | 07:05 |
| StevenK | czajkowski: So project licensing we don't really tend to care about -- we really only care is it an open source license or not? | 07:06 |
| wgrant | StevenK: So, one thing you could do is batch through the products, grab their APs, compare them to the set | 07:07 |
| czajkowski | StevenK: cant really reply with I don't care now can I :0 | 07:07 |
| czajkowski | :) | 07:07 |
| wgrant | StevenK: It's only going to be garbo-daily, so it doesn't need to be a stunningly fast single query | 07:07 |
| StevenK | wgrant: Right, I figured that bit | 07:08 |
| wgrant | StevenK: Then you compare the information types from the access policies with the ones allowed by *_sharing_policy. Any that don't match the sharing_policy, you query accesspolicyartifact to see if there are any artifacts using it. If not, you delete the APG and AP | 07:13 |
| wgrant | s/APG/APGs/ | 07:13 |
| StevenK | wgrant: Yes, I understand that bit, what I've been stuck on is how to tackle the query that finds if there is work to do. | 07:15 |
| wgrant | I'd just iterate through all the products | 07:16 |
| wgrant | There's not very many in the scheme of things. | 07:16 |
| wgrant | And we only need to do this dailyish | 07:16 |
| cjwatson | NCommander: no, livecd.sh is historical interest only. | 07:48 |
| NCommander | cjwatson: well, we still use it for old images, and generally, I think we want the capability to respin those until they leave support, no? | 07:48 |
| adeuring | good morning | 07:56 |
| cjwatson | NCommander: so the way it works is that we always build live images in a chroot of the relevant series, with the relevant series' livecd-rootfs installed | 08:13 |
| cjwatson | NCommander: the only piece that's series-independent is BuildLiveCD | 08:13 |
| cjwatson | NCommander: if at all possible I'd strongly recommend that you simply call BuildLiveCD | 08:13 |
| NCommander | I'm aware. I'm re-implementing BuildLiveCD into the buildd slave. | 08:13 |
| cjwatson | Is there a reason to do that rather than calling it? | 08:14 |
| cjwatson | It has quite a bit of distro-specific logic. | 08:14 |
| NCommander | BuildLIveCD can't be series-independent because the chroots are always presisene unles syou want to pull it in from a PPA or other location | 08:14 |
| cjwatson | BuildLiveCD isn't stored in the chroot. | 08:15 |
| NCommander | In addition, there isn't a lot of distro-specific logic, and by having the interface one level up, its easier to pass new options to build images or other engineering fun | 08:15 |
| NCommander | cjwatson: so then we want to install it on every buildd by hand? (or make it part of launchpad-buildd? | 08:15 |
| cjwatson | It's installed on every buildd by hand at the moment. | 08:15 |
| cjwatson | I guess I can see the logic in reimplementing it. If you do, you need to keep all the things it does, including, yes, livecd.sh. | 08:16 |
| cjwatson | Damn, now that bizarre failure I was seeing in EC2 has infected buildbot. | 08:18 |
| wgrant | cjwatson: Which? | 08:22 |
| wgrant | I don't see one | 08:22 |
| cjwatson | lp.soyuz.browser.tests.test_archive_webservice.TestArchiveWebservice.test_getAllPermissions_constant_query_count | 08:23 |
| cjwatson | on db-devel | 08:23 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | cjwatson: It's odd that it's doing both cookie-based sessions and OAuth | 08:23 |
| wgrant | But what's the extra query? | 08:24 |
| cjwatson | Maybe; but the test is that there are the same number of queries for one perm vs. two. | 08:24 |
| cjwatson | Trying to reproduce locally at the moment. | 08:24 |
| wgrant | I tend to just decrease the limit in the test to get it to give me a dump | 08:24 |
| cjwatson | Yeah. | 08:25 |
| wgrant | Then compare to the buildbot failure, and fail to work out what has changed :) | 08:25 |
| cjwatson | I'm mostly waiting for my beard to grow while make runs, at the moment. | 08:25 |
| wgrant | Heh | 08:25 |
| wgrant | make compile is pretty fast | 08:25 |
| wgrant | and usually sufficient for non-launchpadlib tests | 08:26 |
| cjwatson | This is a launchpadlib test. | 08:26 |
| wgrant | launchpadlib, or the test suite's webservice client thingy? | 08:26 |
| cjwatson | LaunchpadWebServiceCaller plus launchpadlib_for, apparently. I was slotting into the existing TestArchiveWebservice. | 08:27 |
| wgrant | Ah | 08:27 |
| cjwatson | But I specifically wanted to ensure there was no late evaluation hidden in lazr.restful. | 08:27 |
| wgrant | WebServiceCaller doesn't need WADL, launchpadlib_for does | 08:27 |
| wgrant | Right | 08:27 |
| cjwatson | It must be at least slightly random, because my second attempt to get uefi-ppa-no-unapproved through EC2 succeeded. | 08:29 |
| wgrant | cjwatson: Right, this sort of thing often depends on whether you're the first webservice test in the process or not | 08:31 |
| wgrant | Oh | 08:31 |
| wgrant | This is probably complaining there's one too few queries. | 08:32 |
| * wgrant counts.. | 08:32 | |
| wgrant | No, one too many :( | 08:32 |
| wgrant | There goes the session secret theory | 08:32 |
| cjwatson | Mm, it's expected != other. | 08:34 |
| cjwatson | Oh. If I put another list(self.main_archive.getAllPermissions()) at the start of the test, that triggers the failure. So that suggests it's something a bit like what you're suggesting. | 08:38 |
| cjwatson | Also, is lp.buildmaster.tests.test_builder.TestSlave.test_status_after_build a known-flaky test? | 08:39 |
| cjwatson | The extra query in the second run is "134-2193@SQL-main-master SELECT Component.id, Component.name FROM Component WHERE Component.id = 1 LIMIT 1". Oddly, it's listed at the start. I wonder if it's a leftover from the first run somehow | 08:46 |
| cjwatson | Also odd because there's already a "134-138@SQL-main-master SELECT Component.id, Component.name FROM Component WHERE Component.id = 1 LIMIT 1" in the first run. | 08:50 |
| * cjwatson discovers record_two_runs, whose purpose seems to be to deal with this. | 09:04 | |
| === mrevell_ is now known as mrevell | ||
| jml | we'd like to get https://code.launchpad.net/~james-w/udd/binary-scanning-series/+merge/119248 landed, but I've forgotten how to do it for udd (tarmac? pqm? merge & hope?) | 09:10 |
| maxb | Plain old bzr | 09:45 |
| cjwatson | wgrant: https://code.launchpad.net/~cjwatson/launchpad/testfix-getallpermissions/+merge/120094 | 09:46 |
| cjwatson | (or any other reviewer really, but I was talking to wgrant about this above) | 09:46 |
| wgrant | cjwatson: Looking | 09:46 |
| wgrant | Well, once the diff is there | 09:47 |
| wgrant | Ah, it won't be there for a while | 09:48 |
| wgrant | fdt | 09:48 |
| * wgrant looks at loggerhead | 09:48 | |
| wgrant | cjwatson: r=me. I didn't know about that nice helper. | 09:50 |
| cjwatson | nor did I before grep happened to turn it up :) | 09:50 |
| bac | hi adeuring are you reviewing today? | 12:26 |
| === bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| adeuring | bac:sorry, forgot to change the toipic.. | 12:26 |
| === adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac, adeuring | Firefighting: - | Critical bugs: 4.0*10^2 | ||
| bac | adeuring, quite a few branches on +activereviews. hope we can knock those out today. | 12:27 |
| adeuring | bac: ok, i'll start with "fix-.pocket-queue-admin-series" | 12:29 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| * deryck switches work locations, back online shortly | 14:28 | |
| cjwatson | adeuring: Thanks for your review of fix-pocket-queue-admin-series. While I don't object to making the change you mentioned for clarity's sake, you said that it was in LP's style guide, and I can't find it anywhere in https://dev.launchpad.net/PythonStyleGuide or in at least the first few linked pages I looked through. Could you point me to what I missed? | 15:16 |
| adeuring | cjwatson: let me see (actually, I claimed that this rule exists, but I haven't looked at our style guide for longer time...) | 15:17 |
| adeuring | cjwatson: https://dev.launchpad.net/CodeReviewChecklist?highlight=%28elif%29 | 15:20 |
| cjwatson | aha, thanks | 15:20 |
| adeuring | though that might be cruft... | 15:20 |
| adeuring | cjwatson: the idea idea of the rule is that it should be clear that all possible cases of the if/elif/elif... are covered -- just prevent "casual" errors | 15:21 |
| cjwatson | aye | 15:22 |
| cjwatson | I've put it back now | 15:22 |
| sinzui | jcsackett: do you have time to discuss the IBranchEditableAttributes interface. Project maintainers don't have permission to use change the attrs. This is a problem since the branch is shared with the project, and they cannot respond to cases where data is disclosed, or the branch owner is no longer associated with the project. | 15:34 |
| sinzui | jcsackett: I want you to read the interface before we talk because I was surprised by some of the attrs in it | 15:35 |
| === salgado is now known as salgado-lunch | ||
| jcsackett | sinzui: i'll put up the file now, and ping you in a few. | 15:41 |
| jcsackett | sinzui: short read. g+? | 15:44 |
| sinzui | yes | 15:45 |
| jcsackett | sending invite momentarily. | 15:45 |
| === al-maisan is now known as almaisan-away | ||
| === salgado-lunch is now known as salgado | ||
| === matsubara is now known as matsubara-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === matsubara-lunch is now known as matsubara | ||
| sinzui | bac: do you have time to review https://code.launchpad.net/~sinzui/launchpad/project-branch-permissions/+merge/120219 | 18:57 |
| === deryck[lunch] is now known as deryck | ||
| cjwatson | Is there some way to get my testfix from devel earlier merged over to db-devel so that its buildbot can start working again? | 20:19 |
| cjwatson | Actually, isn't buildbot-poll supposed to do that? | 20:21 |
| wgrant | cjwatson: buildbot-poll will do it if the db-devel builder isn't in proper testfix mode | 20:37 |
| lifeless | benji: added | 21:23 |
| benji | lifeless: thanks | 21:32 |
| cjwatson | wgrant: I fear it may be in testfix mode, though | 22:36 |
| cjwatson | So does it need somebody to merge manually? | 22:36 |
| wgrant | cjwatson: Not sure if codehosting's still up, but indeed. | 22:41 |
| wgrant | You can either merge the testfix branch, or just say the whole stable merge is a testfix. | 22:42 |
| cjwatson | wgrant: with bzr lp-land or something more arcane? | 22:45 |
| wgrant | cjwatson: I'd just pqm-submit stable directly | 22:47 |
| wgrant | bzr pqm-submit -m '[testfix][r=foo] Merge db-stable rWHATEVER' --public-location=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel | 22:48 |
| wgrant | or so | 22:48 |
| cjwatson | ok, will have a look in a bit, modulo whatever bits of LP are still alive | 22:48 |
| cjwatson | wgrant: not being a reviewer, can I use r=wgrant? | 23:00 |
| wgrant | cjwatson: Be my guest | 23:00 |
| cjwatson | done | 23:09 |
| wgrant | Thanks. | 23:10 |
| * cjwatson slightly freaked out by glimpsing "bzr: ERROR: no such option: -0" in PQM output | 23:10 | |
| wgrant | I thought I'd removed that check. | 23:10 |
| wgrant | Maybe not | 23:10 |
| wgrant | It's pointless and doesn't work any more, anyway | 23:11 |
| NCommander | cjwatson: ok, now that I slept on it. WHy do we want to keep BuildLiveCD? The API I have for Launchpad lets the client choosing the build choose the chroot and the series its building (by default, whatever series you choose to build will be built in said chroot aka; lucid build in lucid using livecd.sh, precise build in precise using live-buid (or ubuntu-default-image) | 23:14 |
| NCommander | Is there another piece of functionality I'm overlooking? | 23:14 |
| cjwatson | It may not be too outrageous to replace BuildLiveCD with something equivalent, indeed. | 23:14 |
| cjwatson | Now that I've thought about it, our process for modifying that involves RT. Changing that to involve landing an LP branch might actually be an improvement. | 23:15 |
| cjwatson | Would be easier to see what's currently running. | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!