[01:47] <wallyworld_> rick_h: i've discovered a fatal flaw in our changes to how we instantiate the YUI instances
[01:49] <rick_h> wallyworld_: ruh roh /me hides
[01:50] <wallyworld_> rick_h: the change from using a single YUI instance LPS to creating a new YUI instanc eeach time we do a YUI().use(...)
[01:50] <wallyworld_> there's code which puts stuff in a well known global namespace
[01:51] <wallyworld_> and now each YUI().use(...) is sandboxed
[01:51] <rick_h> wallyworld_: right, which code is this? I've been working on moving that code out
[01:51] <wallyworld_> so different bits of YUI code cannot see this shared info anymore
[01:52] <wallyworld_> there's 2 places - one i'm developing now (and is broken after merging trunk), and also the butask deletion code which is on prod
[01:52] <rick_h> wallyworld_: right, that shared stuff needs to become a YUI module and then each use() that needs it has to require it
[01:52] <wallyworld_> so the current bug task deletion setup is in form-picker-macros.pt
[01:53] <wallyworld_> it attaches a function to a 'lp.app.picker.connect' namespace
[01:53] <rick_h> gah, yea that's my task after all this, getting JS out of the .pt files
[01:53] <rick_h> wallyworld_: ok, so can that code be moved to lp.app.picker YUI module?
[01:53] <wallyworld_> the issue here is that we have all this js in pt files and we need a global namespace to be able to glue stuff together
[01:54] <wallyworld_> no, because it's bespoke code
[01:54] <wallyworld_> the picker is generic infrastructure
[01:54] <rick_h> wallyworld_: so that's why I've got the huge glob of JS code in the layout macro file
[01:54] <rick_h> since that makes it global
[01:54] <rick_h> hmmm, but I see, it gets attached to the YUI module ugh
[01:55] <rick_h> it's just so wrong...
[01:55] <wallyworld_> hmmm. but here, the code is paramaterised according to the config of the field the picker pertains to
[01:55] <wallyworld_> and that config is available in form-picker-macros
[01:55] <wallyworld_> and nowhere else easily accessible
[01:55] <rick_h> sec, let me pull up the code so I can see what it is
[01:55] <wallyworld_> rick_h: wanna mumble briefly?
[01:56] <rick_h> wallyworld_: yea, give me a sec to dock and reset the laptop
[01:56] <wallyworld_> ok. sorry to intrude after EOD
[01:56] <rick_h> all good, I was just merging/psuhing out convoy changes to trunk anyway
[01:57] <wallyworld_> rick_h: meet you in Yellow 1-1?
[01:58] <rick_h> k
[02:16] <rick_h> http://paste.mitechie.com/show/521/
[02:26] <lifeless> wallyworld_: hi
[02:27] <wallyworld_> lifeless: g'day
[02:27] <lifeless> wallyworld_: I've just replied to your MP about branches; I'm letting you know in case my reply doesn't make sense.
[02:27] <wallyworld_> ok. let me have a look
[02:28] <lifeless> general pattern of EAFP vs LBYL
[02:28] <wallyworld_> your suggestion makes sense.
[02:29] <lifeless> cool
[02:29] <lifeless> thanks for looking
[02:29] <wallyworld_> i was trying to do it in the picker though so that they could simply pick someone else if they misclicked
[02:29] <wgrant> And this is on +register-merge, right?
[02:29] <wallyworld_> yes
[02:30] <wallyworld_> the same pattern as we use for bug tasking assigning
[02:30] <lifeless> wallyworld_: this would still look like being in the picker, wouldn't it? They click on 'OK', it comes back and says 'nooo'
[02:30] <wallyworld_> ie if a use is not a contributer
[02:30] <lifeless> wallyworld_: then they can click to really do it, or click on someone else.
[02:30] <wallyworld_> there is no ok in the picker, just the link of the person
[02:31] <lifeless>  bah yes
[02:31] <wallyworld_> and they use the picker as part of filling out the form
[02:31] <wallyworld_> ie it's just one field
[02:31] <lifeless> well, there are two places you need to do this
[02:31] <lifeless> +register-merge and also when you request an additional review.
[02:31] <wallyworld_> yes
[02:32] <lifeless> oh interesting corner case for you
[02:32] <lifeless> what if someone in the default review team does not have access to one of the involved branches.
[02:32] <lifeless> e.g. they never click on the picker.
[02:32] <wallyworld_> so the thinking was not not have them submit the mp with a reviewer who could not see stuff if we could catch it beforehand
[02:32] <wallyworld_> hmmm.
[02:33] <wallyworld_> that default reviewer would be auto subscribed atm
[02:33] <lifeless> orly?
[02:33] <wallyworld_> not sure if that's the best thing
[02:33] <wgrant> I doubt it.
[02:33] <wgrant> We cannot have autosubscription.
[02:33] <lifeless> wallyworld_: or do you mean with your code changes?
[02:33] <wallyworld_> no, i mean in my branch
[02:33] <lifeless> ah
[02:33] <wallyworld_> so i think we need a check on form submission as well
[02:34] <wallyworld_> as when using the picker
[02:34] <wallyworld_> so we catch the issue early if we can
[02:34] <wallyworld_> but there's a safety net also
[02:34] <lifeless> so, I would expect the default review team to get the subscription (which is near enough to equivalent), but I do think this needs to be vetted, not automatic.
[02:34] <wallyworld_> ok, so if there are any visibility issues when the form is submitted, we return and let them confirm
[02:35] <wallyworld_> as per your suggestion in the mp
[02:36] <wallyworld_> so we attempt to alert them when using the picker, but also catch things at the back end if required
[02:37]  * wallyworld_ has to go to airport to pick up someone, back soonish
[02:37] <wallyworld_> lifeless: thanks for the input, much appreciated as always
[02:40] <lifeless> de nada
[02:49] <rick_h> StevenK: so heads up, convoy stuff is landed in their trunk.
[02:49] <rick_h> StevenK: let me know if you need anything else then to look at setting up our packages with the directory traversal/etc
[03:22] <StevenK> rick_h: Right, let me look at updating our packages.
[04:10] <wallyworld_> wgrant: if i put an exported api  method on IBranchSet, how to a call it from js, using an instance of Y.lp.client.Launchpad()? Using get(...)?
[04:12] <wallyworld_> in python it seems to be done as lp.branches.getByUniqueName(...) etc
[04:14] <wgrant> wallyworld_: The URL is /branches
[04:14] <wgrant> However you were calling something on the person URL, use /branches instead.
[04:17]  * StevenK grumbles at his test convoy recipe
[04:18] <StevenK> "nest-part packaging lp:~launchpad/convoy/packaging debian" doesn't seem to work :-(
[04:19] <wgrant> StevenK: Oh?
[04:20] <wgrant> Also, packaging-only branches are vile.
[04:20] <StevenK> bzr: ERROR: Merge-into failed because Source tree does not contain debian.
[04:20] <wgrant> Don't do it.
[04:22] <StevenK> No?
[04:22] <wgrant> merge
[04:22] <StevenK> :-(
[04:24] <wallyworld_> wgrant: yes, i was using a named_get() and thought i needed a context object
[04:26] <wgrant> wallyworld_: You should just be able to use a URL. Otherwise construct an object from the URL first.
[04:31] <StevenK> wgrant: I guess you want a one branch recipe
[04:37] <wgrant> StevenK: No.
[04:38] <wgrant> StevenK: Have a branch of trunk, with packaging added.
[04:38] <wgrant> Create a recipe based on trunk with that merged.
[05:11] <lifeless> wow
[05:11] <lifeless> 'The membership status of Allison Randal (allison) in the team Launchpad
[05:11] <lifeless> Stakeholders (private-canonical-launchpad-stakeholders) was changed by
[05:11] <lifeless> the user himself from Approved to Deactivated.'
[05:11] <wgrant> Yep
[05:11] <wgrant> Longstanding bug about that.
[05:11] <lifeless> anyone else see the glaring issue there?
[05:12] <lifeless> wgrant: whats the bug # ?
[05:12] <lifeless> ah 114753
[05:12] <lifeless> hmm, https://bugs.launchpad.net/launchpad?field.searchtext=himself does not find it
[05:13] <lifeless> I suspect our FTI logic didn't include description at that point, or something
[05:18] <StevenK> lifeless: Ugh
[05:20] <StevenK> 77 references to himself in our code -- most of them in doctests.
[05:20] <StevenK> And referencing sampledata to boot
[06:03] <lifeless> win
[06:04] <lifeless> are you going to JFDI this wart?
[06:46] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/user-himself/+merge/90376
[06:47] <benonsoftware> Hello
[06:47] <benonsoftware> I am wondering how do I update my local install of Launchpad?
[06:53] <nigelb> rocketfuel-get will work.
[07:00] <benonsoftware> So just run that in the repo folder and it should work?
[07:13] <nigelb> Well, how did oyu setup the first time?
[07:13] <nigelb> If you did rf-setup the first up, rf-get should "Just Work"
[07:14] <benonsoftware> nigelb: Ok, thanks very much
[08:04] <wgrant> stub: We've been running with targetnamecache search disabled for about a year.
[08:05] <wgrant> And I have a branch to remove the only other use of it.
[08:09] <stub> cool
[08:25] <adeuring> good morning
[09:00] <mrevell> Morning
[09:30] <benonsoftware> What does Firefighting mean?
[09:33] <lifeless> bigjools: donw
[09:33] <bigjools> lifeless: !  thank you
[12:33] <StevenK> rick_h: Feel free to merge my approved convoy MP into trunk
[12:34] <rick_h> StevenK: was there another one? I merged in your tests_require fix last night
[12:35] <rick_h> ah, the copyright stuff
[12:35] <rick_h> StevenK: sure thing, will do
[12:35] <rick_h> wallyworld_: you still around?
[12:39] <rick_h> StevenK: ok, merged and pushed. Thanks for that!
[13:21] <wallyworld_> rick_h: hello
[13:22] <rick_h> wallyworld_: hey, just a heads up that I commented on your MP
[13:23] <rick_h> small notes on just conventions, nothing big
[13:23] <wallyworld_> just saw, thanks. i used what i cargo culted from elsewhere for the wait
[13:24] <rick_h> yea, definitely
[13:24] <wallyworld_> i didn't want to use a simulate - i was black box testing the method which was supposed to raise the event
[13:24] <wallyworld_> so all i needed to do in the test was subscribe to it and see that it was called with the right arguments
[13:26] <rick_h> right, cool
[13:26] <wallyworld_> i'll look at using wait/resume, although there should still be a timeout for dafety so the test doesn't hang
[13:26] <rick_h> it won't
[13:27] <rick_h> so what happens is that the test hits and errors that "wait called without resume" and it fails
[13:27] <wallyworld_> ok, will look into it
[13:28] <wallyworld_> the validation work is a little more problematic - there's no notion ahead of time how many validators there are and what the chaining order should be
[13:29] <wallyworld_> with attaching the callbacks to the namespace, it was easy
[13:29] <wallyworld_> so i'll give it some more thought
[13:29] <rick_h> k
[13:30] <rick_h> well glad at least some of it was easy :)
[13:31] <wallyworld_> async events are good but they make some things a lot harder, especially collaboration between loosely coupled components
[13:31] <wallyworld_> where you need ordering or other behaviours
[13:31] <wallyworld_> how goes the convoy deployment stuff?
[13:31] <rick_h> yea, you have to control the flow and document the expected chain so you can figure out what's up when it fails
[13:32] <rick_h> wallyworld_: honestly not sure atm. Convoy is done and merged and in trunk and StevenK was putting together an updated package
[13:32] <wallyworld_> and controlling the flow is hard when an arbitary component needs to participate
[13:33] <wallyworld_> i really want a way to register validation callbacks - that's a common pattern for this type of thing
[13:33] <rick_h> wallyworld_: well, it depends. In some ways it's easy to bring in an arbitrary bit just by listening for the same event, but yea, it's harder for that guy to then effect what tohers do
[13:33] <wallyworld_> and the global namespace was a convenient point to register them on
[13:33] <rick_h> wallyworld_: right
[13:34] <wallyworld_> and i want them to fire one after the other, and if one fails, the others don't fire
[13:34] <rick_h> where's this code at? I'll see if I can look at it and see an easy way to attack it
[13:35] <wallyworld_> there is none yet - it's all done by registering the callbacks and looping over them
[13:35] <wallyworld_> no event based implementation i mean
[13:35] <rick_h> gotcha
[13:36] <wallyworld_> i'll have a think about it over the w/e
[13:36] <rick_h> cool
[13:36] <rick_h> sorry, bit cloud headed this morning due to cold meds so having fun following
[13:36] <wallyworld_> i'm off to bed, talk later
[13:36] <rick_h> enjoy
[13:36] <wallyworld_> will do, very tired tonight
[14:03] <deryck> Morning, all.
[15:00] <deryck> If anyone needs tips on staying motivated while working from home, I'm happy to oblige.
[15:01] <rick_h> deryck: I feel like i need to grow my hair out so I can get styling tips
[15:02] <deryck> I'm not sure I could do that anymore, even if grew it out again. ;)
[15:06] <sinzui> You get use gel to put your hair into tips, but stay away from open flames
[15:07] <benji> hmm, fetching any code.launchpad.net URL never finishes for me
[16:09] <abentley> deryck: I'm assuming bug comments and code review comments are unicode.  Let me know if that's wrong.
[16:18] <deryck> abentley, that's right.
[16:34] <flacoste> bigjools: about question https://answers.launchpad.net/launchpad/+question/182545, i'm going to contact non-virtualised ppas owner, that's Archive where purpose = 2 and required_virtualized = False, right?
[16:35] <bigjools> flacoste: yup
[16:35] <flacoste> thx
[16:49] <sinzui> adeuring, bac: do either of you have time to review https://code.launchpad.net/~sinzui/launchpad/mailing-list-name-field/+merge/90479
[16:49] <bac> sinzui: i do
[16:50] <sinzui> thank you
[16:52] <bac> sinzui: when you had the pre-implementation call with yourself did you act it out with puppets?  any disagreements?
[16:54] <sinzui> I quite. I wrote one thing 9 hours ago in a somnambulitic state. After 4 hours of sleep, I realised that +review on users was also broken so I told my previous self to fix the base view instead of creating a whole new view to support teams
[17:08] <bac> sinzui: i'm confused by TeamAdminisiterViewTestCase -- the team doesn't (appear) to have a PPA or mailing list, so why is the field not there?
[17:09] <sinzui> bac: the ppa/mailing lists tests are from the mixin
[17:10] <sinzui> The tests I wrote verify the fields show to ~admin or ~registry
[17:11] <bac> sinzui: gotcha
[17:11] <bac> sinzui: based on that it looks good.  i'll finish up shortly.
[17:11] <sinzui> bac: these are the tests I converted to the mixin: http://pastebin.ubuntu.com/819036/
[17:12] <sinzui> diffs often no show what was really done
[17:38] <rick_h> allenap: benji can either of you check and make sure this is the changes you decided as the *right* way at the end of yesterday? https://code.launchpad.net/~rharding/wadllib/fix_tests_922599/+merge/90492
[17:39] <rick_h> allenap: benji and then while I'm getting you guys should we remove buildout from this since it doesn't work in py3?
[17:39] <rick_h> james_w: ^^ as well
[17:40] <benji> why is code.launchpad.net not working for me?  when I look at the source of the page it looks like it's all there; I wonder if there's some JS request that's hanging
[17:40] <rick_h> benji: if there is should be able to see it in the dev tools
[17:40] <SpamapS> OOPS-24aa7bfe6e5dbf33996f05a9614d7d02
[17:40] <rick_h> benji: screenshot of the waterfall from the dev tools?
[17:41] <benji> rick_h: yeah, that's what I was thinking of
[17:41] <SpamapS> I believe this is a known bug...
[17:41] <SpamapS> is anybody working on it? (regression where searching for New/Undecided bugs with ubuntu-server as the bug administrator times out
[17:43] <rick_h> SpamapS: I don't think I've seen this one recently. adeuring this isn't any of the timeout stuff you were poking at right?
[17:43] <james_w> rick_h, I don't think I would change the test. There's a test just below for a stream input, and changing it means that string inputs aren't tested
[17:43]  * adeuring is looking...
[17:44] <SpamapS> Its been over a month where ubuntu-server can't triage bugs.. :-/
[17:44] <rick_h> james_w: ok, let me change that back then and see if that didn't help the tests pass for me
[17:44] <SpamapS> I had a chat w/ lifeless in here about it.. he did some query plans and showed where it would take 7 minutes or something like that
[17:45] <adeuring> no, that's nothing I touched. It's probably not easy to fix, I'm afraid
[17:47] <SpamapS> I think we'll have to write a report to be able to triage then.. and just query each package that we supervise individually. :-/
[17:50] <adeuring> SpamapS: yes, that could help. ANd actually, the slowest query is just a COUNT(*) for bugtasks related to ubuntu -- but the count is limited to bugs the user can see. Removing this filter should not do any harm
[17:51] <SpamapS> adeuring: I'm being told this only happens because I'm in too many teams and so the number of bugs I can see is too high.
[17:52] <adeuring> SpamapS: maybe -- but the Ubuntu bug searches tend to time out too often anyway.
[17:53] <jml> gary_poster: I'm (finally!) watching Rich Hickey's talk on simple vs easy. The graph on development speed looks painfully, painfully familiar.
[17:53] <SpamapS> Could this bug bug 901122 ?
[17:53] <_mup_> Bug #901122: New bug listings need to preload more attributes <bug-columns> <regression> <timeout> <Launchpad itself:In Progress by deryck> < https://launchpad.net/bugs/901122 >
[17:54] <gary_poster> jml :-)
[17:54] <gary_poster> glad you are watching; hope you enjoy.
[17:55] <adeuring> SpamapS: no, that's another issue that might crrep in once the cause for the timeout you are seeing is fixed ;)
[17:55] <jml> gary_poster: yeah, I am enjoying it so far.
[17:55] <gary_poster> great
[17:55] <jml> gary_poster: it's good having such deep thinking clearly expressed
[17:56] <jml> reminds me of the opening SICP lectures in some ways.
[17:56] <sinzui> jcsackett, Maybe you need to fix a trivial bug that really irks you
[17:59] <gary_poster> jml, clear expression of deep thinking: yes.  Hickey has impressed me with that repeatedly.  he gave another talk advocating hammock-driven development, which I think is related. :-)  I haven't taken time for SICP lectures; probably should.
[18:03] <jml> gary_poster: the sicp book is a little blurred with the lecture in my mind. Am pretty sure it has most of the same stuff and can be consumed about 5x faster
[18:04] <gary_poster> heh, cool
[18:04] <gary_poster> will give it a whirl
[18:26] <rick_h> james_w: ok, updated though line 55 seems like a giant line of hack https://code.launchpad.net/~rharding/wadllib/fix_tests_922599/+merge/90492
[18:27] <james_w> rick_h, it does seem to solve the problem though :-)
[18:28] <rick_h> james_w: yea, exactly, ok. I'm going to put this up for review and try to get the powers to review it. I *think* this is the only blocker for the release
[18:28] <rick_h> the other items, fixing the buildout (or removing it) can come later
[18:28] <james_w> yeah
[18:34] <rick_h> cjwatson: allenap benji any of you guys check out https://code.launchpad.net/~rharding/wadllib/fix_tests_922599/+merge/90492 please?
[18:34] <rick_h> and let me know what should be done from here on the buildout side?
[18:34] <abentley> deryck: should BugComments and CodeReviewComments have separate config values for the maximum length before a "Read More..." link?
[18:35] <deryck> abentley, I would tend toward saying no, that we should converge.  But if it's too hard to converge -- i.e. on form really needs longer snippets -- I'm fine to have two different configs.
[18:36] <benji> rick_h: it looks good to me; want an approval?
[18:36] <abentley> deryck: happy to converge.
[18:36] <rick_h> benji: please
[18:37] <deryck> abentley, awesome.
[18:38] <benji> rick_h: done with one small suggestion
[18:39] <rick_h> benji: awesome, ty
[18:39] <benji> my pleasure
[18:49] <jml> gary_poster: I don't think I understand what he's saying about using data for information, rather than objects.
[18:54] <gary_poster> jml, it's been awhile since I've seen it now, but he, and Clojure, have an opinion that standard object oriented design has gone off the deep end.  We should have simple data structures that represent our "objects" and not code that has both data and behavior.  Clojure then has a simple data-y concept of type that can be applied to a data structure,  and generic functions and another simpler and faster dispatch syst
[18:54] <gary_poster> em.
[18:55] <gary_poster> I suspect that's the background for (and/or current best practical example of) what you mentioned but could be wrong.
[18:57] <jml> gary_poster: hmm. interesting. I can begin to see what he's saying but don't grok it the same way as his other points. I wish I knew more about Clojure.
[18:57] <jml> (not enough to actually *learn* more right now, you understand)
[18:57] <gary_poster> lol, I understand
[18:57] <rick_h> anyone know how to tell gpg which key to use to sign a file?
[18:58] <gary_poster> rick_h, that sounds suspiciously like the first line to a joke.
[18:59] <jml> rick_h: look into the --local-user and/or --default-key options
[19:00] <rick_h> gary_poster: heh, looks like I have to change the --default-key
[19:00] <rick_h> jml: yea, that seems to work thanks
[19:00] <rick_h> this whole split private/work life is a mess sometimes heh
[19:02] <deryck> rick_h, you mean you try to split work and private life? ;)  you're bordering on lifeless levels of online time. :)
[19:03] <rick_h> heh
[19:03] <rick_h> deryck: have to make up for being a bit dense :)
[19:03] <rick_h> like where is this magic launchpadlib/bin/py
[19:04] <rick_h> bah, that's a buildout reference I bet
[19:05] <deryck> yeah, buildout create bin/py.  for most projects.  I don't know how launchpadlib is setup.
[19:05] <rick_h> right, the bin/py threw me off hunting. I'm on the right track again I think
[19:07] <rick_h> ok, maybe not. So the docs say I'm looking for: launchpadlib/contrib/upload_release_tarball.py
[19:08] <rick_h> but my launchpadlib library has no contrib, seperate package?
[19:19] <rick_h> deryck: do you know if anyone can upload the pypi package or do I need to get a special user credientials? pypi says the author is: LAZR Developers
[19:20] <deryck> rick_h, I don't know.  My guess would be we have a login for LAZR dev.
[19:20] <deryck> gary_poster, do you know ^^ ?
[19:20] <rick_h> james_w: so I *think* I've got the 1.3.0 release all set on the LP side, just not in pypi yet
[19:21] <rick_h> james_w: let me know if there's any issues and I can check it out
[19:21] <james_w> rick_h, excellent, thanks
[19:21] <rick_h> james_w: sorry for the delay on all that :)
[19:21] <james_w> no problem, thanks for catching the bug and promptly fixing it
[19:27] <gary_poster> deryck, rick_h, you'll need creds for pypi.  looking at pypi.
[19:27] <rick_h> gary_poster: ty
[19:29] <gary_poster> rick_h, is your pypi id rick_h?
[19:31] <rick_h> gary_poster: no, actually not sure beena while
[19:32] <gary_poster> rick_h, tell me what it is and I can give you permissions
[19:32] <rick_h> gary_poster: sure thing, getting reminder sent one sec
[19:32] <gary_poster> cool
[19:32] <rick_h> gary_poster: mitechie
[19:32] <gary_poster> rick_h, cool.  mitechie has owner permissions
[19:32] <rick_h> ty much
[19:33] <gary_poster> welcome
[19:34] <rick_h> gah, py3 damn you!
[19:38] <rick_h> gary_poster: I'll wait a bit to see if something needs time to update, but getting Server response (403): You are not allowed to store 'wadllib' package information
[19:38] <gary_poster> rick_h, sounds like you need wadllib too! :-) I only did launchpadlib.
[19:38] <gary_poster> rick_h, there is no big switch :-/
[19:39] <gary_poster> rick_h, doing wadllib now
[19:39] <rick_h> ah! sorry yea.
[19:42] <gary_poster> rick_h, pypi is not a speed demon.  You are now added for wadllib.  any others?
[19:42] <rick_h> gary_poster: ty much, that worked
[19:42] <rick_h> gary_poster: not atm, wadllib was all I needed for now
[19:42] <rick_h> james_w: so not sure if you need pypi, but should be up there soon as well
[19:43] <gary_poster> cool welcome. rick_h I'm a one-stop-shop for a lot of our pypi privs; feel free to ask for more. ;-)
[19:43] <james_w> thanks rick_h, we're fine with LP
[19:43] <abentley> bac: Could you please review https://code.launchpad.net/~abentley/launchpad/attachment-timeout/+merge/90514 ?
[19:44] <bac> abentley: sure.
[19:44] <abentley> bac: thanks.
[19:45] <bac> abentley: you know it seems we have this conversation about this time every friday!  :)  you're very consistent.
[19:45] <abentley> bac: :-)
[20:24] <abentley> rick_h: When you file bugs on Launchpad projects such as wadllib, please also triage them.
[20:26] <bac> abentley: why did you decide to put the "Download" link at the top of the message instead of below?  i'm not asserting one is preferable but i was surprised to see it there.
[20:27] <abentley> bac: I thought that if you want to download the comment, you probably don't want to read it in the Launchpad UI.
[20:29] <bac> abentley: but you'll read the snippet before deciding, perhaps.
[20:32] <abentley> bac: The snippet is 3200 characters long.
[20:36] <bac> abentley: is the condition at line 557 correct?  shouldn't it be too_long_to_render?
[20:39] <abentley> bac: No, the conditional is what was intended.  It seems like downloading is a reasonable option to present for long comments, even if they're not so long that they cannot be rendered.
[20:39]  * bac looks again
[20:48] <abentley> bac: Thanks!
[21:14] <sinzui> bac: do you have time to review a follow up to my previous branch: https://code.launchpad.net/~sinzui/launchpad/administer-team/+merge/90530
[21:14] <bac__> sinzui: in a bit.  i need to reboot.  and i may disappear due to flaky internet
[21:15] <sinzui> understood