[00:04] <lifeless> I suspect Distribution:+bugtarget-portlet-bugfilters-stats is going to be mondo painful
[00:04] <wgrant> Yes.
[00:04] <lifeless> also we need to remove the override on Archive:+index
[00:05] <wgrant> How low is it now?
[00:05] <wgrant> The page, I mean.
[00:05] <wgrant> Not the 16000 override.
[00:05] <lifeless> 8.26
[00:05] <wgrant> Nice.
[00:05] <lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/2011-03/daily_2011-03-15_2011-03-16/pageids.html
[00:05] <wgrant> Kill it.
[00:05] <wgrant> Yes, but that takes a couple of minutes to load.
[00:07] <wgrant> Hmm. Maybe I want to look at Person:+contactuser.
[00:07] <wgrant> Since its 99% is twice the next worst.
[00:08] <lifeless> 0.11
[00:08] <lifeless> mean sql
[00:08] <wgrant> For +contactuser?
[00:08] <lifeless> hmm, 99th percentile forsql is mising
[00:08] <lifeless> wgrant: yes
[00:08] <wgrant> Right.
[00:08] <wgrant> It'll be mail.
[00:08] <lifeless> wgrant: its probably mail sending
[00:09] <lifeless> wgrant: we would benefit a lot if we had instrumentation on how long sending each email takes
[00:09] <lifeless> its been hard getting that evaluated by is (for fairly good reasons) - but it still an open question around where the issues live
[00:10] <lifeless> archive:+index should wait for monday
[00:20] <thumper> lifeless: can I get you to mentor wallyworld? https://code.launchpad.net/~thumper/launchpad/blueprint-linked-bug-tasks/+merge/53734
[00:22] <lifeless> thumper: I need to pop up to the shops for lunch stuff
[00:22] <lifeless> thumper: will review after
[00:22] <thumper> lifeless: ok, thanks
[00:30] <huwshimi> Does anyone know of a way to use feature flags in JavaScript?
[00:31] <lifeless> yes
[00:31] <lifeless> export the value of the flag in the .pt file
[00:31] <lifeless> interpret it in your js
[00:34] <huwshimi> lifeless: That was my plan, but I was having trouble getting some context values. Maybe I'll try again.
[00:35] <lifeless> its been done before :)
[00:35] <lifeless> huwshimi: e.g. showing the render time in the top right
[00:45] <huwshimi> lifeless: heh no wonder it wasn't working. The feature flag wasn't set. The shame.
[00:45] <lifeless> huwshimi: rotfl
[00:46] <huwshimi> lifeless: I didn't realise that it didn't keep them between make runs
[00:46] <lifeless> huwshimi: make schema will zerg them from your dev insance
[00:47] <lifeless> huwshimi: 'make run' won't reset them
[00:47] <huwshimi> lifeless: I didn't think I'd done a make schema... but maybe I had
[00:47] <StevenK> huwshimi: make schema completly resets the db to 'pristine sampledata'
[00:47] <huwshimi> yeah
[00:47] <StevenK> Now to wash my eyes out for saying 'pristine sampledata'
[00:52]  * thumper is mildly confused by a comment in code
[00:53] <thumper> model/person.py line 1797
[00:54] <mwhudson> thumper: i guess _getPrecachedPersons isn't in the interface?
[00:54] <thumper> it doesn't need to be
[00:54] <poolie> lifeless, i liek your idea about incomplete (bug 737008)
[00:54] <thumper> the self object isn't security wrapped
[00:54] <_mup_> Bug #737008: old incomplete bugs are not treated as incomplete <Launchpad itself:Invalid> < https://launchpad.net/bugs/737008 >
[00:54] <thumper> once inside the object
[00:54] <poolie> maybe we should make that bug ask for what you said (as Low)
[00:54] <thumper> you are free of the security proxy on self
[00:54] <lifeless> poolie: care to do that ?
[00:54] <poolie> sure
[00:55] <mwhudson> thumper: sure, but if you did getUtility(IPersonSet) you get a proxied object
[00:55] <lifeless> thumper: you can use the proxied set and see what happens....
[00:55] <thumper> mwhudson: yes you do
[00:55] <thumper> but once you call a method on the object (that is in the interface)
[00:55] <thumper> the self passed through isn't wrapped
[00:56] <thumper> otherwise that'd be insane
[00:56] <mwhudson> sure
[00:56]  * thumper is 98% sure of this
[00:57] <lifeless> bbs
[01:49] <thumper> lifeless: you back?
[01:49] <thumper> anyone know how to clear the storm cache for tests?
[01:58] <lifeless> store.reset
[01:58] <lifeless> store.invalidate
[01:58] <lifeless> IIRC
[01:59] <lifeless> hmm
[01:59] <lifeless> I should have been on leave today
[02:00] <mwhudson> oh yes, the memorial
[02:01] <lifeless> I'll talk to flacoste, do a day off next week
[02:03] <lifeless> thumper: ^ store answers for you
[02:17] <thumper> lifeless: ta
[02:17] <thumper> lifeless: do I need both, or just the second?
[02:18] <lifeless> either
[02:19] <lifeless> one is deeper than the other
[02:19] <lifeless> invalidate will cause existing objects to be refreshed from the db on next use
[02:19] <lifeless> reset will make them unusable and cause errors if you try to carry an object from before the reset forward
[02:24] <thumper> ok
[02:24] <thumper> anyone remember off the top of their head what the storm equivalent of the sqlobject SQLRelatedJoin is?
[02:25] <poolie> lifeless, i wonder if you (or mrevell or someone) should post to the blog to explain about the critical/high/low categories
[02:25] <poolie> re all the "why is this now Low" comments
[02:26] <lifeless> hmm
[02:26] <lifeless> possibly
[02:26] <lifeless> but there have only been 3 or 4
[02:26] <lifeless> in several hundred bug updates
[02:26] <lifeless> (one bug - the wiki one - had a longer discussion that I'm counting as one)
[02:27] <lifeless> I don't think this is really all that interesting to most users of lp
[02:29] <poolie> maybe not
[02:34] <lifeless> I think people are responding because they get notified
[02:34] <lifeless> and would do so even if they knew that medium is equivalent to low, because the thing they care about is having their change made
[02:40] <thumper> OMFG
[02:40] <thumper> this code is soooooo... bad
[02:40]  * thumper enfixorates
[02:43] <wgrant> thumper: Which code?
[02:44] <thumper> sprints
[02:44] <wgrant> Heh.
[02:45] <thumper> like the way to add an attendee, it iterated through all the attendees to see if the person matched
[02:46] <poolie> huwshimi, did you think you fixed the bug where you have to press enter twice to save the tag list?
[02:46] <poolie> doesn't seem fixed for me on lpnet
[02:47] <lifeless> one enter selects the tag, the other saves
[02:47] <lifeless> huwshimi: btw
[02:47] <poolie> yes, i know
[02:47] <lifeless> huwshimi: try putting a non-typeahead tag into a bug
[02:47] <poolie> but that makes no sense if i've already completely entered a tag
[02:47] <huwshimi> poolie: The fix is in lazr-js which I haven't got around to releasing a new version of yet.
[02:48] <lifeless> huwshimi: its not done till its done
[02:48] <poolie> ok thanks
[02:48] <poolie> just wondered if it was in-progess or failed validation
[02:48] <wgrant>      1029  OOPS-1902EE937  BugTask:+nominate
[02:48] <wgrant> 1029 statements on +nominate!?
[02:48] <lifeless> win
[02:48] <poolie> sorry just one more thing there, what controls which tags show up in the portlet?
[02:49] <poolie> oh, deja vu, this is a caching bug, isn't it?
[02:49] <wgrant> Probably, yes.
[03:08] <thumper> :(
[03:08] <wgrant> Sprints are that bad?
[03:09] <wgrant> Can I burn bug heat?
[03:09] <lifeless> wgrant: no
[03:10] <wgrant> :(
[03:10] <wgrant> Does anybody use it enough that the performance penalty is worth it?
[03:10] <lifeless> the performance penalty is not intrinsic to having heat
[03:11] <wgrant> No.
[03:11] <wgrant> But we need to either optimise or destroy.
[03:11] <lifeless> optimise
[03:11] <lifeless> distro are asking for heat improvements
[03:11] <wgrant> Well, destruction is the ultimate optimisation :)
[03:11] <wgrant> :(
[03:11] <thumper> getUtility(IPersonSet).getPrecachedPersonsFromIDs isn't doing what I'd expect
[03:11] <lifeless> if we don't deliver the (thing) then its not optimisation anymore
[03:12] <wgrant> thumper: list()
[03:12] <lifeless> thumper: are you listifying it and passing need_validity=True ?
[03:12] <wgrant> thumper: You need to evaluate the result.
[03:12] <thumper> wgrant: yeah got that
[03:12] <thumper> and I ahve need_validity=True
[03:12] <lifeless> ok
[03:12] <lifeless> so what are you seeing
[03:12] <thumper> but it is still doing the valid query for some of them
[03:12] <thumper> and if I add more people
[03:12] <thumper> then it does shit loads more
[03:12] <thumper> even getting some people
[03:12] <thumper> I'm wondering if I'm hitting the storm cache limit
[03:12] <lifeless> where are you doing the preloading ?
[03:13] <lifeless> there is no cache limit
[03:13] <thumper> test says different
[03:13] <wgrant> lifeless: Even in tests?
[03:13] <lifeless> its much more likely that something is triggering loading and doing a person:fmt before your eager load happens
[03:13] <thumper> I'm preloading in Sprint.attendances
[03:13]  * thumper tries something
[03:13] <lifeless> wgrant: if you test with getUserBrowser, should be same as prod
[03:14] <lifeless> thumper: you're using the matcher for testing this, right ?
[03:14] <thumper> yep
[03:14] <thumper> and the DatabaseFunctionalLayer
[03:14] <lifeless> BrowsersWithQueryLimit or whatever it was
[03:23] <wgrant> Hmm.
[03:23] <wgrant> I wonder.
[03:23] <lifeless> wgrant: dangerous
[03:23] <wgrant> Should I turn recalculateBugHeat into something that adds a commit hook?
[03:23] <wgrant> As a quick fix for all this heat badness.
[03:23] <lifeless> what do you mean
[03:24] <wgrant> At the moment any change to a bug calls recalculateBugHeat, which then sets maxheat everywhere and blah.
[03:24] <wgrant> Some views call addChange several times.
[03:26] <lifeless> so
[03:26] <lifeless> uhm
[03:26] <lifeless> I don't know what you should do
[03:26] <lifeless> I can share the thoughts I had looking at this previously
[03:26] <wgrant> Well, I should move heat updating to a job.
[03:26] <wgrant> But that's a bit hard.
[03:27] <bac> hi thumper
[03:27] <lifeless> updating the heat in a context should be exactly two single-row queries always.
[03:27] <thumper> bac: hi
[03:27] <bac> thumper: hey could you re-review my branch?  i addressed all of your issues.
[03:27] <thumper> ok
[03:27] <lifeless> wgrant: [in the current design/implementation]
[03:28] <thumper> bac: diff is updating
[03:28] <bac> thumper: despite what i said in the earlier comment, i've removed the line-height altogether
[03:28] <lifeless> wgrant: the fact that its now looked like a very low hanging fruit
[03:28] <lifeless> s/now/not/
[03:28] <LPCIBot> Yippie, build fixed!
[03:28] <LPCIBot> Project db-devel build #464: FIXED in 4 hr 44 min: https://hudson.wedontsleep.org/job/db-devel/464/
[03:28] <thumper> lifeless: if I reduce the number of people I add to the sprint, I get expected behaviour.  with 30 people, it is fine, with 50 I get some validation queries, with 100 I get people and validation queries
[03:28] <thumper> lifeless: so I'm guessing it is a caching issue
[03:31] <lifeless> thumper: I've done some pretty large datasets and not see that, but you might be right
[03:31] <lifeless> thumper: is it constant regardless of people in launchpad.dev (I use the harness to populate data for that sort of manual test)
[03:32] <lifeless> wgrant: does that make sense, or have I been to minimal in my description ?
[03:32] <wgrant> lifeless: It makes sense.
[03:33] <wgrant> lifeless: I guess it should be reasonably cheap, but it's still going to be somewhat duplicated.
[03:33] <wgrant> I'll fix the underlying stuff first.
[03:33] <wgrant> (mostly the fact that DSP's pk isn't (distribution, sourcepackagename), so Storm likes to reretrieve it lots)
[03:33] <lifeless> wgrant: things like: why do we query 'hottest bug' - if this bug has higher heat, update the cache, if not do nothing unless our heat lowered, and in that case [rare] query highest bug and set if and only if different
[03:35] <wgrant> lifeless: Right.
[03:35] <lifeless> wgrant: I don't see any reason to move heat to a job
[03:36] <lifeless> wgrant: I wouldn't object to it per se, I just don't see anything driving it
[03:38] <thumper> lifeless: so where is this storm cache defined?
[03:38] <thumper> rendered locally, a sprint with 100 attendees was 30 queries
[03:38] <thumper> 200 attendees was 30 queries
[03:38] <thumper> 400 attendees was 102
[03:39] <thumper> wondering if I was hitting the limit again
[03:39] <lifeless> heh, do we even use stormsugar.py
[03:39] <thumper> I was looking for it
[03:39] <thumper> but didn't end up using it
[03:40] <lifeless> thumper: grep for StupidCache
[03:40] <StevenK> Is that seriously its name?
[03:40] <thumper> bac: I think you were too aggressive in your code removal
[03:40] <thumper> bac: with no link it should be a <span> and it is no more
[03:43] <wgrant> lifeless: Well, for one thing it seems pretty unwise to be locking Ubuntu during every change to an Ubuntu bug.
[03:44] <lifeless> wgrant: right, but only *one bug* can cause that
[03:44] <lifeless> wgrant: note that all bug updates will take a row lock preventing deletes on ubuntu
[03:44] <wgrant> lifeless: We hope.
[03:45] <lifeless> wgrant: if there are two bugs fighting for peak heat
[03:45] <lifeless> wgrant: we can deal
[03:45] <wgrant> Maybe.
[03:46] <wgrant> StevenK: What are you doing to Jenkins?
[03:46] <StevenK> Moving it
[03:46] <StevenK> Well, moving its DNS name to lpci.w.o
[03:46] <wgrant> Aha.
[03:47] <lifeless> hmm
[03:48] <lifeless> does bug expiry look a the project group ?
[03:48] <lifeless> if so, that would explain why its not working for launchpad
[03:48] <lifeless> and there is no ui for setting it on project gourp
[03:49] <wgrant> It doesn't seem to use the project group setting.
[03:50] <StevenK> wgrant: It should announce URLs as lpci.w.o anyway. hudson.w.o is now a CNAME.
[03:50] <lifeless> wth defines 'fixed elsewhere'
[03:50] <lifeless> zomg
[03:50] <wgrant> lifeless: Where have you seen that?
[03:50] <lifeless> we support *per distroseries* bug expiry
[03:50] <wgrant> Er, what?
[03:50] <wgrant> Do we?
[03:50] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=1857C157#longstatements query 4
[03:51] <StevenK> That seems like crack.
[03:51] <StevenK> Pure crack.
[03:51] <lifeless> its mindblowingly insane
[03:51] <wgrant> lifeless: Er.
[03:51] <wgrant> That's not per-distroseries bug expiry.
[03:51] <wgrant> That's finding bugs in distroseries in distributions that are expirable.
[03:52] <StevenK> Sigh, lp-oops DIAF
[03:52] <StevenK> It always misbehaves for me
[03:52] <wgrant> Authentication drops the query string, yes.
[03:52] <lifeless> https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-bugfilters-stats - thats where the 'fixed elsewhere' thing shows up
[03:52] <lifeless> wgrant: thats true, but the query is nutjob noddy anyway
[03:52] <wgrant> lifeless: Welcome to Launchpad.
[03:53] <StevenK> wgrant: And https://lp-oops.canonical.com/ is the most unhelpful front page EVER
[03:54] <lifeless> argh
[03:55] <lifeless> extra_clauses.append("BugTask.bug IN " "(SELECT DISTINCT bug FROM BugCve)")
[03:55] <lifeless> -not win-
[03:56] <huwshimi> StevenK: Ouch, whatever server is running that site must be really hurting if that's running in debug mode
[03:57] <wgrant> huwshimi: That's devpad.
[03:57] <lifeless> the fixed elsewhere queries are buggy too - they ignore product series bugs
[03:58] <huwshimi> wgrant: I'm guessing it doesn't have much ram free.
[04:01] <StevenK> Meh, it's only 220MiB into swap
[04:05] <huwshimi> well we probably shouldn't be running it in dev mode anyway
[04:05] <huwshimi> or rather debug mode
[04:05] <lifeless> huwshimi: why not?
[04:06] <huwshimi> lifeless: In debug mode Django holds every query in ram
[04:06] <lifeless> huwshimi: since start up?
[04:06] <lifeless> huwshimi: or for a request lifetime?
[04:06] <huwshimi> lifeless: I think so
[04:07] <StevenK> The only thing that isn't playing so nice with carob is the PPR
[04:07] <lifeless> generation ?
[04:07] <StevenK> Yes
[04:07] <lifeless> yeah, its started failing again
[04:08] <huwshimi> lifeless: Sorry I mean, I think it is since start up
[04:08] <lifeless> huwshimi: right, well that could be cause for concern, yes.
[04:08] <huwshimi> lifeless: Let me just check the docs
[04:09] <huwshimi> lifeless: "It is also important to remember that when running with DEBUG turned on, Django will remember every SQL query it executes. This is useful when you are debugging, but on a production server, it will rapidly consume memory." from: http://docs.djangoproject.com/en/dev/ref/settings/#debug
[04:10] <lifeless> hahahahahahha
[04:10] <lifeless> my respect for django just increased
[04:10] <lifeless> so, could you please file a bug on oops-tools noting this?
[04:12] <StevenK> lifeless: You had some? :-)
[04:12] <lifeless> StevenK: its gone so far in one direction that things that make it worse, make it better
[04:13] <StevenK> wgrant: Last SPR processed by p-s-c was for edgy.
[04:13] <wgrant> StevenK: We are getting somewhere.
[04:13] <StevenK> Slowly.
[04:14] <StevenK> The OO.o SPRs are taking 1 minute.
[04:18] <huwshimi> lifeless: We might have to check our other Django deploys too.
[04:19] <huwshimi> (I believe we have others)
[04:20]  * wgrant stabs postgres in the eye.
[04:21]  * mwhudson has one too....
[04:21] <mwhudson> (but it hardly uses the database so that might be ok)
[04:22] <huwshimi> lifeless: https://bugs.launchpad.net/oops-tools/+bug/737327
[04:22] <_mup_> Bug #737327: django should not be running in debug mode on production, it will eat all the RAM <OOPS Tools:New> < https://launchpad.net/bugs/737327 >
[04:23] <thumper> https://code.launchpad.net/~thumper/launchpad/sprint-attendees/+merge/53941
[04:24] <thumper> lifeless: and other review poke
[04:24]  * thumper goes to get friday takeaways
[04:30] <lifeless> thumper: reviewing
[04:30] <lifeless> thumper: I have suggestions fwiw, but nothing mandatory so far
[04:32] <thumper> ok, I'll look later
[04:32]  * thumper afk
[04:38] <jtv> wgrant: do you know where the contents of /srv/launchpad.net/ubuntu-archive/ubuntu-distscopy come from?
[04:42] <wgrant> jtv: It's maintained by the script.
[04:43] <wgrant> It keeps two copies of the dists tree around.
[04:43] <wgrant> So it can do reasonably atomic updates.
[04:43] <jtv> wgrant: what is "the" script?
[04:43] <wgrant> "the script" being cron.publish-ftpmaster
[04:43] <jtv> Ah
[04:43] <wgrant> It grabs the backed up dists tree ubuntu-distscopy, and moves it to ubuntu/dists.new
[04:44] <wgrant> It then runs the publisher on that.
[04:44] <jtv> I see it copying _from_ ubuntu-distscopy… does it write _to_ ubuntu-distscopy further on?
[04:44] <wgrant> See cleanup() near the top.
[04:44] <jtv> So this is a chicken-and-egg situation?
[04:45] <wgrant> Howso?
[04:45] <wgrant> # Create backup dists folder, if this is the first time.
[04:46] <jtv> That copies _from_ ubuntu-distscopy
[04:46] <wgrant> Then it will move the empty folder to dists.new, swap dists and dists.new bring the new dists.new up to date, then move dists.new into ubuntu-distscopy
[04:46] <wgrant> s/ bring/, bring/
[04:46] <jtv> But publish-distro is failing to write a Release file there
[04:46] <wgrant> Oh?
[04:47] <wgrant> grumpy?
[04:47] <jtv> No, a freshly-created distroseries.
[04:47] <wgrant> Does it have any ComponentSelections?
[04:47] <jtv> Errr
[04:47] <wgrant> You need ComponentSelections in all your publishable series.
[04:47] <jtv> what's a component selection?
[04:47] <wgrant> Or you'll have no components.
[04:47] <wgrant> And the publisher will crash.
[04:47] <jtv> "Components?  But Andy Tanenbaum told me that Linux was monolithic!"
[04:47] <wgrant> (not optimal, but it's better than lucilleconfig)
[04:48] <wgrant> Bug #675042
[04:48] <_mup_> Bug #675042: Release file generation fails for series without components <lp-soyuz> <soyuz-publisher> <Launchpad itself:Triaged> < https://launchpad.net/bugs/675042 >
[04:48] <wgrant> Does that look like what you're seeing?
[04:49] <jtv> Yes, except it's not in /var/tmp/archive.
[04:49] <wgrant> So, try adding a ComponentSelection for main to your new series.
[04:50] <jtv> Does the test publisher know how to do that for me?
[04:51] <wgrant> I doubt it.
[04:51] <wgrant> Not even the LOF does.
[04:51] <jtv> The Line Of Flight?
[04:51] <jtv> Launchpad Object Factory.
[04:52] <jtv> I'm tempted to fix the bug, but in this case that'd probably be hiding incomplete test coverage for cron.publish-ftpmaster, wouldn't it?
[04:53] <wgrant> It would.
[04:58]  * jtv sings hi-ho, making componentselections we go
[05:04] <wgrant> lifeless: Hi.
[05:06] <lifeless> wgrant: hi
[05:06] <lifeless> hi ho
[05:06] <lifeless> hi ho
[05:06] <lifeless> its off to work we go?
[05:06] <wgrant> Ha ha.
[05:06] <wgrant> Could you please explain analyze query 106 from https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1902A2028?
[05:06] <wgrant> It is a wonderful 9978ms abomination.
[05:06] <lifeless> \o/
[05:07] <wgrant> It takes about 30s on mawson, and adding a very sensible index brings it down to 2s.
[05:07] <lifeless> what bug
[05:08] <wgrant> Bug #276950, probably.
[05:08] <_mup_> Bug #276950: DistroSeries:+queue Timeout accepting many packages queue page <lp-soyuz> <queue-page> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/276950 >
[05:08] <wgrant> Although this is probably only bad on GETs.
[05:08] <lifeless> still running
[05:08] <wgrant> Heh
[05:09] <wgrant> I guess the index was not terribly bad when it was created.
[05:10] <lifeless> still going
[05:10] <lifeless> I'm going to go fiddle this portlet a bit more and check back in a bit
[05:10] <wgrant> Thanks.
[05:11] <lifeless> ok, on the bug
[05:11] <lifeless> hot is 600ms
[05:12] <wgrant> Bah.
[05:12] <wgrant> Thanks.
[05:12] <lifeless> cold is 201945.176
[05:13] <StevenK> Over 2 minutes?
[05:13] <lifeless> wgrant: so you're adding distinct there
[05:13] <wgrant> Over three minutes.
[05:13] <lifeless> to stop redundant rows?
[05:13] <wgrant> I presume so.
[05:14] <lifeless> lets see
[05:14] <lifeless> 53 rows
[05:16] <lifeless> 720 rows without the distinct
[05:18] <lifeless> wgrant: so its doing about 10 times the work needed
[05:18] <lifeless> wgrant: because the non distinct version is still 600ms
[05:19] <wgrant> lifeless: It must think that a full scan is a better idea. It's probably right.
[05:23] <lifeless> wgrant: rephrasing it may work
[05:24] <lifeless> wgrant: its doing index scans
[05:24] <lifeless> wgrant: an index that permits doing distinct inline may make it a lot better, we can ask stub to play with that later
[05:29] <jtv> wgrant: I'm adding a makeComponentSelection to the factory.
[05:29] <wgrant> jtv: Why?
[05:29] <wgrant> the constructor is fairly trivial.
[05:29] <wgrant> The only bonus is omitting an import.
[05:30] <jtv> wgrant: makes it easy to say self.factory.makeComponentSelection(distroseries, "main")
[05:31] <wgrant> Ah
[05:31] <jtv> Accepts component, component name, or none.
[05:31] <jtv> Also, it means that yokels such as yours truly won't have to worry about just how trivial they are to create.  :-)
[05:32] <jtv> And meanwhile I'm on to the next hurdle: missing Sources files
[05:33] <wgrant> Even with a component?
[05:33] <jtv> It may be the thing you ran into with my parallelization branch—it's a-f.
[05:33] <jtv> WARNING a-f: E: Could not open file /var/tmp/archive/distribution510022/dists.new/distroseries510031/main/source/Sources.bz2.new - open (2: No such file or directory)
[05:34] <wgrant> Hmmm.
[05:34] <wgrant> Does that dir exist?
[05:35] <jtv> (Luckily I rigged this test with a "now tar up the temp directory so I can have a look" finale)
[05:35] <wgrant> Heh
[05:35] <jtv> oh wait, this is in /var/tmp
[05:36] <jtv> It'd be nice to avoid messing with /var/tmp, wouldn't it?
[05:36] <jtv> Yuck, crud piling up there!
[05:37] <jtv> wgrant: the dists.new directory isn't present
[05:37] <wgrant> What's in /var/tmp/archive?
[05:37] <wgrant> Besides dozens of distribution dirs.
[05:39] <jtv> Dozens of distribution-like dirs with "-cache," "-misc," "-overrides," "-partner," or "-temp" suffixed to their names.
[05:40] <wgrant> What evil have to done to cron.publish-ftpmaster? It sounds like it's not moving the backup in.
[05:40] <wgrant> s/have to/have you/
[05:42] <jtv> I made it use a temp directory instead of /srv/launchpad.net, I sabotaged the lockfile usage, and I faked dsync-flist and commercial-compat.sh.  That's about it, really.
[05:43] <wgrant> echo "$(date -R): Moving backup dists into place..."
[05:43] <wgrant> Does it do that?
[05:44] <lifeless> wgrant: so its about 300ms in the bpr lookup
[05:44] <lifeless> and 300-500 (depending on plan) in the bpph filtering
[05:44] <wgrant> lifeless: Right.
[05:45] <lifeless> 210814 rows in bpph
[05:46] <jtv> wgrant: yes it does do "Moving backup dists into place…"
[05:46] <wgrant> jtv: Then why is dists.new not there? :/
[05:47] <jtv> wgrant: well we solved that one by adding the ComponentSelection didn't we?
[05:47] <wgrant> 16:37:12 < jtv> wgrant: the dists.new directory isn't present
[05:48] <wgrant> dists.new's existence is not really related to ComponentSelection.
[05:49] <jtv> wgrant: but how does the (non-)existence of dists.new relate to this problem?
[05:49] <jtv> To the Sources problem, I mean.
[05:50] <wgrant> Oh, I guess it probably moved it back away by the time you checked...
[05:52] <lifeless> wgrant: I'd get stub to try that index
[05:52] <wgrant> lifeless: Which?
[05:52] <lifeless> wgrant: the one you said helped on mawson ?
[05:52] <wgrant> Ah, right.
[05:53] <wgrant> It still doesn't make it awesome. But I guess we'll see.
[05:53] <lifeless> whats it on btw ?
[05:53] <wgrant> bpph(archive, distroseries, status)
[05:53] <wgrant> It cuts the BPPH search time massively. So probably not much help in the hot case.
[05:55] <wgrant> Er, distroarchseries, but yeah.
[05:56] <lifeless> ok, I'm going to stop fiddling
[05:56] <lifeless> this is another case of overnormalisation
[05:56] <wgrant> Thanks for trying.
[05:56] <lifeless> bpr's shouldn't be shared
[05:56] <wgrant> Oh?
[05:56] <wgrant> For efficiency they should not.
[05:56] <wgrant> For every other reason they should be.
[05:57] <lifeless> or we should do a fact table for this
[05:57] <lifeless> rather than chained content tables
[05:57]  * lifeless handwaves
[05:58] <wgrant> This is the sort of situation in which cross-table indices would work well. The underlying table is immutable, so there is no concern there.
[05:58] <wgrant> But yes, we do reasonably urgently need to denormalise a bit.
[06:00] <wgrant> We also need collection preload helpers.
[06:03]  * lifeless sobs at related_projects in person.py
[06:10] <lifeless> it aggregates product pillar counts but nothing else
[06:10] <wgrant> Better than nothing.
[06:10] <wgrant> Just.
[06:35] <jtv> Time for the buying of the foodstuffs, ja?
[07:32] <wgrant> Yay, only two CCW oopses so far today.
[07:53] <lifeless> wgrant: false positives still, or actual things-we-need-to-act-on ?
[07:54] <wgrant> lifeless: The latter.
[07:54] <lifeless> wgrant: excellent
[07:54] <lifeless> wgrant: well, excellent that we can tell.
[07:54] <lifeless> what is the issue?
[07:56] <wgrant> Well, they are sort of actual things. Some of our code is crashing, possibly due to broken remote bug trackers.
[07:56] <wgrant> But they are real code bugs.
[07:57] <lifeless> cool
[07:57] <wgrant> Fragile parsers, basically.
[08:27] <jtv-eat> hi henninge, hi rvba
[08:36] <lifeless> I can has review? https://code.launchpad.net/~lifeless/launchpad/bug-711071/+merge/53956
[08:48] <rvba> lifeless: Hi Robert, I have two MP which include db changes, but I can't get a hold of stub these days ... maybe you could take a look at these (the db part)?
[08:48] <rvba> https://code.launchpad.net/~rvb/launchpad/db-distroseries-migrate-owner-to-registrant/+merge/53770
[08:48] <rvba> https://code.launchpad.net/~rvb/launchpad/db-dds-diffpage-form/+merge/53913
[09:01] <lifeless> rvba: both should be looked at by stub
[09:01] <lifeless> I will note though that this
[09:01] <lifeless> 718	- potemplate.distroseries.owner = self.factory.makePerson(
[09:01] <lifeless> 719	+ makePerson = self.factory.makePerson
[09:01] <lifeless> 720	+ potemplate.distroseries.distribution.owner = makePerson(
[09:01] <lifeless> 721	password='test')
[09:01] <lifeless> is an ugly change
[09:02] <rvba> indeed
[09:02] <lifeless> potemplate.distroseries.distribution.owner = \
[09:02] <rvba> I'm still trying to change that
[09:02] <lifeless>     self.factory.makePerson(password='test')
[09:02] <lifeless> would be better
[09:03] <rvba> the "makePerson = self.factory.makePerson" is only here for not having a really long line
[09:03] <lifeless> indeed - see the \ instead
[09:04] <rvba> that was my first move ... but I've been advised the opposite ;-) ... and made the change
[09:05] <lifeless> who by?
[09:05] <lifeless> there was a meme that \ is bad, but that is a broken meme
[09:05] <rvba> Julian, the big guy :-)
[09:05] <rvba> I don't mess why people that tall :-)
[09:06] <rvba> s/why/with/
[09:06] <lifeless> (heck, 80 character limits are bad - we really should make usre of the realities of our development environments)
[09:06] <lifeless> rvba: so its neither here nor there
[09:06] <lifeless> rvba: I will only say, that seeing that, I would do a driveby fix if I was in the area
[09:07] <henninge> rvba: id do this:
[09:07] <henninge> distribution = potemplate.distroseries.distribution
[09:07] <henninge> distribution.owner = self.factory.makePerson(...)
[09:08] <henninge> Hi jtv!
[09:08] <henninge> s/id/I'd/
[09:08] <rvba> henninge: this looks like a better option indeed
[09:11] <rvba> lifeless: any 'final thought' on this?
[09:12] <lifeless> rvba: what henninge suggests is ok
[09:13] <lifeless> rvba: however as I say, stub should look at these patches, he should be around AFAIK
[09:13] <rvba> lifeless: henninge thanks for the drive by advice :-)
[09:13] <rvba> lifeless: I'll ask him about the db part yes
[09:14] <henninge> rvba: np
[09:16] <bigjools> morning all
[09:17] <jtv> hi bigjools
[09:28] <lifeless> bigjools: what are the specs of the machine you run lp tests on ? - and how long does it take?
[09:29] <lifeless> [to run everything, that is]
[09:29] <bigjools> I have 2 machines
[09:29] <bigjools> quad core Phenom, with 3 very sad cores doing nothing, takes 270 minutes
[09:29] <lifeless> thats amd right ?
[09:30] <lifeless> but 4 core - moderately old?
[09:30] <bigjools> the "quad core" i5 with SSD takes about 240 IIRC but not run it on there for a while
[09:30] <wgrant> 270 minutes? Is that with or without Windmill?
[09:30] <bigjools> w/o
[09:30] <bigjools> it's about 4.5 hours now
[09:30] <wgrant> When I got my new machine in December, it was slightly under 3 hours.
[09:30] <bigjools> yes, we have had a massive regression in time
[09:30] <wgrant> ec2 is back down around 3.5
[09:31] <wgrant> Not much worse than it used to be.
[09:31] <wgrant> Since I killed Windmill.
[09:36] <lifeless> adeuring: https://code.launchpad.net/~lifeless/launchpad/bug-711071/+merge/53956
[09:36] <adeuring> lifeless: I'll look
[09:37] <lifeless> thanks
[09:48] <rvba> adeuring: Hi, I'd appreciate a review of https://code.launchpad.net/~rvb/launchpad/db-dds-diffpage-form/+merge/53913
[09:49] <adeuring> rvba: sure, let me just finish a review for Robert
[09:49] <rvba> adeuring: sure
[09:49] <rvba> thx
[09:58] <bigjools> wgrant: my last ec2 took 4 hours
[10:00] <wgrant> bigjools: Mine take between 3:30 and 3:45
[10:02] <bigjools> lifeless: sorry missed your question, yeah the Phenom is 2 years old now
[10:03] <lifeless> I'm considering a new desktop
[10:03] <bigjools> but parallel test runs... could breathe new life into it :)
[10:03] <lifeless> yeah
[10:03] <lifeless> will want 2-4GB per core though
[10:04] <bigjools> lifeless: if money is not a problem I'd get an i7
[10:04] <lifeless> [because of silly overheads]
[10:04] <bigjools> or perhaps there's better now
[10:04] <lifeless> bigjools: I have a gen-1 i7, limited to 6GB memory
[10:04] <bigjools> they're not slack :)
[10:04] <lifeless> bigjools: runs like a rocket, but nowhere near enough memory to use all the cores well
[10:04] <lifeless> not even for compiling drizzle ;P
[10:05] <bigjools> lifeless: memory contention?
[10:05] <bigjools> bus ^
[10:05] <lifeless> footprint
[10:05] <bigjools> ah
[10:05] <lifeless> 8 g++ instances >> 6GB of ram, for instance
[10:08] <adeuring> lifeless: r=me
[10:09] <lifeless> adeuring: thanks!
[10:09] <lifeless> should fix 80 timeouts/day
[10:10] <lifeless> huh, thats oddd
[10:10] <lifeless> there is no 'set commit message' widget on https://code.launchpad.net/~lifeless/launchpad/bug-711071/+merge/53956
[10:10] <lifeless> or am I crazy?
[10:12] <lifeless> there is now. weird
[10:57] <deryck> Morning, everyone.
[11:03] <rvba> stub: thanks for your review on my branch (lp:~rvb/launchpad/db-distroseries-migrate-owner-to-registrant) ... a question though:
[11:03] <rvba> stub: patch-2208-53-0.sql was adding a new 'registrant' column to distribution. This branch renames the 'owner' column into registrant for distroseries. Could you elaborate on where the conflict is?
[11:04] <stub> rvba: The conflict is in my mind then :)
[11:04] <stub> I'll change that now
[11:04] <rvba> stub: all right thx ;-)
[11:06] <bigjools> lol
[11:22] <adeuring> rvba: r=me
[11:24] <allenap> deryck: Javascript tests, lib/lp/registry/javascript/tests/test_milestone_table.html for example, are messed up; the skin appears missing. Applying http://paste.ubuntu.com/582035/ fixes it. I'm wondering if my build changes last week broke this. Do you know much about this?
[11:30] <rvba> adeuring: thx for the review, just pushed the changes you suggested.
[11:31] <adeuring> rvba: great, thanks!
[11:31] <rvba> stub: thank you for your reviews. I just pushed the modifications you requested.
[11:37] <deryck> allenap: I think the CSS was broken because we changed to fetchCSS: false in the test. I never worked out what CSS it wanted because it was just trying the Yahoo CDN with some massive list of CSS.
[11:37] <deryck> allenap: so if adding that file link fixes it, awesome!
[11:38] <deryck> allenap: we had to set fetchCSS false to better play with Windmill as the test runnner.
[11:38] <allenap> deryck: Cool. As long as it wasn't me :) I might @import it from test.css.
[11:38] <deryck> allenap: sounds good.
[11:38] <allenap> Thanks for your help.
[11:38] <deryck> np.  Thank you for working on this!
[11:39] <wgrant> jml: Your assignment of that bug is encouraging.
[11:39] <jml> wgrant: I'm just looking into it right now. No amazing insights.
[11:39] <wgrant> Oh :(
[11:39] <wgrant> Well, good luck...
[11:39] <jml> wgrant: do you have any clue as to why the comment says "run a job that will not time out first, followed by a job that is sure to time out." when the code seems to only run one job?
[11:40] <stub> rvba: Looks fine
[11:41] <wgrant> jml: StuckJob is two jobs.
[11:41] <jml> wgrant: ta.
[11:41] <wgrant> See iterReady... the first one has an arg of 1, the second 2. Only when the arg is 2 does it sleep.
[11:41] <jml> yeah. I see now.
[11:42] <wgrant> It is not really sensible.
[11:42] <jml> it seems a bit indirect.
[11:47] <jml> huh. If I'm reading this correctly, TwistedJobRunner only runs one job at a time.
[12:12] <lifeless> night y'all
[12:13] <bigjools> lifeless: nn - just replying to your ha uploaders email BTW
[12:13] <lifeless> bigjools: cool,thanks
[12:14] <bigjools> nearly done if you want to wait :)
[12:27] <lifeless> bigjools: take the time to reply fully
[12:27] <lifeless> bigjools: I'm just lining up the ducks to point losas at after we finish the appserver capacity work, so there isn't a panic - we can knock ideas back and forth for maybe a couple of weeks without impacting schedules
[12:28]  * lifeless halts()
[12:29] <bigjools> lifeless: np at all
[12:31] <jml> :(
[12:32] <wgrant> jml: No luck?
[12:32] <wgrant> Or perhaps anti-luck?
[12:32] <jml> wgrant: some success.
[12:33] <jml> wgrant: test_shhh manipulates sys.path on import and doesn't clean it up, which is why the _pythonpath thing doesn't bite us on the full suite run.
[12:33] <wgrant> jml: Ahhh.
[12:34] <jml> ampoule tries to get the correct sys.path for the "must be available" packages by importing them in the current process and manipulating their path.
[12:34] <wgrant> Yep.
[12:34] <wgrant> I got that bit.
[12:34] <jml> OK.
[12:34] <wgrant> It's a bit odd.
[12:34] <jml> went down a bit of a rabbit hole assuming it was something to do with zope.testing respawning.
[12:34] <wgrant> As did I, but then I deleted some stuff to prevent that and it was still broken.
[12:35] <wgrant> I didn't think that test_shhh might have been doing path evil.
[12:38] <jml> I'm going to change test_timeout to temporarily extend sys.path and fix up the test_shhh thing in another branch.
[12:39] <jml> ... and file a bug about providing a decent mechanism for doing this with python-fixtures.
[12:49] <gmb> adeuring: Are you accepting reviews today?
[12:49] <bac> gmb: i am if adeuring isn't
[12:49] <adeuring> gmb: yes, but i'd like to start my lunch break right now.
[12:49] <gmb> adeuring: Ok, no worries.
[12:50] <gmb> So, bac. Hi :).
[12:50] <gmb> bac: https://code.launchpad.net/~gmb/launchpad/non-js-muting-bug-734732/+merge/53981 if you please
[12:50] <bac> good morning
[13:12] <bac> hi mrevell
[13:12] <mrevell> Hello bac
[13:13]  * jml sets the test to run 50 times over and takes a brief programmer's break
[14:36] <abentley> deryck: I'm trying to use jquery, but I can't figure it out.  The queries in lib/lp/code/windmill/tests/test_recipe_index.py succeed on my page, and they shouldn't, because it's a different page.
[14:36] <abentley> deryck: e.g. self.client.waits.forElement(jquery=u'("div#edit-build_daily a.editicon.sprite.edit")', timeout=5)
[14:37] <deryck> ok, that's a bit scary.
[14:37] <deryck> abentley: you don't get an error with that on your page?
[14:37] <abentley> deryck: No.
[14:38] <abentley> deryck: it's green.
[14:38] <abentley> deryck: I'm using a pdb session to test.
[14:39] <abentley> deryck: meanwhile, $("ul#branch") fails, even though firebug identifies an element that way.
[14:40] <abentley> Apparently, the $ makes the difference.
[14:42] <deryck> abentley: can you commit the test you have to your branch so I can pull and run it?
[14:42] <abentley> deryck: sure, one sec.
[14:44] <abentley> deryck: pushed to bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/js-translation
[14:44] <deryck> abentley: ack.
[14:44] <deryck> oh yippee, another Windmill hang!
[14:44] <abentley> deryck: run with bin/test -t test_sharing_details windmill --layer=WindmillLayer
[14:45] <deryck> abentley: let me get a bt on my current Windmill hang, and then I'll kill it and look at yours.
[14:45] <abentley> deryck: thanks!
[14:59] <gmb> adeuring, bac: I have a minor JS branch for review, if you'd be so kind: https://code.launchpad.net/~gmb/launchpad/fix-js-errors-bug-737557/+merge/54007
[14:59] <bac> gmb: i'll do it
[14:59] <adeuring> gmb: I'll look
[14:59] <bac> i win!
[14:59] <adeuring> bac:  ok ;)
[15:00] <gmb> Thanks :)
[15:00] <gmb> bac: https://code.launchpad.net/~gmb/launchpad/fix-js-errors-bug-737557/+merge/54007
[15:00] <gmb> Dur.
[15:00] <gmb> Sorry, forgot I'd pasted it.
[15:11] <deryck> abentley: ok, sorry.  got what I need now.  Turning to your branch.
[15:11] <bac> sinzui: are you saying you want me to put the line-height: 20 back in?
[15:13] <sinzui> bac: no. I do not want that instruction anywhere in the code base
[15:14] <bac> sinzui: good -- it's gone
[15:14] <sinzui> \o/
[15:15] <sinzui> Sorry about the confusion. I got very distracted yesterday evening. I composed my reply to you, but never sent it
[15:37] <deryck> abentley: ok, so this has me terrified of the reliability of jquery selectors now.
[15:38] <abentley> deryck: sorry.
[15:38] <deryck> abentley: if you try to click jquery=u'("div#edit-build_daily a.editicon.sprite.edit")' it will fail.  But using waits.forElement or asserts.assertNode, it passes.
[15:38] <deryck> abentley: which clearly makes no sense and is wrong
[15:40] <leonardr> adeuring or bac, can you review https://code.launchpad.net/~leonardr/lazr.restful/operation-sanity-check/+merge/54014 ?
[15:40] <abentley> deryck: so avoid using with those?  I've been plugging away using xpath, and it's... beauty-challenged.
[15:40] <adeuring> leonardr: i'll look
[15:40] <leonardr> great
[15:41] <deryck> abentley: I'm not sure what to recommend at this point.  xpath is equally problematic. You often get false positives the same way, from crafting xpath expressions you don't understand.
[15:41] <leonardr> adeuring: i'll fill in some background in a comment
[15:41] <leonardr> since the feature is new
[15:41] <adeuring> leonardr: great, thanks!
[15:42] <deryck> abentley: or fragile tests from poorly crafted xpath.
[15:42] <deryck> abentley: and there is no way to hang IDs off this html?  because of the menu stuff.
[15:42] <abentley> deryck: I wonder if any of our intermittant failures are from waits.forElement(jquery= ?
[15:43] <deryck> abentley: if it's a failure and not a hang, that's easy to check -- i.e. was it a jquery line?  Hangs don't appear related to this at all.
[15:44] <LPCIBot> Project devel build #553: FAILURE in 4 hr 58 min: https://lpci.wedontsleep.org/job/devel/553/
[15:44] <abentley> deryck: Yes, not hangs.  But failing to wait long enough would cause a failure on a later line.
[15:44] <deryck> right
[15:45] <deryck> indeed, it's something to look out for.
[15:45] <leonardr> adeuring: background is added
[15:45] <deryck> abentley: but we're only using it in recipe tests at this point, I think.
[15:45] <abentley> deryck: I could use ids, but classes seemed a better approach, because I could consistently use the same value-- class=incomplete, not id=branch-incomplete
[15:46] <deryck> abentley: I don't see an issue with specific IDs.  Reuse is not always a virtue when dealing with the DOM and js and js testing.
[15:46] <abentley> Then I can do foo=Y.one('#branch'), foo.one('.incomplete')
[15:47] <abentley> It just makes it simpler once you've got the checklist node.
[15:48] <deryck> but you can hang id="branch-incomplete" off the element just for the sake of testing.  sure, it's hacked on, but if the test is less fragile.
[15:49] <deryck> abentley: I leave it to you, though.  Just warning that xpath is usually a source of trouble at some point.  But maybe this is easy enough xpath.
[15:49] <abentley> deryck: I would rather not have both class=incomplete and id=branch-incomplete.  That's a DRY violation to me.
[15:50] <deryck> abentley: sure, but I'm arguing DRY is not that big a deal in HTML. ;) :)
[15:50] <abentley> deryck: But I hadn't realized the testing implications before, so perhaps it's better to change my approach now.
[15:50] <deryck> abentley: yeah, HTML is not code. ;)
[15:51] <abentley> deryck: i'm saying if I add ids, I'll remove the classes.  No need for both.'
[15:51] <deryck> abentley: but I do agree it's generally better if you can avoid.  less characters, less to download.  but our testing story is weak without the ids.  and you could just use branch-incomplete and not the class.
[15:51] <deryck> agreed ^^ :-)
[15:53] <deryck> abentley: ok, so I'll lunch now, if you've got everything you need.
[15:53] <abentley> deryck: anyhow, I think I have to use xpath with the picker.
[15:53] <deryck> abentley: maybe so.  this is one area where we've had to use it and can't avoid it in the past.
[15:54] <abentley> deryck: cool.  Thanks.  Enjoy lunch.
[15:54] <deryck> ok, cool.  thanks!
[16:12] <gary_poster> mrevell, hi.  I'm trying to find the accordion prototyping round 2 version 2 slides
[16:12] <gary_poster> I found https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/Testing/AccordionPrototypingRound2
[16:13] <gary_poster> which has version 2
[16:13] <mrevell> Ah, glad you got it gary_poster
[16:13] <gary_poster> but I can't find version 2
[16:13] <gary_poster> and https://wiki.canonical.com/Launchpad/UserResearch/BugSubsFeb2011/Round2 points to the wrong location (round 1)
[16:13] <mrevell> Oh, sorry
[16:13] <mrevell> Let me look
[16:13] <gary_poster> thank you
[16:16] <gary_poster> mrevell, found it somehow or other :-)
[16:16] <mrevell> gary_poster, I've created a page at https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/Testing/AccordionPrototypingRound2/Version2 which links to the 5 slides and I've updated the wiki page
[16:16] <mrevell> on Canonical
[16:16] <gary_poster> awesome thank you mrevell
[16:18] <mrevell> no probs :)
[16:23] <adeuring> leonardr: r=me. Thanks for the new checks and for the explanation!
[17:08] <sinzui> bac: will you have time to review https://code.launchpad.net/~sinzui/launchpad/tea-and-biscuts/+merge/54041 today?
[18:01] <abentley> deryck: turns out there's some picker logic in testing.windmill.widgets, so we don't need to use xpath for it.
[18:02] <deryck> excellent!
[18:02] <deryck> I forgot about that actually.  Sorry.
[18:03] <abentley> deryck: np
[18:07] <abentley> deryck: how would you test for the absence of a class on a node?  Currently, I'm doing self.client.waits.forElement(xpath='//*[@id="branch"]/*[@class="complete sprite yes"]') to ensure the node is not unseen.
[18:10] <deryck> abentley: that looks fine. Are you worried that by not being explict about the absence of unseen that the test will pass but not be correct?
[18:10] <abentley> deryck: I'm just wondering if you would avoid using xpath for that, and if so, how.
[18:12] <deryck> abentley: well, I would have mad the ID "branch-complete" or given it some other unique ID, to avoid the xpath.  As we talked about eariler.
[18:13] <abentley> deryck: okay, but if you did that and did forElement(id="branch-complete"), how would you know what the class was?
[18:13] <jcsackett> leonardr: ping
[18:13] <leonardr> jcsackett, yo
[18:14] <jcsackett> hi. do you have a few minutes to mumble or skype about webservice stuff?
[18:14] <deryck> abentley: I wouldn't test that in Windmill.  I would do that in the YUI test.  I wouldn't worry much about DOM in the Windmill test. You really should only care the data was saved correctly.
[18:15] <leonardr> jcsackett, sure, 1 minuteeeeeee
[18:15] <jcsackett> leonardr: thanks.
[18:15] <abentley> deryck: If I don't wait until the dom is updated, how do I know when it's safe to check the model?
[18:16] <deryck> abentley: do you not add some class when you remove the unseen class, i.e. changing it to "seen"?
[18:16] <sinzui> deryck: all pickers are using the wrong headings. I do not think the instructions should be a heading at all in fact. That will make the text smaller
[18:16] <deryck> sinzui: agreed.  Just plain on text.
[18:17] <abentley> deryck: No, I don't add a "seen" class.  But I could use the other element, where I add "unseen".
[18:17] <sinzui> deryck: I can start this in a hour or so...I was irked by the very add-member issue this morning when testing
[18:17] <deryck> abentley: yes, that would work.
[18:17] <abentley> deryck: Okay, how would that work?
[18:18] <abentley> deryck: forElement(id="branch-incomplete") still won't wait until the DOM is updated.
[18:19] <deryck> abentley: I'm getting confused.  :-)  I thought you just said you could wait for the unseen class on the other element.  so waits.forElement(blah blah blah about the other element now).  That won't work?
[18:20] <deryck> sinzui: thanks!  Did something change recently to cause this?
[18:20] <abentley> deryck: I've got lots of elements that have the unseen element, so waits.forElement(class="unseen") will not wait until branch-incomplete gains the class.
[18:20] <leonardr> jcsackett: expose_as_webservice_entry()
[18:20] <abentley> s/unseen element/unseen class/
[18:20] <leonardr> exposed()
[18:21] <sinzui> deryck: sort of. Heading sizes were updated to be like the guidelines. but in this specific case, the instructions exceeded the default width of the picker last December when we fixed security in team membership
[18:21] <leonardr> expose_as_webservice_collection()
[18:22] <abentley> deryck: it's fine if the answer is "I would use xpath in that case".
[18:23] <deryck> abentley: can you craft an xpath expression or jquery selector?  That would be my suggestion, yes.  Use one of those.
[18:23] <deryck> sinzui: ah, gotcha.
[18:23] <abentley> deryck: I am already using an xpath expression, so I'll just keep using it, then.
[18:25] <deryck> abentley: ok.
[18:28] <abentley> deryck: you said to avoid xpath where possible.  I was just exploring where that's possible.
[18:29] <deryck> abentley: yeah, maybe it's not possible here.  I'm always worried when we're checking for the visibility of an element.  But maybe there's no other way to know the page changed.
[18:31] <abentley> deryck: when the page changes, one element becomes visible, the other is hidden, and the href and contents of a link are changed.
[18:34] <deryck> abentley: so I'd check for the contents change then.
[18:34] <deryck> abentley: textIn
[18:36] <deryck> ah, crap, that's an assert
[18:36] <abentley> deryck: all the uses I see are client.asserts.assertTextIn.  Is there a waits version?
[18:37] <deryck> abentley: yeah, that's what I just noticed.  Let me look
[18:40] <deryck> abentley: so that won't work.  Sorry.  You could do waits.forElementProperty to do the classname or href nicer than xpath.
[18:40] <abentley> deryck: Ah, okay.
[19:14] <jml> \o/
[19:20] <jml> OK. I think I've got this failure reproducing consistently.
[19:20] <jml> Time to make some food and then track the bugger down.
[20:04] <deryck> Have a nice weekend, everyone.
[20:22] <bac> hi jcsackett, where do i see the diff overlay you mention?
[20:25] <bac> jcsackett: nm, i found it
[20:31] <jcsackett> bac: good thing. i never got the ding i usually get to let me know someone's pinging me. :-)
[20:41] <bac> nice branch jcsackett, r=ac
[20:41] <bac> er, r=bac
[20:42] <jcsackett> thanks, bac.
[20:44] <jcsackett> sinzui: standup at 5:30 or at 6, given our other members are enjoying the weekend?
[20:44] <sinzui> We can do it now if you like
[20:46] <jcsackett> sinzui: right now i am at a coffee shop. i'm figuring out when i need to make the short walk back home. :-)
[20:46] <sinzui> Ping me when you are ready
[20:46] <jcsackett> sinzui: righto.
[21:07] <leonardr> wallyworld, do you know where thumper is? i'd like to do the standup and then take a nap
[21:08] <leonardr> unless... oh, wait, it's saturday for oyu, isn't it?
[21:08] <sinzui> leonardr: yes it is
[21:08] <sinzui> take a nap
[21:08] <leonardr> ok, never mind then. nap time! talk to you on monday/tuesday
[21:16] <jcsackett> sinzui: i am now in a mumble friendly place. i can do standup whenever you like.
[21:16] <jml> I think ampoule handle timeouts badly
[21:16] <sinzui> jcsackett: starting mumble
[22:58] <LPCIBot> Yippie, build fixed!
[22:58] <LPCIBot> Project devel build #554: FIXED in 5 hr 16 min: https://lpci.wedontsleep.org/job/devel/554/
[23:33] <LPCIBot> Project windmill build #72: FAILURE in 1 hr 16 min: https://lpci.wedontsleep.org/job/windmill/72/