[00:38] <wgrant> Erm
[00:38] <wgrant> r14367 is a little odd
[00:40] <StevenK> Oh?
[00:40] <wgrant> Naming cookies after the LP username.
[00:40] <wgrant> Very odd.
[00:41] <StevenK> qas looks okay to me, is the topic stale?
[00:42] <wgrant> It's been back for an hour or so.
[00:42] <StevenK> Good enough for me.
[00:45] <wgrant> lifeless: Was there consensus on which cookie approach to take?
[00:50] <lifeless> wgrant: see the discussion on the MP that just landed
[00:51] <wgrant> Hmm, OK.
[00:51] <wgrant> Still seems pretty hideous to include the (mutable) username in the cookie.
[00:52] <lifeless> agreed
[00:53] <lifeless> deryck is coming around
[01:28] <poolie> wallyworld__, i guess feedback about the specifics of the disclosure ui would be beside the point?
[01:29] <wgrant> Probably, but still useful.
[01:29] <wallyworld__> poolie: for the email to the dev list yes. but huwshimi and mrevell etc would love to hear feedback
[01:30] <wallyworld__> poolie: since we are iterating based on screenshots from 18 months ago and user testing now etc
[01:33] <wallyworld__> poolie: also, that ui you saw from the email is now old. we're working on a new version, something like http://people.canonical.com/~huwshimi/policy7.png
[01:34] <poolie> ok
[01:34] <poolie> that looks a lot better
[01:35]  * poolie cancels his draft
[01:35] <poolie> maybe you can follow up with that?
[01:43] <wgrant> fuuuuuuuuuuuuu
[01:43] <wgrant> buildbot failed again.
[01:43]  * wgrant disables yuixhr
[01:43] <wgrant> gary_poster: Around?
[01:44] <gary_poster> wgrant: I'm working on it
[01:44] <wgrant> actual = ["Failure in lp/app/javascript/tests/test_lp_client_integration.Cache data.test_logged_in_user_has_cache_data: Unexpected error: Can't find variable: url",
[01:44] <StevenK> wgrant: I thought you did that last night?
[01:44] <wgrant> StevenK: I decided to give it another run to sort itself out.
[01:44] <wgrant> It didn't.
[01:44] <StevenK> wgrant: Or was that just a threat?
[01:44] <wgrant> gary_poster: Any reason not to disable it now?
[01:44] <wgrant> It's blocked all builds for more than a day now.
[01:45] <wgrant> Ah, I see your email.
[01:45] <wgrant> Thanks.
[01:48] <wallyworld__> poolie: the ui from the screenshot is not quite ready yet. the point of the email wasn't get get feedback on the disclosure ui, but the technology used to produce the mockups
[01:49] <poolie> yeah i understand
[01:49] <poolie> it was just an example
[01:49] <poolie> i think it's great that you did an interactive mockup
[01:51] <wallyworld__> it took a bit of work (lots of javascript hacking) but it's got some great feedback into the development of the feature
[01:51] <wallyworld__> if we can speed up the process by which we can deliver such mockups and end up with less wastage (throwaway code), i think that will be great
[02:07] <poolie> i wonder if there is any path to having it running in an actual lp instance but with no backend
[02:07] <poolie> i don't know if that would actually be harder
[02:11] <wallyworld__> poolie: pyramid or grok (ie a lightweight, easily deployable app server with zope support) i think may be easier
[02:19] <lifeless> wallyworld__: is there any reason you can't just edit templates in-place on lp ?
[02:19] <lifeless> wallyworld__: with the same persistence throwaway story ?
[02:19] <wallyworld__> lifeless: wouldn't that involve landing stuff via pqm or whatever?
[02:20] <wallyworld__> or do you mean ssh into the deployment server
[02:20] <wallyworld__> and edit directly via the file system?
[02:20] <rick_h_> wallyworld__: is this up some place to play with? (seeing screenshot)
[02:21] <lifeless> wallyworld__: ec2 demo
[02:21] <rick_h_> I'm curious what the edit link does, it seems like it'd just be on the person to overlay a ui to add/edit permsisions for that user vs per permission
[02:21] <wallyworld__> rick_h_: the latest screenshot isn't (yet). only the earlier version as per the email
[02:22] <lifeless> wallyworld__: e.g. just edit in your own local copy to hearts content, then shove it up on the ec2 instance (or canonistack or ...)
[02:22] <wallyworld__> lifeless: ah, that may work. i haven't used ec2 demo before
[02:23] <wallyworld__> rick_h_: the edit icon per person uses a ChoiceSource popup to edit the permissions for that person
[02:23] <wgrant> As discussed on the call yesterday, ec2 demo probably doesn't quite work any more, but would be easy enough to fix.
[02:24] <rick_h_> wallyworld__: got it, missed the link when I read your email originally
[02:25] <wallyworld__> the thing to remember also is that it has to be a RAD environment. hacking javascript and static html fits the bill there. but we want a bit more, like templates etc
[02:25] <rick_h_> wallyworld__: are you guys using a JS tpl language at all?
[02:25] <rick_h_> YUI is building in support for handlebar in their MVC stuff, but I've used jquery-tmpl and underscores stuff
[02:25] <wallyworld__> rick_h_: no. but we would look to use mustache i guess since that's now in our technology stack
[02:26] <rick_h_> yea, I think deryck and the guys are using it on their feature landing
[02:26] <wallyworld__> (it wasn't when we started the mockup)
[02:26] <rick_h_> sorry, handlebar/mustache
[02:26] <rick_h_> I group the two together when I think of them
[02:26] <wallyworld__> sure :-)
[02:27] <rick_h_> I've always thought the couchapp stuff would be awesome for mockups, but I think it's a bit far from where you want to be
[02:30] <rick_h_> wallyworld__: small ui thing, curious why the "Add an Observer" wouldn't fit over on the right like a "Report a bug" or "Register a branch" type item?
[02:31]  * rick_h_ is checking out when different ui mechanisms are used like that
[02:32] <wallyworld__> rick_h_: it may well go there. we were working off the supplied screenshots that were done a while ago
[02:32] <rick_h_> ah ok
[02:32] <wallyworld__> poolie: rick_h_: latest version http://people.canonical.com/~ianb/disclosure/
[02:32] <rick_h_> sorry, it's interesting stuff so I like to pester :)
[02:33] <rick_h_> I'd definitely try to go lighter on the grey for more contrast
[02:33] <rick_h_> but cool
[02:33] <wallyworld__> rick_h_: please continue to ask questions. fwiw, a lot of what is there in the screenshots we are working of we agree needs to be fixed
[02:33] <wallyworld__> so were are using them as a starting point
[02:34] <rick_h_> what would be sweet, would be if the grey boxes were buttons, and the edit link only showed on hover
[02:34] <rick_h_> that would clean it up a bit readable wise imo
[02:34] <wgrant> That was what I was sorting of thinking, yeah.
[02:34] <wgrant> The edit links all over LP are really cluttersome.
[02:34] <rick_h_> I know that hover stuff gets into the way of mobile, but I'm not sure how mobile friendly we are atm anyway
[02:34] <rick_h_> wgrant: yea, I want to align them something fierce lol
[02:35] <rick_h_> I've wished I had started back when the new buglist stuff had first started lol
[02:35] <wgrant> Heh
[02:35] <wgrant> Yeah
[02:35] <rick_h_> I like my lines through my ui/design I guess, though I hate css grids...so go figure
[02:36] <wallyworld__> rick_h_: lighter grey now done :-)
[02:36] <rick_h_> ah, much nicer
[02:37] <rick_h_> so why can I click on some and not others?
[02:37]  * wgrant tries to dig up the faded edit icon.
[02:37] <wallyworld__> rick_h_: atm, if you are in a team role, you get full observer rights (thats that the original screenshots called for). i'd have to check to see if that's still the case
[02:38] <wallyworld__> s/team role/project role
[02:38] <wgrant> wallyworld__: It's no longer the case.
[02:38] <rick_h_> ah, default perms then
[02:38] <wgrant> It's merely the default during project setup.
[02:38] <rick_h_> gotcha
[02:38] <wallyworld__> wgrant: np. i'll add the edit icons to those ones then
[02:43] <wgrant> Aha, https://launchpad.net/@@/edit-grey
[02:43] <wgrant> That's what I was looking for.
[02:43] <wgrant> Slightly less abhorrent.
[02:43] <wgrant> The initial inline bug status/importance used that until hover.
[02:45] <wallyworld__> wgrant: i think anything is less abhorent than the yellow :-)
[02:46] <wgrant> Surely not.
[02:48] <wgrant> (I think ideally it would appear like a dropdown listbox, so it would have a down arrow instead of an edit icon. but lazr-js doesn't really do that sort of thing)
[02:49] <wgrant> wallyworld__: I don't think it's useful to show "View nothing" rather than just hiding that policy. But then how do we add a new one.
[02:50] <wallyworld__> wgrant: that's the dilemma
[02:51] <wallyworld__> wgrant: we could have a proper popup form/widget
[02:51] <wallyworld__> and a single edit icon in the table row
[02:51] <poolie> wallyworld__, are the pencils on the permissions really helping anything?
[02:51] <wgrant> Our JS UI toolkit is sort of limited :/
[02:51] <wgrant> Yes, they're helping to lots of LP pages look crap :)
[02:52] <poolie> also, having the bug/branch column have no text is a bit odd
[02:52] <poolie> and the whole layout looks a bit oddly cramped
[02:52] <wallyworld__> poolie: they are currently needed to allow the permissions to be edited
[02:52] <poolie> technically needed?
[02:52] <poolie> hm
[02:53] <wallyworld__> poolie: the bug/branch column doesn't need text - it's the mechanism to navigate to the user's detailed disclosure page
[02:53] <wgrant> wallyworld__: Well, might be useful to say "1234 bugs, 2 branches" or something like that.
[02:53] <poolie> exactly
[02:53] <poolie> and make that a link
[02:53] <poolie> it just looks broken at the moment
[02:53] <wallyworld__> can do that
[02:54] <poolie> mm
[02:54] <poolie> to make the top of the thing less cluttered
[02:54] <wgrant> Also, those are really an attribute of the "restricted observer" grant for a particular policy.
[02:54] <poolie> maybe move "add an observer" to the distinguished actions portlet in the top right?
[02:54] <poolie> like for 'report a bug'
[02:54] <poolie> "The list of observers can be large. Use Search to look for particular users.
[02:54] <poolie> The search term will be matched against name, Launchpad id, email.
[02:54] <poolie> "
[02:55] <poolie> seems like it doesn't really need to be there
[02:55] <wallyworld__> can do that too. the current layout is as per the supplied screenshots that were were given to start from
[02:55] <poolie> it's pretty obvious what search will be for
[02:55] <wgrant> wallyworld__: Are these mockups in a branch somewhere?
[02:55] <poolie> the heavy black rule through the middle of the filters is a bit odd too
[02:56] <poolie> might be better if all the filters were grouped within a box
[02:56] <poolie> "Show users which can view the project because they belong to a team which has permission."
[02:56] <wallyworld__> wgrant: lp:~launchpad-purple-squad/+junk/disclosure_mockups
[02:56] <poolie> to start with surely you mean "who" not "which"
[02:56] <poolie> but
[02:56] <poolie> i don't know if that sentence is adding much
[02:56] <poolie> or what it's supposed to mean
[02:57] <wallyworld__> poolie: the black line is to separate the controls since the ones above the line cause a xerver call, the ones below filter in place
[02:57] <poolie> :/
[02:57] <poolie> ok
[02:57] <wallyworld__> but rememeber, this is all exploratory, a starting point
[02:58] <poolie> sure
[02:58] <poolie> i'm exploring it :)
[02:58] <poolie> i think, if the line was not there
[02:58] <poolie> it would probably be clear that some of them act immediately and others need to be submitted
[02:58] <wallyworld__> huwshimi: you may want to cut n paste the above discussion for feedback into the devel process
[02:59] <wallyworld__> poolie: the line was added because users thought it wasn't clear
[02:59] <huwshimi> wallyworld__: I'll have a look
[03:00] <poolie> what specifically wasn't clear?
[03:00] <wallyworld__> huwshimi: thanks. there's been some good feedback to add to whatever the user testers come up with
[03:00] <poolie> mm
[03:00] <huwshimi> wallyworld__: OK great
[03:00] <poolie> i think it's a bit like the green link thing
[03:00] <poolie> yes it means something
[03:00] <poolie> but is it something users actually need to know about?
[03:01] <wallyworld__> poolie: it wasn't clear that the bottom controls acted in place vs doing a submit
[03:01] <poolie> if they need to know about it to use the thing effectively, it needs to be a distinction they'll actually understand
[03:01] <poolie> hm ok
[03:01] <wallyworld__> poolie: i sort of agree with you. i was just following orders :-)
[03:01] <poolie> so they clicked it and
[03:01] <poolie> ...
[03:01] <poolie> trying to understand why that would be confusing
[03:02] <wallyworld__> by that i mean i think it was indicated we need to distinguish between the two types of controls, but i could have mis remembered that
[03:03] <poolie> i don't think that's a goal in itself
[03:03] <poolie> the point is just that people can understand how to use it
[03:03] <wallyworld__> so, so far we've gone from the original old screenshots to huwshimi's latest design which came from one round of user testing plus the ever evolving feature requirements
[03:03] <poolie> nobody else specifically distinguishes them so i'm really skeptical that we need to
[03:03] <wallyworld__> the end users haven't yet seen this 2nd iteration
[03:04] <poolie> i think if we ask them "will foo cause a round trip to the server" they may not know but that's not a practical question
[03:05] <wallyworld__> poolie: it's not so much a round trip to server thing vs a responsiveness thing. in-place obviously much quicker
[03:05] <wallyworld__> but perhaps the distinction isn't required
[03:05] <poolie> mm
[03:05] <poolie> people will find out it's slow easily enough :)
[03:06] <wallyworld__> like with the rest of lp untilthe recent performance improvements :-)
[03:07] <wallyworld__> so, the idea now is to iterate to get to the point where the ui reflects the latest functional requirements. then we can bikeshed^H^H^H^H^H file tune :-)
[03:16] <StevenK> wgrant: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/use-userHasPriviledges/+merge/82967 ?
[03:18] <wgrant> StevenK: Is DSP.driver necessary?
[03:18] <wgrant> Also, I don't see any tests for SP/DSP.drivers
[03:18] <wgrant> Apart from that it looks disturbingly sensible.
[03:19] <StevenK> Disturbingly? :-/
[03:19] <StevenK> I'm not sure about DSP.driver, I don't think so, since the codepath checks if it implements IHasDrivers and then grabs .drivers
[03:19] <wgrant> Right.
[03:19] <wgrant> But you seem to have added DSP.driver.
[03:20] <StevenK> And .drivers. I am a muppet.
[03:21] <StevenK> wgrant: Right, binned. Let me write a test for both.
[03:21] <wgrant> Thanks.
[03:21] <wgrant> Should be pretty quick :)
[03:24] <huwshimi> wallyworld__: Which discussion exactly did you want me to look at?
[03:24] <wallyworld__> huwshimi: just the feedback about the mockup which people saw after i sent the email to dev. eg search form, edit icons etc
[03:32] <StevenK> wgrant: Diff updated
[03:33] <wgrant> k
[03:36] <wgrant> StevenK: Are you sure those new tests aren't just [] == []?
[03:39] <StevenK> wgrant: Yes. I've added self.assertIsNot([], obj.drivers) where obj is the distro or the series and the tests still pass.
[03:40] <wgrant> StevenK: k
[03:40] <wgrant> Hah
[03:40] <StevenK> wgrant: Do you want me to commit and push that change, or you don't care?
[03:40] <wgrant> fhjwejiowefjio
[03:40] <wgrant> StevenK: You know xfce4-smartbookmark-plugin?
[03:41] <wgrant> How gina's been complaining about it for weeks?
[03:41] <wgrant> StevenK: s/IsNot/NotEqual/, but yes.
[03:41] <StevenK> Was that the non-free->main madness that the ftp-masters screwed up?
[03:42] <wgrant> StevenK: No, it fails to unpack due to a patch referenced in series that doesn't exist.
[03:42] <wgrant> It turns out that dpkg-dev is actually hideous.
[03:42] <wgrant> And having reliably unpackable packages would be too easy.
[03:42] <wgrant> There are vendor-specific series files.
[03:42] <StevenK> Oh, right, that one.
[03:42] <wgrant> So this unpacks fine on Debian, but not Ubuntu.
[03:42] <StevenK> Bwaha
[03:42] <wgrant> Because the bogus patch is mentioned in debian/ubuntu.series.
[03:42] <StevenK> Sigh
[03:42] <wgrant> Who could possibly think it was a good idea.
[03:43] <wgrant> To make it ununpackable in that case.
[03:43] <StevenK> So we need to patch dpkg to complain but not abort?
[03:44] <wgrant> No, we probably need to slap whoever designed 3.0 (quilt) like that.
[03:44] <wgrant> I'm not sure what dpkg-source can sensibly do here :/
[03:45] <wgrant> I wonder if --no-preparation works.
[03:45] <wgrant> It does not.
[03:45] <wgrant> Ah, --skip-patches
[03:45] <StevenK> We do not care about patches for gina, surely
[03:45] <wgrant> Exactly.
[03:46] <StevenK> wgrant: Not so fast though -- does Lucid's dpkg support --skip-patches ?
[03:46] <wgrant> I'm about to find out.
[03:46] <wgrant> It does.
[03:46] <StevenK> wgrant: Perhaps we should get wallyworld__ to fix it. Then he can touch Soyuz and wish he didn't.
[03:47] <wgrant> I wonder what happens if I transfer the unpacked tree from an Ubuntu machine to a Debian one.
[03:47] <wgrant> StevenK: Do you feel like filing a bug in Debian?
[03:47]  * wallyworld__ ducks for cover
[03:47] <wgrant> Since I hate the BTS.
[03:47] <StevenK> Against dpkg?
[03:47] <StevenK> :-)
[03:49] <wgrant> Hah
[03:49] <wgrant> As much as I would like to consider the vendor-specific unpacking rules to be a grave bug, I don't think they'd like me much for that.
[03:50] <StevenK> wgrant: Why don't you just configure reportbug?
[03:50] <wgrant> STAB
[03:50] <wallyworld__> poolie:  wgrant: i added the grey edit icons
[03:50] <wgrant> wallyworld__: I doubt they look good, but they're probably less offensive.
[03:50]  * wgrant checks.
[03:51] <wgrant> Hah
[03:51] <wgrant> The circle is just slightly visible.
[03:51] <wallyworld__> less offensive is also what i'd say
[03:51] <StevenK> wgrant: Those two extra asserts are in the diff.
[03:51] <wgrant> But still looks much better.
[03:51] <wallyworld__> yeah
[03:51] <wgrant> With slight tweaking of the (otherwise unused, AFAIK) icon, it could look quite reasonable.
[03:51] <wgrant> In fact, possible just drop the circle entirely.
[03:52] <wgrant> StevenK: lol
[03:52] <wgrant> StevenK: dpkg-source: warning: --skip-patches is not a valid option for Dpkg::Source::Package::V3::native
[03:52] <wgrant> StevenK: So it warns if you ask for reliable extraction all the time.
[03:52] <StevenK> Fucking hell.
[03:53] <wgrant> It still works.
[03:53] <wgrant> But spews warnings.
[03:53] <StevenK> wgrant: However, here it unpacks, just exits 2
[03:53] <wgrant> StevenK: Ah, is that so...
[03:53] <wgrant> I didn't think about that.
[03:53] <wgrant> I wonder what 2 means.
[03:54] <StevenK> I wonder if I can claim serious
[03:54] <StevenK> important, at the very least
[03:55]  * wgrant watches for the wontfix
[03:56]  * wgrant wonders why we don't have any running water.
[03:56]  * wgrant goes hunting.
[03:58] <StevenK> wgrant: debian/patches/series is a symlink to ubuntu.series
[04:01] <wgrant> StevenK: In Ubuntu's version, or Debian's?
[04:01] <StevenK> Debians
[04:02] <StevenK> So Debian's xfce4-smartbookmark-plugin has a patch applied to direct people to launchpad to file bugs
[04:02] <StevenK> Rather than the BTS
[04:03] <wgrant> Which version?
[04:04] <wgrant> In 0.4.4-1, debian/patches/series doesn't exist.
[04:04] <wgrant> Because Debian's patches were included upstream.
[04:04] <StevenK> I have 0.4.4-1 unpacked, and it's a symlink
[04:05] <StevenK> Oh, that's dpkg-source being stupid
[04:05] <wgrant> Hah
[04:06] <StevenK> Nastygram filed
[04:07] <StevenK> wgrant: Now that I've wrangled the BTS for you, can you wrangle my MP for me?
[04:08] <wgrant> Sorry, got distracted by lack of water.
[04:08] <wgrant> And dpkg-dev
[04:16] <StevenK> wgrant: Thanks, tossing at ec2.
[04:23] <poolie> wallyworld__, grey just looks kind of disabled
[04:23] <wallyworld__> yeah, i guess so
[04:24] <poolie> is there a technical thing that will break if there's no icon?
[04:24] <wallyworld__> but final styling will come later
[04:24] <poolie> or is it more just that we think people won't realize they can click it...?
[04:24] <poolie> you get a hover underline
[04:24] <poolie> that makes it pretty obviously clickable to me
[04:24] <wallyworld__> i think people expect an icon
[04:24] <poolie> huwshimi, remove bug tags woo
[04:25] <wallyworld__> but i'll defer to the usability testing for what we need to do
[04:25] <poolie> yeah, me too
[04:25] <poolie> i just want the possibility of no pencils to be considered
[04:25]  * StevenK stabs jtv
[04:25] <poolie> the argument is basically just "we've always done that"
[04:25] <jtv> What have I done now?
[04:26] <jtv> Or are you just exploring different uses of pencils?
[04:26] <StevenK> jtv: Inflicted that damnable buildd-manager branch on me
[04:26] <poolie> haha
[04:26] <jtv> SCORE!
[04:26] <jtv> I was going to mention that.
[04:26] <jtv> At some point.
[04:26] <jtv> Almost certainly.
[04:27] <jtv> Cross my heart and hope to be just outside my home when a slight drizzle starts.
[04:27] <poolie> wallyworld__, so while we're waiting for the testing
[04:27] <poolie> i don't know, is there any other reason than just people might expect it?
[04:28] <StevenK> jtv: We've had 23mm here since 9am
[04:28] <poolie> .. i don't want to be a pain
[04:28] <poolie> i just really think it looks bad without adding anything
[04:28] <poolie> we have to stop some day
[04:28] <wallyworld__> poolie: well, i  would think we need to be consistent with the test of lp
[04:28] <wallyworld__> s/test/rest
[04:28] <StevenK> wgrant: Debian #649680, since the BTS sucks.
[04:28] <_mup_> Bug #649680: Link titles of pages that aren't UTF8 appers as gibbrish <Hoborg IRC Bot:Fix Committed> < https://launchpad.net/bugs/649680 >
[04:28] <poolie> cause the rest of lp has totally consistent ui?
[04:28] <poolie> :)
[04:28] <wallyworld__> mostly
[04:29] <StevenK> poolie: I thought you knew!
[04:29] <wallyworld__> more or less
[04:29] <wallyworld__> perhaps
[04:29] <wgrant> I think we need some indication that it's editable.
[04:29] <poolie> consistency has value but
[04:29] <wgrant> A pencil is probably not it.
[04:29] <poolie> if you want to change things
[04:29] <wgrant> It's really a list both.
[04:29] <wgrant> List box.
[04:29] <poolie> you've got to start somewhere
[04:29] <wallyworld__> sure
[04:29] <poolie> so one pattern people use is a little [v] icon when it pops up a control
[04:30] <poolie> especially a list
[04:30] <wgrant> Exactly.
[04:30] <wgrant> That's exactly what this is.
[04:30] <wgrant> But lazr-js doesn't really do that sort of thing.
[04:30] <poolie> but really on many sites just hover underline/color/background seems to be enough
[04:30] <wgrant> It prefers invoking a popup somewhere else on the page.
[04:30] <poolie> it invites people to click and then they can see what happens
[04:31] <wallyworld__> my thinking is that lp is being rebranded atm, so we should wait for that to establish the guidelines
[04:31] <wallyworld__> we have other things to deliver
[04:31] <poolie> fair enough
[04:32] <wallyworld__> poolie: but i'm sure huw is open for suggestions on his rebranding work :-)
[04:34] <poolie> :)
[04:52] <jtv> StevenK: thank you for your sage comment on my branch.
[04:53] <jtv> The bit about the vodka was particularly insightful.
[04:53] <jtv> I think you're right.
[04:53] <StevenK> About which bit?
[04:54] <jtv> The vodka.
[04:54] <lifeless> the vodka, clearly
[04:55] <jtv> wgrant: do you drink vodka?  I'm asking because we need another expert opinion on https://code.launchpad.net/~jtv/launchpad/bug-717969/+merge/83022
[04:56] <nigelb> A branch about vodka?
[04:56]  * nigelb looks
[04:57] <jtv> nigelb: nooooooo!  Don't!
[04:58] <jtv> Poor man.  Went in without his Absolut goggles.  He'll never be the same.
[04:58] <nigelb> Hahaha. Nice.
[04:58] <nigelb> I stayed away from the code. So not scarred.
[04:58] <nigelb> The only read your description and StevenK's rerview.
[04:58] <nigelb> *review
[04:59]  * jtv tearfully greets nigelb back
[05:00] <nigelb> :)
[05:01] <wgrant> Yay
[05:01] <wgrant> UnicodeDecodeError in bson.loads
[05:02] <StevenK> LIFELESS
[05:03] <nigelb> ooh. Caps Lock.
[05:05] <lifeless> StevenK
[05:06] <StevenK> lifeless: I was just guessing the Unicode issue was from oops-tools or something
[06:52] <poolie> hm so merging this loggerhead export patch raises the question of upgrading loggerhead as a whole
[06:59] <lifeless> same as other source deps - land a change to LP to upgrade it
[08:34] <poolie> ok
[08:34] <poolie> tarball download works here; it should be ok to get it in tomorrow
[09:11] <danhg> Morning
[11:55] <rick_h_> morning
[12:18] <allenap> Good morning rick_h_
[13:58] <rick_h_> wallyworld__: wgrant is there a branch for the disclosure stuff I can see/find to checkout?
[14:34] <cr3> sinzui: hola, I noticed your branch ~sinzui/html5-browser/trunk doesn't seem to exist anymore, which one should I be using instead?
[14:34] <sinzui> !
[14:34] <sinzui> I will find it and put it back
[14:35] <cr3> sinzui: thanks man, it's been really nice for testing yui
[14:38] <sinzui> cr3, I am helping another user. It will be a few minutes
[14:39] <cr3> sinzui: no worries, take your time
[14:48] <sinzui> cr3, can you see https://code.launchpad.net/~sinzui/html5-browser/trunk ?
[14:48] <sinzui> I just branches lp:html5-browser
[14:50] <sinzui> I just branched lp:html5-browser
[14:50] <cr3> sinzui: seems to work, but it didn't work when building overnight: https://launchpadlibrarian.net/85743890/buildlog_ubuntu-precise-i386.launchpad-results_0.13-1%7Eppa0.12.04_FAILEDTOBUILD.txt.gz
[14:53] <sinzui> ah. cr3, I think gary was changing lp's buildout rules. That was added recently. I created debs, but buildbot does not have them
[14:54] <cr3> sinzui: the package seems to have built fine for 10.04 and 10.10 though, only later releases failed. anything I should do?
[14:54] <abentley> rick_h_: I don't see assert_change being used anywhere.  Is it dead code?
[14:54] <rick_h_> looking
[14:55] <rick_h_> yes, changed to using the .wait() thanks
[14:55] <sinzui> cr3. I will copy the package to precise. I may want to do that for a few other too
[14:55] <cr3> sinzui: the build also failed for 11.04 and 11.10 though
[14:56] <sinzui> I am not sure what to say, maybe gary_poster can help since he added the source deps
[14:56] <gary_poster> what did I do?
[14:57] <gary_poster> All I remember doing was adding html5_browser as a buildout dependency to lp
[14:57] <cr3> gary_poster: can you have a look at this build failure, seems to be related to buildout: https://launchpadlibrarian.net/85743890/buildlog_ubuntu-precise-i386.launchpad-results_0.13-1%7Eppa0.12.04_FAILEDTOBUILD.txt.gz
[14:57] <gary_poster> but I didn't touch the debs
[14:59] <gary_poster> sinzui, cr3, this seems to be the heart of the issue: http://pastebin.ubuntu.com/747089/
[14:59] <gary_poster> I don't think I touched html5 browser's buildout either, though I could be wrong
[15:00] <gary_poster> but I don't think that error has anything to do with buildout anyway
[15:00] <sinzui> gary_poster, who put html5 in buildout? I only make deb packages
[15:01] <cr3> gary_poster, sinzui: I'll try rebuilding in the ppa and then maybe try locally with sbuild
[15:01] <cr3> sinzui: I put html5 in my buildout
[15:01] <sinzui> ah, thank you for clarifying
[15:01] <gary_poster> sinzui, I put html5 in LP buildout.  That has nothing to do with this error
[15:03] <cr3> gary_poster: so we both have html5 in our buildouts, do you have a tarball in your sourcedeps branch or do you branch html5 directly in buildout?
[15:03] <gary_poster> cr3 tarball
[15:03] <cr3> gary_poster: maybe I should do the same...
[15:13] <abentley> rick_h_: It's really helpful if you include my nick.  This can be a noisy channel, but using my nick makes your replies stand out.
[15:13] <rick_h_> abentley: yea, sorry.
[15:14] <rick_h_> I forget that not all irc has nick highlighting and such. I know some do notifications so try to avoid doing that too much
[15:14] <rick_h_> thanks for the heads up abentley
[15:15] <abentley> rick_h_: my IRC has nick highlighting, but your nick is the same colour as sinzui's.
[15:15] <rick_h_> gotcha
[15:16] <abentley> rick_h_: When you mention my nick, you get highlighted orange, and I get a bell.
[15:18] <abentley> rick_h_: I try to avoid pausing in tests for two reasons: 1. such tests often fail intermittently, 2. such tests take longer than they otherwise would.
[15:19] <abentley> rick_h_: what is the operation you're needing to wait for?
[15:19] <rick_h_> abentley: agreed. I can see if I lessen the amount of test text I use the redraw on the clone element will be fast enough to not require it
[15:19] <rick_h_> abentley: I believe it's the updating of the content from the target, to the clone, and getting that to resize before I can check it's new height value
[15:20] <abentley> rick_h_: can you just change the code to be synchronous, i.e. to only return once the new value is set?
[15:20] <rick_h_> it's going off off a YUI triggered event
[15:21] <rick_h_> I'll see if I can find a way there and I'll trace the actual draw/etc timings to make sure where the pause is
[15:21] <abentley> rick_h_: whatever is triggering the event will not return until all the event's listeners have been run.
[15:27] <deryck> hmmm, wonder why we got some css changes on qastaging but not all.
[15:28] <abentley> rick_h_: On line 358, you specify CHANGE_TIME as a third parameter to target.plug.  What does that mean?
[15:29] <rick_h_> abentley: nothing, not sure how that got into that one call
[15:29] <rick_h_> removed
[15:30] <abentley> rick_h_: Cool
[15:32] <abentley> rick_h_: could you change "ns" to "module" per https://dev.launchpad.net/JavaScriptReviewNotes#Javascript_Module_formatting ?
[15:32] <rick_h_> abentley: sure thing
[15:33] <deryck> abentley, rick_h_ -- can one of you guys check qastaging for me.  are the importance colors the same as they were?
[15:34] <abentley> deryck: they look different.  "Medium" is light blue.
[15:35] <deryck> abentley, ah nice.  So some odd caching on my end then.  cool.
[15:38] <abentley> rick_h_: Do you need MAX_HEIGHT and MIN_HEIGHT to be separate variables, or would it work to do e.g. "min_height: {value: 10}"?
[15:39] <deryck> man, getting those "columns" to line up with real data is going to be really hard to do.
[15:40] <rick_h_> abentley: looking
[15:42] <rick_h_> abentley: I'll need to find a different way to tell if a value has been passed in at object construction time.
[15:43] <rick_h_> abentley: I'll add a test to picking up the min height from the current element (I think that's broken right now) but that needs to know if you passed a min height or not
[15:43] <abentley> rick_h_: I think you could move that code into a valueFn.
[15:45] <abentley> rick_h_: But why do want to pick up the min height from the current element?
[15:45] <abentley> rick_h_: ISTM that the current element could be really big, and you could be reducing its size a lot.
[15:45] <rick_h_> abentley: well if in the html of your textarea you say height=xxx, I want to respect that and not resize it down to the default
[15:47] <abentley> rick_h_: aren't textareas usually configured in rows and columns rather than height and width?
[15:48] <rick_h_> you can, but I think most move that to css these days
[15:48] <rick_h_> so if the css says the height is 150, I'll use that as the new min if you didn't specify one at your .plug() call
[15:48] <rick_h_> abentley: ^
[15:49] <abentley> rick_h_: Okay.
[15:49] <rick_h_> looking at the valueFn, if I have set a value, it seems this.get('min_height') would return value into my valueFn() call
[15:49] <rick_h_> I'll check to make sure, if not, then I can remove the constant and move to a valueFn
[15:49] <abentley> rick_h_: If you supply a value, the valueFn will not be used at all.
[15:50] <abentley> rick_h_: If the valueFn return undefined, then the value will be used.
[15:50] <rick_h_> "If both the value and valueFn properties are defined, the value returned by valueFn has precedence over the value property,"
[15:50] <abentley> rick_h_: right.
[15:50] <abentley> So, the precedence is supplied value > valueFN > value
[15:51] <rick_h_> ok, I see. So using this.get('min_height') in the valueFn is safe because I know that no value was supplied
[15:53] <abentley> rick_h_: in the valueFn, I don't see why you'd get('min_height') at all.  It would either return undefined or do infinite recursion.
[15:54] <rick_h_> right, it would just check if there was a css style to use
[15:54] <rick_h_> if so return it else undefined and value kicks in
[15:54] <abentley> rick_h_: right.
[15:55] <rick_h_> thanks, I like that a lot better
[15:55] <abentley> rick_h_: someone writing YUI was thinking the same way you are.
[15:55] <rick_h_> yea, I've not used valueFn and such. New toys!
[16:01] <abentley> rick_h_: the condition at 186 looks very complicated.  Are you worried about the case where this._prev_scroll_height < this.get('min_height') ?
[16:02] <rick_h_> abentley: no, if the prev_scroll_height < min_height it falls through to the else case and sets the height to the min
[16:03] <rick_h_> I could wrap those into bool returning function calls with better names to help make it clearer perhaps
[16:03] <abentley> rick_h_: how would prev_scroll_height be less than min_height>
[16:03] <abentley> rick_h_: how would prev_scroll_height be less than min_height?
[16:04] <rick_h_> abentley: _set_start_height should make sure that never happens
[16:05] <rick_h_> but you asked if I was worried about that case, and even if it *were* to happen the else clause should cover it
[16:05] <abentley> rick_h_: If it's safe to assume that this._prev_scroll_height < this.get('min_height'), then can't we rewrite the conditional as "if (scroll_height > this.get('min_height'))" ?
[16:07] <abentley> rick_h_: Or maybe do new_height = Math.max(this.get('min_height'), Math.min(scroll_height, this.get('max_height')) ?
[16:08] <rick_h_> abentley: yes, I think you're right. I set the default _prev due to a bug in testing and I think you're right that it greatly simplifies the conditions there now
[16:09] <abentley> rick_h_: cool.
[16:10] <abentley> rick_h_: You talk about preventing resize in webkit.  What happens in firefox?
[16:10] <rick_h_> abentley: it doesn't allow users to drag/resize. Since it's based off a css property, I'd hope that if it's added they'd support the same standard
[16:11] <abentley> rick_h_: yes, it does, in recent Firefoxes on Ubuntu.
[16:11] <rick_h_> ah, you're right. And the css rule applies there
[16:12] <rick_h_> abentley: so I'll generalize that comment then vs just calling out webkit
[16:12] <abentley> rick_h_: okay.
[16:13] <abentley> rick_h_: this._t_area is just meant as a more meaningful alias for this.get('host')?
[16:14] <rvba> abentley: Can you please have a look at this MP? https://code.launchpad.net/~rvb/launchpad/revert-14355/+merge/83183
[16:14] <rick_h_> abentley: yes, shorter to type, specific, and prevents calling .get() multiple times
[16:14] <abentley> rvba: I can do it next.
[16:14] <rvba> abentley: I'm reverting the "improvement" I've made to an expensive query because the performance is worse.
[16:15] <abentley> rvba: doh!
[16:15] <rvba> abentley: oh, allenap agreed to have a look at it right now…
[16:16] <abentley> allenap: have at it.
[16:16] <abentley> rick_h_: why does _setup_css take a parameter?
[16:17] <rick_h_> abentley: no good reason.
[16:18] <abentley> rick_h_: okay, please change it to use this._t_area, then.
[16:18] <rick_h_> done
[16:19] <rick_h_> abentley: you use the timeline tool in the chrome dev tools much?
[16:19] <abentley> rick_h_: no, I don't use chrome much.
[16:19] <rick_h_> ok
[16:20] <abentley> rick_h_: what does it do?
[16:20] <rick_h_> it shows the low level browser calls/events, layout, paint, event fired, etc
[16:20] <rick_h_> I'm trying to use it to figure out why I need that pause
[16:20] <rick_h_> that's ok, nvm. Just curious
[16:21] <jcsackett> sinzui: would review for the mockup wallyworld and i whacked together be sending it over to dan and huw for comments, or ... ?
[16:22] <sinzui> jcsackett, I think I did
[16:22] <jcsackett> sinzui: ok. i'll throw the card into review then.
[16:22] <jcsackett> i'll also take a quick look at that padlock icon on loggerhead; i think it's a quick fix.
[16:22] <sinzui> fab
[16:22] <abentley> rick_h_: Is it a case where "setStyle('foo', 'bar'); getStyle('foo')" does not return "bar"?
[16:23] <rick_h_> abentley: it seems to be. I can see the event fired, but it doesn't show it hitting the event catching code
[16:23] <rick_h_> and then I see it running a layout call because I called getStyle
[16:23] <rick_h_> which should cause it to pick up the recalc, but it's like the event callback isn't done yet
[16:23] <rick_h_> but like you say, it should be
[16:23] <sinzui> I think the main reason I do not blog like it is 2005 is because the spammers comment like it is 2012
[16:24] <abentley> rick_h_: What event?  this.t_area.on('valueChange' ?
[16:24] <rick_h_> abentley: yes
[16:25] <rick_h_> that callback has to complete before I can grab the updated height for the test to verify the change
[16:25] <abentley> rick_h_: so if you set a breakpoint in resize, it never stops there?
[16:26] <rick_h_> it does, but the timeline doesn't show it calling out to resize. What I'm trying to figure out is how the new value is getting pulled as the same as the original before the callback is complete
[16:31] <abentley> rick_h_: so in FF, test_initial_resizable and test_max_height pass without the wait.
[16:31] <abentley> rick_h_: the other two fail.
[16:31] <rick_h_> abentley: it fails for me
[16:31] <rick_h_> initial_resizable
[16:32] <rick_h_> in FF
[16:32] <rick_h_> I've commented out the rest and only working on trying to get the initial_resizable working without the wait
[16:32] <rick_h_> in both browsers, without luck so far
[16:32] <abentley> rick_h_: weird, it consistently works for me.
[16:33] <abentley> rick_h_: FF 8
[16:33] <rick_h_> abentley: ah, I'm on 7.0.1
[16:34] <abentley> rick_h_: In initial_resizable, there's no event involved, is there?
[16:34] <rick_h_> abentley: true
[16:35] <rick_h_> it just runs resize on the first call after it determins min/max
[16:35] <abentley> rick_h_: Oh, there are two waits in that one, and I missed the second.
[16:35] <abentley> rick_h_: fails for me too, now.
[16:35] <rick_h_> abentley: ah ok
[16:38] <abentley> rick_h_: I track the event down to value-eventchange.js:157
[16:38] <abentley> rick_h_: and it appears to do polling.
[16:39] <rick_h_> abentley: gah, that makes a lot of sense then
[16:40] <rick_h_> abentley: makes a lot of sense. If I changed the CHANGE_TIME to 50ms it would always pass, but under that it would fail, even with the wait
[16:40] <rick_h_> and that's the POLL_INTERVAL
[16:40] <abentley> rick_h_: In your tests, do you have a philosophical objection to firing the event yourself?  Or invoking the functions directly?
[16:41] <rick_h_> abentley: the simulate code doesn't support valueChange
[16:41] <rick_h_> abentley: so I had to mimic a keypress event which it does support
[16:42] <deryck> abentley, hi. I realize you're on call today, but we need someone from our squad to get a deployment done today.
[16:42] <rick_h_> abentley: the event code dupes the content to the clone so I could pull that out in order to make it callable for testing purposes
[16:42] <deryck> abentley, and I think it's a bit too soon to ask that of rick_h_ :)
[16:43] <abentley> rick_h_: I think that would be best.
[16:43] <rick_h_> abentley: ok, I'll ajust for that and let you know when I get that into place
[16:43] <abentley> rick_h_: Right now, it's a bit of an integration test, where YUI is part of the system under tests.
[16:43] <rick_h_> sounds like deryck has plans for you :)
[16:43] <rick_h_> abentley: agreed, thanks for pointint out the polling
[16:44] <abentley> deryck: Okay, but it's not something I have much experience with, either, TBH.
[16:45] <deryck> abentley, it's not too hard.  See the qa report here:  http://lpqateam.canonical.com/qa-reports/deployment-stable.html
[16:45] <deryck> abentley, you just need to pester people to get qa done or do qa for anyone who is sleeping, if you can.
[16:47] <deryck> abentley, we need to deploy up to r14369.
[16:47] <deryck> abentley, and either I or flacoste can help a bit if you get stuck.
[16:47] <deryck> abentley, then once the qa is caught up, you update the LPS page and ask a losa to do the deploy.
[16:50] <abentley> deryck: I don't think we can deploy, because r14355 is bad, and the rollback hasn't landed yet.
[16:51] <deryck> ah crap.
[16:51] <deryck> flacoste, ^^
[16:51] <abentley> deryck: that rolllback is pending, though.
[16:51] <rvba> fwiw I've just reverted r14355 (r14374).
[16:51] <deryck> so that's some better then.
[16:52] <deryck> still probably 4-5 hours to the build completes then.
[16:52] <deryck> abentley, that may be ok, then.  By the time you get all the qa chased up, that rev could be merged.  right?
[16:52] <deryck> assuming buildnot plays along with us.
[16:53] <rick_h_> can either of you load code.qastaging without a timeout?
[16:53] <abentley> rick_h_: did it recently.
[16:53] <rick_h_> I thought things were still 'not right' since I've not been able to load to look at my QA
[16:53] <rick_h_> ok, I'll keep trying then
[16:54] <abentley> rvba: Cool.
[16:54] <abentley> deryck: Sure, though that means more revisions to QA.
[16:56] <flacoste> deryck, abentley: so the next deployable revision will be 14374, but there is still some QA to go still
[16:57] <deryck> abentley, yeah, sorry, just more to qa.  And you don't have to do it all either.  You can ask for help, for the original author to qa, etc.
[16:58] <deryck> abentley, the idea is just that you'll be the one to poke people and prod the process along.
[16:59] <mterry> flacoste, gary_poster, benji: barry suggested I ask you a question I have about zope.  I'm trying to fix a FTBFS for zope2.12 because the package is hardcoded to use python2.6.  It will build if I change that to 2.7, but do you have any ideas how likely that is to work run-time?  2.13 apparently explicitly added support for python2.7.  Do you know if that was a no-op or if there's a patch floating around I can use?
[17:00] <abentley> rvba: what about 14366?
[17:00] <rvba> abentley: I knew you would ask ;)… I need the revert to be on qastaging to qa that revision.
[17:01] <gary_poster> mterry, I'm afraid I have no idea--I haven't had any connection to Zope 2 in a very long time.  benji is not around today, but probably is similar.  I can give you two emails of people I'd recommend asking in a privmsg.  Would that be helpful?
[17:01] <mterry> gary_poster, sure, thanks
[17:01] <abentley> rvba: I don't understand.  It looks like it needs a rollback or a bugfix.  Are you doing either one?
[17:03] <rvba> abentley: Well, I can qa it on anther page… but the page I'd like to see now issued a very bad query that makes the page time out.
[17:04] <rvba> s/issued/issues/
[17:04] <abentley> rvba: it's marked qa-bad.
[17:05] <abentley> rvba: it doesn't sound like it needs qa.
[17:05] <rvba> abentley: both revisions target the same bug.
[17:05] <rvba> abentley: r14355 is qa-bad (I've reverted it), the other one needs qa.
[17:06] <rvba> abentley: https://bugs.launchpad.net/launchpad/+bug/867941
[17:06] <_mup_> Bug #867941: person:+activereviews times out <affects-ubuntu> <code-review> <qa-bad> <timeout> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/867941 >
[17:06] <rvba> abentley: not sure how to deal with that situation…
[17:06] <abentley> rvba: Ah.  CAN WE PLEASE HAVE REVISION BASED QA?  PRETTY-PLEASE?
[17:06] <rvba> Right!
[17:07] <deryck> rick_h_, this matches the new spinner you added, right?  http://people.canonical.com/~deryck/spinner-big.gif
[17:08] <abentley> rvba: So once your revert is landed, you'll be able to QA the other revision, which may or may not be bad.
[17:09] <rvba> abentley: right. Please take into consideration the fact that I'm almost EODed, but I can come back later this evening to do that qa.
[17:09]  * deryck see doing a deploy has driven abentley to shouting :)
[17:09] <rvba> hehe
[17:11] <abentley> deryck: This is how I always feel when I have to interact with the deployment reports.  They don't tell me what I want to know, and they don't tell me the truth.
[17:11] <rvba> abentley: waterfall says the ETA for the build is ~2h.  How long after that for the revisions to be deployed to qastaging?
[17:12] <flacoste> rvba: if you leave instructions on how to do the qa, i can take care of it
[17:13] <abentley> rvba: I don't know how long that takes.
[17:14] <abentley> rvba: I guess we could ask a losa to help the process along.
[17:16] <rvba> flacoste: thanks for the offer, I'll write the instructions on the mp, but I'll nonetheless pop up in 2h30 min to see if I can do the qa myself.
[17:17] <flacoste> ok, thx
[17:22] <rick_h_> deryck: yes, that matches
[17:23] <rvba> flacoste: abentley I've just updated the mp https://code.launchpad.net/~rvb/launchpad/activereviews-bug-867941-eagerload2/+merge/82904. Right now the page it talks about on qastaging is not accessible because it times out (hence my previous revert of an attempt to improve one of the huge queries).
[17:25] <flacoste> rvba: perfect!
[17:25] <deryck> rick_h_, thanks!
[17:26] <deryck> my xchat indicator seems to have died.
[17:27] <rvba> I'm off now but I'll be back later tonight to see if I can do my qa…
[18:15] <abentley> deryck: https://code.launchpad.net/~benji/launchpad/bug-877195-code/+merge/80619 does not have enough information for me to do QA, and benji isn't around.
[18:17] <abentley> rick_h_: Have you been able to do QA on lp:~rharding/launchpad/bug_814697_missing_spinner ?
[18:18] <rick_h_> abentley: no, I can't get code.xxx to load other than the root page
[18:18] <rick_h_> I've been trying the last hour
[18:20] <abentley> rick_h_: https://code.qastaging.launchpad.net/bzrtools/+activereviews works for me.
[18:22] <abentley> rick_h_: also https://code.qastaging.launchpad.net/bzrtools/+merges
[18:23] <rick_h_> abentley: thanks, looking for a good sample case now
[18:37] <rick_h_> gah, this is nuts
[18:37] <rick_h_> abentley: so do the branches actually exist on qastaging if I wanted to "fake" enough to get something to QA?
[18:37] <rick_h_> I've tried three different ones and just get "error not a branch" from bzr
[18:38] <abentley> rick_h_: yes, pushing to qastaging should work.
[18:38] <rick_h_> ok
[18:39] <abentley> rick_h_: bzr push lp://qastaging/~abentley/bzrtools/monk works for me.
[18:39] <rick_h_> ok, I was trying to pull from an existing merge request branch.
[18:39] <rick_h_> I'm probably doing more wrong, working on setting up something to be able to test with
[18:39] <abentley> rick_h_: no, only a few branches get copied across.
[18:40] <rick_h_> abentley: ok, thanks
[18:40] <abentley> rick_h_: so you need to push fresh ones, but that will work.
[18:40] <rick_h_> abentley: ok, will try that
[19:04] <rick_h_> abentley: any way to foce the make sync_branches on qa next?
[19:04] <rick_h_> or should I just be patient
[19:04] <abentley> rick_h_: yes, ask a losa to run the appropriate script.
[19:34] <jcsackett> abentley: can i get a quick look at https://code.launchpad.net/~jcsackett/loggerhead/add-lock-icon/+merge/83203? it's very short.
[19:34] <abentley> jcsackett: certainly.
[19:35] <jcsackett> thanks.
[19:35] <abentley> jcsackett: r=me
[19:35] <jcsackett> thanks, abentley.
[19:43] <deryck> abentley, how are we doing on prepping deploy?  Just waiting on rollback to work it's way through now?
[19:43] <abentley> deryck: No, https://code.launchpad.net/~benji/launchpad/bug-877195-code/+merge/80619 does not have enough information for me to do QA, and benji isn't around.
[19:46] <deryck> abentley, hmmm, perhaps one of his squad mates could help us? gary_poster or bac, any idea?
[19:46] <abentley> rick_h_: You don't need to resubmit.  You can just push and tell me you've updated it.
[19:46] <rick_h_> abentley: updated MP per our discussions this morning: https://code.launchpad.net/~rharding/launchpad/bugfix_891735/+merge/83217
[19:46] <rick_h_> abentley: ah ok, it wasn't showing the changes after a push so I thought I had to resubmit it
[19:46] <abentley> rick_h_: It should show that the diff is updating after a push, but it's easy to miss.
[19:47] <bac> deryck: let me look
[19:48] <deryck> bac, ok, thanks.  there are qa notes, but I'm guess abentley doesn't know the problem well enough to follow the notes.
[19:48] <bac> deryck: i just saw that
[19:51] <gary_poster> thanks bac
[19:55] <abentley> rick_h_: bind_events doesn't do a lot.  Would it make sense to merge it into initializer?
[19:57] <rick_h_> abentley: it can. I tend to move bindings out for clarification and a home to group any/all in one place
[19:58] <abentley> rick_h_: It's no biggie.  When I see a short single-call-site callable, I tend to move it to the callsite.
[19:59] <rick_h_> abentley: moved and pushed, no problem at all.
[20:00] <abentley> rick_h_: On line 176, why set this._prev_scroll_height = this.get('min_height')?  Why not set it to the actual size, for example?
[20:01] <sinzui_> flacoste, ping
[20:01] <flacoste> hi sinzui_
[20:02] <rick_h_> abentley: looking
[20:02] <sinzui_> flacoste, I *had* included the date of 2011-11-27 in the email to project owners to say when we would stop supporting shared private bugs...
[20:03] <sinzui_> flacoste, We are not technically stopping now, we are preventing users from creating new ones...
[20:03] <abentley> rick_h_: Or perhaps allow it to be undefined, and let the first call to resize set it?
[20:03] <flacoste> sinzui_: right
[20:03] <rick_h_> abentley: so if your textarea is 40px tall, but you set a min of 100, I need it to be different so resize kicks in
[20:04] <rick_h_> if I set it to undefined...I'd have to see what Math.max considers undefined
[20:04] <sinzui_> but I think I should mention that there will be a bug linking feature in the future and we expect to migrate the remaining shared bugs when the feature is available
[20:04] <sinzui_> ^ flacoste
[20:05] <abentley> rick_h_: this._prev_scroll_height is not an input to Math.max AFAICT.
[20:05] <rick_h_> abentley: ok, so tests pass with it at undefined
[20:05] <rick_h_> abentley: no, you're right, I was thinking the other way around. min_height
[20:05] <abentley> rick_h_: Ah.
[20:06] <rick_h_> abentley: ok, removed it entirely, tests all pass with it set to default of 0 as a start point
[20:07] <abentley> rick_h_: at 51, I think a second "var" would be clearer than having variable declaration spanning lines.
[20:08] <flacoste> sinzui_: yes, that would be good
[20:08] <sinzui_> okay
[20:08] <rick_h_> abentley: ok, not a fan of the mutliple vars at a time?
[20:08] <abentley> rick_h_: I'm fine with them if they don't span multiple lines.
[20:09] <rick_h_> oh heh, I'd hate them on one line. Ok,
[20:09] <rick_h_> updated
[20:10] <abentley> rick_h_: at 53, please use Y.Lang.isUndefined or Y.Lang.isValue rather than !== undefined.
[20:10] <abentley> rick_h_: Also, please indent only 4 spaces at 54.
[20:10]  * rvba takes a look at qastaging to see if r14374 has been deployed.
[20:11] <rvba> Not yet it seems…
[20:12] <rick_h_> abentley: sounds good
[20:13] <abentley> rick_h_: Your comments have more lines at the bottom than I'd expect.  I'd expect just "*/" after the last line of text.
[20:13] <rick_h_> abentley: gotcha, sorry, the python docstring rules coming out in me
[20:14] <abentley> rick_h_: Our docstrings have """ after the last line of text.
[20:14] <rick_h_> abentley: oh, could have sworn pep is one blank line at the end for readability. I missed that so far
[20:15] <abentley> rick_h_: I haven't consulted the PEP, but I think that's how we always do it.
[20:16] <rick_h_> abentley: ok, thanks for the heads up. Looks like it's more a "suggestion" in the pep 257 for it "The BDFL [3] recommends inserting a blank line between the last paragraph in a multi-line docstring and its closing quotes"
[20:17] <abentley> rick_h_: Interesting.
[20:17] <rick_h_> abentley: little retraining...to be expected :)
[20:17] <abentley> rick_h_: please remove one newline around 172.
[20:19] <rick_h_> abentley: sure thing
[20:19] <abentley> rick_h_: At 190, our style looks like this: http://pastebin.ubuntu.com/747478/
[20:20] <abentley> rick_h_: i.e. if all the arguments don't fit on a line, we do a line break and indent.  This is not PEP8, but it's what we do.
[20:20] <rick_h_> abentley: ok, since that's still long I'd wrap to a thired line at the Math ok?
[20:20] <rick_h_> abentley: sure thing
[20:20] <abentley> rick_h_: sure, that's fine.
[20:21] <rick_h_> http://pastebin.ubuntu.com/747480/ abentley so first/second preferred?
[20:21] <rick_h_> or doesn't matter
[20:21] <abentley> rick_h_: first.
[20:21] <rick_h_> abentley: thanks
[20:22] <abentley> At 271, I've see it in other test suites, but I'm pretty dubious that saving two keystrokes is a win.
[20:22] <rick_h_> abentley: ?
[20:23] <abentley> if you do "var Assert = Y.Assert;"  you can save two keystrokes by doing "Assert.areEqual" rather than "Y.Assert.areEqual".
[20:24] <rick_h_> abentley: ah, ok, yea I grabbed that out of other tests. Honestly, I'd prefer to just pull in the tests themselves and avoid the lookup costs of going through the object
[20:25] <abentley> rick_h_: Anyhow.  No big deal either way.
[20:25] <rick_h_> abentley: no problem, find and replace is my friend.
[20:26] <rick_h_> updated and pushed
[20:27] <abentley> rick_h_: 341, why not Assert.areSame?
[20:29] <abentley> rick_h_: test_removing_content looks sensitive to browser settings, but maybe that's inevitable.
[20:29] <rick_h_> abentley: no reason, just inexperience with array of assert methods
[20:29] <abentley> rick_h_: Ah.  Well, since we have it, let's use it.
[20:30] <rick_h_> abentley: how so? on the browser settings
[20:31] <abentley> rick_h_: You're asserting that the height of test_text will be greater than 100 px, and "shrink" will be <= 100 px, but both seem to depend on font settings.
[20:32] <rick_h_> abentley: ah true, I tried to pick values that would not be drastic enough to change much, but perhaps I can do better with finding smaller test values for those
[20:33] <abentley> rick_h_: I don't think it matters in a practical sense.
[20:34] <abentley> rick_h_: Oh, 273 is excessively long.  That should be split up into a list and joined: https://dev.launchpad.net/JavaScriptReviewNotes#Plain_Old_JavaScript
[20:35] <abentley> rick_h_: have you run make lint on this?
[20:36] <rick_h_> abentley: I've run jslint myself, I've not found the lint tool run during testing
[20:36] <rick_h_> abentley: so I was going to ask on the long block of text, would it be better to put into the test html and pull it out vs in the JS?
[20:36] <abentley> rick_h_: Sorry, don't understand "not found the lint tool run during testing"
[20:37] <rick_h_> I've seen refernce to a lint tool that's run during the test/merge/etc process
[20:37] <rick_h_> abentley: no, I've not run lint on it
[20:37] <abentley> rick_h_: right.  It's bin/lint.sh, but usually run as "make lint".
[20:38] <abentley> rick_h_: I'd prefer to keep the long block of text in the JS.
[20:38] <rick_h_> abentley: ok
[20:40] <abentley> rick_h_: at 379, "n" is too short as a variable name.  I suggest "node": https://dev.launchpad.net/JavaScriptReviewNotes#Plain_Old_JavaScript
[20:41] <rick_h_> abentley: ok
[20:42] <abentley> rick_h_: please remove the newline at 453.  And I think that's everything.
[20:43] <rick_h_> abentley: can you give me some context around 453? I've been a few lines off and not sure where you mean
[20:46] <abentley> rick_h_: I'm sorry.  443: http://pastebin.ubuntu.com/747500/
[20:47] <abentley> rick_h_: we don't go for multiple blank lines except at module level, generally.
[20:47] <rick_h_> abentley: yes, my fault completely. Just wasn't looking at the filedupe file
[20:48] <abentley> rick_h_: np.
[20:48] <rick_h_> abentley: thanks, changes all pushed
[20:49] <abentley> rick_h_: This was far more thorough than reviews typically are, but since you'll want to get up to speed with our style, I indulged my inner nit-picker.
[20:50] <rick_h_> abentley: definitely, it's completely what I was expecting
[20:50] <rick_h_> though I had thought I tried to catch things a bit better, so sorry for all the issues
[20:50] <rick_h_> appreciate you letting me time sink your day
[20:50] <rick_h_> now I'll go get a drink and lick my wounds :)
[20:51] <abentley> :-)
[20:51] <abentley> rick_h_: it was the same for me.
[20:55] <abentley> rick_h_: r=me.
[21:10] <rick_h_> abentley: ty much sir
[22:00] <poolie> hi all
[22:43] <poolie> oh huw, your tags list is so soothing
[22:44] <huwshimi> poolie: :D
[22:56] <huwshimi> poolie: Looking forward to that being deployed :)
[22:56] <poolie> me too
[22:57] <poolie> huwshimi one interesting thing is on eg https://bugs.qastaging.launchpad.net/bzr/+bugs it shows some tags with 0
[22:57] <poolie> i guess they are official but there are no remaining open bugs
[22:57] <poolie> this is reasonable
[23:35] <wgrant> poolie: I believe that's always been the case. It just wasn't obvious before because the counts weren't shown.
[23:35] <wgrant> Ooh
[23:35] <wgrant> Beta banner.
[23:36] <jelmer> wgrant: ooh, where?
[23:37]  * jelmer is still wondering how to add that for mercurial imports
[23:37] <wgrant> jelmer: mmm, not sure how well it would work for imports. see eg. https://bugs.qastaging.launchpad.net/launchpad/+bugs
[23:37] <jelmer> wgrant: I don't see anything there
[23:38] <wgrant> You may need to be in ~custom-buglisting-demo
[23:38] <poolie> yeah that is nice
[23:52] <jelmer> hmm, that looks good indeed
[23:52] <jelmer> takes up quite a bit more vertical space per bug than previously though
[23:53] <wgrant> Yeah, and it's a lot less scannable.
[23:55] <jelmer> I think the beta banner would actually work for mercurial imports - we could show it on the branch page of imports, and just add a "(beta)" bit after the choice in the import creation menu.
[23:55] <wgrant> jelmer: True.