[13:58]  * skaet waves
[14:00] <stokachu> o/
[14:00]  * stgraber waves
[14:00] <stgraber> #startmeeting 12.04.1 team meeting
[14:00] <meetingology> Meeting started Thu Jul 12 14:00:40 2012 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[14:00] <jamespage> o/
[14:00] <arges> o\
[14:00] <arges> o/
[14:01] <stokachu> did you just hi-five yourself
[14:01] <arges> stokachu, yes you win
[14:01] <stgraber> ;)
[14:01] <stokachu> lol
[14:01] <stgraber> #topic Action items review
[14:01] <stgraber> arges to work on a 12.04.1 bug report, showing targeted bugs and information on status in development release, patches attached and branches linked
[14:02] <arges> http://people.canonical.com/~arges/point-release/milestone-12.04.1.html
[14:02] <arges> We can still fix if needed, but have it ready. I've proposed a merge for the code into the Arsenal project so anyone can look at it. (Patches welcome)
[14:03] <arges> The code is here for now:
[14:03] <arges> https://code.launchpad.net/~christopherarges/arsenal/arsenal
[14:03] <arges> ..
[14:04] <stgraber> what are the current criteria for a bug to show up on the list? (total bugs: 57 vs 112 in my current list)
[14:04] <arges> stgraber, targeted to 12.04.1 && status is  ["New", "Confirmed", "Triaged", "In Progress", "Fix Committed"]
[14:04] <arges> and targed to precise
[14:05] <smoser> o/
[14:05] <stgraber> smoser: go
[14:05] <stokachu> lol
[14:06] <smoser> i was a bit confused.
[14:06] <stgraber> smoser: or was that just a "I'm around o/" ? :)
[14:06] <smoser> i'm around.
[14:06] <smoser> yeah.
[14:06] <stgraber> ok :)
[14:06]  * smoser wipes forehead.  whew!
[14:07] <skaet> looks good arges.   Will do some correlations with the other data sources.  :)
[14:07] <stgraber> arges: odd, it doesn't match my LP search but I can't really tell which of my LP search or the arsenal report is wrong to be honnest ;)
[14:07] <stokachu> looks like several are missing tags
[14:07]  * skaet is a bit worried about bug 1017001
[14:07] <stokachu> i see a bunch with fix committed but no verification needed
[14:07] <arges> I'll work on it and make it more accurate. but for the time being hopefully it can still be useful
[14:08] <arges> in addition, where should I host it?
[14:08] <arges> right now its just generated on my desktop here
[14:08] <stokachu> geocities.com
[14:08] <stgraber> stokachu: I'll try and take a pass through all the bugs, fix them where needed... I'm guessing some are marked fix commited but haven't actually been uploaded yet...
[14:08] <stokachu> arges: canonistack
[14:08] <stokachu> stgraber: ok
[14:08] <skaet> stokachu,  I think the columns need to be switched to make it more intuitive.  (Verification Needed before Verification Done).   Is that the source of confusion?
[14:09] <stokachu> skaet: ah
[14:09] <stokachu> skaet: yea that does make more sense
[14:09] <skaet> :)
[14:09] <stokachu> haha
[14:09] <arges> i can switch them
[14:09] <stokachu> running off fumes this morning
[14:09] <arges> I wanted to sort them by 'most actionable items' on top
[14:09] <arges> so if it has the patch and the verification is done and there are lots of branches linked, then its on the top
[14:10] <stokachu> ive been linking related branches of merge proposals
[14:10] <stokachu> is there a way to tell a difference?
[14:10] <skaet> clicking the column headers works for resorting ...  :)  hence me finding that critical that looks like its stalling out.
[14:10] <stgraber> arges: you should be able to run the report on lillypilly initially, though it should then be moved to reports.qa.ubuntu.com/reports with the others
[14:10] <stokachu> that could be a +1 for patch column
[14:11] <arges> stokachu, what do you mean?
[14:11] <arges> stgraber, ok
[14:12] <stokachu> arges: can you tell ifa related branch is a merge proposal or not
[14:12] <stokachu> rather than seeing if an attachment is set to patch
[14:12] <stokachu> you could set to 'has patch' if no attachment but there is a merge proposal
[14:13] <arges> stokachu, yea right now the logic is patch_attached || patch tag
[14:14] <arges> anyway. there are a lot of comments. so maybe I can summarize some actions for the next few weeks to work on this
[14:14] <arges> - Verify this matches the list on https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.1
[14:14] <arges> - Get this hosted on lillypilly or another machine.
[14:14] <arges> - Switch the Verification Done/Needed columns?
[14:15] <arges> What else?
[14:15] <stgraber> you may also want to check for verification-needed-precise/verification-done-precise
[14:15] <arges> stgraber, yes I do that as well
[14:16] <stgraber> cool! I wish all our other reports did :)
[14:16] <skaet> looks like a good summary for now to me....  I suspect that after we start working with it,  there will be more ;)
[14:16] <arges> ok great. feel free to ping /email me with more ideas
[14:16] <stgraber> yeah, that report looks good and will surely be useful for monitoring other point releases or even non-LTS releases in the future
[14:17]  * skaet nods
[14:17] <stgraber> next action is:
[14:17] <stgraber> xnox to liase with ballons, gema and jibel w.r.t. fs/storage testing
[14:17] <arges> thanks
[14:17] <stgraber> though xnox is at debconf so probably not much changed on that one. Keeping it around for next meeting
[14:17] <stgraber> #topic Review of upcoming deadlines
[14:17] <stgraber> 2012/08/02: Beginning of PointReleaseProcess and DesktopInfrastructureFreeze
[14:17] <stgraber> 2012/08/09: KernelFreeze, LanguageTranslationDeadline, SRU Fix Validation Testing
[14:17] <stgraber> 2012/08/16: FinalFreeze, ReleaseNoteFreeze
[14:17] <stgraber> 2012/08/23: Ubuntu 12.04.1
[14:18] <stgraber> as usual, if you have any other Ubuntu or downstream deadline to add, please let me know
[14:18] <stgraber> #topic Quick look through the current bug lists, checking for progress
[14:19] <stgraber> So, looking at the LP bug lists, it doesn't look particularly good...
[14:19] <stgraber> Bug list went from 106 bugs targeted to 12.04.1 to 112.
[14:19] <stgraber> 26 of these are currently marked fix commited (vs 27 two weeks ago).
[14:19] <stgraber> 50 of the 112 bugs aren't currently assigned to someone.
[14:19] <stokachu> only 1 fix committed?
[14:19] <smoser> -1
[14:19] <stokachu> err yea
[14:20] <stgraber> I'm hoping these fix commited are different ones from last week, but I don't have an easy way to check that
[14:20] <stokachu> tbh i haven't seen much movement on sru's last week
[14:20] <stokachu> i assume b/c of holidays etc
[14:21] <skaet> in particular,  a bit worried about bug 1017001.   There are also some bugs that QA is encountering yesterday that they're worried about:  bug 1021718,  bug 1022864, bug 1022927
[14:21] <stgraber> I think at this point we really really need every team to go through the list, assign the work to their team members, target any missing bug and re-target any bug that won't be fixed in time
[14:22] <stokachu> yea the lack of ownership is worrisome
[14:22] <skaet> I think stgraber's recommendation that the teams go through and assign individuals to each of the flagged bugs is what's needed.
[14:23] <stokachu> agreed
[14:23] <stgraber> 1017001 should probably be assigned to mvo or should at least be escalated to mvo. I'll take care of that when going through the foundations bugs
[14:23] <skaet> thanks stgraber
[14:24] <skaet> if when doing the pass to assign the bugs,  if folks could make sure the priority is accurate as well,  it would help.
[14:25]  * skaet figures its probably worth bringing up at the meeting tomorrow,  that we're in the last push for 12.04.1 and there are lots of worrisome bugs out there.
[14:25] <seb128> doh
[14:25] <seb128> was there a meeting today? why didn't anyone ping me?
[14:26] <stgraber> also don't hesitate to move things to 12.04.2 or -updates, I'm guessing we have quite a few of these bugs that aren't realistically going to make it to the point release and I'd prefer to have the list reflect that (instead of being over-optimistic as it seems to be at the moment)
[14:26] <skaet> stgraber,  should we also be switching to weekly now?
[14:26] <skaet> for the meeting
[14:26] <stgraber> seb128: yep, there's a meeting. Google should have pinged you 10 minutes before the meeting... wan me to copy/paste the log so far?
[14:27] <seb128> stgraber, google did, I got carried up in other discussions and forgot to join
[14:27] <seb128> stgraber, that's fine, I will read the log online
[14:27] <seb128> stgraber, just let me know if there was any question for me ;-)
[14:27] <stgraber> skaet: I think it'd be a good idea to ensure that everyone is focused on getting these done
[14:27] <stgraber> seb128: the only think desktopy I saw so far is bug 1022864 that Kate mentioned a bit earlier
[14:28] <seb128> stgraber, ok, I started following up on this, will keep doing that
[14:28] <seb128> stgraber, is the meeting over?
[14:28] <seb128> (sorry to step in the middle)
[14:28] <skaet> seb128,  there wasn't a question,  but an action ;)  please go through the 12.04.1 bugs and clean up assignments/priority/milestone targets.  :)
[14:28] <seb128> ok
[14:28] <stgraber> seb128: nope, we're in the middle of it (going through the bug lists)
[14:29] <ScottK> skaet/stgraber: There's a postfix microversion update pending acceptance that really ought to go into 12.04.1 because if it doesn't, upgraders are likely to have TLS problems.
[14:29] <seb128> stgraber, ok, sorry for the noise then, please get going, I'm around now ;-)
[14:29] <skaet> ScottK,  bug number?
[14:29] <stgraber> ScottK: are the relevant bugs targeted to 12.04.1?
[14:29]  * ScottK looks
[14:30] <jamespage> ScottK, bug 1022772
[14:30] <ScottK> That's the SRU bug.
[14:31] <jamespage> original bug report - bug 991754
[14:31] <ScottK> That's the one.
[14:31] <ScottK> I think Bug #1001040  is related too.
[14:32] <ScottK> I think we definitely want this resolved before server upgrades start in earnest.
[14:32] <stgraber> ok, status looks good and it's targeted, so assuming it gets tested quickly, there'll be no problem to have it in 12.04.1
[14:33] <ScottK> First some other SRU person needs to accept it ...
[14:33] <ScottK> Maybe bdmurray would do it.
[14:35] <stgraber> we seem to have almost 2 weeks worth of SRU backlog in the queue, that's getting a bit scary... hopefully it'll get better when debconf is over and we get back slangasek and infinity
[14:35] <skaet> ScottK,  yup, its his day for SRU vanguarding... https://wiki.ubuntu.com/SRUTeamProcess
[14:35] <ScottK> Perfect.
[14:35] <bdmurray> ScottK: postfix is it?
[14:35] <ScottK> bdmurray: yes.  For Precise.
[14:35] <skaet> stgraber,  ok,  I'll start beating the drums, and seeing if we can get some focus.
[14:36] <seb128> yeah, SRU backlog is concerning
[14:36] <stgraber> skaet: would be great. Apparently nagging directly for a given package seems to work quite well, but that means that people who aren't nagging in #ubuntu-release have to wait weeks to have their stuff accepted...
[14:36] <seb128> we are at constant level around  30 items backlog
[14:36] <skaet> yeah,  infinity had some ideas on this,  but I haven't seen any updates about it.
[14:36] <seb128> it's going to be an increasing issue as we get close from the freeze date
[14:36] <stokachu> good we are getting fixes proposed, bad we dont have the bandwidth
[14:37] <stokachu> is it possible to check for valid sru's in the first comment and dismiss those missing any one of the 3 required
[14:37] <stokachu> or description, whatever
[14:38] <stokachu> was thinking maybe launchpad janitor or some other bot
[14:38] <stokachu> also having a form submission for SRU's would help to keep required fields
[14:38] <stgraber> stokachu: I'd expect one that doesn't have these fields set to be rejected, not left in the queue. I don't think the format is strict enough that it can easily be detected at this point though
[14:39] <stokachu> stgraber: yea im just curious if they haven't been touched yet though
[14:39] <ScottK> I think I did leave a couple in the queue that needed work on the bug, but made comments there/set them to incomplete.
[14:40] <stokachu> ScottK: do those actually show in the queue waiting for someone in SRU team to work on?
[14:40] <stgraber> at some point we'll want to automatically get these test cases and push them to packages.qa.ubuntu.com, so requiring a well structured description will help achieve that. Though I guess that's something to discuss at the next UDS.
[14:40] <stokachu> i recommended an updates system at the previous one
[14:40] <stokachu> QA didn't seem to impressed though :)
[14:41] <stokachu> anyway, stgraber those bugs i posted yesterday for you are the ones relevant to 12.04.1 as well
[14:41] <stokachu> should i post them again for archival's sake?
[14:41] <ScottK> stgraber: I think it would be nice to have a page like the one for SRU status in -proposed that serves a a control panel for what needs working on.  It could mark incomplete bugs yellow or something so people don't relook.
[14:42] <stgraber> #action skaet to poke the SRU team and see what can be done to process the current backlog
[14:42] <meetingology> ACTION: skaet to poke the SRU team and see what can be done to process the current backlog
[14:42] <skaet> yup
[14:42] <stgraber> #action stgraber to review and sponsor bug 977947, bug 977952 and bug 977940
[14:42] <meetingology> ACTION: stgraber to review and sponsor bug 977947, bug 977952 and bug 977940
[14:43] <stokachu> stgraber: thanks :D
[14:43] <stokachu> seb128 could probably help with 977940 if he has time
[14:43] <stgraber> ScottK: yeah, having tried to do some of that in queuebot, the main pain is that the API doesn't let us query much from the queue at this point. Though that may have changed with cjwatson's work on the queue API
[14:44] <stgraber> ScottK: the main problem in the past was that you would only get the URL to the .changes file and would then have to parse it to get anything out of it (and then query LP again based on that)
[14:44] <ScottK> Not very helpful.
[14:45] <stgraber> yeah :) I wanted to show the IRC nickname of the uploader in queuebot but decided not to do it as I'd have had to: grab the .changes => parse it => extract e-mail => match against LP => get the user object => query ircnickname
[14:46] <stokachu> seb128: you mentioned multi-arch bugs at the previous meeting, are there any that you are aware of that I haven't touched yet
[14:46] <stgraber> instead of being able to do the usual .uploader.irc_name :)
[14:46] <ScottK> stgraber: ./queue info shows stuff like " 4373718 | S- | qemu-kvm             | 1.0+noroms-0ubuntu14 | 17 hours         | * qemu-kvm/1.0+noroms-0ubuntu14 Component: main Section: misc" now.
[14:46] <seb128> stokachu, what's the status of those atm? I uploaded libart-lgpl and reviewed gnome-vfs that you updated yesterday
[14:46] <ScottK> That seems like a useful basis for something.
[14:46] <stokachu> ah
[14:46] <seb128> stokachu, what about the libbobobo,ui ones, did slangasek review it again?
[14:47] <stokachu> seb128: stgraber added it to his list to review
[14:47] <seb128> ok
[14:47] <stokachu> i saw you reviweed gnome-vfs but did you review the merge proposal?
[14:47] <stokachu> he addressed your changes mentioned
[14:47] <stokachu> it*
[14:48] <stokachu> the only other 2 i know of are libgnome2 and appmenu-gtk
[14:48] <stgraber> gnome-vfs is on my list for today, so I'm happy to review it too
[14:48] <stokachu> which im current working
[14:48] <seb128> stokachu, ok, yeah, appmenu-gtk seems to be the one coming often
[14:48] <seb128> stokachu, thanks, seems those are on track then
[14:48] <stokachu> ok cool, please lemme know if any other come up
[14:49] <stgraber> stokachu: let me know when they're ready to be looked at and I'll look and sponsor (I have a few more questions on the testing you did, but I'll poke you post-meeting)
[14:49] <stgraber> #topic Round table
[14:49] <stokachu> ok
[14:49] <stgraber> stgraber@castiana:~$ echo $(shuf -e NCommander seb128 stgraber arges jibel skaet smoser jamespage)
[14:49] <stgraber> NCommander arges jibel skaet seb128 smoser stgraber jamespage
[14:50] <stokachu> aww no love 4 stokachu
[14:50] <skaet> stokachu, why don't you start then...  I suspect NCommander's offline
[14:50] <stgraber> stokachu: oops :) let's pretend you're after arges
[14:50] <stokachu> LOL
[14:50] <stgraber> or now, whatever :)
[14:50] <stokachu> I think im covered for now
[14:51] <stgraber> arges:
[14:51] <arges> i'm good
[14:51] <arges> ..
[14:51] <stgraber> no jibel around
[14:51] <stgraber> skaet:
[14:51] <skaet> back from vacation,   getting concerned about all the recent failures (as mentioned);  about to start beating the drum....
[14:52] <skaet> need to get the QA daily tests working reliably again as first priority.
[14:52] <skaet> ..
[14:52] <stgraber> seb128:
[14:52] <seb128> desktop SRUs still go well, on a regular basis
[14:52] <seb128> we are a bit behind for compiz,unity
[14:52] <seb128> we should have an unity SRU with a big pile of fixes next week
[14:53] <seb128> then a compiz one
[14:53] <seb128> (we got an issue with the current compiz  SRU this week, that's going to be addressed with a follow up upload rsn)
[14:53] <seb128> then we aim at another round of unity uploads at the end of the month, mostly backports from quantal performance improvements
[14:54] <seb128> otherwise as mentioned before the SRU team backlog and delay to do review is still concerning
[14:54] <seb128> it really slow down work and breaks the dynamic, it also makes hard to follow errors.ubuntu.com since lot of the issues are addressed with fixes blocked in the queue for weeks
[14:54] <seb128> ..
[14:54] <skaet> seb128,  please remind unity/compiz teams of the 08/02 date to get all the desktop infrastructure changes in by.
[14:54] <seb128> skaet, yes, we have that in mind and we will make sure to be in time ;-)
[14:55] <skaet> :)
[14:55] <stgraber> smoser:
[14:56] <smoser> jamespage, and i just went through the server team bugs.
[14:56] <smoser> significant amount are juju or maas.
[14:56] <smoser> and we'll follow up with those teams to push a bit and get a sense of urgency
[14:57] <smoser> that really just about covers the list at http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
[14:57] <smoser> thats it.
[14:58] <stgraber> stgraber:
[14:59] <stgraber> must admit being a bit behind on tracking SRUs at the moment... I still have at least one in the queue. Started reviewing stokachu's multi-arch SRUs (should be uploaded today)
[15:00] <stgraber> I'll also go through the whole list and make sure the bugs have all proper target/tags/importance/status and assign these that are foundation-y
[15:00] <stgraber> will probably be talking a bit with skaet on these that I think we'd need to drop from 12.04.1
[15:01] <stgraber> I remember some of the listed ones requiring significant upstream changes that haven't even started, so pretty unlikely to be ready (thinking of one of the dnsmasq bug)
[15:01] <stgraber> ..
[15:01] <stgraber> jamespage:
[15:03] <stgraber> going to assume that it's mostly the same as smoser
[15:03] <stgraber> #topic AOB
[15:04] <stgraber> so as Kate suggested earlier, the meeting will now become a weekly meeting
[15:04] <stgraber> I'll update the wiki and the calendar
[15:04] <stgraber> same place, same time, just every week now
[15:04] <stgraber> #action stgraber to change the meeting to a weekly meeting
[15:04] <meetingology> ACTION: stgraber to change the meeting to a weekly meeting
[15:04] <stgraber> anything else?
[15:05] <jamespage> stgraber, sorry - it was - got called away for a second...
[15:05] <stgraber> #endmeeting
[15:05] <meetingology> Meeting ended Thu Jul 12 15:05:37 2012 UTC.
[15:05] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-14.00.moin.txt
[15:05] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-14.00.html
[15:05] <stgraber> thanks everyone, sorry for finishing a bit late
[15:05] <stokachu> thanks!
[15:06] <skaet> thanks!
[16:18] <asomething> #startmeeting "MOTU Meeting"
[16:18] <meetingology> Meeting started Thu Jul 12 16:18:58 2012 UTC.  The chair is asomething. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:18] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:19] <asomething> Hi all! Any one around for the motu meeting?
[16:20] <asomething> looks like we have one agenda item besides our standing ones
[16:20] <asomething> MOTU School Doodle poll results update and discussion
[16:20] <coolbhavi> m there!
[16:21] <coolbhavi> asomething, one good news is we had a good response for the 1st school session on restart yesterday
[16:21] <asomething> #topic MOTU School Doodle poll results update and discussion
[16:22]  * tumbleweed waves from debconf
[16:22] <asomething> coolbhavi, great, how'd the session go? good attendance?
[16:23] <coolbhavi> asomething, yes there was a reasonable turn up yesterday
[16:23]  * coolbhavi searches his bookmarks for the poll link
[16:23] <asomething> are the logs up one the wiki somewhere?
[16:24] <asomething> coolbhavi, http://doodle.com/w9p6hh43hfwk8xmp
[16:25] <coolbhavi> thanks asomething  the logs are linked by nhandler today I believe on the wiki
[16:27] <asomething> one thing I've noticed is that we have https://wiki.ubuntu.com/Packaging/Training and https://wiki.ubuntu.com/MOTU/School
[16:27] <asomething> i wonder if these should be merged
[16:28] <coolbhavi> yes asomething I'll do that over the next week
[16:28] <asomething> great
[16:28] <asomething> #action coolbhavi, merge https://wiki.ubuntu.com/Packaging/Training and https://wiki.ubuntu.com/MOTU/School
[16:29] <meetingology> ACTION: coolbhavi, merge https://wiki.ubuntu.com/Packaging/Training and https://wiki.ubuntu.com/MOTU/School
[16:30] <coolbhavi> asomething, based on the timings feedback I got here is the post I posted on the mailing list: https://lists.ubuntu.com/archives/ubuntu-motu/2012-June/007267.html
[16:30] <asomething> is there anything that could go better for the next class? was there some kind of help you could have used that you don't feel you got?
[16:30] <coolbhavi> asomething, yes there is a streamlining process in my mind
[16:32] <coolbhavi> basically to sustain the school we need to have a team who co ordinate with various people and setup sessions
[16:32] <coolbhavi> fitting across most time zones
[16:33] <coolbhavi> doing a bit of blogging about the sessions just a week before the sessions
[16:33] <asomething> #action asomething, help blog about the next motu school session
[16:33] <meetingology> ACTION: asomething, help blog about the next motu school session
[16:33] <coolbhavi> and sending a remainder to the list 2 or 3 days before the sessions
[16:34] <coolbhavi> asomething, any views on the same welcome!
[16:34] <asomething> ya, in the past we've struggled to have trainings on a regular basis. I think you're probably hitting the same issues
[16:35] <asomething> has anyone stepped up to lead the next class?
[16:36] <coolbhavi> hmm I see a https://launchpad.net/~packaging-training-coordinators team on LP maybe we can open up a new team and merge the same as in the case of d-a-t
[16:37] <coolbhavi> asomething, I got a lukewarm response for handling sessions on the list so I took the first session
[16:37] <coolbhavi> keeping in mind the audience turnout
[16:41] <asomething> so from your email, it looks like 27th July will be the next class, right?
[16:42] <asomething> #link http://doodle.com/w9p6hh43hfwk8xmp
[16:42] <coolbhavi> yes
[16:42] <asomething> #link https://lists.ubuntu.com/archives/ubuntu-motu/2012-June/007267.html
[16:43] <asomething> #info 27th July will be the MOTU School next class, still needs an instructor
[16:45] <asomething> so is there anything else to discuss? I don't think we have any thing new for the ARB to report back
[16:46] <coolbhavi> no I am done from my side
[16:47] <asomething> #topic Next MOTU meeting
[16:47] <asomething> so turn out was a bit low =)
[16:47] <coolbhavi> ll catchup on the list on motu school
[16:47] <coolbhavi> :)
[16:48] <asomething> if we're going to keep the every other week pace, that put's us on 26 July
[16:49] <coolbhavi> +1
[16:49] <asomething> I can't commit to chairing the next meeting, but I'll send out the minutes from this one and commit to sending the reminder mails to the list
[16:49] <asomething> #action send out meeting minutes
[16:49] <meetingology> ACTION: send out meeting minutes
[16:50] <asomething> #action asomething, update wiki headers and send out reminders for next meeting
[16:50] <meetingology> ACTION: asomething, update wiki headers and send out reminders for next meeting
[16:50] <asomething> guess that's all for today
[16:51] <coolbhavi> same here but I can chair i think next
[16:51] <asomething> #endmeeting
[16:51] <meetingology> Meeting ended Thu Jul 12 16:51:42 2012 UTC.
[16:51] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-16.18.moin.txt
[16:51] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-16.18.html
[18:00] <jono> #startmeeting
[18:00] <meetingology> Meeting started Thu Jul 12 18:00:20 2012 UTC.  The chair is jono. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:00] <jono> hi everyone, and welcome to the Ubuntu Accomplishments meeting!
[18:00] <jono> I know cielak is going to be a bit late to join us
[18:00] <jono> but who is here for the meeting?
[18:00]  * mfisch is
[18:00]  * imbrandon waves o/
[18:01] <AlanBell> o/
[18:01] <jono> awesome
[18:01] <jono> I wanted to first discuss quality
[18:01] <jono> recently we have been working to improve the quality across our codebases
[18:01] <jono> I wrote an admin UI for visibility on server-side issues
[18:02] <jono> and we are moving towards unit testing
[18:02] <jono> mfisch, can you summarize your work on this?
[18:02] <mfisch> yes
[18:02] <mfisch> so I basically gutted the unit tests for the daemon
[18:02] <mfisch> the setup for the daemon was much simpler back then.  I spent a few hours last night perfecting the directory structure
[18:03] <mfisch> writing config files
[18:03] <mfisch> ABOUT files
[18:03] <mfisch> extrainformation directorys
[18:03] <mfisch> ies I mean
[18:03] <mfisch> then today I wrote 10 tests, so far
[18:03] <mfisch> there's probably 10-15 more to be writt8en
[18:03] <mfisch> I found 2 small bugs already
[18:04] <mfisch> first of all my code is here:
[18:04] <mfisch> https://code.launchpad.net/~mfisch/ubuntu-accomplishments-daemon/ubuntu-accomplishments-daemon-new-unittests/
[18:04] <mfisch> the bugs are:
[18:04] <jono> mfisch, so the setUp is completely created in /tmp?
[18:04] <mfisch> jono: yes
[18:04] <mfisch> the bugs are:
[18:04] <mfisch> 1) if you have an icon without a file extenstion you get an exception
[18:04] <mfisch> I think this is unlikely and was just due to my fake accomplishment, so I commented it only
[18:05] <cielak> hello everyone, sorry for being late
[18:05] <jono> hey cielak
[18:05] <imbrandon> heya
[18:05] <jono> cielak, we are just discussing mfisch's unit testing work:
[18:05] <mfisch> bug 2)
[18:05] <mfisch> lol
[18:05] <jono> so I basically gutted the unit tests for the daemon
[18:05] <jono>  the setup for the daemon was much simpler back then.  I spent a few hours last night perfecting the directory structure
[18:05] <jono>  writing config files
[18:05] <jono>  ABOUT files
[18:05] <jono>  extrainformation directorys
[18:05] <jono>  ies I mean
[18:05] <jono>  then today I wrote 10 tests, so far
[18:05] <jono>  there's probably 10-15 more to be writt8en
[18:05] <jono>  I found 2 small bugs already
[18:05] <jono>  first of all my code is here:
[18:05] <jono>  https://code.launchpad.net/~mfisch/ubuntu-accomplishments-daemon/ubuntu-accomplishments-daemon-new-unittests/
[18:06] <imbrandon> :)
[18:06] <jono> mfisch, so are you running quickly test to run the tests?
[18:06] <mfisch> the 2nd bug is if the mediafile doesn't exist, you set media_filename to None and then try to concat Str + None
[18:06] <mfisch> jono: right now they're run manually, after I finish writing tests I will set this up so that the package build runs them
[18:07] <mfisch> the standard is that if the tests fail, the package build fails
[18:07] <jono> mfisch, if you used the same class and file, quickly test should run them all anyway
[18:07] <jono> mfisch, right
[18:07] <mfisch> so I'd recommend everyone either build the package or run the tests before checkin
[18:07] <imbrandon> we can likely have automated ci jenkins.ubuntu.com run them too
[18:07] <mfisch> jono: yes, I'm using python's unit test
[18:07] <jono> mfisch, so these bugs...are they bugs in unit testing or this is where the unit tests have identified failures?
[18:07] <mfisch> I was going to use nosetests in the package build, but maybe quickly does that already?
[18:07] <jono> using jenkins might be useful
[18:08] <mfisch> jono: both bugs are cases that could happen, but were found due to incomplete tests
[18:08] <mfisch> jono: like "icon=foo", if you do that in a accomp, you will get an exception
[18:08] <jono> mfisch, right
[18:08] <mfisch> because: a, b = icon.split(".")
[18:08] <jono> so these are good testings to have
[18:08] <jono> which already will improve our quality
[18:08] <imbrandon> i'm familar with it is none else is so can help setup the ci scripts to run the test once mfisch has them more completed
[18:09] <imbrandon> ( for jenkins )
[18:09] <jono> mfisch, I will definitely take a look at your branch
[18:09] <mfisch> one large thing is missing so far from these tests
[18:09] <mfisch> they do not start the service
[18:09] <mfisch> they're just testing the Accomplishments class
[18:09] <mfisch> so things like the accomplish() method, don't work
[18:10] <jono> mfisch, right
[18:10] <jono> so I am not sure if we need to start the service
[18:10] <imbrandon> corectino its https://jenkins.qa.ubuntu.com/ btw sorry :)
[18:10] <mfisch> jono: we can do a lot of testing without it
[18:10] <jono> this is why we would use setUp to generate the data and then pass it to the function
[18:10] <mfisch> I chose a different route
[18:10] <jono> mfisch, so maybe right now we focus on the testing that can just do assertEqual checks
[18:11] <mfisch> I end up creating an accomplishment object in each test so I can mess around with stuff, like the ABOUT file
[18:11] <mfisch> for example
[18:11] <mfisch> I have a test that removes the ABOUT file and asserts that we get an exception
[18:11] <cielak> well, that makes sense for me too - all the service stuff is mosty done by twistd, and there is very little we actually mess with it
[18:11] <mfisch> jono: and I have tests for your config writer/reader stuff
[18:11] <jono> mfisch, cool
[18:12] <jono> I think this is going to help us to get to a culture where all functions have tests and documentation
[18:12] <imbrandon> is there plans for a linter for the accomplishments or do we think the tests are enough
[18:12] <mfisch> jono: I also removed all the "homedir = " references which are not needed since you added that environment vairable
[18:12] <mfisch> imbrandon: personally I think a linter will help
[18:12] <jono> mfisch, which homedir refs?
[18:12] <mfisch> imbrandon: the code will throw exceptions when it sees stuff it doesnt like
[18:13] <mfisch> jono: look at checkin #100 in my branch
[18:13] <imbrandon> yea we can do thinkgs like E: and W: with a linter tho :)
[18:13] <cielak> jono: http://bazaar.launchpad.net/~mfisch/ubuntu-accomplishments-daemon/ubuntu-accomplishments-daemon-new-unittests/revision/100#accomplishments/daemon/api.py
[18:13] <mfisch> imbrandon: here's some examples that I've found
[18:13] <imbrandon> k
[18:13] <mfisch> imbrandon: one call will fail if there's no icon field
[18:14] <jono> mfisch, I see, as we already have self.dir_<whatever> set earlier in the code
[18:14] <mfisch> imbrandon: another will fail if icon doesn't have a . in it
[18:14] <mfisch> jono: yep
[18:14] <jono> cool
[18:14] <jono> mfisch, how much test coverage do you think we can get without requiring the service?
[18:14] <jono> just pure unit testing
[18:15] <mfisch> we can easily test every public API
[18:15] <mfisch> well
[18:15] <mfisch> except accomplish()
[18:15] <mfisch> thats the only one I'm sure we can't test
[18:15] <jono> right
[18:15] <imbrandon> i'll start on a basic linter this afternoon then, thats something i can easily fit into my schedule and then post to the list once i have the basics working and we can discuss things to check
[18:15] <mfisch> I have a huge list at the top of the tests
[18:15] <jono> mfisch, so that list is acting as the TODO?
[18:15] <mfisch> a list of public API calls
[18:15] <mfisch> yeah
[18:15] <jono> imbrandon, cool
[18:15] <mfisch> it's a TODO
[18:16] <cielak> I guess that's enough to test all the 'logic' of all functions... mfisch, why there is an exception for accomplish() ?
[18:16] <mfisch> I hope to knock a few more out today
[18:16] <mfisch> cielak: when you instantiate the Accomplishment class you're supposed to pass a service reference
[18:16] <mfisch> self.service = service
[18:16] <mfisch> I'm passing None because I don't have one
[18:16] <jono> cielak, indeed
[18:17] <cielak> yeah, but why does it stop you from testing accomplish() ?
[18:17] <jono> and that is going to be the primary focus on these unit tests, to ensure that the result is as expected
[18:17] <cielak> how does it differ from other methods?
[18:18] <mfisch> accomplish calls service routines
[18:18] <mfisch> self.service.trophy_received(accomID)
[18:18] <mfisch> since self.service is None, bad things happen
[18:18] <mfisch> I'd eventually like to fix that
[18:18] <cielak> ah, right, that's true
[18:18] <mfisch> but we can get some low hanging fruit without it
[18:18] <jono> thanks for your efforts on this, mfisch
[18:18] <mfisch> np
[18:18] <cielak> what about we passed it a fake service instance?
[18:18] <jono> this is going to be really helpful in ensuring we don't break things
[18:19] <cielak> that would have a fake, empty trophy_received() method?
[18:19] <imbrandon> yea mock
[18:19] <mfisch> something like that would work
[18:19] <jono> perfect
[18:19] <mfisch> so let me do this
[18:20] <mfisch> let me write more tests this afternoon and then do a MP
[18:20] <mfisch> and then we can discuss next steps
[18:20]  * cielak just read some code from that branch, and it looks very promising
[18:20] <jono> mfisch, perfect, if you file a MP we can then merge in your work so far and then you can just iterate with more tests
[18:20] <jono> and before long we should have full test coverage
[18:20] <imbrandon> yup
[18:20] <mfisch> so I do have one request, or something to watch for
[18:20] <jono> mfisch, sure
[18:21] <mfisch> it is confusing for people reading the code when we use acc, accs, accom, accomp, accomps, accoms, and accomplishments
[18:21] <jono> yeah we need to fix this
[18:21] <jono> mfisch, you mean in api.py?
[18:21] <mfisch> so when you're designing your API and writing your code, it's better to agree on one abbreviation
[18:21] <mfisch> jono: thats the only one I've really been looking at
[18:21] <jono> makes sense
[18:21] <mfisch> just a thought
[18:21] <jono> we should fix these
[18:22] <cielak> yup, agreed
[18:22] <jono> mfisch, could you file a bug against the daemon for this
[18:22] <jono> my hunch is that we use 'accom'
[18:22] <mfisch> sure, will do
[18:22] <cielak> but it's not just the daemon
[18:22] <jono> thanks mfisch
[18:22] <cielak> it's us too
[18:22] <jono> cielak, indeed :-)
[18:22] <jono> so I have a related topic
[18:22] <jono> documentation
[18:22] <cielak> we need to standartize not only appearances in the code, but out vocabulary too :)
[18:22] <cielak> our*
[18:22] <jono> cielak, agreed
[18:23] <jono> this week I started putting together developer documentation
[18:23] <imbrandon> sphinx ROCKS! , we've been using it in juju, omg i'm in love with sphinx docs ... that is all :)
[18:23] <jono> I want to ensure that our daemon API is fully documented
[18:23] <jono> and I talked with cielak a little about this
[18:23] <jono> imbrandon, indeed
[18:23] <jono> so the plan is this:
[18:23] <jono>  * we want to document the following core things:
[18:24] <jono>  - api.py - this is the internal implementation, and these docs will be designed for people hacking on the daemon
[18:24] <jono>  - dbusapi.py - this generates our client documentation that client devs will use
[18:24] <jono> you can see this work evolving at http://213.138.100.229/ubuntu-accomplishments-daemon/docs/_build/html/index.html#module-accomplishments.daemon
[18:25] <jono> take a look at http://213.138.100.229/ubuntu-accomplishments-daemon/docs/_build/html/clientref.html
[18:25] <jono> this is the client docs
[18:25] <jono> I spent some time adding this earlier this week, I still need to finish
[18:25] <jono> cielak, did you get a chance to document api.py?
[18:26] <jono> the docs in api.py might be useful for mfisch when writing tests and knowing what a function should return
[18:26] <cielak> jono: not yet, but that's on top of my priority list now, so I'll do it really soon
[18:26] <jono> awesome cielak
[18:26] <jono> one thing I wanted ask re. this
[18:26] <jono> so our functions in dbusapi.py typically output dbus data
[18:26] <mfisch> yes, docs would help
[18:27] <jono> but I have been showing the examples just outputting the plain lists to show it simplifiied
[18:27] <jono> do you think this makes sense?
[18:27] <cielak> jono: do you have an example of that?
[18:28] <jono> cielak, as an example: http://213.138.100.229/ubuntu-accomplishments-daemon/docs/_build/html/clientref.html#accomplishments.daemon.dbusapi.AccomplishmentsDBusService.get_acc_categories
[18:28] <imbrandon> jono as a side note, the ubuntu theme i created for http://juju.ubuntu.com/docs/ ( sphinx ) is at lp:ubuntu-community-webthemes/light-sphinx-theme if when its time to publish you want to make it follow branding etc
[18:28] <jono> I show this just outputting a straight list
[18:29] <jono> imbrandon, oh cool, could you merge it into ubuntu-accomplishments-daemon and submit a MP?
[18:29] <cielak> jono: aah, and it should actually be [dbus.String("Launchpad")], or something like that?
[18:29] <jono> cielak, right
[18:29] <imbrandon> jono: aure thing
[18:29] <imbrandon> sure*
[18:29] <jono> but I am not sure if I should show the full dbus output, cielak
[18:29] <jono> or keep it simple, as it is still a list
[18:29] <jono> my hunch is to keep it simple
[18:29] <jono> thanks imbrandon!
[18:30] <cielak> well, if we will state clearly enough that this actually are dbus data types, then any developer familiar with dbus will know what does that mean
[18:30] <jono> cielak, that makes sense
[18:30] <jono> we can mention that in the general docs
[18:30] <jono> I can put that at the top of the docs page
[18:30] <cielak> and of course, being consistent is the key:  http://213.138.100.229/ubuntu-accomplishments-daemon/docs/_build/html/clientref.html#accomplishments.daemon.dbusapi.AccomplishmentsDBusService.build_viewer_database
[18:31] <jono> cielak, indeed
[18:31] <jono> we will want to give them all a look for accuracy
[18:31] <jono> ok cool, so cielak, you are going to work on docs next?
[18:31] <jono> and I will finish off the client docs too
[18:31] <cielak> I think a general note about the AccomplishmentsDBusSrvice class will do the trick
[18:31] <jono> cielak, yup
[18:31] <cielak> yup, that's what I'm gonna do next :)
[18:32] <imbrandon> also note i can make it "look" liek anything with the CSS :)
[18:32] <jono> cielak, it might make sense if you can start documentating the functions that mfisch has not written tests for yet
[18:32] <jono> so he knows the return values to expect
[18:32] <jono> imbrandon, cool!
[18:32] <mfisch> good idea
[18:33] <cielak> okay, sure - but documenting all this shouldn't take much time anyway
[18:33] <cielak> but I'll start with these that are missing test, to ensure mfisch will get them as soon as possible
[18:33] <jono> mfisch, would it helpful for cielak to just list all the return details first for all the missing tests and then fill the docs afterwards?
[18:33] <jono> cielak, cool!
[18:34] <mfisch> yeah that works
[18:34] <mfisch> most so far I've figured out from reading the python
[18:35] <mfisch> cielak: the "to do" list is at the top of the unit tests
[18:35] <cielak> yeah, in most cases that's not complicated at all
[18:35] <cielak> thanks mfisch, will follow it
[18:35] <mfisch> so I have another topic
[18:35] <mfisch> depending on what jono has
[18:35] <jono> thanks
[18:35] <jono> mfisch, sure
[18:36] <mfisch> does the accomp linter remove the need for the daemon to be more bullet proof?
[18:36] <mfisch> i know it helps
[18:36] <mfisch> but when I wrote my accomplishments I was greeted by lots of crashing
[18:37] <jono> mfisch, accomp linter?
[18:37] <imbrandon> hrm, i think it would help devs more than needing to be bulletproof
[18:37] <mfisch> accomplishment checker/verifier
[18:37] <imbrandon> jono: the new linter i talked about earlier
[18:37] <jono> mfisch, oh you mean battery?
[18:38] <mfisch> I think its a tool that will read 1 accomp file and tell you if something required is missing or broken
[18:38] <jono> mfisch, we have that
[18:38] <cielak> more or less
[18:38] <jono> I wrote a tool called Accomplishments Battery
[18:38] <imbrandon> jono: no , like "lintian" for ebian packageing only this will be for ubuntu accompilshment writers
[18:38] <imbrandon> ahhh
[18:38] <imbrandon> well maybe so then
[18:38] <cielak> actually, I think the battery should be expanded with the funcionality of a linter
[18:38] <mfisch> ok
[18:38] <imbrandon> yea
[18:38] <imbrandon> that sounds like ti
[18:38] <jono> let me explain:
[18:39] <jono> so I wrote this tool called accomplishments-battery that can do a full test run over all accoms
[18:39] <cielak> there is a lot of other checks it might perform to help accomplishment devs to ensure their accomplishment works
[18:39] <jono> and you can use it to test a specific accomplishment
[18:39] <cielak> okay, but now the battery makes sense only for global accomplishments
[18:39] <jono> I also added a check which tells you if you missed fields in your .accomplishment file
[18:39] <jono> cielak, yes, we need to make it work better for local accoms
[18:39] <mfisch> perfect
[18:40] <cielak> oh, I didn't know about that feature
[18:40] <imbrandon> yuo perfect
[18:40] <jono> mfisch, imbrandon https://wiki.ubuntu.com/Accomplishments/Creating/Guide/Testing
[18:40] <mfisch> let me explain my thought
[18:40] <jono> mfisch, sure
[18:40] <mfisch> right now, a missing = sign in 1 accomp file will take the whole daemon down
[18:40] <jono> mfisch, right
[18:40] <mfisch> it sounds like we have tools to help you test that (we didn't back in my day!)
[18:41] <jono> mfisch, well, we have a tool that checks if the script works
[18:41] <mfisch> so, I guess just keep that in mind when we're writing code, we might need more exception handling
[18:41] <jono> we don't currently do syntax checking in bettery
[18:41] <jono> which would be handy
[18:41] <jono> mfisch, although I think the daemon should not go down when it finds a syntax issue
[18:41] <jono> we might want to throw some badly formed accomplishments at it as part of the unit tests
[18:41] <mfisch> I have some
[18:42] <mfisch> but now I only assert that they do throw exceptions
[18:42] <jono> the goal of battery is to help the accom dev submit a perfectly working accom
[18:42] <jono> mfisch, gotcha
[18:42] <mfisch> I had a plan to do this
[18:42] <jono> mfisch, what would be handy is if you could file bugs for these issues
[18:42] <jono> we should definitely fix them
[18:42] <mfisch> have 3 good accomps, make sure we see 3, add 1 bad one, make sure we still see 3
[18:42] <mfisch> ok
[18:42] <jono> mfisch, cool
[18:42] <mfisch> right now 3+ 1 bad one = crash
[18:42] <jono> mfisch, good point though
[18:42] <jono> right
[18:42] <cielak> very true
[18:43] <mfisch> I'll file a few more today then
[18:43] <cielak> daemon does indeed depend on the accoms correctness
[18:43] <jono> fortunatley, these should be simple fixes
[18:43] <jono> thanks mfisch
[18:43] <cielak> also, it can be crashed with a wrong config file
[18:43] <jono> cielak, would you be happy to look at these bugs and I will fix it in battery?
[18:43] <cielak> of course
[18:43] <jono> maybe we can look at this when our docs are finalized
[18:43] <jono> mfisch, cool, so if you can file the bugs and assign them to cielak
[18:43] <cielak> this may require some tricks, but is really needed
[18:44] <mfisch> ok
[18:44] <jono> I will try to get better syntax checking in battery
[18:44] <jono> thanks guys
[18:44] <jono> I will be out at OSCON next week, so my battery work may be a little later
[18:44] <jono> cielak, good news is I am not seeing any server failures
[18:45] <cielak> neither I do :-)
[18:46] <jono> ok, just to recap:
[18:46] <jono>  * cielak - you will add the return types to the api.py docs first and mfisch can use that to continue building the tests
[18:46] <jono>  * cielak - you will then flesh out the api.py docs
[18:46] <jono>  * mfisch - you will continue to grow our unit tests
[18:47] <jono>  * imbrandon - you will add ubuntu theming support to sphinx
[18:47] <jono>  * me - I will finish off the docs for the client side
[18:47] <imbrandon> jono: yup, just about done actually :)
[18:47] <jono>  * cielak - you will look at the syntax bugs in the daemon and I will fix this in battery
[18:47] <jono> this should keep us busy until the next meeting
[18:47] <cielak> yeah, exactly ;)
[18:48] <jono> awesome
[18:48] <jono> also, I am expanding https://wiki.ubuntu.com/Accomplishments/GetInvolved/Hacking more and more where I can
[18:48] <jono> so we can have good docs for new devs joining us
[18:48] <jono> any other topics?
[18:49] <imbrandon> nope , not here
[18:49] <jono> ok cool
[18:49] <imbrandon> jono: http://api.websitedevops.com/accomplishments-docs/
[18:49] <cielak> does anyone lurking want to ask us anything? ;-)
[18:49] <jono> imbrandon, haha!
[18:49] <jono> nice!
[18:50] <imbrandon> needs some tweeks but its almost ready :)
[18:50] <cielak> imbrandon: oh, wow!
[18:50] <imbrandon> :)
[18:50]  * imbrandon loves web stuff 
[18:50] <jono> imbrandon, looks like there are a few tweaks that need to happen in there
[18:50] <jono> a few layout issues
[18:50] <jono> imbrandon, thanks so much
[18:50] <jono> this is going to rock when we get this online
[18:50] <imbrandon> yup, its talored to juju docs now, but yea
[18:50] <bkerensa> imbrandon: rocking job man!
[18:51] <imbrandon> hour or two of touchups and it will rock
[18:51] <jono> thanks imbrandon
[18:51] <imbrandon> heya bkerensa
[18:51] <imbrandon> np jono
[18:51] <jono> any other questions, folks?
[18:51] <jono> I guess we can wrap
[18:51] <jono> thanks everyone for joining us, awesome meeting!
[18:52] <jono> and as ever, we are in #ubuntu-accomplishments
[18:52] <gigix> jono, I might come back and ask for a summary though
[18:52] <cielak> thanks everyone, thanks jono!
[18:52] <jono> gigix, this meeting will be logged
[18:52] <jono> #endmeeting
[18:52] <meetingology> Meeting ended Thu Jul 12 18:52:14 2012 UTC.
[18:52] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-18.00.moin.txt
[18:52] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-18.00.html
[18:52] <jono> gigix, ^