=== StevenK changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | firefighting: - | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews
=== lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews
=== matsubara is now known as matsubara-afk
lifelesssinzui: ping02:06
LPCIBotProject windmill build #91: FAILURE in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/91/02:06
lifelessthats better,02:45
lifelessmore closed bugs02:45
lifelessand one more hidden critical unearthed02:45
* lifeless resists the urge to start at bug oldest and walk forward02:55
lifelesswgrant: ping02:55
lifelessI'm pinging you cause curtis had better be asleep by now :) -  where is Cve:+index - is jc still on it, or would it be ok if I pick it up? its our #2 frequency OOPS02:56
wgrantlifeless: He's still on it.02:56
lifelesswgrant: have you poked at +needs-packaging at all ?03:08
lifelesswgrant: I'm struggling to find top-10 timeouts that are not fixed-undeployed, bugtask:+index, or in-progress by someone03:08
wgrantlifeless: Not at all.03:10
wgrantYou seem to love BugTask:+index03:11
lifelesswgrant: Not at all.03:11
lifelesswgrant: the next obvious thing is a paginated message display03:12
lifelesswgrant: which is to big for me: I get called away all over the place.03:12
lifelesswgrant: I mean, making a vertical page-reloading batchnav is easy.03:12
lifelesswgrant: making one that uses js to incrementally pull in new messages and actions and shows the comment form once you read to the bottom - a bit harder.03:13
lifelesswgrant: so other than ratcheting scaling down a bit more, I'm not likely to really touch it for a bit03:15
lifelessdammit, I need to finish my analysis of deletable bugtasks etc03:15
* lifeless adds a note to talk to jml about said03:15
lifelesswgrant: (oh, and I'd be delighted for someone else to do the next iteration on bugtask:+index)03:16
lifeless400ms overhead per page atm03:18
lifelessjust doing traversal03:19
lifelessprobably a busy appserver contributing03:19
mwhudsoni worry a bit sometimes about the minimum time launchpad can produce a page in03:27
mwhudson(i think it's quite a while, like 100ms)03:27
mwhudsonmaybe not that bad03:27
lifelessmwhudson: well, the page I'm looking at - 400ms minimum.03:28
lifelessmwhudson: trace the queries down to the session update after traversal03:28
mwhudsonlifeless: erk03:29
lifelesswe're still in phase one though - drive the 99th% percentile down by fixing poor scaling in pages03:29
mwhudsonoh that's the server machine wgrant is always complaining about isn't it?03:30
lifelessmwhudson: well, its not the hardware.03:30
wgrantIt's partly the hardware.03:30
lifelessmwhudson: its a 4-thread appserver with maybe 2-4 additional requests parsed and awaiting handoff03:30
lifelesswgrant: it really isn't :)03:30
wgrantlifeless: soybean has lots of them as well.03:30
wgrantBut we see most of our timeouts from the old appservers.03:30
mwhudsonlifeless: yeah, something smells off about that that's not entirely related to the code in lp:launchpad03:31
lifelesstonight is pounce on the sysadmins night03:31
StevenKPoor sysadmins03:31
lifeless(not nastily)03:31
lifelessjust that tom is the guy working this progression03:32
wallyworld_lifeless: if there's a bug with total crap in it (random text), do we just mark it as incomplete or do we need to get it deleted?03:34
lifelessinvalid probably.03:36
lifelesswhats the bug #?03:36
lifelesswallyworld_: ^03:37
wgrantwallyworld_: Sorry, I meant to look at that earlier, but got sorta distracted :/03:37
lifelesslol - classic - http://programming-motherfucker.com/03:38
lifelesswallyworld_: that seems to be outside the launchpad project?03:38
wallyworld_but it's an open lp question03:39
wallyworld_so i thought i'd clean it up since it's clearly a crap bug03:39
lifelessso there is no spam in it03:39
lifelessincomplete leaves it open03:39
lifelessI would make it invalid03:40
wallyworld_no. just crap03:40
cody-somervilleWhy does the series filter on the main pages of PPAs have such huge text? lol03:47
wgrantSomeone embedded a form inside a heading, and this was exposed in the recent style unifications.03:47
lifelessH1 is big03:48
lifelessI can has review https://code.launchpad.net/~lifeless/launchpad/bug-722794/+merge/54466 ?04:45
StevenKlifeless: Done, r=me04:51
lifelesswgrant: wtf: https://lp-oops.canonical.com/oops.py/?oopsid=1907C233705:36
lifelesswgrant: I'm pinging you cause you added the transaction status to the timeline :)05:37
wgrantlifeless: Huh.05:40
wgrantBut API timeouts normally work fine :/05:40
wgrantAlthough leonardr did change them recently.05:41
_mup_Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 >05:41
=== jtv is now known as jtv-eat
=== almaisan-away is now known as al-maisan
lifelesswhat does BuildFarmJob.status <> 1 OR BuildFarmJob.date_finished IS NOT NULL imply05:54
lifelessnot fullybuilt and finished ?05:54
lifelessthe query I'm looking at also checks for FAILEDTOBUILD05:54
lifelesscan I drop the BuildFarmJob.date_finished IS NOT NULL condition without breaking semantics ?05:54
lifelessthumper: https://bugs.launchpad.net/launchpad/+bug/730396/comments/906:03
_mup_Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 >06:03
wgrantlifeless: That query is stupid, yes. For some of the cases you can drop the first BFJ <> AND date_finished IS NOT NULL check, yes.06:15
wgrantlifeless: But we need to keep date_finished IS NOT NULL if status == 1.06:15
lifelessso over here06:18
lifelessif we don't gc builds06:18
lifelessthere is no point reading all *FTBFS* rows every time06:18
lifelessfull stop06:18
StevenKHmmm, looks like I didn't kill dogfood06:18
wgrantlifeless: If we move to an incremental model, sure.06:19
wgrantlifeless: But then we'd need to read all recent successes too.06:19
lifelesswgrant: why?06:19
wgrantlifeless: Because we need to be able to remove failures that are no longer failures.06:20
lifelesswgrant: do they get removed from this collection?06:20
wgrantIf we're not reading the whole failure collection, we need to read every other collection.06:20
lifelesswgrant: do they get removed from this collection?06:23
wgrantlifeless: Which collection?06:25
wgrantlifeless: A retried build is not a new build.06:25
wgrantA retried build will disappear from this page.06:25
wgrant(unless it fails again)06:25
lifelesswgrant: so, we do gc06:25
lifelessor are you asying we reuse the BFJ ?06:25
wgrantWe reuse the BFJ.06:26
* lifeless headdesks06:26
wgrantSomeone made this decision 6 years ago, and uh, yeah.06:26
lifelessI'd read all collections incrementally06:26
lifelessthat seems cheap and effective as long as you don't shutdown for a month06:27
lifelesswgrant: what rev has leonards change for timeouts ?06:28
wgrantlifeless: It was a lazr.restful upgrade.06:28
lifelessmeh, I'll raise a critical06:29
wgrantI'm pretty sure this worked after my changes, although it's clearly somewhat related.06:29
=== al-maisan is now known as almaisan-away
_mup_Bug #740750: API timeouts broken and returning no useful data... <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 >06:33
pooliebig f* jools?07:05
lifelesspoolie: ?07:11
poolie<wgrant> We reuse the BFJ.07:15
lifelesspoolie: before his time07:16
StevenKpoolie: Build Farm Job07:16
pooliehttps://bugs.launchpad.net/launchpad/+bug/740759 might amuse you07:17
_mup_Bug #740759: creating bzrdir on launchpad is slow (BzrDirFormat.initialize_ex_1.16) <codehosting-ssh> <hpss> <lp-code> <performance> <Launchpad itself:Triaged> < https://launchpad.net/bugs/740759 >07:17
adeuringgood morning08:28
=== StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
=== almaisan-away is now known as al-maisan
lifelessstub: hi09:03
lifelessstub: how are you feeling?09:03
stubBetter today... slept 13 hours straight last night.09:03
=== jtv-eat is now known as jtv
lifelessstub: good timing - we tried your live index docs but got the patch number wrong: https://code.launchpad.net/~wgrant/launchpad/fix-patch-57/+merge/54481 is meant to fix it, but wanted to confirm: is the db patch *in the tree* meant to be a .1 patch, or a .0 with the same major as the one done live ?09:04
wgrantI think the numbers have to match./09:04
wgrantOr it will be reapplied on the next db-deploy and then blow up.09:04
wgrantI think.09:04
stubdb patch in the tree is supposed to be a 2208-xx-01 (or -02 etc.) patch. The number should match what you inserted into LaunchpadDatabaseRevision on production09:04
pooliewould i be right in expecting that the qastaging database will be generally faster than lpnet?09:05
pooliebecause of less load09:05
wgrantIt's a much smaller DB server.09:05
wgrantAnd the cache will be colder.09:06
stubWhy this works - Launchpad appservers check LaunchpadDatabaseRevision for patches that have been applied that are not in the local source tree, and for patches in the local source tree that have not been applied. It ignores all patches that are non-zero in the 'patch' field.09:06
StevenKSo it's generally slower09:06
stublifeless, wgrant: So that patch seems correct, and matches what I see on the production db. Did the patch also get applied to launchpad_prod_2 and launchpad_prod_1 ?09:07
lifelessstub: yup09:08
stubSo it worked out best with id in the first field of the index?09:08
wgrantstub: It was applied as -0 to all three.09:08
lifelessstub: it was a lopsided problem09:08
stubI don't see -0 in LaunchpadDatabaseRevision - I only see 57-109:08
wgrantstub: Right, we had to fix it when an appserver failed to start.09:08
lifelessstub: we tried a number of permutations on qastaging, and found that a partial index on the queues that are driven to 0 (the NEW and INCOMPLETE) performed very well09:08
wgrantlifeless: NEW and UNAPPROVED09:08
stubI thought the index would have worked better with id in the last field, as the ordering would have been done last, but I hadn't checked and wasn't sure.09:09
wgrantstub: As would I. I didn't follow lifeless' trials very closely, though.09:09
lifelesscan't do id last09:09
lifelessnot without a bunch of headaches09:09
lifelessright now we use one query for both:09:10
lifeless - queue processing09:10
lifeless - historical data analsis09:10
lifelesspg won't use the indices we tried with id last, unless the full index sort was given09:10
lifelessarchive desc distroseries desc setc09:10
lifelessit *will*, but not for status=0 [or 1 we are pretty sure]09:11
lifelessbecause its a lopsided data problem09:11
lifeless status |  count09:11
lifeless      4 |    577709:11
lifeless      1 |     18209:11
lifeless      2 |   4749409:11
lifeless      3 | 228983109:11
lifeless      0 |   4096109:11
wgrantUm what?09:12
wgrantThat's about 41000 more with status 0 than I would expect.09:12
lifelesswgrant: indeed, but not enough to worry the index09:12
wgrantEnough to worry me, though...09:12
lifelesswgrant: sure, separate problem09:13
wgrantSimilar on mawson.09:13
wgrant      0 |           97 | 4087709:14
wgrantDistroseries 9709:14
lifelessstub: so the headaches are: we would have to either: split out a separate query for the historical data, if we changed the status 0 case to use archive desc distroseries desc status 0 desc id desc09:14
lifeless     (because the historical data /wants/ id as the first sort key - and pg does a decent job there today)09:15
lifeless or09:15
wgrantbigjools: Old archive rebuilds :(09:15
lifelesswell, no or09:15
stublifeless: Sure. I recall the query. I'm interested in you found it works best with the id in the sort key. I think we have similar cases elsewhere - bugs or bugtask I think.09:15
lifelessbasically, there are two totally different use cases in the one table09:15
lifelessstub: only because its essentially a micro-table embedded in the bigger one09:16
lifelessstub: thats why adding a partial index gave good results - -very- fast results once applied [to that particular query]09:16
bigjoolswgrant: grar09:17
wgrantbigjools: 2009ish09:17
bigjoolslet's clear those out09:17
wgrantSo long-fixed.09:17
wgrantBut yes.09:17
lifelessstub: its possible you can come up with something better09:17
wgrantAlso, accepted is pretty big... probably newer copy archives.09:17
wgrantIndeed, the newer copy archives.09:18
stublifeless: If you tried the partial index on (distroseries, archive, id) instead of (id, distroseries, archive), that would be all I'm interested in at the moment.09:19
lifelessstub: but the nice thing here was that the partial index was small - 1280 kB09:19
stublifeless: I think in earlier versions of PG, the index would not have been used at all because the first field in the index was not used until the very end.09:20
lifelessstub: we didn't try that variation, no09:20
bigjoolswgrant: we need a way of cleaning out copy archives entirely09:21
wgrantbigjools: Yes.09:21
bigjoolswgrant: I want to make derived distros supersede them09:21
lifelessstub:  Limit  (cost=0.00..104.34 rows=31 width=36) (actual time=0.132..83.965 rows=1 loops=1)09:21
lifeless   ->  Index Scan Backward using packageupload__distroseries__status__archive__idx on packageupload  (cost=0.00..5287.65 rows=1571 width=36) (actual time=0.131..83.961 rows=1 loops=1)09:21
wgrantbigjools: An interesting plan.09:21
lifeless         Index Cond: (distroseries = 104)09:21
lifeless         Filter: ((archive = ANY ('{1,534}'::integer[])) AND (status = 0))09:21
lifeless Total runtime: 84.023 ms09:22
lifelessstub: ignore the index name, thats on qastaging where we were experimenting09:22
bigjoolswgrant: they're essentially the same thing, but copy archives have a spethial UI09:22
lifelessstub: also - thats *cold* runtime09:22
wgrantbigjools: Indeed.09:22
stublifeless: Right. So in PG 8.4, it might well be more efficient to put the field we are ordering on first, and the ordering and filtering done in one index scan.09:23
lifelessstub: at least sometimes, yeah09:23
stubWhich is different to how we optimized stuff before elsewhere in the schema. Might be some room for improvement there.09:23
bigjoolswgrant: OOPS-1907BUILDMASTER3 ....09:25
stublifeless: Where the live rollout docs good enough for the losas to apply the patch without hiccups?09:25
wgrantbigjools: What about it?09:25
lifelessstub: yup, except we got the patch # wrong09:25
wgrantbigjools: It's annoying, but ordinary and harmless.09:26
bigjoolswgrant: it should not be an oops09:26
wgrantbigjools: Sure.09:26
bigjoolswell, we could see if someone deleted the source09:27
wgrantSomeone uploaded one to supersede it.09:27
bigjoolsor that09:27
stublifeless: Right. Applying a -0 patch live would mean the appservers fail to restart, so wouldn't even be immediately noticeable.09:27
bigjoolsthat oops happened 3 times09:27
wgrantbigjools: Different archs?09:27
bigjoolsah might be09:28
wgrantHm, no.09:28
wgrantDifferent series.09:28
lifelessstub: we only caught it when we tested dropping the appserver name from the lpnet configs and found it broke09:28
lifelessstub: so the name in db-devel is meant to be -1 ?09:28
stublifeless: Yes.09:28
stublifeless: Anything non-zero in that field. A non-zero in the 'patch' field means ignore this on runtime checks - it is a minor patch and you shouldn't care if it has been applied or not. Matches our life updates usecase exactly, so yay for prescience.09:29
lifelessstub: kk09:30
henningejtv: Hi!09:31
jtvhi henninge09:31
henningejtv: Are your reviewing today?09:31
jtvhenninge: oh, completely forgot about it.  :(  OTP now.09:31
stublifeless: Hmm.... in fact, I can't see why -1+ patches can't land on launchpad/devel ....09:32
henningedanilos should be reviewing today, too. ;-)09:32
lifelessstub: that would be great09:32
stubWhere does that rule get changed now?09:33
lifelessthe pqm config09:33
lifelessits out of the tree09:33
wgrantHeh, the first time it's needed a change in almost three years, a month after I argued that it never needed changing...09:34
stubI think we just need to block *-0.sql from landing on launchpad/devel now. No problems landing updates to the scripts, security.cfg or minor db patches.09:36
stubAnyone see a problem with that rule?09:36
wgrantNope. We should also drop the conflict check while we're there, since it doesn't work.09:36
wgrantAnd is pointless.09:36
lifelessfine with me09:36
stubwgrant: Do you want to file an RT explaining that conflict check thing, or do you want to explain the conflict check thing to me so I can file the RT ?09:38
wgrantstub: https://pastebin.canonical.com/45073/ is the current hook.09:39
stubMY EYES!09:40
wgrantstub: The second bit (bzr ls -0 [...]) is meant to check for conflicts, but doesn't actually work. I considered removing it when we migrated the check from the tree to PQM, since it seems pretty pointless, but decided to make as few changes as possible.09:40
stubSo precommit_hook=[ -z "$(bzr status -S database/schema/ | grep '-0.sql$')" ]     ??09:43
wgrantstub: Don't need to protect fti.py or anything?09:44
stubwgrant: fti.py is 50/50 - adding a new index could futz things, changing an existing one will not (the column will exist, it just won't have the expected data in it)09:45
wgrantSounds good, then.09:47
wgrantRT time.09:47
stubI guess we should block it - we likely won't change anything there anyway until we know where our search is heading.09:47
wgrantstub: Thanks for the review.09:47
stubprecommit_hook=[ -z "$(bzr status -S database/schema/ | grep -e '\(-0\.sql\|/fti.py\)$')" ]09:55
stubis what I end up with09:55
wgrantLooks sensible, as long as it works.09:56
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews
henningedanilos! ;)10:55
daniloshenninge, :)10:55
daniloshenninge, I don't know what you've been talking about ;)10:55
henningedanilos: I do, though! Can I please have a review?10:55
daniloshenninge, sure thing10:56
henningedanilos: diff is only 1075 lines10:56
daniloshenninge, ha-ha-ha10:56
daniloshenninge, ok, I'll take it10:56
henningedanilos: thanks10:56
=== al-maisan is now known as almaisan-away
daniloshenninge, btw, just looking through proposal text, "shortlist" is especially recommended when you expect something to return a short list10:58
daniloshenninge, because then it catches bugs early10:58
henningedanilos: oh, i thought it was about cutting a list off.10:58
daniloshenninge, no, it throws an OOPS/exception when hard limit is broken10:59
henningeso using shortlist is saying "tell me if this ever gets longer than X"10:59
henningedanilos: thanks, I did not know that. I am happy to put it back in, then.11:00
daniloshenninge, yeah, it's a developer tool :)11:00
daniloshenninge, I don't know in what context did you drop it, so it all depends on that, but just clarifying what shortlist is about11:00
LPCIBotProject windmill build #92: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/92/11:01
deryckMorning, folks.11:03
daniloshenninge, good job clearing the inter-dependency between template count and uses-translations11:05
henningeyeah, that was strange to see11:06
daniloshenninge, not yours, but line 226 of the diff: "hidding"11:16
=== jtv1 is now known as jtv
daniloshenninge, in TranslationTemplatesCollection, I am surprised target_pillar is not used anywhere, but since it's apparently not, good cleanup there as well :)11:29
henningedanilos: yes, that was only used to access translation_usage in getCurrentTranslationTemplates11:30
daniloshenninge, also, instead of listifying stuff in tests, I suggest you use assertContentEqual instead11:31
daniloshenninge, unless where you want to compare the order as well11:32
daniloshenninge, fwiw, this is probably irrelevant comment when you get shortlist back :)11:32
daniloshenninge, also, I'd rather see test_has_obsolete_translation_templates as 3 separate tests11:33
daniloshenninge, or 411:33
daniloshenninge, and also, you probably inserted list() on diff line 116 because you removed the shortlist as well, so that can probably go (and if you decided not to re-insert shortlist, this is where you should use it)11:36
daniloshenninge, r=me11:38
henningedanilos: yup, that's just because of shortlist.11:38
henningedanilos: thanks11:38
daniloshenninge, up to you to decide if you want shortlist back or not, not a big deal either way11:39
henningedanilos: I felt the same about test_translation_templates but I played along with what the rest of the file was doing.11:39
henningeI may just split up the other tests, too.11:39
daniloshenninge, right, we did write tests that way in the past11:40
henningedanilos: And I was always the one saying "one assert per test"!11:40
daniloshenninge, that'd be great, but if it gets complex, it might mean a new branch11:40
* bigjools waves at danilos11:40
henningeI'll have a look11:40
daniloshenninge, heh, well, that is tricky because we sometimes use asserts to make sure input data is right11:40
danilosbigjools, hi there11:41
henningedanilos: ok, that is only a guideline.11:41
danilosbigjools, I hope you just look forward to hearing my lovely voice :)11:41
bigjoolsdanilos: are you reviewing?  I have a short branch11:41
danilosbigjools, yeah, I do (but I am disappointed ;)11:41
danilosbigjools, pass it on, just done with henninge's11:41
bigjoolsdanilos: I miss your booming presence on the TL calls :)11:41
daniloshenninge, yep, cheers11:41
danilosbigjools, ok, now I feel better, thanks :)11:42
bigjoolsdanilos: https://code.launchpad.net/~julian-edwards/launchpad/localdiff-sync-bug-739525/+merge/5449611:42
danilosbigjools, branch sounds like a nice feature, but you've got a single lint issue so please fix it (I understand it may not be from your changes :)11:44
daniloslooking at the code now11:44
LPCIBotProject windmill build #93: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill/93/11:45
bigjoolsit was my lint11:45
danilosbigjools, I am sad to see a message like "The following sources *would have been* synced if..." go from the real UI11:48
wgrantbigjools: Have you worked out how permissions are going to work?11:50
danilosbigjools, r=me, but I'd also remove the "XXX" from a comment about a thing you are not really going to fix unless it proves to be broken11:50
bigjoolsthanks danilos11:50
bigjoolswgrant: right now it's launchpad.edit on the series11:51
wgrantbigjools: launchpad.Edit and launchpad.Append (since you need Append to run syncSources)11:52
bigjoolsthis will all fall out in the wash when we start doing intensive testing11:52
wgrantAnd then we realise we need queues.11:52
bigjoolswhich Steve is doing tomorrow :)11:53
wgrantAnd then you have an excuse to fix copying.11:53
bigjoolsqueues would be nice11:53
bigjoolsI might have to badger flacoste and jml about that11:53
jmlmushroom! mushroom!11:53
=== matsubara-afk is now known as matsubara
=== almaisan-away is now known as al-maisan
sinzuijcsackett: I Untriaged bug 740225. The former rosetta team need to explain if this was inteded and why or if it is a regression. The behaviour is correct for Ubuntu so it appears to be by design13:29
_mup_Bug #740225: The differences between New and Translated for upstreams was removed <rosetta-imports> <upstream-translations-sharing> <Launchpad itself:New> < https://launchpad.net/bugs/740225 >13:29
stubAre lp-propose-merge bugs bzr bugs or something else?13:36
jcsackettsinzui: understood.13:39
jcsackettsinzui: do you remember the issue you helped oem with regarding filing bugs in IE?13:42
jcsacketti believe it was an issue with an error popping up on the summary field? i've got an open question about it, and was wondering if there was a bug filed. i can't find one.13:43
sinzuijcsackett: The JS to populate the matches and enable the continue actions does not work in IE. It is impossible to report a bug since the user is forced to use the guided process13:44
sinzuijcsackett: The bug is filed and has many dupes. tag: javascript, text ie or ie8 or ie713:45
jcsackettah right, tags!13:45
* jcsackett never remembers tags when bug searching.13:45
sinzuifirst match13:46
sinzuiI always use tags but I hate the default ANY, I am not sure I have ever used ANY in a search13:46
=== mrevell is now known as mrevell-lunch
abentleyadeuring1: bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/js-translation14:02
abentleyadeuring1: https://code.launchpad.net/~abentley/launchpad/js-translation/+merge/5406714:03
henningederyck: I'll restart14:06
abentleyadeuring1: do you want to chat in mumble about the template changes?14:10
adeuring1abentley: no yet, let me first read a bit more14:10
abentleyadeuring1: okay, ping me whenever.14:10
leonardrdanilos, would you take a look at https://code.launchpad.net/~leonardr/lazr.restful/integrate-strict-versioning/+merge/54530 ?14:15
adeuring1abentley: so your idea is to always render both variants of "X is configured/not configured" and to make the "wrong" variant invisible via CSS, right?14:16
abentleyadeuring1: right.14:16
adeuring1ok, so no need to mess with the menu:overview stuff, i think14:16
adeuring1abentley: ^^^14:16
abentleyadeuring1: Actually, we probably do.14:18
adeuring1abentley: why?14:18
danilosleonardr, after lunch, sorry14:18
abentleyadeuring1: The icon is supposed to vary between "plus" and "edit".14:18
adeuring1abentley: ah, right14:18
abentleyadeuring1: Depending on whether there's already a value.14:18
abentleyadeuring1: But that state is frozen when the template is rendered.14:19
abentleyadeuring1: So either we get two plusses or we get two edits.14:19
jamdear codehosting devs, why is my +junk branch trying to stack on /~sathishmanohar/junk/main14:19
jamah, stupid me, doing '/junk/" without the +14:20
abentleyjam, right.14:20
jamI only noticed because it fails on qastaging because 'junk' doesn't exist14:20
=== abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: danilos, abentley | https://code.launchpad.net/launchpad-project/+activereviews
=== mrevell-lunch is now known as mrevell
jcsackettdanilos or abentley: could i request a review of https://code.launchpad.net/~jcsackett/launchpad/set-question-message-visibility/+merge/54408?14:26
jamany way to bulk upload attachments? I have 6 attachments I want to add to a bug, and it is a pain to do them one-by-one14:27
benjijam: not that I know of; I wonder if a little launchpadlib script would be helpful, but it will take longer to write than just doing the uploads14:31
abentleyjcsackett: sure.14:37
abentleyjcsackett: You say "the branch partially relies on a branch that exposes Question on the webservice".  This sounds like a prerequisite branch to me.14:38
abentleyjcsackett: Do you know about prerequisite branches?14:39
LPCIBotProject windmill build #94: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/94/14:52
jmlabentley: I learnt a thing about the job system today. It uses Python imports as a registry.14:58
abentleyjml: that doesn't parse.14:59
jmlabentley: as in, it very strongly encourages job sources to be defined as classes that have all of their state on the class so that it can then load these classes using import/module-lookup/getattr-fu in other processes.15:00
abentleyjml: this is true.15:01
jmlabentley: so in this regard, it's using Python's namespace/import system as a registry of job sources. sort of.15:02
jmlabentley: I bumped into this because I thought having an instance job source would make testing easier, so I gave it a try.15:03
abentleyjml: Seems like a stretch to me, unless you think that most python functionality uses imports (by which you mean packages/modules?) as a registry.15:03
jmlabentley: well, maybe it is a stretch. it's just that I can imagine alternative implementations that make as much sense as importing that are more obviously registry-like15:04
abentleyjml: In which case, it doesn't seem worth mentioning.15:04
jmle.g. pickling the job source to a known directory and passing the filename through to the child process15:04
jmlor having a config file that maps names to ways of acquiring job source objects.15:05
abentleyjml: we actually do have a config that maps names to job source classes.15:06
jmlabentley: class names in Python modules?15:07
abentleyjml: No, when we use cronscripts/run_jobs.py, we pass in a config name, which includes the job source as one of its variables.15:09
abentleyjml: e.g.  packaging_translations15:10
jmlabentley: hmm. that's a more flexible than the TwistedJobRunner. Still assumes a particular mechanism for acquiring the IJobSource object though (it has to be a member of a module, available on import).15:13
abentleyjml: I don't think it's more flexible.  I can easily imagine using it with the TwistedJobRunner.15:14
jmlabentley: you'd have to change TwistedJobRunner first, surely15:14
abentleyjml: what would I need to change?15:14
jmlabentley: the bit where it figures out the import name based on job_source.__name__15:15
abentleyjml: why?15:15
jmlabentley: to use a non-class object as a job source15:15
abentleyjml: I expect an interface to correspond to a class.  Don't you?15:16
jmlabentley: Yes, but that's not what I mean.15:16
jcsackettabentley: sorry i missed your comment earlier. i know about prereq branches, but the the prereq branch had other stuff that messed up the diff, as i only brought over the webservice bits.15:17
jmlabentley: the TwistedJobRunner theoretically expects a job source object that provides ITwistedJobSource. The implementation demands that it is a class that classProvides ITwistedJobSource.15:18
abentleyjml: From an interface, we get a class, from the class, we get job_source.__name__, what's the issue?15:18
abentleyjml: still not following why I'd need to change TwistedJobRunner to make it work with run_jobs.15:19
jmloh right.15:19
jmlabentley: run_jobs takes an arbitrary name to import, TwistedJobRunner infers the name from the passed in job source object (which has to be a class)15:20
LPCIBotProject devel build #569: FAILURE in 4 hr 52 min: https://lpci.wedontsleep.org/job/devel/569/15:20
abentleyjml: right, but these conditions are met for all of our job sources, so I don't need to address that in order to use TwistedJobRunner.15:23
jmljob_source = somethingThatMakesAJobSource(); runner = TwistedJobRunner(job_source, ...); ... will explode unless job_source has a __module__ and __name__ and can be reconstructed by importing "%s.%s" % (job_source.__module__, job_source.__name__)15:23
sinzuijcsackett: set  ~jcsackett/launchpad/questions-on-webservice  as a dependency of https://code.launchpad.net/~jcsackett/launchpad/set-question-message-visibility/+merge/5440815:23
jcsackettsinzui: ok.15:23
jmlabentley: of course. I was trying something different and discovered these conditions.15:24
adeuring1abentley: I think there is a more fundamental problem with the approach to hide  the "wrong" <li> entries via CSS: If no packaging link is set, we can't generate the links "set source branch", "enable translations", "enable auto sync" at all: We don't know which target to use...15:25
jcsackettsinzui: is there a way to do that without redoing the proposal?15:26
abentleyadeuring1: I've already addressed that for the branch link.15:26
abentleyjcsackett: You resubmit the proposal.15:26
adeuring1let me look...15:26
abentleyadeuring1: It creates an empty link.15:26
adeuring1abentley: ah, right!15:26
sinzuijcsackett: you may hate me. We should not export Question.priority. It is unused15:27
adeuring1abentley:  regarding the icons: I think we always have the pencil icon. So I think we don't have to tinker with the menu: stuff15:28
jcsackettsinzui: that's an easy fix. no need for hate. :-)15:28
abentleyadeuring1: that's nice, but it's inconsistent with how we're handling branches.15:29
abentleyderyck: adeuring1 reports that productseries always has an edit icon, never an add icon, unlike branches.  Should we make them consistent?15:30
deryckabentley: I would think consistency would be better, yes.15:34
leonardrbenji, i'd like to go over lp:~leonardr/launchpad/explicit-versions with you, both to do review and to bring you up to speed on my changes15:34
abentleyjcsackett:   If you base your branch on the other branch, it's much clearer what came from what.  Why did you only bring over the webservice bits from the other branch?15:35
jcsackettabentley: prereq was based on devel, this is db-devel. didn't want all the changes coming across before pqm brought them over automatically.15:36
LPCIBotProject windmill build #95: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill/95/15:36
benjileonardr: sure; I'm deep in something at the moment; how about after lunch (1 ish)15:36
abentleyderyck: Do you want to change branch so it only uses edit, or productseries so it uses add and edit?15:36
jcsackettabentley: in retrospect, questions-on-webservice probably should have just been based on db-devel as well.15:36
deryckabentley: can productseries be none intially?  (I assume so)15:37
deryckabentley: if so, that should behave like branch then.15:38
abentleyderyck: Yes, and this is the most important case.15:38
deryckabentley: yes, so it should get an add icon to start with, I think.15:38
abentleyadeuring1: ^^ could you do this as part of your work, please?15:38
adeuring1deryck. abentley: yes.15:39
abentleyadeuring1: thanks.15:39
danilosleonardr, looks good, r=me15:42
abentleyjcsackett: I wouldn't worry overmuch about applying the changes before PQM brings them across automatically.  You might get a criss-cross merge, but --lca or --weave merge should handle it fine.15:43
jcsackettabentley: dig.15:43
=== al-maisan is now known as almaisan-away
jcsackettif you like, i can merge the prereq completely in before you review.15:43
jcsackettabentley ^15:44
abentleyjcsackett: I don't think I need that.  It just stuck out as weird, and I didn't want to start reviewing until I understood what was going on.15:45
jcsackettabentley: got it. sorry for the oddities.:-)15:46
=== danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews
abentleyjcsackett: For your tests, did you consider using WebServiceTestCase?15:53
jcsackettabentley: i did not. i am not aware of WebServiceTestCase15:53
abentleyjcsackett: It allows you to test your code using launchpadlib.15:54
abentleyjcsackett: So you're testing something closer to what users will actually use, and it's closer to native code, too.15:55
sinzuijcsackett: I had a few notes about the branch too. I added them to the MP15:56
=== deryck is now known as deryck[lunch]
jcsackettabentley: seems worth looking at then. :-)15:58
jcsackettthere are a lot of tests i've seen that could benefit from that.15:59
abentleyjcsackett: it's similar to what you're doing in TestSetCommentVisibility, only generic.15:59
sinzuijcsackett: wgrant. allhands should know about your participation in the 2011 campaign now.15:59
abentleyjcsackett: Why are you testing the XHTML?  This seems like your are testing the webservice implementation, not your exports.16:01
jcsackettabentley: it looks like even the "clean" diff i pasted in has some noise--if you're looking at TestQuestionRepresentation, that's from the other branch. sorry.16:04
abentleyjcsackett: yes, I was.16:05
jcsacketti'm not sure why that made it into the diff i generated.16:05
sinzuiabentley: jcsackett: this testing point relates to my experience with anon users and representations. The simple doctests for the representation easily documents what anon users can see16:05
sinzuijcsackett: and about my anon + IQuestionMessage remark on the Mp, may be we do not want them public, see bug 74020816:06
abentleyjcsackett: Was there a preimplementation discussion?16:10
jcsackettyes, sinzui and i have talked a lot about how to go about this.16:10
* jcsackett sees he skipped that bit in the proposal.16:11
abentleyjcsackett: 1 out of 1 abentleys recommend lp-propose for all your merge-proposing needs.16:12
stubabentley: Are lp-propose bugs bzr bugs or some other package?16:13
abentleystub: bzr, I would say.16:13
jcsackettabentley: i have actually used lp-propose before, and while it opens a local editor and then pushes the whole thing to lp, it doesn't do so from a template. is there a config step i missed for that?16:14
abentleyjcsackett: You may be missing the lpreview-body plugin.16:14
jcsacketti am indeed.16:15
abentleyjcsackett: try apt-get install bzr-lpreview-body16:17
jcsacketti have it now. i'll see if alls well on the next branch.16:19
abentleyjcsackett: cool.16:20
=== fjlacoste is now known as flacoste
benjileonardr: ready when you are17:07
leonardrbenji, let's go17:08
leonardrhave you read the mp?17:08
benjilooking at it now17:09
=== beuno is now known as beuno-lunch
benjileonardr: ok, the MP makes sense17:12
leonardrbenji: and you understand the basic require_explicit_versions rule, right?17:13
benjileonardr: yep, I believe so (its intent if not yet its implementation)17:13
leonardrok, take a look at apihelpers.py to see how i hack into the implementation17:14
benjiwhy did you have to add all the patch_entry_explicit_version calls in _schema_circular_imports?  Is it really circular imports or something else?17:14
leonardrbenji: it's something else, but it's the same kind of 'patch everything' logic17:16
leonardri'm ok with moving it though the imports would be a pain17:16
benjijust I wonder if making a new module and copying over all the imports and then running that through the linter to show unused imports would work well enough to make it worth it17:17
benjiwould those ideally be in the same file where the interface is defined?17:18
leonardrbenji: yeah, but if you're going to go through that much trouble it approaches the amount of work necessary to just stop using it17:20
benjithat makes sense; I'm cool on leaving them where they are.  I might try the move-and-lint trick if I get 15 minutes.17:21
=== deryck[lunch] is now known as deryck
bigjoolsnight folks17:56
=== beuno-lunch is now known as beuno
abentleyderyck: chat?18:32
deryckabentley: I can't sorry.  Sorry.  Having to pull double duty now, since wife just came home sick.  Kids need moderate supervision.18:47
abentleyderyck: okay.  Will want to chat tormorrow about branch picker and vocabulary context.18:48
=== Ursinha is now known as Ursinha-lunch
deryckabentley: sure.  we can do it first thing tomorrow.18:50
sinzuijcsackett: mumble?19:01
jcsackettsinzui: oh, it is 3. one sec.19:01
jcsackettabentley: my earlier mp is updated, both with new diff and comments.19:02
abentleyjcsackett: cool.  I'll have a look.19:03
sinzuijcsackett: http://pastebin.ubuntu.com/584448/19:16
jcsackettabentley: ws_object is now used in the test, and your question about endInteraction was answered.19:46
LPCIBotProject devel build #570: STILL FAILING in 4 hr 53 min: https://lpci.wedontsleep.org/job/devel/570/20:14
=== Ursinha-lunch is now known as Ursinha
lifelessgary_poster: hi20:18
lifelessgary_poster: I noticed this - https://bugs.launchpad.net/launchpad/+bug/741234 - by chance when looking at a timeout20:18
gary_posterlifeless hi20:18
lifelessgary_poster: I don't know if you want to pick it up or not, I may well be misremembering which squad changed the visibility rules20:19
_mup_Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment <Launchpad itself:Triaged> < https://launchpad.net/bugs/741234 >20:19
lifeless[I probably am misremembering]20:19
gary_posterlifeless, I don't *think* we touched that...it certainly doesn't ring any bells20:19
lifelessgary_poster: de nada :)20:19
jmllifeless: Red squad will be doing disclosure/visibility once one of the current squads finishes up20:20
lifelessjml: cool20:22
lifelessjml: this was missed during a change in the last few months which is why I mentioned it20:22
lifeless-> dentist20:22
sinzuijcsackett: how goes CVEs?20:32
jmlhttps://code.launchpad.net/~jml/launchpad/test-timeout-505913/+merge/54598 – fix for an intermittent failure (I think)20:32
jmlwgrant: ^^20:33
jcsackettsinzui: i got derailed by a hardware issue, but i think what we chatted about is showing promise.20:37
jcsacketti'm having to fight my desire to do something about the nested chain that is the various nomination-rows &c.20:38
sinzuijcsackett: are you working with BugLinksListingView ?20:38
sinzuiI see the pairing of the view to the template is broken. That view ensures can_view_bug is available to avoid security checks, but the template ignores it in two cases. I think that view should also use the trick I showed you to change the security checker on the object so subsequent checks are fast20:40
jcsackettsinzui: how can you tell it is broken? i recall odd behavior when i was looking at this last which that might explain.20:44
jcsackettthough i just have the recollection of said behavior, and can't recall exactly what it was.20:44
* jcsackett needs to take better notes.20:44
sinzuijcsackett: view build a dict of bug info to show. It recovered from an Unauthorized error and adds 'can_view_bug': False. The template does not need to call required:launchpad.View on the bug!20:45
sinzuijcsackett: I am sure the adaption to +bugtasks-and-nominations-table also calls permission checks. Since the view has done the work, we want a fast permission checker on the good ones. We can update the cve-index.pt template to always use can_view_bug20:50
jcsackettsinzui: dig.20:52
sinzuijcsackett: I can send you a diff of the changes actually, so you can have an adventure with milestones20:54
=== almaisan-away is now known as al-maisan
=== abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
jcsackettsinzui: i'm not sure that's what i would call "adventuring" :-P20:57
=== al-maisan is now known as almaisan-away
wallyworld_leonardr: mumble?21:02
jmlg'night all.21:05
leonardrwallyworld, 1 minute, sorry21:09
leonardrwallyworld, i can hear you21:11
leonardrwallyworld, go ahead and give me your status, i'll try to figure it out21:11
lifelesssinzui: jcsackett: are you talking bug security checks?21:11
=== matsubara is now known as matsubara-afk
lifelesssinzui: jcsackett: if so there is no need for that now, our searches inject the rules.21:11
leonardrwallyworld: sorry, still not working21:13
lifelessjml: I wrote the fixture you asked for21:13
sinzuilifeless: okay good to know. We could reimplement the oddness in the view21:14
lifelesssinzui: what symptoms are you seeing ?21:16
sinzuiNo symptoms. The does very odd things to build a dict of bugs, and the template ignores the work the view did hald the time. We have bool in the dict, which must be faster than adaption21:18
lifelesssinzui: any bug task gotten via IBugTaskSet.searchTasks will not trigger security lookups; bugs gotten via other methods that do not indirect to searchTasks should be updated to do so21:18
lifelesssinzui: ok21:18
jmllifeless: yeah, I saw, thanks.21:29
leonardrwallyworld_: take a look at lazr.restful.interfaces.IWebBrowserOriginatingRequest21:33
leonardrlaunchpad defines an adapter from WebServiceLayer (ie. a web service request) to IWebBrowserOriginatingRequest, in webapp/configure.zcml21:33
leonardrin _resource.py, applyChanges, lazr.restful casts the current request to IWebBrowserOriginatingRequest21:39
leonardrif the result is None (because the application never defined an adapter), one thing happens21:39
leonardrif it's not none (because this is launchpad), another thing happens21:39
wgrantjml: !21:58
wallyworld_leonardr: thanks!21:59
rockstarhuwshimi, hi22:02
huwshimirockstar: Hey22:02
rockstarhuwshimi, what particularly about YUI are you struggling with?22:03
huwshimirockstar: Oh, nothing in particular (I've just replied to your email).22:04
rockstarhuwshimi, yeah, I saw it.22:04
huwshimirockstar: I just don't like the way it does certain things, but I can get over that and use it anyway22:04
rockstarhuwshimi, most of the concerns I've seen from people about YUI (and javascript in general) are because there's something idiomatic that they don't understand.22:05
rockstarhuwshimi, what particularly do you not like though?22:05
rockstar(It's quite possible that we are doing it wrong it YUI, and I'd like to help fix it if need be)22:05
huwshimirockstar: I'm not sure exactly. I need to spend some more time with YUI3 to really be able to help you out with that22:08
sinzuiwgrant: I think you should block about the private bug as 404 change. Many users are confused by this. They think Lp is broken (making bad links)22:44
sinzuiwgrant: s/block/blog/22:44
cody-somervilleIn that case why is it 404 instead of 403?22:48
wgrantcody-somerville: We are moving to deny the existence of private objects, because it is much simpler. :/22:49
wgrantPrivate bugs are just about impossible to do sensibly.22:49
wgrantWithout 404ing.22:49
wgrant(because of the redirects)22:49
sinzuiwgrant: actually, I think switching to NotFound is a bug. We cannot make links that will 404. We need to ensure that the user has permission to see the link we are making22:49
sinzuiwgrant: and yes, because of redirects this can be near impossible22:50
wgrantsinzui: We don't make links, AFAIK.22:50
cody-somervillewhat redirects?22:50
wgrantExcept perhaps if the bug is referenced in text.22:50
wgrantcody-somerville: /bugs/1 -> /ubuntu/+bug/122:50
_mup_Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I22:50
_mup_Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I22:50
wgrantcody-somerville: /otherproject/+bug/1 -> /ubuntu/+bug/122:50
_mup_Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I22:50
_mup_Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I22:50
pooliegood thing that line is truncated :)22:50
sinzuiwgrant: bug https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/739380 certainly does link to a private bug. I am sure it shows up in the 404 reports22:52
_mup_Bug #739380: update-manager crashed with AuthorizationFailed in _run(): org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name':  ':1.129'}): org.debian.apt.update-cache <apport-crash> <i386> <natty> <running-unity> <update-manager (Ubuntu):New> < https://launchpad.net/bugs/739380 >22:52
sinzuiwgrant: I think this is another case where the is a right way to do something, but it is more fun to creaft your own links and play with interpolation22:53
sinzuisorry about the spelling. I am a wreck. I should end my day22:54
lifelesssinzui: we don't create links to hidden bugs though22:54
cody-somervillewhy not just handle this the same way as oh, I dunno... most other websites? :P lol. Sorry to be facetious but LP can't be the first website trying to solve these kinds of problems, can it? :P22:55
lifelesssinzui: (because we filter all hidden bug objects so they don't show up in miletones, search results etc)22:55
sinzuilifeless: But we do https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/73938022:55
_mup_Bug #739380: update-manager crashed with AuthorizationFailed in _run(): org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name':  ':1.129'}): org.debian.apt.update-cache <apport-crash> <i386> <natty> <running-unity> <update-manager (Ubuntu):New> < https://launchpad.net/bugs/739380 >22:55
lifelesscody-somerville: this is how other websites handle it22:55
sinzuilifeless: look above the comment box22:55
lifelessthe 'Remember, this bug report is a duplicate of bug #710026. ' ?22:55
lifelesssinzui: so, this is related to the disclosure work - remember how you were saying that we shouldn't permit adding tasks outside of visibility zones22:56
lifelesssinzui: same thing - when something is duped on a private bug we need to take disclosure into account22:56
wgrantlifeless: I thought the duplicate warning avoided linking. Maybe only some of them do.22:56
sinzuilifeless: I think this relates to an even older rule I have when reviewing code. Do not craft a link that you are not will to write a test for to verify it behaves like the canonical link code.22:57
lifelesssinzui: sounds plausible to me22:58
lifelesssinzui: I can see that private bug22:58
sinzuiyour special22:58
lifelessI'm not an admin22:58
wgrantAny more, at least.22:58
lifelesssigh, rub it in :)22:59
sinzuiI am just one of the proles.22:59
lifelessI'm in ubuntu-bugcontrol22:59
wgrantIf it's apport, your MOTU membership will let you see it.22:59
lifelesswgrant: ah22:59
wgrantIndeed, it is apport.22:59
lifelesssinzui: so you see a link there22:59
lifelesssinzui: and you can't see the master bug22:59
lifelesswgrant: looks to me like apport should have unprivated this23:00
sinzuiI see "Remember, this bug report is a duplicate of bug #710026. Comment here only if you think the duplicate status is wrong."23:00
lifelesssinzui: and that is linkified ?23:00
wgrantlifeless: Indeed, nothing private there.23:01
lifelesswgrant: worth filing a bug about this?23:02
wgrantlifeless: Not sure.23:03
sinzuiI think this instance I see is bug. Isn't the reason the oops reports have a NotFound section is to encourage us to not do stupid thinks to frustrate users.23:06
lifelesssinzui: indeed, we shouldn't generate links that break23:07
lifelesswe need to teach the linkifier code to rewrite bug references too23:07
lifelesse,g. https://bugs.l.n./foo/+bugs/NNN -> check visibility and don't link otherwise.23:08
sinzuiThe message I see is wrong. Since the bug is private and I cannot see it, I cannot say I think the duplication was a mistake. I have to know to locate a bug contact for the zero-vector bug I cannot see and ask for it to be make pulic of be subscribed23:08
lifelesswhich also implies a batch scan-and-check for efficiency23:08
sinzuiThat is an daunting task for most users23:08
lifelesssinzui: I totally agree. I filed a couple of bugs about usability here earlier this week23:08
lifelesssinzui: let me dig them up23:08
sinzuioh, yes I do realised that my grievance is goes back to when we issued a 403. Users are just more confused since bugs privacy is volatile, unlike team privacy.23:10
=== salgado is now known as salgado-afk
lifelessthumper: bug 740750 - I think I mailed you.23:11
_mup_Bug #740750: API timeouts broken and returning no useful data... <regression> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 >23:11
lifelessbug 33413023:16
_mup_Bug #334130: misbehaviour in marking duplicates of a private bug <lp-bugs> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/334130 >23:16
lifelessbug 43473323:16
_mup_Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <confusing-ui> <disclosure> <lp-bugs> <privacy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434733 >23:16
lifelessI can't find the one I thought I filed23:16
lifelessbug  15789923:17
poolielifeless, oh just one more thing23:17
_mup_Bug #157899: Shouldn't need access to private bug report to reverse a public duplicate marking <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/157899 >23:17
lifelessbug 13657023:17
_mup_Bug #136570: Can't unsubscribe from duplicates if dupe is private <duplicate-subscribing> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/136570 >23:17
pooliei see people adding new apis for admin use etc23:17
lifelesspoolie: yes?23:20
poolieit seems like it's kind of half-baked without a cli23:21
pooliei don't want to hold things hostage but i was wondering if people could add things to lptools for admin use23:21
poolieit shouldn't be much more incremental work23:21
lifelesspoolie: I don't think they should23:21
poolieor, at least, to file a bugtask against lptools23:21
lifelesspoolie: following reasons:23:21
lifeless - these apis are not productised; we don't want to have to care about them in the stable api, and lptools is a productised project23:22
lifeless - the api client for them should be the web ui, not a cli23:22
lifelessI think its fine if a dev things lptools is the best place to do it, but its not where I would encourage them to go with these apis23:23
poolieare these meant to be internal-use things for ajax only?23:23
pooliei misunderstood23:23
lifelesspoolie: we have /one/ api, it serves both launchpadlib (python) and a yui launchpad object that all the web ui ajax uses23:24
lifelessso theres no clear separation, for right or wrong23:24
pooliewhat does "not productised" mean in this context?23:24
lifelesswe don't care about API churn23:25
lifelesswe'll change them willynilly as needed23:25
pooliewhat is the intended client for them? ajax?23:27
lifelessI don't know23:28
lifelessthe syadmin request is a button in the ui23:28
lifelessbut the work is being done in spare timeslots23:28
pooliei was confused because the bug seemed to say "please add an api"23:29
pooliei'll add lptools bugtasks23:29
lifelessthe bug was added to reflect the unit of work, for tracking qa23:29
lifelesspoolie: if the api is in devel, which I htink it is, you may not want lptools using it23:30
lifelesspoolie: because lptools is a packaged product23:30
lifelessI wouldn't want bugs filed on lp if we change this api23:30
pooliebetter to have the function than not at all though23:30
lifelesspoolie: this doesn't seem like a thing that will broadly interest lptools users; I'm confused by your interest in it23:31
pooliei had the misapprehension that people were adding an api so that other people could write ad hoc scripts to call it23:31
poolieand in that case i would rather those scripts went into lptools23:31
sinzuilifeless: one of those bugs may be a duplicate of a bug I reported 5 months ago. I would need to see a TB to be certain. Maybe Gary's team will fix the defect before they declare bug subscriptions ready.23:31
lifelessthey may be; even if that is the case, why is it appropriate for lptools ?23:31
poolieit's more the general pattern than the specific case23:31
pooliesorry i've got to go get a haircut, biab23:32
lifelesspoolie: I'm worried about the problem we have with edge and bzr happening here. Talk to you later about it.23:32
lifelesswgrant: https://bugs.launchpad.net/launchpad/+bug/434733/comments/423:37
_mup_Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <confusing-ui> <disclosure> <lp-bugs> <privacy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434733 >23:37
lifelesswgrant: it happens a lot, I think we need to talk to pitti23:37
lifelessdo we still send mail to all duplicates when a master bug is altered, even if the master is privte?23:53
wgrantlifeless: I'm pretty sure not.23:53
wgrantSince only direct subscriptions function for private bugs.23:54
lifelesshmm, then I think I can close one of those bugs off completely23:55
lifelessbug 13657023:55
_mup_Bug #136570: bug mail explaining cause of message has an inaccessible link when the the master is private and the subscription is is via duplicates <duplicate-subscribing> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/136570 >23:55
lifelessdon't need to unsubscribe if you don't get mail23:56
lifelessbug 589878 looks nice, I was thinking of a branch of yours recently I'd love the bug subscribers to all be able to see23:57
_mup_Bug #589878: bzr branches should be private by default if linked to a private bug <lp-code> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/589878 >23:57

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