[00:50] can has review ? https://code.launchpad.net/~lifeless/python-oops-wsgi/extraction/+merge/71969 [00:51] mwhudson: btw - ^ django is wsgi based yes? you might like that :) [01:11] lifeless: ^^ as a drive by, did you want to fix the ordering of the imports and __all__ declaration? [02:55] wallyworld: I can, I didn't notice they were unordered? [02:55] wallyworld: indeed, they look ordered to me [02:55] lifeless: the __all__ is below the imports when it should be above? [02:55] thats correct [02:56] pep8 ' You should put a blank line between each group of imports. [02:56] Put any relevant __all__ specification after the imports.' [02:56] al of our lp py code is the other way around then [02:56] ie it has __all__ first then imports [02:56] we should fix that :) [02:57] that's a *lot* of fixes [02:57] yes [02:57] but easier than fixing all of pypi ! [02:57] hah [02:57] i like lp's way of doing it [02:58] easier to see what's exported [02:58] Is the error reporting utility meant to be broken? It seems to have killed dogfood. [02:58] jtv: broken? no. Changed? yes. [02:58] jtv: symptoms? [02:58] Hang on, still pasting [02:58] lifeless: http://paste.ubuntu.com/668808/ [02:59] Not too helpful, I'm afraid. [02:59] bwah [02:59] probably need to drop a pdb in there and have a peek [02:59] Ouch. [02:59] I have just overhauled oops handling entirely [03:00] make sure your download-cache is up to date [03:00] and that you have bin/buildout [03:00] Does it require a config change by any chance? [03:01] I ran rocketfuel-get, which I think takes rare of the other stuff. [03:01] no, no config changes [03:01] jtv: can you try bin/buildout ? [03:02] Hmm the tree ended up in an unbuilt state. Rebuilding first. [03:03] wallyworld: did you have any other comments on that mp ? [03:04] lifeless: no, looks ok to me. there's not much to it === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 238 - 0:[#######=]:256 [03:29] lifeless: dogfood's running now. Does rocketfuel-get not run buildout? [03:30] not directly [03:30] it runs make [03:31] rocketfuel-get is unmaintained AFAIK - you're the first person I've heard using it some time [03:33] It still works fine. [03:37] i imagine it gets run very roughly once per someone joining the lp/buying a new machine? [03:37] oh no, that would be -setup [03:37] * mwhudson hides again [03:38] Well, -setup runs -get. [03:39] Now, why didn't "make" run buildout? [03:40] mwhudson: hey [03:40] mwhudson: so, did you see my oops stuff ? [03:41] lifeless: i didn't click the link, i'm afraid [03:41] mwhudson: tsk! [03:41] mwhudson: what do you do for error reporting / aggregation / analysis with your dango sites? [03:42] lifeless: currently embarrassingly little [03:42] mwhudson: so the goal of oops-* is to be easy to use. [03:42] mwhudson: *hint* *hint* [03:42] lifeless: i believe there's a plan to deploy http://pypi.python.org/pypi/django-sentry [03:51] sentry is interesting [03:51] isd are evaluating it [03:52] it really operates on single log entries FWICT [04:00] lifeless: are you reviewing today? I've got a small one here: https://code.launchpad.net/~jtv/launchpad/bug-824553/+merge/71823 [04:05] yes, and its done :) [04:05] jtv: I will happily review most any day [04:05] Thanks. Yes, I know—but I also know how much other stuff you do and I wonder if you have enough clones in that closet of yours... [04:59] lifeless: wha, rocketful-get is unmaintained? I keep using it! [05:00] nigelb: I do as well -- but the last thing rf-setup does is copy rf-get to /usr/local/bin. If there any other changes to rf-get later, you don't get them ... [05:01] ah. [05:02] isn't sort of easier to just modify $PATH? [05:02] that way the changes do get propogated. [05:03] or alternatively, symblink instead of copy. [05:03] grah [05:03] nigelb: And then when devel breaks, you can't use rf-get to fix it ... [05:03] ok, web.py is off the microservice list [05:03] StevenK: err, why? [05:03] or rather, why not [05:03] lifeless: What has it done? Or not done? [05:04] StevenK: it -very much- does not want oops_wsgi in the call tree [05:04] StevenK: it helpfully doesn't use wsgi internally! [05:04] StevenK: so there is nowhere in its stack to inject the middleware [05:04] StevenK: and if you warap the stack, it does its own error handling. [05:04] *headdesk* [05:05] try Flask? I don't know about Flask /that/ deep to know if it will work or not. [05:12] If there was some code without tests and I add some more code to it, do I write tests for the entire thing? [05:14] (I'm fairly sure the answer is yes, but I could try ;) ) [05:15] You aren't required to, but it would be awesome. [05:19] Great! Can I bug you for help with it? ;) [05:19] If you like [05:46] nigelb: nope, flask is also overly clever. [05:47] nigelb: rather than having separate concerns, its monolithic, [05:47] yay ;) [05:47] I will port gpgverify to paste tomorrow [05:47] write your own wgi app then? :) [05:47] *wsgi [05:47] nigelb: no, we use paste for loggerhead and its great [05:47] :) [05:47] a little *too* bare bones in some ways, but it doesn't get in the way. [05:51] Also, it's not CherryPy. [05:51] That's the main thing. [05:52] heh [05:52] (Loggerhead used to use CherryPy. Those days were bad.) [05:56] So, what happens to IPerson(self.request.principal) when I'm not logged in? [05:57] None IIRC [05:57] hm, why is my code breaking then [05:57] ok, I'm kindof EODing, allergy injections suck :) [05:57] user=None for search should just work right? [06:08] halp. [06:08] TypeError: ('Could not adapt', , ) [06:09] is it kosher to do a try catch? [06:11] wallyworld__: around? :) [06:11] should just be self.user if you're using a form, or call_with in the API [06:11] nigelb: hi [06:11] anything else and you're doing it wrong :) [06:12] lifeless: no no. [06:12] lifeless: it's not a form and it's not the ws api. it's a view [06:12] You warned me about the anonymous use case, only I don't remember how to catch it :) [06:12] similar to HugeVocabularyJSONView for example [06:12] blah, I meant view [06:12] LaunchpadView sets an attribute to Just Work [06:13] anyhow, I'm really not here, ciao. [06:14] nigelb: i think in the case of anon, request.prinicpal is None [06:14] nigelb: because LinkChecker doesn't extend LachpadView, there's no self.user [06:14] nigelb: perhaps you should make LinkChecker a subclass of LaunchpadView [06:15] it may then allow you to just use self.user [06:15] let me do that then [06:15] just a guess, it may work [06:21] wallyworld__: \o/ works :) [06:21] nigelb: excellent! [06:21] * nigelb now needs to wwite tests [07:20] wallyworld__: how do I test behavior with a public bug number and a privaet bug number? [07:20] make the bug private and then try with anonymous user? [07:21] or something. [07:21] nigelb: you need to create a private bug and log in as the user who owns the project the bug is reported against [07:22] nigelb: with_person_logged_in is one way [07:22] nigelb: i assume you are talking about a python unit test here [07:22] so, create a person, create project with owner that person, create private bug, then logging as that user and try and try as anonymous [07:22] yah [07:22] wallyworld__: yeah, unit tests, I should have been further clear :) [07:23] yes what you say above sounds right. do it as 2 tests [07:25] always the fun bit in LP [07:25] unit testing [07:35] good mornning [08:06] poolie, hi, if you are still around, are you familiar with our loggerhead QA/rollout setup? [08:09] hi there [08:09] danilos: slightly [08:10] what do you want to know? [08:10] poolie, well, I've landed a fix yesterday, and I would like how to best QA it, and how to ensure it gets rolled out [08:10] would like *to know* :) [08:11] oh, ok, i think i saw your mp [08:11] do you know if that revision is live on qas? [08:11] or staging? [08:13] poolie, how can I tell that? :) (I assume that means it's not) [08:14] one trick here is that there's only actually back-end storage for lp:bzr on qas and staging [08:14] i think [08:14] at any rate lots of branches are in the db but will break if you try to touch them [08:14] for disk space reasons [08:15] pushing tp +junk is ideal [08:15] poolie, right, I know that, but I should be able to push stuff to lp://staging/, right? [08:16] danilos: so, does landing something into lp:loggerhead cause it to be rolled out? [08:16] i don't think so but i'm not sure [08:16] poolie, I have no idea, those are the things I am trying to find out, but I doubt it [08:17] let's see if there's version info [08:17] the losas are sprinting but they should be awake now [08:17] spm? [08:17] poolie: hi [08:18] poolie: no, you need to update the version ref in lp [08:18] spm, hi, can you tell me if normal deployments to qas pull in loggerhead from trunk? [08:18] oh ok, i thought so [08:18] poolie: the qa deployment includes loggerhead, but not trunk [08:18] danilos: so, i think you need to make an additional landing into lp:launchpad for it to be live, like that [08:18] in fact it says 1.18 on the web page, and isn't trunk later than that? [08:20] danilos: does that help at all? [08:21] poolie, yeah, trunk does have a few revisions compared to what I have in sourcecode/loggerhead [08:21] ok trunk still says it's v 1.18 [08:21] poolie, yeah, I figure I might need to land to loggerhead through PQM to ~launchpad-pqm/loggerhead/devel [08:22] poolie: sorry, quite distracted atm. have your questions been answered satisfactorily? [08:22] yes, thanks [08:22] enjoy your brown sauce [08:22] heh [08:27] lifeless, do you know if I can just bump the LP loggerhead to trunk (I see issues like bug 826082 in a bit of indeterminate state), or if I should just include my own revision that I want rolled out? [08:27] <_mup_> Bug #826082: BadUrl from safe_open opening a branch < https://launchpad.net/bugs/826082 > [08:28] danilos: i would like to get lp running trunk [08:28] if necessary by reverting stuff that's unstable [08:28] i don't have an detailed opinion about that specific bug [08:28] poolie, so would I, but I ain't sure what are those [08:29] poolie, so, I followed the trail of bug 820065 and bug 812583, which got me to the above bug [08:29] <_mup_> Bug #820065: TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

< https://launchpad.net/bugs/820065 > [08:29] well it looks like that might be fixed [08:29] <_mup_> Bug #812583: IndexError in add_template_values in loggerhead annotate

< https://launchpad.net/bugs/812583 > [08:29] so, we rolled back loggerhead after deploying coincided with a 1000 oops a day increase. [08:29] however [08:29] that increase appears to be jelmers safe-open refactoring [08:29] which he was fixing [08:30] In the spirit of one-change-at-a-time, I think we should get that sorted, then upgrade again. [08:30] if jelmers patch is landed, then upgraded loggerhead should be pretty straight forward [08:30] lifeless, jelmer's patch is not landed in either loggerhead trunk or Launchpad [08:31] he should be up soon and we can ask him [08:31] (that would be clearer if it was "is landed in neither...nor" :) [08:31] it was in ec2 overnight but appears to have failed [08:31] danilos: it would be in launchpad [08:33] poolie, lifeless, any suggestions on where should I put the docs for developers wanting to QA/deploy loggerhead? (something that'd be easy to find, I found no pages about it on dev.launchpad.net and wiki.canonical.com) [08:33] danilos: README.txt in loggerhead ? [08:34] lifeless, I was more thinking in terms of Launchpad QA/deployment [08:34] danilos: I know its a bit LP specific, but you could note that this is the primary place its deployed :) [08:34] danilos: otherwise, yeah somewhere on d.l.n. [08:34] Ew, that does not belong in the loggerhead tree. [08:34] lifeless, right, fair enough, though I'll add a few pages titled /Loggerhead to the dev wiki pointing at the readme then [08:35] i think dev.l.n [08:35] danilos: its only a though, wiki is fine too [08:35] *thought* [08:35] so, I guess d.l.n is the consensus choice here, thanks all for chipping in :) [08:35] how to run or deploy it in general belongs in the tree; not the quirks of lp deployment though [08:35] the reason I think its reasonable to put it in the loggerhead tree is we want to run trunk [08:35] if you ask me [08:35] partly becaues there's much less chance losas will touch that [08:36] if we want to keep trunk deployable, we should have the instructions for that clear and visible to all contributors [08:44] danilos: so, ping me or someone else if you want more [08:49] poolie, lifeless: any fixes/improvements welcome on https://dev.launchpad.net/Code/Loggerhead, I am sure I got some bits of the process wrong [08:53] I've also removed a reference to inactive project launchpad-loggerhead from dev.l.n/Code and pointed at this page instead [08:57] jelmer, so, I assume I'd better wait for you to land your changes and get them deployed before I try that with my changes to loggerhead [08:57] jelmer, I am sure you might have a few suggestions for https://dev.launchpad.net/Code/Loggerhead [09:00] a buildbot failure in an unrelated test :( [09:05] danilos: Looking at the test failures right now.. [09:05] jelmer, cool, thanks [09:05] jelmer, though, I was referring to a spurious buildbot failure for my branch :) [09:06] lifeless, since I am lazy, what was the policy for triaging bugs about spurious test failures? critical? (bug 828584) [09:06] <_mup_> Bug #828584: Spurious test failure: test_sigint_exits_nicely < https://launchpad.net/bugs/828584 > [09:09] vila, jam, so i wonder how we could unstack it safely [09:10] poolie: reconfigure --unstacked isn't safe? [09:11] If you want the quick bzrlib invocation [09:11] just open the repository directly [09:11] repo.fetch(basis_repo) [09:11] which fills in everything [09:11] jam: without unstacking right ? [09:11] vila: if you do Repository.open() instead of Branch.open().repository [09:11] jam, oh, i mean it _should_ be safe [09:11] the repo won't be stacked [09:12] my question was really, is it safe, and how could we mitigate any risks [09:12] and .fetch() without a search recipe or target revision [09:12] fetches everything [09:12] poolie: I think it is safe, but if you want to do it easily Repo.fetch(repo) works just fine [09:13] danilos: that looks pretty good; though i'd like to know whetehr things automatically go onto buildbot, *staging, etc [09:13] i guess you would too :) [09:13] Speaking of which, I just did: jameinel@chinstrap:~$ time bzr branch lp:gcc-linaro/4.6 lp:~jameinel/gcc-linaro/test-4.6 [09:13] Using default stacking branch /+branch-id/355386 at bzr+ssh://bazaar.launchpad.net/~jameinel/gcc-linaro/ [09:13] poolie, exactly :) [09:13] And it was still transferring at 500MB or so when I killed it. [09:14] but you know, that could be the "created a branch and didn't populate it" or something like that. [09:14] I'll try again with debug flags set === almaisan-away is now known as al-maisan [09:32] poolie: very strange "bzr branch lp:gcc-linaro/4.6 lp:~jameinel/gcc-linaro/test-4.6" is at about 1GB transferred so far. [09:32] 1.2GB [09:33] the discovery phase was fast, but the bytes transferred seems really wonky [09:34] there is only like 100MB in /4.6, so it doesn't line up at all, unless something is broken with the target stacking. [09:34] but the request says that it is trying to stack. [09:35] though this is bzr-2.1.4... because it was the binary on Chinstrap [09:35] not sure how much that matters or not. [09:37] It had "transferred" 1.2GB (probably down and then up again), and there was 465MB in the target. Still too much. === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | Critical bugs: 238 - 0:[#######=]:256 [10:16] allenap: Can you please review this MP https://code.launchpad.net/~rvb/launchpad/overlay-bug-827220/+merge/71915 ? [10:24] rvba: Sure. [10:24] allenap: : Thanks. [10:25] danilos: thats fine I think [10:25] I will look at the docs tomorrow :) [10:25] rvba: Ah, interesting, I would have suspected that you'd need to use getComputedStyle(). r=me/ [10:26] lifeless, please extend them with as much as you know how stuff gets to *staging, what gets run in the buildbot and similar :) [10:27] allenap: looks like getStyle is enough ... [10:27] rvba: Cool. [10:40] lifeless: Hi! [10:41] lifeless: about python fixtures [10:42] hi [10:45] lifeless: I don't see where we include it [10:45] henninge: setup.py [10:46] henninge: or do you mean inside LP? grep 'Fixture' lib -r. [10:46] lifeless: yeah, in LP [10:46] but I just saw that it is called "fixtures", let me look [10:47] lifeless: ah ok, I was looking for python-fixtures [10:47] henninge: grep Fixture) [10:47] it's in download-cache [10:47] will show where its used. [10:47] no, I was not looking for that, I have used it in tests myself ... [10:47] at least directly; it won't show indirectly like in python-gbouncer, the rabbit notifier etc [10:47] I just wanted to see which version we used [10:47] henninge: oh, :) I get you. [10:48] lifeless: so you are saying fixtures will need an update to work with the latest testtools? [10:48] s/update/patch/ [10:48] yes, incompatible change to gather_details [10:49] probably the same that I ran into [10:49] because the output changed [10:49] ? [10:49] no [10:49] rev 207 in testtools [10:50] breaks fixtures [10:50] fixed in rev 29 of fixtures [10:50] lifeless: that's what I was trying to get at. [10:51] so I don't need to fix fixtures, I just need to package the latest version of it. [10:52] wgrant: yes [10:52] bah [10:52] henninge: yes [10:53] lifeless: thanks, that's much easier of course ;-) === al-maisan is now known as almaisan-away === henninge is now known as henninge-lunch === almaisan-away is now known as al-maisan === henninge-lunch is now known as henninge [12:31] guys, anyone up to help me to understand what exactly launchpad understands when I say ubuntu.searchTasks(bug_supervisor=oneteam) ? [12:34] Ursinha: sure. [12:35] afaik, packages don't have bug supervisors, only ubuntu does [12:35] but using that returns me different tasks for different packages [12:36] I can't ubuntu.searchTasks(structural_subscriber=oneteam) to compare, because that times out [12:37] Ursinha: just found http://paste.ubuntu.com/669193/ in bugtask.py [12:38] bdmurray: ^ [12:38] jml: so it should work pretty much as structural_subscriber does? [12:38] Ursinha: I'm still grokking it. one sec. [12:39] jml: sure [12:40] Ursinha: if I understand correctly, it'll match any package that oneteam is subscribed to [12:40] s/any package that/any bugtask on a package that/ [12:40] as well as any bug task on ubuntu itself [12:41] that's exactly what we need, and also what we tried to accomplish with structural_subscriber but it times out now... [12:41] bdmurray: so we can use bug_supervisor [12:41] and it doesn't do team unrolling [12:41] exact match of user ids [12:41] https://bugs.launchpad.net/launchpad/+bug/191809 [12:41] <_mup_> Bug #191809: A DistributionSourcePackage needs a bug supervisor role to control permissions < https://launchpad.net/bugs/191809 > [12:42] mrevell: hi [12:43] Hey nigelb [12:43] cool [12:43] thanks jml :) [12:43] mrevell: hey, did you get a chance to look at that bug? :) [12:43] Ursinha: np [12:45] nigelb, Not yet. I'm at an event today. I'll be back tomorrow. [12:45] mrevell: cool, ok :) [12:46] gary_poster, nigelb is interested in bug 816105. As your squad worked on the feature, I'd love to hear your thoughts on that bug report. [12:46] <_mup_> Bug #816105: UI for subscribing to a bug is confusing < https://launchpad.net/bugs/816105 > [12:55] mrevell, any solution needs to support the new notification levels. IMO, a solution should also communicate if "[y]ou have subscriptions that may cause you to receive notifications". [12:55] A more perfect solution IMO (also fixing another related UI bug filed by mpt, I think) would also remove the necessity for the "Edit bug mail" link by making the notification of "[y]ou have subscriptions that may cause you to receive notifications" have a link to an in-page overlay that explains what is meant and what can be done about it other than muting. [12:55] Specifically, this would be the "Other subscriptions" information on the "Edit bug mail" page included as an overlay on the bug page. That information should only be loaded dynamically--it is somewhat expensive to calculate and +index is already slow enough. [12:55] I suspect that the "Other subscriptions" code is factored well enough that this would not be too tricky to do. [12:55] * nigelb reads the wall of text [12:56] nigelb: It's even more awesome when you talk to gary_poster IRL. Since then it's a wall of speech. :-P [12:56] StevenK: haha [12:56] ha. ha. :-) [12:57] gary_poster: my main irk was this. it was way more easier to find how to subscribe others than subscribe myself. [12:57] nigelb, I can see what you mean. [12:59] sinzui: both new picker feature flags are now on lp.net [12:59] nigelb, I believe it is mrevell's responsibility to actually decide how it should work, or at least delegate and approve it. The above is my take. [12:59] gary_poster: 'm still parsing that ;) [13:00] \o/ [13:00] seems to work well [13:00] the "wall" or the mention of mrevell as the responsible party as acting product mgr? [13:00] gary_poster, nigelb: Thanks both. I'll return to this tomorrow, when I'm back from the QA CoP sprint. [13:00] cool [13:01] gary_poster: heh, the wall ;) [13:02] nigelb, mrevell, the mistake we made IMO was not not take this part through user testing. It was at the end of the project and we were in a rush. Whatever is done, I suggest you not make our mistake, and actually produce mockups and run user tests. [13:04] gary_poster: I agree there. I'm only helping implement. Like I said the other day, I think the code bit is probably triivial. the UX bit is not. === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | Critical bugs: 238 - 0:[#######=]:256 [13:52] sinzui: I have a question about a distro in Launchpad: https://launchpad.net/cinux [13:52] ask away [13:58] hello everyone! [14:00] Hi, flacoste. Welcome back! [14:00] hi deryck! [14:02] adeuring, hi, shall we mumble now? [14:02] deryck: ah, sure! [14:10] hi flacoste, welcome back to the land of the internets [14:10] hi bac! === bigjools-afk is now known as bigjools_ [14:14] Bah. We can't logout from the appserver layer as it redirects through secure codehosting to clear tokens before ending up on the openid side. [14:14] No tests for logout :-( [14:35] welcome back flacoste [14:35] hi gary! [15:04] deryck, abentley: I am really unsure with this javascript test. I am not sure how and what to test, maybe taht's why I keep finding excuses to do something else ... ;-) [15:04] I have this now: http://paste.ubuntu.com/669304/ [15:05] henninge: looking. [15:05] It's just checking that the handler works properly. [15:06] henninge: Okay, do you want to mumble about it? [15:07] abentley: sure === al-maisan is now known as almaisan-away === deryck is now known as deryck[lunch] [16:32] Could somebody please try landing https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152/+merge/32868 ? The necessary python-apt and apt-utils packages are now installed on production [16:32] *try ... again === deryck[lunch] is now known as deryck === beuno is now known as beuno-lunch [17:40] jcsackett, do you have time to mumble? [17:46] allenap or jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/twisted-logging/+merge/72082 ? [17:46] abentley: i'm otp now, but can look after that. [17:46] jcsackett: thanks. [18:02] abentley: looking at your branch now. [18:03] jcsackett: great. [18:05] sinzui: is bug 828493 related to your current work? [18:05] <_mup_> Bug #828493: Bogus results in package search < https://launchpad.net/bugs/828493 > [18:06] anyone know if there's a ui bug open against launchpad about the watermark and maincontent header being repetitive, like bugs.launchpad.net/checkbox showing "Checkbos System Testing" and "Bugs for Checkbox System Testing" respectively? [18:06] No, It is a duplicate of an old bug my team will fix [18:06] abentley, I will find the master and mark it as a dupe [18:07] sinzui: rawk. [18:09] abentley: looks good. r=me. [18:09] jcsackett: thanks. === beuno-lunch is now known as beuno === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 238 - 0:[#######=]:256 [21:05] jcsackett, are you about to do a code review? [21:23] spm: around? [21:24] spm: if I did a staging import of bug a few weeks ago, and now I'm ready to go live, but re-ran the script to get more recent bugs - do we need to do another staging import? and do you want me to open a new ticket? or re-use the old one? [21:29] mtaylor, Another staging import is not needed, but someone, maybe spm, needs to run out preprocessor over your data to generate the bug nicknames. You need to post the URL to the updated data or send someone an email with the attachment. [21:31] sinzui: k. awesome. https://answers.launchpad.net/launchpad/+question/168463 [21:32] sinzui: btw- I now have a script that can export bugs from a github project and generate the xml if you guys want a copy of it [21:33] sinzui: https://github.com/openstack/openstack-ci/blob/master/gh_issues_to_lp_bugs.py [21:33] sinzui: the lack of great way to map users and the lack of readily accessible email addresses sort of blows, but other than that it's workable at least [21:34]