/srv/irclogs.ubuntu.com/2012/05/02/#launchpad-dev.txt

=== bdmurray_ is now known as bdmurray
wallyworldwgrant: i don't think there's a bug search api that can be used to find all bugs a person is directly subscribed to is there? you can search and find bugs for structural subscriptions on a pillar but I want to find bugs subscribed to directly00:51
wgrantwallyworld: https://launchpad.net/~wgrant/+subscribedbugs01:07
wgrantwallyworld: But you don't want to remove all subscriptions.01:07
wallyworldwgrant: if a person has had their access to a pillar revoked, then we want to unsubscribe them from all bugs for that pillar, no?01:09
baclifeless, wgrant: do you know if storm makes any guarantees about the default ordering of results if no order_by is specified?01:09
wgrantbac: It does not. That would be evil.01:09
wgrantwallyworld: Their direct access to the pillar has been revoked.01:09
wgrantwallyworld: But they may still have access through a team.01:10
bacwgrant: yeah, well we have unit tests that rely on order by id...and they fail when run out of order01:10
wgrantbac: You'll need to order explicitly. Do not add implicit order to the model, as it is likely to break queries.01:10
wgrantSorting is expensive.01:11
bacyou don't say.  :)01:11
wgrantbac: Some old SQLObject-based classes have a default order defined, but it causes no end of performance trouble when you write what seems to be an innocent query but it actually sorts behind your back.01:12
wallyworldwgrant: the argument about team access could be applied to the case where their access is revoked to a single artifact via the sharingdetails page and we unsubscribe there01:12
wgrantwallyworld: For example, once the UI is turned on we'll want to remove about 130 of the Launchpad grants.01:13
bacthanks wgrant01:13
wgrantwallyworld: But we'll want to keep lots of the subscriptions.01:13
wgrantwallyworld: Because engineers have subscribed to things that they're interested in. We're just revoking their explicit access because they should get it through ~launchpad instead.01:13
wallyworldsure, so that's what i'm doing in this job - removing direct subscriptions for an individual when access is revoked01:14
wgrantYou need to remove direct *grants*, and subscriptions to artifacts that are no longer accessible.01:14
wgrantBut not all subscriptions to private artifacts.01:15
wallyworldgrants are removed already, but i was told i also need to remove subscriptions also01:15
wallyworldit's in a bug on the board01:16
wgrantYou need to remove some of them, yes.01:16
wallyworldso there's 3 cases 1. revoke access to individual artifact, 2. revoke access to entire pillar, 3. revoke access to artifcats of an info type01:17
wallyworldso far in the job i've done case #1 - simply unsubscribe user from given artifact01:18
wgrantIn all cases, if there is a subscription and no remaining access (eg. through a team), the subscription must be removed.01:18
wgrantHowever01:18
wgrantThis gets complicated, because eg. team membership changes affect which subscriptions are allowed.01:18
wallyworldif the grant is revoked, they won't have access even if there is a team subscription01:19
wgrantThey will so.01:19
wgrantWell01:19
wgrantNot a team subscription.01:19
wgrantBut a team grant.01:19
wallyworldright. but the sharing details page only shows direct access01:20
wgrantSure01:20
wgrantBut revoking the direct access does not necessarily revoke all access.01:20
wallyworldand when the delete button is hit, the grant is revoked and the invisual sub to the aertifact is removed01:20
wgrantThat is incorrect behaviour.01:20
wgrantThere may still be access, through a policy grant or a grant to a team.01:21
wallyworldbut if there's a policy grant, you don't see that artifact on the sharing details page01:21
wallyworldso you can't revoke it individually01:22
wgrantAh, through that UI that is true indeed (although it might be visible on the bug page)01:22
wgrantBut it's still true for team grants.01:22
wallyworldextending that metaphore of case #1 above, if i revoke a user's access to userdata things, that user needs to be unsubscribed from those things01:23
wgrantNo.01:24
wgrantBecause you might be doing it to clean up.01:24
wgrantNot to revoke access.01:24
wgranthttps://launchpad.net/launchpad/+sharing <- most of those grants are invalid, but the subscriptions are fine.01:24
wallyworldwgrant: see bug 933839, the second bit of the description indicates we do need to remove subscriptions01:25
_mup_Bug #933839: Share nothing with a user or team <disclosure> <job> <Launchpad itself:Triaged> < https://launchpad.net/bugs/933839 >01:25
wgrantBug descriptions from 3 months ago don't override logic :)01:26
wallyworldbut i discussed this work over the past 2 standups and nothing was said to the contrary01:27
wgrantIt doesn't explicitly state either way.01:27
wallyworldyes it does, it says "Unsharing also removes subscriptions to bugs and branches"01:27
wgrantOne behaviour clearly produces undesirable results, the other potentially contradicts one reading of a vague statement in an old bug report.01:27
wallyworldit wasn't just in this bug report, the same issue has come up in conversation over the past little while01:29
wgrantI'd always heard it phrased more along the lines of "subscriptions to which there is no longer access must be removed"01:30
wgrantNot "subscriptions to artifacts from which a grant is being revoked must be removed"01:30
wgrantI don't think the latter version makes much sense.01:32
wgrantAs it is clearly inconsistent with intended behaviour elsewhere.01:32
wgrantI can subscribe to a bug I have access to, even if it's through a team.01:32
* StevenK stabs BugChange01:33
wallyworldsure. the intent of the ui then becomes an issue01:33
wgrantThe UI will make it clear that people may still have access through teams.01:33
wallyworldif a user clicks the delete icon on the sharing page, they think they are revoking access for that user01:33
StevenKI can clearly see two BugInformationTypeChange's being created, but printing a traceback when they're created is less than helpful.01:33
wgrantwallyworld: Removing subscriptions doesn't make that true or false.01:34
wgrantwallyworld: It's already false.01:34
wgrantwallyworld: Because access may remain through teams.01:34
wallyworldso does access policy grant flat take account of team membership, i can't recall01:36
wgrantNop.01:36
wgrantNo.01:36
wgrantRemember the concerns around private team expansion etc. which led us to defer the audit view.01:36
wallyworldbut if the requirement is to unsubscribe users if direct access is revoked and they have no further access via teams, i could join apgf to teamparticiaption and check that way01:37
wgrantThat would be one way to do things, inded.01:38
wallyworldso i think the current mp which unsubscribes when revoke is done from the sharing details page is correct01:39
StevenKwgrant: Can you see any difference in http://pastebin.ubuntu.com/961462/ ? I'm printing the arguments BugInformationTypeChange is getting created with and then forcing a stack trace01:40
wgrantwallyworld: mmm01:41
wgrantwallyworld: It's not incorrect, because it doesn't specify how to calculate the bug IDs.01:42
wgrantHowever, I question the design. eg. this probably makes it impossible to revoke apport's access to Ubuntu bugs.01:42
wgrantAs the request will have to grab like 300000 bugs out of the DBs, calculate their IDs, put them in a list, serialise them to JSON, stuff them into a multi-megabyte text column in the DB.01:43
wallyworldwgrant: you misunderstand - the bug ids list is only for individual revokes, not info type or pillar based ones01:43
wgrantwallyworld: Ah, that makes me a lot less worried.01:44
wallyworldi'm not *that* stupid01:44
wgrantMost people don't quite realise the magnitude of some of the horrific exceptional cases we have.01:44
wgrantLike, no reasonable person could think that one principal would have 300000 bug grants.01:45
wgrantBut they do :)01:45
wallyworldseriously? 30000001:45
wgrantMaybe only 20000001:45
wgrantBut a few01:45
wgrantThat order of magnitude, anyway :)01:45
* wallyworld needs food01:46
wgrantStevenK: https://code.launchpad.net/~wgrant/launchpad/no-job-oops-prefix/+merge/10431501:50
* StevenK scratches his head over this double BugInformationTypeChange01:51
* wgrant looks01:51
StevenKI have a diff between them01:52
wgrantThose are tracebacks for the two calls?01:52
StevenKYeah01:52
StevenKwgrant: http://pastebin.ubuntu.com/961476/ is the diff01:52
StevenKThe first one is -, the second is +01:52
wgrantStevenK: lazr.restful calls notify() itself01:53
wgrantPresumably it diffs the object too01:53
mwhudsonlazr.lifecycle woo01:53
wgrantUsing lazr.lifecycle, yeah01:54
StevenKThe one from lazr.restful is wrong, though :-(01:54
mwhudsonfor some reason the fact that that isn't part of launchpad any more has never really settled into my brain01:54
StevenKwgrant: Your MP looks excellent01:55
wgrantStevenK: How's it wrong?01:55
StevenK-BugInformationTypeChange(None, <security proxied lp.registry.model.person.Person instance at 0x2b5d6c031c50>, information_type, Unembargoed Security, Public)01:55
StevenK+BugInformationTypeChange(None, <security proxied lp.registry.model.person.Person instance at 0x2b5d6c031c50>, information_type, Unembargoed Security, <security proxied lazr.enum._enum.DBItem instance at 0x54ab810>)01:55
wgrantStevenK: Thanks01:55
wgrantWell01:56
wgrantYou could make it not wrong.01:56
mwhudsonzope.security woo01:56
StevenKwgrant: This explains why it's going wrong, though. Bug:+secrecy is calling transitionToInformationType directly which is firing off one notify. The JS is calling it via the API and lazr.restful is doing the notification and then transitionToInformationType is doing it.01:57
wgrantThat is clear, yes.01:58
StevenKIt's only clear to me as of 60 seconds ago.01:58
StevenKSo transistionToInformationType shouldn't notify if from_api is set, or is there a better pattern?01:59
wgrantIt should perhaps not notify at all. Check what corresponding things to, eg. status/assignee changes01:59
StevenKtransitionTo{Assignee,Target} at least don't notify02:01
* StevenK comments out the notify() and see what happens with Bug:+secrecy and the JS fire.02:02
StevenKwgrant: Looks like Bug:+secrecy requires the notify() at least.02:04
StevenKSo I can fix Bug:+secrecy to make an API call, which I don't like, or change transitionToInformationType to not notify() when called from the API, which I don't like either.02:05
wgrantOr change Bug:+secrecy to notify like other edit forms.02:05
wgrantThat is the correct solution.02:05
StevenKAh ha02:06
lifelessbac: if they are ordered on id, how are they failing - are the objects having the wrong ids, or was the sort actually undefined ?02:19
StevenKwallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/double-bugdelta-js/+merge/10431602:44
StevenKwallyworld: I think that MP might fix your double e-mail issues, too02:45
wallyworldcool02:45
wallyworldStevenK: should you do a check to ensure info type really has changed?02:47
wallyworldlike is done for private etc02:47
StevenKwallyworld: I just didn't want to unilattery notify on both fields there.02:49
StevenKFor information_type I don't think it matters02:49
wgrantStevenK: Did you try making it a LaunchpadEditForm?02:50
wgrantLaunchpadEditFormView, sorry02:51
wgrantThat should fire the events automatically.02:51
StevenKwgrant: Will that deal with private+security_related/information_type?02:52
wgrantStevenK: It diffs the objects like lazr.restful does.02:53
wallyworldStevenK: if you do use LEFV you will likely need to override updateContextFromData()02:55
StevenKI didn't know about LaunchpadEditFormView02:56
StevenKMy concern about diffing the object is private, security_related and information_type all change.02:57
wgrantStevenK: Doesn't the subscriber handle filtering that?02:57
StevenKI'm not certain, I'd left most of the notification stuff alone due to HBD02:58
StevenKI'd prefer to switch to LEFV when I drop the legacy behaviour.02:59
wallyworldthe ff complicates it so if it works as is i'm ok with that02:59
wgrantget_bug_changes filters based on the FF03:00
wgrantSo notifying with the entire diff should be fine.03:00
wallyworldStevenK: there were no failing tests, right? so do we need a test to check that notifications for info type are as expected?03:00
StevenKwallyworld: No, the tests all exist03:01
wgrantClearly not.03:01
wgrantbuildbot would have failed.03:01
wallyworldbut there we no failures03:01
StevenKI perhaps need a notification test when changing via the API03:01
wallyworldand/or a test that changing info type via the ui produces the correct notifications03:02
StevenKwallyworld: Given that involves JS, I'm not sure how to do that.03:02
StevenKWe know it fires the API call, if the API call only generates one notification we're good03:03
wallyworldjs is irrelevant here - you just need to write a normal view test03:03
wallyworldinitialise a view with form={} with the right things in the dict03:03
StevenKwallyworld: Right, hold on03:03
StevenKwallyworld: Bug:+secrecy has always done one notification, this branch doesn't change that.03:04
wallyworldi got 2 the other day03:04
StevenKwallyworld: The error this branch fixes is when you change the information_type via the JS on Bug:+index, since that uses the API.03:04
wgrantThe solution with the minimal amount of code, so minimal bugs, is to use LEFV03:04
wgrantSo use that03:04
wallyworldnot necessarily given the ff complication03:05
lifelessLEFV?03:05
StevenKLaunchpadEditFormView03:06
wallyworldLaunchpadEditFormView03:06
lifelessthanks03:06
wgrantLaunchpadEditFormView03:06
StevenKPeer pressure03:06
wallyworldwhat he said03:06
wallyworldStevenK: afaik, the js used to call the BugSecrecyEditView - there's even code in the submit action to handle it.perhaps it's changed now03:07
StevenKwallyworld: I'll switch it to LEFV, there is already notification tests for Bug:+secrecy, I'll write a webservice test.03:07
StevenKwallyworld: The legacy JS calls BugSecrecyEditView, yes.03:07
wallyworldah, ok. but the new js for the info type choice popup doesn't03:07
StevenKYes.03:08
wallyworldi didn't really that, sorry03:08
wallyworldrealise03:08
StevenKwallyworld: I thought I explained it well enough in the MP's description.03:08
wallyworldi makes more sense if i re-read it now. i didn;t connect legacy and js03:09
StevenKwgrant: Which is why I'm probably a little retiscent to change it to LEFV. The legacy JS calls the form.03:09
StevenKThe legacy *untested* JS03:09
lifelessWCPGW03:10
StevenKIt's already taken me four hours nailing down this issue in the first place.03:10
StevenKThe next time I want to touch this code is when I remove the legacy bits.03:11
wallyworld+103:12
wallyworldStevenK: i'm still i little curious why there were no failing tests, that's my remaining concern03:13
wallyworldideally you'd address that before landing03:13
StevenKwallyworld: Right, so I'm writing a webservice test now03:13
wallyworldok, r=me otherwise03:14
StevenKWhich will probably get interrupted by lunch, but meh.03:14
StevenKOh, blah. the bugchanges tests assume that transitionToInformationType is the one generating the notifications.04:09
StevenKwallyworld: http://pastebin.ubuntu.com/961639/04:34
StevenKwallyworld: That brings the information_type and visibility tests into line with things like IBugTask.status which make the change and then notify04:35
wallyworldlooking good so far, need to finish reading the diff04:36
StevenKwallyworld: I've confirmed that if I revert the changes in the MP you reviewed that the API test fails due to getting two notifications.04:37
wallyworldthat's helpful04:38
wallyworldStevenK: the change_activity 'person': private_bug.owner (was self.user); what's the reason for that?04:38
StevenKwallyworld: I'm notify()'ing with user=private_bug.owner, I can change that to self.user and revert those bits if you wish.04:39
wallyworldStevenK: i'd just do it the same as the other similar tests for consistency04:40
wallyworldwhatever way that is04:40
StevenKwallyworld: Fixed04:40
wallyworldthanks. send it to ec204:41
StevenKGladly.04:41
mwhudsondid you know04:41
wallyworldgood to see this one fixed04:41
mwhudsonthat editing shell scripts while they are running seems to be a bad idea04:41
wallyworldwho would have thought :-)04:41
mwhudsonwell it works for python scripts :)04:43
StevenKwallyworld: Let me XXX BugEditSecrecyView to note about LEFV too04:43
wallyworldsounds like a plan04:43
wallyworldcan't wait to get rid of more legacy04:43
StevenKTell me about it04:43
StevenKLaunchpad encountered an internal error during the following operation: generating an incremental diff for a merge proposal.  It was logged with id OOPS-b36d837108d341fbaba9b6ef591ac4f0.04:54
* StevenK stabs the job system over and over and over.04:54
lifelesswgrant: did you try using an aggregate + comparise rather than AND's ?04:55
lifelessor an aggregate with set ops ?04:55
wgrantlifeless: You mean the abomination that's used for structural subscription sorting and is slow as hell?04:56
wgrantNULL_COUNT and such?04:56
lifelessnot sure04:56
wgrantwell04:56
wgrant"comparise" isn't a word04:56
wgrantSo I was trying to work out what you meant04:56
wgrantAdding more aggregates is unlikely to help performance.04:57
lifelessbah, typo04:57
lifelessaggregate and compare04:57
wgrantIn this case the estimates are important for correct performance.04:57
lifelessand aggregates are throwing it off ?04:58
wgrantWhat sort of structure were you thinking of?04:58
wgrantI've found that aggregate conditions tend to be hard to plan through.04:58
lifelessmapping the tags into an array04:59
lifelesswhat performance do you get with the AND's ?04:59
wgrantRight, that's what's done for structural subscription filtering.04:59
wgrantThat's always entirely thwarted estimation when I've tried it in the past, but I'll recheck just in case.05:02
wgrantlifeless: I'm not sure it's feasible, given the complex constraints that are possible.05:11
wgrantWe could do it nicely with the complex query stuff in intarray05:11
lifelesswhat performance do you get with the AND's ?05:12
wgranthttps://pastebin.canonical.com/65322/05:13
wgrantThe FTI is pretty slow, but hopefully GIN will fix that.05:15
lifeless540 for a moderate search is fine05:15
wgrantFSVO05:16
wgrantWe've got that + a similar count right now05:16
wgrantSo it's more like 1.3s before we get any other time.05:17
wgrantIt actually ends up planning really well like this.05:17
lifelesswas thinking about counts05:17
lifelesswe could make that async05:18
lifelessissue two requests05:18
wgrantBecause it has accurate stats for fti and tags05:18
wgrantYeah, I've considered that fairly strongly.05:18
wgrantAlso remembering counts.05:18
wgrantAnd guessing from bugsummary sometimes05:18
wgrantMost counts can be satisfied straight from bugsummary05:18
wgrantAnd those that can't are mostly complex things with FTI that nobody will notice if they're cached for a while.05:18
lifelessmmmm05:19
lifelesscaches tend to get you in trouble05:19
wgrantAlthough the estimates are much better with bugtaskflat, so rough_length could possibly be a bit more workable.05:19
wgrantBut I still don't like it much for this sort of thing.05:19
lifelesssimple ones people complain about, complex ones are complex05:20
wgrantlifeless: Also, I have a branch landing in 30 minutes that rips out the oops_prefix per-section customisability, and was thinking of pushing forward the one-config-per-user thing next week so I can eliminate the rest. Any objections? Should basically just mean adding a few new configs, getting them deployed, throwing a crontab diff at LOSAs and getting a few init scripts fixed up.05:27
wgrantThen we can delete like 1000 lines of prod config :)05:27
wgrantAnd a similar amount of config schema.05:27
wgrant(we currently have lots of overrides in eg. the production config because different scripts run as different users, so need different error_dirs)05:28
StevenKwallyworld: Do you want to review https://code.launchpad.net/~stevenk/launchpad/bugs-factory-information_type/+merge/104326 ?05:32
lifelesswgrant: sounds lovely05:32
wallyworldok05:33
wallyworldStevenK: r=me05:40
StevenKwallyworld: Sorry for the massiveness05:40
wallyworldthat's what i say to the girls05:40
StevenKwallyworld: http://picardfacepalm.com/05:41
wallyworldwell, you started it :-)05:41
=== mthaddon` is now known as mthaddon
adeuringgood morning08:01
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
wgrantwallyworld: You didn't run your new table through ec2?08:54
wgrantLooks like it's missing person merge permissions.08:54
lifelessrollback time08:55
wgrantDinner time, actually.08:55
=== StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2
=== al-maisan is now known as almaisan-away
jmlheavens10:11
jmlI need to make my branch listing page more readable.10:11
jmlrick_h_: did you ever get any test results from that ec2 test run?10:17
rick_h_jml: that landed10:18
rick_h_and was merged I thought10:18
jmlrick_h_: there was another one10:18
rick_h_oh, I didn't complete the test run, I thuoght we were just debugging why it wouldn't run10:19
jmlrick_h_: it's not a huge deal. I'll probably be able to run it myself today.10:19
jmlrick_h_: ah, right :)10:19
rick_h_my apologies, I thuoght once you had it figured out why it was ok and set10:19
jmlrick_h_: np.10:19
=== danhg_ is now known as danhg
=== dpm is now known as dpm-afk
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: 3.47*10^2
deryckabentley, you meant that you and adeuring would stay on the call, right?  not me?13:44
abentleyderyck: yes.13:44
deryckabentley, great, thanks13:44
jmlhttps://code.launchpad.net/~jml/lp-dev-utils/public-ip/+merge/104273 needs review13:51
rick_h_hah, jml finding someone else today :P sorry abentley13:52
jml:)13:52
jmlgot this error on 'ec2 demo': http://pastebin.ubuntu.com/962408/13:53
jmland then this error after terminating with Ctrl+D: http://pastebin.ubuntu.com/962410/13:54
abentleyjml: why is it a guess?13:55
jmlabentley: because it might be wrong.13:55
abentleyjml: why might it be wrong?13:55
cjwatsonIn general, if your HTTP routing is different from your SSH routing.13:56
jmlabentley: I'm being pessimistic. checkip.amazonaws.com was wrong sometimes, I don't see what makes akamai guaranteed to not be wrong. All I know for sure is that it's less wrong than checkip.amazonaws.13:56
abentleycjwatson: fair point.  I suppose we could determine our IP via SSH?13:57
cjwatsonFor example, if you have a public IP address, but you connect through an HTTP proxy on another public IP address (say, for performance, or because it's mandated in some way by your network layer), then akamai would return the address of the proxy; but you might be connecting directly to the cloud instance over SSH.13:57
cjwatsonAmazon had the opposite problem; in proxy cases, it would always return the address of the client system as seen by the proxy, private or not.13:58
jmlhmm.13:58
cjwatsonI would argue that it's more common for Amazon's case to break, in the modern internet; but the other kind of breakage is *possible*.13:58
cjwatsonSo I support jml having added an option for this.13:58
jmlthen IIUC the correct thing is to always use the akamai address for 80 & 443 ports and only apply the provided IP to the SSH port?13:59
cjwatsonI don't know of any way to reliably determine our IP address via SSH, in the absence of some new service.13:59
cjwatsonjml: The behaviour in your MP is the best I can think of.13:59
jmlcjwatson: thanks.14:00
=== danhg_ is now known as danhg
abentleycjwatson: And yet, the who command knows your IP/domain, and when you log in, it will tell you your last ip/domain.14:00
abentleyjml: Anyhow, fair point that this is only a guess.14:01
abentleyjml: although if you SSH and HTTP routings are different, then security_group.authorize('tcp', 22, 22, '%s/32' % public_ip); security_group.authorize('tcp', 80, 80, '%s/32' % public_ip) is also wrong.14:03
jmlabentley: I think that's what cjwatson meant by "some new service". You'd need to have an SSH service up that could be got into by everyone who needs to run 'ec2 test'.14:04
jmlabentley: well, that's sort of what I thought, but cjwatson responded otherwise when I raised the question with him.14:05
cjwatsonabentley: But you only get to ask it that after you've told Amazon to authorise you to connect from a given IP address.14:06
cjwatsonabentley: Chicken and egg.14:06
abentleycjwatson: I see.14:06
cjwatsonjml: Oh, sorry, I misunderstood that part.  Um, maybe.14:06
abentleyjml: I'm not sure whether "transparent proxy" or "intercepting proxy" is the right terminology in this case.  Do you know?14:08
jmlabentley: no, I don't.14:08
abentleyjml: Okay, let's leave it as is.  Rob can tell us different if he wants.14:09
abentleyjml: r=me14:09
jmlabentley: thanks.14:09
cjwatsonabentley: Proper proxies have a problem too, anyway.14:25
=== dpm-afk is now known as dpm
nik90hi everyone, I would like to know how to read a user's translation activity using launchpadlib15:25
nik90this is for ubuntu accomplishments project started by jono15:26
nik90any help would be appreciated15:26
jmlnik90: hmm.15:43
jmlnik90: you know about the API, right?15:43
nik90jml: yes I did go through the API..but couldn't find a suitable one for translation...i am new to this..15:43
sinzuinik90, API does not provide that useful information. Some of this information is implied in karma activity which idoes not have the detail and not over the API15:43
nik90sinzui: oh so using the API, I cannot access the translation activity of a user but must rely on the user's karma?15:44
sinzuiNo, because karma is bogus.We only export a number which is itself ogus15:45
sinzuinik90, https://launchpad.net/+apidoc/devel.html does not provide any means to answer you questions15:46
nik90sinzui, that was the API list that I went through15:46
nik90sinzui, the closest I came to was the translation_import_queue_entries...but that could not check the translations still15:47
sinzuinik90, right, but entries in the queue is just uploading15:48
nik90sinzui, would I be able to use translation_template by checking with the user's name15:49
nik90would that check the translations?15:49
sinzuinik90, https://launchpad.net/~sinzui/+karma shows a bogus score for types of activity, and a list of recent activity15:50
nik90sinzui: hmm, yes it does..I guess that should do it temporarily15:51
nik90sinzui, the thing was, I wanted to confirm that the translation made by the user were approved and useful before giving the accomplishment15:51
sinzuinik90, I argue that we care about seeing the frequency of activity and batched listing that allows me to see contributions over a year, month, and week15:51
nik90but through this I wont be able to...but atleast I can check if they made a translation in the first place15:51
nik90sinzui: thanks for your help15:52
sinzuinik90, ah, that is a challenge. I really don't think that can be answered at all15:52
nik90sinzui: going through the api to distunguish between different karma15:53
sinzuinik90, we only provide a number over the API. karma is broken so we choose not to encourage people to use it over the API15:54
nik90sinzui: :( alrite that's ok15:55
=== salgado is now known as salgado-lunch
=== deryck is now known as deryck[lunch]
=== salgado-lunch is now known as salgado
=== matsubara is now known as matsubara-lunch
=== deryck[lunch] is now known as deryck
=== benji is now known as Guest45135
=== benji___ is now known as benji
=== matsubara-lunch is now known as matsubara
lifelessmorning18:47
lifelessderyck: / abentley: Are you guys planning on blogging (blog.l.n.) about the bundles-to-mp code being removed?18:55
abentleylifeless: no.18:56
lifelessabentley: is there more to it than that ?18:57
derycklifeless, hey.  I didn't think we needed much public notice for it....18:57
abentleylifeless: It's unlikely that anyone will notice, since no one's used the feature at all this year.18:57
derycklifeless, it hasn't been used since June of last year.18:57
deryckcalling attention to it seems like asking people who don't use it to complain about it being removed. ;)18:58
lifelessI can understand that angle19:00
lifelessOTOH we're been very forthright about other removals and redefinitions with a generally positive response.19:00
lifelessI think it is better to be clear than to have folk surprised later (even though that is unlikely).19:01
lifelessWe're doing a good thing here19:01
lifelessfocusing the system on what users need19:01
lifelessmaking it possible for us to develop and iterate faster19:01
lifeless*I* think you should be proud of the removal19:02
lifeless(btw, I presume you have it on your todo list, but https://help.launchpad.net/Code/Review still references the feature)19:02
abentleylifeless: Yes, I didn't want to remove it until the change had landed.19:03
lifelesscool cool19:04
rick_h_81683120:24

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