| StevenK | wgrant: Apparently, you broke buildbot | 00:03 |
|---|---|---|
| StevenK | I suspect the libav thing is the Host: header, too | 00:06 |
| StevenK | But still checking | 00:06 |
| * StevenK looks how to register a bugtracker | 00:25 | |
| wgrant | StevenK: Just let it autocreate | 00:30 |
| wgrant | Add a product task on a bug, specifying the URL | 00:30 |
| StevenK | It didn't work that well for me, but I think I got there | 00:30 |
| StevenK | 2012-11-16 00:31:01 DEBUG No watches to update on http://bugzilla.libav.org/ | 00:31 |
| StevenK | :-( | 00:31 |
| StevenK | wgrant: I created a project, registered the bugtracker, set the project to report in LP, filed a bug, changed the project details to point to the registered bugtracker and set the watch on the bug | 00:32 |
| StevenK | Hmmm, look at that | 00:33 |
| wgrant | You might need to manually set the next update time | 00:34 |
| StevenK | Yeah, I reset the watch and checkwatches has picked it up | 00:34 |
| StevenK | 2012-11-16 00:33:23 INFO Error updating http://bugzilla.libav.org/: Failed to parse XML description for http://bugzilla.libav.org bugs [u'298']: mismatched tag: line 101, column 4 | 00:34 |
| wgrant | Ah yes | 00:35 |
| wgrant | Bugzilla's XML generation is somewhat interesting | 00:35 |
| StevenK | It isn't XML | 00:38 |
| wgrant | How far off XML is it? | 00:38 |
| StevenK | It's returning an HTML error page | 00:39 |
| wgrant | Ahh | 00:39 |
| StevenK | Bugzilla has suffered an internal error. Please save this page and send it to Reinhard Tartler with details of what you were doing at the time this message appeared. | 00:41 |
| StevenK | Cannot seem to handle bug_id and include together. | 00:42 |
| wgrant | Is there anough info in the page to see what's wrong, or do you need to try poking siretart tonight? | 00:45 |
| StevenK | The cannot seem to handle along with the code has shown me 'bug_id_type': 'include', | 00:46 |
| StevenK | So I'm checking the version parsed out | 00:46 |
| StevenK | Right, I got it to work | 00:51 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1361616/ | 00:52 |
| wgrant | StevenK: What does bug_id_type: include do? | 00:54 |
| StevenK | But I don't know if that will break every other bugwatch ever | 00:54 |
| StevenK | wgrant: I have no idea, I took a guess based on the error message | 00:54 |
| StevenK | And Google has failed me | 00:54 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1361625/ also works, and it seems Google actually knows about bugidtype a lot more | 01:03 |
| * StevenK stabs Bugzilla. Hard. | 01:04 | |
| StevenK | http://www.bugzilla.org/status/changes.html is not helpful. In the slightest | 01:04 |
| wgrant | Wow | 01:05 |
| wgrant | That's an impressive page | 01:05 |
| StevenK | Impressive, but unhelpful | 01:06 |
| StevenK | http://bzr.mozilla.org/bugzilla/4.0/revision/6940/Bugzilla/CGI.pm seems to show that bug_id_type is the new style, but only for version 4.0 and higher | 01:09 |
| wgrant | Hm | 01:10 |
| wgrant | So bugidtype maps to bug_id_type? | 01:10 |
| wgrant | Maybe talk to siretart about upgrading... | 01:10 |
| StevenK | We still support bugzilla 2.16 in the code | 01:11 |
| wgrant | Hmm | 01:11 |
| wgrant | What does annotate say about that arg in our tree? | 01:11 |
| StevenK | That's an interesting question. | 01:13 |
| StevenK | It was touched by jtv in r12227 as part of fixing a redirect on submit issue, and then it was changed in r5896 by gmb when he refactored the world of external bug trackers | 01:15 |
| StevenK | And r5896 was when lib/lp/bugs/externalbugtracker/bugzilla.py starts existing, so I'm not sure where the code was before. | 01:16 |
| StevenK | Ah, lib/canonical/launchpad/components/externalbugtracker.py | 01:18 |
| StevenK | And that was touched in what turns out to be r3745 by kiko when he added issuezilla support | 01:20 |
| StevenK | So it's been bug_id_type in our code since at least 2006 | 01:20 |
| mwhudson | if it was when kiko was still writing code... | 01:20 |
| StevenK | mwhudson: In the deep, dark ages, when dinosaurs still ruled the earth? | 01:21 |
| mwhudson | something like that | 01:21 |
| * StevenK grumps at bug 1049366 | 03:11 | |
| _mup_ | Bug #1049366: Incorrect bug status imported from freedesktop-bugs <bugwatch> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1049366 > | 03:11 |
| StevenK | It works locally | 03:11 |
| StevenK | wgrant: I've commented on the libav bug, since siretart is subscribed | 03:35 |
| StevenK | But I'm not sure about that freedesktop bug | 03:35 |
| wgrant | StevenK: Have you checked the prod logs? | 03:47 |
| StevenK | They're syncing | 03:48 |
| StevenK | wgrant: I can't see that remote id in the logs, but according to the UI it was checked | 04:26 |
| wgrant | StevenK: Does the UI give a timestamp? | 04:27 |
| StevenK | 3 hours ago | 04:27 |
| StevenK | wgrant: Haha. Resetting it has given " Update failed with error 'Unable to set link remote bug to Launchpad' 5 minutes ago" | 05:08 |
| wgrant | Aha | 05:08 |
| StevenK | *But* it set the status correctly | 05:08 |
| StevenK | wgrant: local OOPSes disappear into the ether? | 05:31 |
| wgrant | StevenK: Yes. If you kill rabbitmq they'll go into /var/tmp/lperr, or you can run a local amqp->stdout thing | 05:32 |
| wgrant | I think there's one around | 05:32 |
| StevenK | wgrant: The rabbit that's owned by me, or rabbitmq? | 05:32 |
| wgrant | StevenK: Yours | 05:33 |
| StevenK | .... WTF does that mean | 05:34 |
| StevenK | Fault: <Fault -32000: 'Cannot compare a datetime to a regular scalar at /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/DateTime.pm line 1385.\n'> | 05:34 |
| StevenK | Oh, is that from the remote tracker ... | 05:36 |
| wgrant | Yes | 05:40 |
| wgrant | Unless you ported checkwatches to perl | 05:41 |
| wgrant | In which case you would be declared to be an enemy combatant | 05:41 |
| StevenK | But it might behave better | 05:41 |
| StevenK | So, I have no idea about that error, and we haven't had people shooting us | 05:42 |
| czajkowski | jtv: ello you about? | 08:36 |
| jtv | hi czajkowski | 08:36 |
| czajkowski | jtv: have you ever come across a complaint like this in translations, https://support.one.ubuntu.com//Ticket/Display.html?id=25271 | 08:37 |
| jtv | Grrr auth dance not linking to actual ticket | 08:38 |
| czajkowski | no that is a known bug in RT | 08:39 |
| czajkowski | pita | 08:39 |
| jtv | Reported by "Genghis Khan"... I thought his son Aga had taken over the business? | 08:39 |
| jtv | czajkowski: yes we get this sometimes. Have a look at the work to get a feel for how real the complaint is. Assuming it is, contact the accused and tell them to report, clean up their act, or yield the post. | 08:41 |
| jtv | If there's no response in a few weeks, change the team's ownership (whoever complains is usually volunteering). | 08:42 |
| jtv | If the response is "I'll do my best from now on," set a deadline of a few weeks and check back with the complainer's help. | 08:43 |
| jtv | A translation team's job is to manage translations, not to get a monopoly on entering them. | 08:44 |
| jtv | And of course, bear in mind that the faceless nature of the interaction between the two parties you're dealing with naturally leads to strife. Be ready to build bridges if intentions were good. | 08:46 |
| adeuring | good morning | 08:46 |
| jtv | Hi there adeuring | 08:47 |
| czajkowski | jtv: ah ok so kinda like dealing with lcoo teams | 08:47 |
| adeuring | hi jtv! | 08:47 |
| czajkowski | what do you mean by yield the post? | 08:47 |
| jtv | Ownership of the translation team. | 08:47 |
| czajkowski | ahhh | 08:48 |
| czajkowski | jtv: thanks for the help | 08:48 |
| jtv | The owner's first job is to vet applicants for the team _and approve some_. | 08:48 |
| jtv | After that, manage the translation process. | 08:48 |
| jtv | "Do some translations" doesn't even enter into it — anyone with an account can do that. | 08:48 |
| jtv | If anyone volunteers, make sure they understand this responsibility. Don't mistake "I want to translate" for "I want to manage translation." | 08:49 |
| jtv | I think sometimes people start out with "I want to translate," acquire a translation team along the way, and then don't hear about the management side of the job so they ignore it. | 08:49 |
| jtv | Having provided czajkowski with bedside reading material for the near future, jtv goes about his way :) | 08:51 |
| czajkowski | jtv: cheers | 08:52 |
| jtv | :) | 08:52 |
| === joey[a] is now known as joey | ||
| === almaisan-away is now known as al-maisan | ||
| StevenK | wgrant: I guess the p-d-r complaints are due to OMG backlog? | 09:33 |
| czajkowski | StevenK: what complaints? | 09:41 |
| StevenK | czajkowski: The scriptactivity mails | 09:41 |
| czajkowski | ahh | 09:41 |
| czajkowski | thought you were referring to an OMG article | 09:42 |
| StevenK | p-d-r was turned on after being off for a long while, so a OMG-normous backlog is to be expected | 09:42 |
| czajkowski | nods | 09:42 |
| czajkowski | so have we resolved the ppa issue as we're turning this on or are they seperate issues? | 09:42 |
| StevenK | czajkowski: Turning on p-d-r will resolve the issue. Once it has caught up | 09:43 |
| czajkowski | lovely that will make my inbox and irc happy :) | 09:43 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | StevenK: Yeah, it's working, just taking a while to catch up | 10:44 |
| wgrant | Been going nearly 6 hours now | 10:44 |
| === Ursinha is now known as Ursinha-afk | ||
| === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~190 | ||
| === Ursinha-afk is now known as Ursinha | ||
| jcsackett | adeuring: MP for review is https://code.launchpad.net/~jcsackett/launchpad/filter-milestone-vocabulary-for-projectgroups/+merge/134667 | 14:39 |
| adeuring | jcsackett: I'll look | 14:40 |
| jcsackett | adeuring: thanks. :-) | 14:42 |
| adeuring | jcsackett: r=me, with a remark about getProductPrivacyFilter() | 15:09 |
| jcsackett | adeuring: i don't know that we need that--we're only using the function when we're expressly filtering out private products. artifact listings are handled separately when they exist, right? | 15:11 |
| jcsackett | probably worth bringing up on monday though, you're right. | 15:11 |
| adeuring | jcsackett: yes, the intent is to filter private projects a user can't see -- but people with artifacts grant for a private project would see a private project in the vocab but would not be able to access it. | 15:13 |
| jcsackett | adeuring: i may not be understanding you right; the getPrivacyfilter method only checks against the product itself--if you have access to a bug, you still won't get the product. or are you suggesting they should be able to see the product in that instance? | 15:14 |
| adeuring | jcsackett: getProductprivacyFilter() uses Select(Product.id, granted_products), where the granted_products clause does not distingiush between records where the column artifact is null and not null, meaning that people will be have products listed that they cannot access | 15:21 |
| adeuring | this may or may not be desirable -- i am simply not sure ;) | 15:21 |
| jcsackett | adeuring: ah, dig. yeah, there's definitely room for discussion. good catch. :-) | 15:23 |
| deryck | sinzui, hi. so we had some confusion on our stand-up call this morning, I'm hoping you can resolve.... | 15:36 |
| sinzui | okay | 15:36 |
| deryck | sinzui, wgrant reverted my work and I agreed to it, thinking that we couldn't have public bugs on private projects.... | 15:36 |
| sinzui | you cannot..transitive privacy | 15:37 |
| deryck | sinzui, but abentley was under the impression that we wanted to warn but not prevent users from having these mixed policy situations. | 15:37 |
| deryck | sinzui, some PES use case for mixed artificats he mentioned after discussing with you | 15:37 |
| abentley | sinzui: You have also said that we don't want to have transitive privacy where bugs are private. | 15:37 |
| sinzui | We warn when the user is not in the policy and that someone instead needs to agree to grant access for a subscription | 15:37 |
| abentley | i.e. userdate | 15:38 |
| abentley | s/userdate/userdata | 15:38 |
| sinzui | abentley, thank you for calling me out. I mean confidential, not private userdata | 15:38 |
| abentley | sinzui: Could you expand? | 15:40 |
| sinzui | abentley, non-confidential is not transitive. bugs, branches, and specs can be private with a public context as they has always been | 15:40 |
| sinzui | confidential is transitive. you cannot have a public comment or attachment on a confidential bug | 15:40 |
| abentley | sinzui: Can you please define confidential? | 15:41 |
| sinzui | you cannot have a public branch stacked on a confidential branch...there is a long history of Lp implying it can be done. This is a data/state error. the user see a 403 because Lp enforces that traversal/stacking access rules | 15:41 |
| deryck | sinzui, when you say confidential do you mean either proprietary or embargoed projects? | 15:42 |
| deryck | sinzui, or do you mean something more inclusive by confidential? | 15:42 |
| sinzui | Confidential is Private, Private security, Proprietary, and Embargoed. They are all information types that have sharing rules to restrict access | 15:42 |
| abentley | sinzui: Good, wanted to make sure I understood what you meant by confidential. | 15:43 |
| sinzui | We designed sharing to take advantage of Zope and bzr stake already does -- make a make a quick check of the user can proceed to the next thing. | 15:44 |
| deryck | sinzui, so to make it concrete -- a proprietary project could have proprietary bugs or emabargoed or private but not public.... | 15:44 |
| deryck | sinzui, and a public project can have any kind of bug. did I get that correct? | 15:44 |
| sinzui | limitedview + subscriptions + artefact grants are an escape clause that stakeholders required so that they could continue to use contractors to work on a small amount of NDA data | 15:45 |
| sinzui | deryck, yes | 15:45 |
| deryck | sinzui, excellent. so abentley's work should in fact block you from changing a public project to proprietary if you have any public bugs, rather than just warn. right? | 15:46 |
| sinzui | yes! | 15:46 |
| sinzui | We abentley has learned about the nasty migration problem with hwe | 15:46 |
| deryck | but we should warn when you have any other confidential information type for bugs if setting a project to proprietary? trying to understand where the warning idea came in. | 15:47 |
| abentley | Sigh. I wrote it that way originally, but after talking with you, I thought we could not forbid that, since we do not forbid other sharing policy violations. | 15:47 |
| sinzui | We wanted to enforce changing all non-compliant artefacts to the declared type, but HWE's has bugs that do not conform...they need to dismantle some projects to separate the data | 15:47 |
| sinzui | deryck, We never intend to allow a public project become proprietary. It must be created properly | 15:48 |
| sinzui | Teams have the same issue. They really need to be made private. we allow users to try to make a team private, but it often fails because information was leaked when it was setup :( | 15:49 |
| === almaisan-away is now known as al-maisan | ||
| sinzui | ...the most common cause of leaks was setting up thing public, so both teams changed registration to ensure things could be setup right during registration | 15:50 |
| deryck | sinzui, I don't see why we would prevent that. we would allow embargoed, right? why not proprietary? Any project wanting to use proprietary that already exists would be ruled out. | 15:50 |
| sinzui | Because you cannot remove the data from Google or the way back machine | 15:50 |
| sinzui | Changing the information type does not undo the leak of a NDA with a OEM/OED | 15:51 |
| deryck | true, so it's not truly super secret. but why would I want an embargoed project just because it's the only private info type I can use? | 15:51 |
| sinzui | Proprietary and Embargoed are intend to truly super secret | 15:51 |
| sinzui | Public with some proprietary artefacts is the the intermediate project, like ubuntuone-server | 15:52 |
| sinzui | Remember we we commission to build this to stop NDA leaks. | 15:53 |
| sinzui | There is not NDA that is sort of private | 15:53 |
| deryck | sinzui, I understand the use case your wanting to prevent -- i.e. leaks. What I don't understand is why it matters if someone wants to turn a public project private. yes, they have no assurance that the name of the thing wasn't already discovered, but they could otherwise work in private going forward, i.e. with future series and milestones. | 15:55 |
| deryck | no one will understand that we're blocking private projects because they didn't start out that way. that makes literally no sense to a user. | 15:56 |
| sinzui | deryck, sharing already detects contradictions in policy with the current state of artefacts. If you choose Proprietary only, but there are Private, the sharing overlays list the non-supported state. A garbo job looks at the inconsistencies. When all the artefacts transition to the allowed creation/transition states, the unused policies are removed from the sharees. | 15:56 |
| sinzui | deryck, because Lp/Canonical cannot do what the user thinks will happen. | 15:57 |
| deryck | I can assure you that the user has no idea what will happen. :) | 15:57 |
| deryck | this notion that proprietary == never ever discoverable is our own invention. it's only for PES. other people will want to use private projects and it makes no sense why they can't. | 15:58 |
| deryck | and I don't see how allowing others to use the feature undermines PES's concerns. they can create wholly new proprietary projects and never worry if they desire that level of secrecy. | 15:59 |
| sinzui | deryck, If we want to entertain public -> Confidential-type, then you need to write a job that purges all the blocking conditions: remove linked packages, shared bugs, etc... | 15:59 |
| deryck | no, I don't think so. I think we can block until they clean up their data themselves and warn in that condition. I don't have issue with that kind of soft block.... | 16:00 |
| sinzui | NO | 16:00 |
| sinzui | NO | 16:00 |
| sinzui | NO | 16:00 |
| deryck | why shout at me? clearly we're not understanding each other. but there's no need to freak out about it. | 16:00 |
| sinzui | We already had to audit leaks from inclusive teams in trusted roles | 16:00 |
| sinzui | Lp must enforce a transition to a state is valid | 16:01 |
| deryck | look, I'll make sure we're careful about it. that's why I'm having this discussion now. please give me a little bit of the benefit of the doubt. | 16:01 |
| === matsubara is now known as matsubara-lunch | ||
| sinzui | Confidential projects cannot share bugs, have answers, link to packages. Trying to switch such a project MUST fail because we cannot easily unleak | 16:02 |
| deryck | that's part of our work... that's what we're doing. we've already made it where you can turn to private if you have answers. we block until you fix it. we're doing work to make sure you unlink branches, or else allow us to do it for you. | 16:03 |
| deryck | sinzui, is it your argument that there's just too many of these type of relationships to ever allow it? | 16:03 |
| sinzui | You cannot make a private team public if it had a mailing list because the conversations were provided knowing that the information was confidential | 16:03 |
| deryck | sure, that makese sense. that's different, IMHO, to making something public private. | 16:03 |
| sinzui | conversely you cannot make a public team private is it has a public ppa...people are subscribed to archive | 16:04 |
| deryck | can you not unsubscribe them from the ppa? | 16:04 |
| deryck | I'm asking only to follow the trail here. not saying we should do that. | 16:05 |
| sinzui | deryck, as I said you can entertain public => confidential projects, but you need to enforce the transition. You need to scope out a process that cleans up the inconsistencies. I think that is more than a month of work | 16:05 |
| sinzui | since you rejected allowing teams to transition because of scope...and there is more need for that then surely you will reject projects. teams | 16:06 |
| sinzui | Teams have two tricky transitions...projects have dozens | 16:06 |
| deryck | I didn't reject teams, you did. :) But that decision was made outside the private projects work we inherited. | 16:07 |
| sinzui | deryck, Canonical needs to be certain its projects meet our NDA agreements. If project creation is not good enough, we need to fix it | 16:07 |
| deryck | those are two different concerns. project creation is fine. it works. it's secure. how does transitioning from public to private undermine project creation? | 16:08 |
| sinzui | We promised teams would be done once private projects were done. They were the last part of discusure | 16:08 |
| deryck | I thought team were already done. I don't follow what | 16:08 |
| deryck | what's left to do. | 16:08 |
| abentley | sinzui: We already guard against transitioning a product to proprietary if it has linked packages. | 16:10 |
| sinzui | Canonical needs to make teams public when their projects become public. It took 2 admins, 2 commercial admins, and 2 PM admins 2 days to do an incomplete unembargoing of webapps after the announcement. Private teams own the projects and the code, so it was impossible for user to get the code | 16:10 |
| sinzui | abentley, right, so if Lp says it cannot make the project Proprietary then we have a choice of saying sucks to be you, or building something that can help make the transition possible | 16:12 |
| deryck | I think we're all over the place here, sinzui. just to be issues and concerns from too many ankles. that's paralyzing. | 16:12 |
| deryck | sinzui, so how about this.... | 16:12 |
| abentley | sinzui: It's not a big "sucks to be you", though. Just unlink the packages... | 16:12 |
| sinzui | abentley, deryck if I create a project, then immediately notice that It was supposed to be Proprietary, I have less than 5 minutes to fix that before Google has indexed every word and team name on that page | 16:13 |
| abentley | sinzui: I'm okay with safe-but-annoying, and reducing annoyance where we can. | 16:13 |
| deryck | sinzui, to get abentley going again, we do agree that we need to forbid transitions to proprietary if there are public artifact's.... | 16:13 |
| deryck | sinzui, what we disagree on is whether or not we should forever block that transition. right? | 16:14 |
| sinzui | I am certain the transition would happen...only the bug supervisor could conflict with rules during registration, and I think we only show it if the project is declared to be Proprietary/Embargoed | 16:14 |
| deryck | sinzui, likewise, we are uncertain if there is any work we need to do on teams, or how teams relate to these transitions, which you are concerned about it. | 16:15 |
| sinzui | deryck, I don't out-right disagree with the transition, I am concerned that the transition wont be safe | 16:15 |
| deryck | ok, cool. I'm also concerned definitely. common ground! :) | 16:16 |
| deryck | but it's just code. We own it. We wrote it. We can change it. it might be hard, but I don't like the code owning me. I own the code. | 16:16 |
| deryck | sinzui, so I think we can get back to work on it now. maybe Monday or Tuesday you and I should talk more about teams to make sure I'm clear on your concerns there. cool? | 16:19 |
| sinzui | deryck, we have 3 people on maintenance with 170 criticals. Since Canonical does not want any one on maintenance, I prefer to take less risky steps that ensure 3 people can keep it running, possibly prepare Lp for no developers | 16:20 |
| deryck | sinzui, sure, that's a fair argument. But you're assuming that we'll fail. I'm not so pessimistic. | 16:22 |
| sinzui | I am not assuming failure. Since the intent was to remove all maintenance teams this week, I think there our plans to complete work are undermined by business concerns | 16:24 |
| sinzui | 3 maintenance staff are a compromise | 16:25 |
| jcsackett | can someone point to a product series picker on LP that uses the search for product and series functions? i can't seem to find one. | 16:34 |
| === deryck is now known as deryck[lunch] | ||
| === Ursinha_ is now known as Ursinha | ||
| === matsubara-lunch is now known as matsubara | ||
| === al-maisan is now known as almaisan-away | ||
| sinzui | jcsackett, I don't think there is a series picker. | 17:51 |
| czajkowski | sinzui: how do we feel about - SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 | 17:52 |
| sinzui | jcsackett, milestones let you retarget the series, and the packaging link also retargets. Neither though uses a picker | 17:52 |
| * sinzui tries to remember | 17:53 | |
| sinzui | czajkowski, I search for SIL in reviewed and approved projects and see I have approved it | 17:54 |
| sinzui | it is okay | 17:54 |
| sinzui | czajkowski, There was a font license that was rejected, but that clearly is not SIL | 17:54 |
| === deryck[lunch] is now known as deryck | ||
| czajkowski | nods | 17:54 |
| czajkowski | sinzui: thanks | 17:54 |
| czajkowski | just doing project reviews now before my EOD | 17:55 |
| jcsackett | sinzui: yeah, i think there's a good chance the code in questions isn't actually used properly anywhere. | 18:19 |
| sinzui | I suspect is is old. | 18:19 |
| * jcsackett nods | 18:19 | |
| jcsackett | i verfied that nothing that should work as is stopped working and set the bug to qa-ok. | 18:19 |
| sinzui | jcsackett, We changed packaging link to a multistep form and that probably factored out the last case | 18:19 |
| jcsackett | sinzui: that makes sense. | 18:21 |
| === yofel_ is now known as yofel | ||
| === joey[a] is now known as joey | ||
| === joey[a] is now known as joey | ||
| abentley | jcsackett: There's no OCR. Could you please review https://code.launchpad.net/~abentley/launchpad/fix-bp-timeouts/+merge/134744 ? | 20:59 |
| jcsackett | abentley: sure. | 20:59 |
| abentley | jcsackett: Thanks. | 21:00 |
| deryck | abentley, I need a review, too, if you don't mind. This one should be pretty easy. | 21:01 |
| abentley | deryck: sure. | 21:01 |
| deryck | abentley, thanks! https://code.launchpad.net/~deryck/launchpad/bugs-embargoed-or-proprietary-1079352/+merge/134746 | 21:01 |
| abentley | deryck: r=me. | 21:03 |
| deryck | abentley, awesome, thanks! | 21:03 |
| jcsackett | abentley: looks good. r=me. | 21:11 |
| abentley | jcsackett: Thanks. | 21:12 |
| jcsackett | sinzui: can you add me to the aaron-curtis-test-2 project on qastaging? i need to poke more at the data--i can't replicate in .dev or tests according to our expectations. | 21:35 |
| jcsackett | or abentley ^ | 21:35 |
| abentley | jcsackett: I can't access it. | 21:36 |
| jcsackett | abentley: ok. sinzui? | 21:37 |
| sinzui | jcsackett, it is shared with you now | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!