#title #ubuntu-meeting Meeting Meeting started by jono at 18:00:20 UTC. The full logs are available at http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-07-12-18.00.log.html . == Meeting summary == ''LINK:'' https://code.launchpad.net/~mfisch/ubuntu-accomplishments-daemon/ubuntu-accomplishments-daemon-new-unittests/ (mfisch, 18:04:08) Meeting ended at 18:52:14 UTC. == Votes == == Action items == * (none) == People present (lines said) == * jono (167) * mfisch (101) * cielak (41) * imbrandon (36) * meetingology (3) * gigix (1) * ubottu (1) * AlanBell (1) * bkerensa (1) == Full Log == 18:00:20 #startmeeting 18:00:20 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:20 18:00:20 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:29 hi everyone, and welcome to the Ubuntu Accomplishments meeting! 18:00:43 I know cielak is going to be a bit late to join us 18:00:47 but who is here for the meeting? 18:00:55 * mfisch is 18:00:55 * imbrandon waves o/ 18:01:02 o/ 18:01:14 awesome 18:01:35 I wanted to first discuss quality 18:01:47 recently we have been working to improve the quality across our codebases 18:01:57 I wrote an admin UI for visibility on server-side issues 18:02:06 and we are moving towards unit testing 18:02:11 mfisch, can you summarize your work on this? 18:02:23 yes 18:02:34 so I basically gutted the unit tests for the daemon 18:02:56 the setup for the daemon was much simpler back then. I spent a few hours last night perfecting the directory structure 18:03:03 writing config files 18:03:05 ABOUT files 18:03:08 extrainformation directorys 18:03:13 ies I mean 18:03:23 then today I wrote 10 tests, so far 18:03:38 there's probably 10-15 more to be writt8en 18:03:44 I found 2 small bugs already 18:04:08 first of all my code is here: 18:04:08 https://code.launchpad.net/~mfisch/ubuntu-accomplishments-daemon/ubuntu-accomplishments-daemon-new-unittests/ 18:04:17 the bugs are: 18:04:20 mfisch, so the setUp is completely created in /tmp? 18:04:28 jono: yes 18:04:32 the bugs are: 18:04:40 1) if you have an icon without a file extenstion you get an exception 18:04:54 I think this is unlikely and was just due to my fake accomplishment, so I commented it only 18:05:03 hello everyone, sorry for being late 18:05:09 hey cielak 18:05:13 heya 18:05:19 cielak, we are just discussing mfisch's unit testing work: 18:05:22 bug 2) 18:05:23 Error: Launchpad bug 2 could not be found 18:05:27 lol 18:05:27 so I basically gutted the unit tests for the daemon 18:05:27 the setup for the daemon was much simpler back then. I spent a few hours last night perfecting the directory structure 18:05:27 writing config files 18:05:27 ABOUT files 18:05:28 extrainformation directorys 18:05:30 ies I mean 18:05:32 then today I wrote 10 tests, so far 18:05:34 there's probably 10-15 more to be writt8en 18:05:36 I found 2 small bugs already 18:05:38 first of all my code is here: 18:05:40 https://code.launchpad.net/~mfisch/ubuntu-accomplishments-daemon/ubuntu-accomplishments-daemon-new-unittests/ 18:06:02 :) 18:06:07 mfisch, so are you running quickly test to run the tests? 18:06:22 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:45 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:01 the standard is that if the tests fail, the package build fails 18:07:08 mfisch, if you used the same class and file, quickly test should run them all anyway 18:07:13 mfisch, right 18:07:17 so I'd recommend everyone either build the package or run the tests before checkin 18:07:22 we can likely have automated ci jenkins.ubuntu.com run them too 18:07:28 jono: yes, I'm using python's unit test 18:07:43 mfisch, so these bugs...are they bugs in unit testing or this is where the unit tests have identified failures? 18:07:44 I was going to use nosetests in the package build, but maybe quickly does that already? 18:07:55 using jenkins might be useful 18:08:16 jono: both bugs are cases that could happen, but were found due to incomplete tests 18:08:29 jono: like "icon=foo", if you do that in a accomp, you will get an exception 18:08:35 mfisch, right 18:08:40 because: a, b = icon.split(".") 18:08:41 so these are good testings to have 18:08:48 which already will improve our quality 18:08:54 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:03 ( for jenkins ) 18:09:10 mfisch, I will definitely take a look at your branch 18:09:24 one large thing is missing so far from these tests 18:09:27 they do not start the service 18:09:35 they're just testing the Accomplishments class 18:09:44 so things like the accomplish() method, don't work 18:10:04 mfisch, right 18:10:15 so I am not sure if we need to start the service 18:10:18 corectino its https://jenkins.qa.ubuntu.com/ btw sorry :) 18:10:33 jono: we can do a lot of testing without it 18:10:34 this is why we would use setUp to generate the data and then pass it to the function 18:10:47 I chose a different route 18:10:50 mfisch, so maybe right now we focus on the testing that can just do assertEqual checks 18:11:02 I end up creating an accomplishment object in each test so I can mess around with stuff, like the ABOUT file 18:11:05 for example 18:11:15 I have a test that removes the ABOUT file and asserts that we get an exception 18:11:33 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:48 jono: and I have tests for your config writer/reader stuff 18:11:53 mfisch, cool 18:12:24 I think this is going to help us to get to a culture where all functions have tests and documentation 18:12:25 is there plans for a linter for the accomplishments or do we think the tests are enough 18:12:30 jono: I also removed all the "homedir = " references which are not needed since you added that environment vairable 18:12:42 imbrandon: personally I think a linter will help 18:12:50 mfisch, which homedir refs? 18:12:56 imbrandon: the code will throw exceptions when it sees stuff it doesnt like 18:13:04 jono: look at checkin #100 in my branch 18:13:24 yea we can do thinkgs like E: and W: with a linter tho :) 18:13:34 jono: http://bazaar.launchpad.net/~mfisch/ubuntu-accomplishments-daemon/ubuntu-accomplishments-daemon-new-unittests/revision/100#accomplishments/daemon/api.py 18:13:52 imbrandon: here's some examples that I've found 18:13:57 k 18:13:59 imbrandon: one call will fail if there's no icon field 18:14:08 mfisch, I see, as we already have self.dir_ set earlier in the code 18:14:09 imbrandon: another will fail if icon doesn't have a . in it 18:14:15 jono: yep 18:14:18 cool 18:14:43 mfisch, how much test coverage do you think we can get without requiring the service? 18:14:47 just pure unit testing 18:15:19 we can easily test every public API 18:15:22 well 18:15:25 except accomplish() 18:15:30 right 18:15:30 thats the only one I'm sure we can't test 18:15:35 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:36 I have a huge list at the top of the tests 18:15:49 mfisch, so that list is acting as the TODO? 18:15:53 a list of public API calls 18:15:53 yeah 18:15:56 imbrandon, cool 18:15:57 it's a TODO 18:16:00 I guess that's enough to test all the 'logic' of all functions... mfisch, why there is an exception for accomplish() ? 18:16:01 I hope to knock a few more out today 18:16:27 cielak: when you instantiate the Accomplishment class you're supposed to pass a service reference 18:16:34 self.service = service 18:16:38 I'm passing None because I don't have one 18:16:59 cielak, indeed 18:17:10 yeah, but why does it stop you from testing accomplish() ? 18:17:16 and that is going to be the primary focus on these unit tests, to ensure that the result is as expected 18:17:25 how does it differ from other methods? 18:18:11 accomplish calls service routines 18:18:12 self.service.trophy_received(accomID) 18:18:22 since self.service is None, bad things happen 18:18:31 I'd eventually like to fix that 18:18:32 ah, right, that's true 18:18:37 but we can get some low hanging fruit without it 18:18:47 thanks for your efforts on this, mfisch 18:18:50 np 18:18:54 what about we passed it a fake service instance? 18:18:58 this is going to be really helpful in ensuring we don't break things 18:19:11 that would have a fake, empty trophy_received() method? 18:19:23 yea mock 18:19:32 something like that would work 18:19:36 perfect 18:19:51 so let me do this 18:20:00 let me write more tests this afternoon and then do a MP 18:20:05 and then we can discuss next steps 18:20:16 * cielak just read some code from that branch, and it looks very promising 18:20:20 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:31 and before long we should have full test coverage 18:20:36 yup 18:20:44 so I do have one request, or something to watch for 18:20:49 mfisch, sure 18:21:11 it is confusing for people reading the code when we use acc, accs, accom, accomp, accomps, accoms, and accomplishments 18:21:23 yeah we need to fix this 18:21:31 mfisch, you mean in api.py? 18:21:33 so when you're designing your API and writing your code, it's better to agree on one abbreviation 18:21:49 jono: thats the only one I've really been looking at 18:21:53 makes sense 18:21:55 just a thought 18:21:56 we should fix these 18:22:04 yup, agreed 18:22:05 mfisch, could you file a bug against the daemon for this 18:22:11 my hunch is that we use 'accom' 18:22:13 sure, will do 18:22:15 but it's not just the daemon 18:22:20 thanks mfisch 18:22:20 it's us too 18:22:32 cielak, indeed :-) 18:22:36 so I have a related topic 18:22:41 documentation 18:22:47 we need to standartize not only appearances in the code, but out vocabulary too :) 18:22:52 our* 18:22:55 cielak, agreed 18:23:13 this week I started putting together developer documentation 18:23:18 sphinx ROCKS! , we've been using it in juju, omg i'm in love with sphinx docs ... that is all :) 18:23:24 I want to ensure that our daemon API is fully documented 18:23:39 and I talked with cielak a little about this 18:23:41 imbrandon, indeed 18:23:46 so the plan is this: 18:23:57 * we want to document the following core things: 18:24:13 - api.py - this is the internal implementation, and these docs will be designed for people hacking on the daemon 18:24:30 - dbusapi.py - this generates our client documentation that client devs will use 18:24:58 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:16 take a look at http://213.138.100.229/ubuntu-accomplishments-daemon/docs/_build/html/clientref.html 18:25:19 this is the client docs 18:25:39 I spent some time adding this earlier this week, I still need to finish 18:25:47 cielak, did you get a chance to document api.py? 18:26:06 the docs in api.py might be useful for mfisch when writing tests and knowing what a function should return 18:26:14 jono: not yet, but that's on top of my priority list now, so I'll do it really soon 18:26:21 awesome cielak 18:26:33 one thing I wanted ask re. this 18:26:48 so our functions in dbusapi.py typically output dbus data 18:26:49 yes, docs would help 18:27:07 but I have been showing the examples just outputting the plain lists to show it simplifiied 18:27:27 do you think this makes sense? 18:27:48 jono: do you have an example of that? 18:28:30 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:39 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:42 I show this just outputting a straight list 18:29:04 imbrandon, oh cool, could you merge it into ubuntu-accomplishments-daemon and submit a MP? 18:29:06 jono: aah, and it should actually be [dbus.String("Launchpad")], or something like that? 18:29:11 cielak, right 18:29:12 jono: aure thing 18:29:16 sure* 18:29:21 but I am not sure if I should show the full dbus output, cielak 18:29:28 or keep it simple, as it is still a list 18:29:32 my hunch is to keep it simple 18:29:45 thanks imbrandon! 18:30:21 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:31 cielak, that makes sense 18:30:38 we can mention that in the general docs 18:30:44 I can put that at the top of the docs page 18:30:54 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:02 cielak, indeed 18:31:14 we will want to give them all a look for accuracy 18:31:34 ok cool, so cielak, you are going to work on docs next? 18:31:40 and I will finish off the client docs too 18:31:42 I think a general note about the AccomplishmentsDBusSrvice class will do the trick 18:31:49 cielak, yup 18:31:58 yup, that's what I'm gonna do next :) 18:32:04 also note i can make it "look" liek anything with the CSS :) 18:32:14 cielak, it might make sense if you can start documentating the functions that mfisch has not written tests for yet 18:32:20 so he knows the return values to expect 18:32:29 imbrandon, cool! 18:32:54 good idea 18:33:01 okay, sure - but documenting all this shouldn't take much time anyway 18:33:18 but I'll start with these that are missing test, to ensure mfisch will get them as soon as possible 18:33:33 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:37 cielak, cool! 18:34:52 yeah that works 18:34:58 most so far I've figured out from reading the python 18:35:08 cielak: the "to do" list is at the top of the unit tests 18:35:11 yeah, in most cases that's not complicated at all 18:35:29 thanks mfisch, will follow it 18:35:32 so I have another topic 18:35:43 depending on what jono has 18:35:45 thanks 18:35:49 mfisch, sure 18:36:11 does the accomp linter remove the need for the daemon to be more bullet proof? 18:36:34 i know it helps 18:36:45 but when I wrote my accomplishments I was greeted by lots of crashing 18:36:59 mfisch, accomp linter? 18:37:11 hrm, i think it would help devs more than needing to be bulletproof 18:37:29 accomplishment checker/verifier 18:37:35 jono: the new linter i talked about earlier 18:37:39 mfisch, oh you mean battery? 18:38:01 I think its a tool that will read 1 accomp file and tell you if something required is missing or broken 18:38:09 mfisch, we have that 18:38:15 more or less 18:38:15 I wrote a tool called Accomplishments Battery 18:38:18 jono: no , like "lintian" for ebian packageing only this will be for ubuntu accompilshment writers 18:38:22 ahhh 18:38:27 well maybe so then 18:38:36 actually, I think the battery should be expanded with the funcionality of a linter 18:38:37 ok 18:38:46 yea 18:38:50 that sounds like ti 18:38:51 let me explain: 18:39:05 so I wrote this tool called accomplishments-battery that can do a full test run over all accoms 18:39:21 there is a lot of other checks it might perform to help accomplishment devs to ensure their accomplishment works 18:39:22 and you can use it to test a specific accomplishment 18:39:37 okay, but now the battery makes sense only for global accomplishments 18:39:40 I also added a check which tells you if you missed fields in your .accomplishment file 18:39:57 cielak, yes, we need to make it work better for local accoms 18:39:59 perfect 18:40:01 oh, I didn't know about that feature 18:40:05 yuo perfect 18:40:12 mfisch, imbrandon https://wiki.ubuntu.com/Accomplishments/Creating/Guide/Testing 18:40:18 let me explain my thought 18:40:31 mfisch, sure 18:40:34 right now, a missing = sign in 1 accomp file will take the whole daemon down 18:40:43 mfisch, right 18:40:48 it sounds like we have tools to help you test that (we didn't back in my day!) 18:41:02 mfisch, well, we have a tool that checks if the script works 18:41:09 so, I guess just keep that in mind when we're writing code, we might need more exception handling 18:41:12 we don't currently do syntax checking in bettery 18:41:15 which would be handy 18:41:35 mfisch, although I think the daemon should not go down when it finds a syntax issue 18:41:53 we might want to throw some badly formed accomplishments at it as part of the unit tests 18:41:58 I have some 18:42:06 but now I only assert that they do throw exceptions 18:42:09 the goal of battery is to help the accom dev submit a perfectly working accom 18:42:13 mfisch, gotcha 18:42:19 I had a plan to do this 18:42:26 mfisch, what would be handy is if you could file bugs for these issues 18:42:30 we should definitely fix them 18:42:32 have 3 good accomps, make sure we see 3, add 1 bad one, make sure we still see 3 18:42:42 ok 18:42:45 mfisch, cool 18:42:47 right now 3+ 1 bad one = crash 18:42:49 mfisch, good point though 18:42:51 right 18:42:55 very true 18:43:05 I'll file a few more today then 18:43:05 daemon does indeed depend on the accoms correctness 18:43:07 fortunatley, these should be simple fixes 18:43:08 thanks mfisch 18:43:23 also, it can be crashed with a wrong config file 18:43:27 cielak, would you be happy to look at these bugs and I will fix it in battery? 18:43:38 of course 18:43:41 maybe we can look at this when our docs are finalized 18:43:52 mfisch, cool, so if you can file the bugs and assign them to cielak 18:43:58 this may require some tricks, but is really needed 18:44:00 ok 18:44:07 I will try to get better syntax checking in battery 18:44:12 thanks guys 18:44:38 I will be out at OSCON next week, so my battery work may be a little later 18:44:53 cielak, good news is I am not seeing any server failures 18:45:51 neither I do :-) 18:46:05 ok, just to recap: 18:46:33 * 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:44 * cielak - you will then flesh out the api.py docs 18:46:54 * mfisch - you will continue to grow our unit tests 18:47:05 * imbrandon - you will add ubuntu theming support to sphinx 18:47:19 * me - I will finish off the docs for the client side 18:47:25 jono: yup, just about done actually :) 18:47:35 * cielak - you will look at the syntax bugs in the daemon and I will fix this in battery 18:47:44 this should keep us busy until the next meeting 18:47:54 yeah, exactly ;) 18:47:59 awesome 18:48:07 also, I am expanding https://wiki.ubuntu.com/Accomplishments/GetInvolved/Hacking more and more where I can 18:48:14 so we can have good docs for new devs joining us 18:48:16 any other topics? 18:49:34 nope , not here 18:49:38 ok cool 18:49:39 jono: http://api.websitedevops.com/accomplishments-docs/ 18:49:47 does anyone lurking want to ask us anything? ;-) 18:49:52 imbrandon, haha! 18:49:54 nice! 18:50:06 needs some tweeks but its almost ready :) 18:50:14 imbrandon: oh, wow! 18:50:22 :) 18:50:31 * imbrandon loves web stuff 18:50:32 imbrandon, looks like there are a few tweaks that need to happen in there 18:50:35 a few layout issues 18:50:38 imbrandon, thanks so much 18:50:44 this is going to rock when we get this online 18:50:49 yup, its talored to juju docs now, but yea 18:50:56 imbrandon: rocking job man! 18:51:00 hour or two of touchups and it will rock 18:51:09 thanks imbrandon 18:51:11 heya bkerensa 18:51:13 np jono 18:51:16 any other questions, folks? 18:51:41 I guess we can wrap 18:51:52 thanks everyone for joining us, awesome meeting! 18:52:00 and as ever, we are in #ubuntu-accomplishments 18:52:02 jono, I might come back and ask for a summary though 18:52:12 thanks everyone, thanks jono! 18:52:13 gigix, this meeting will be logged 18:52:14 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)