shang | jimbaker: yes we did :) | 02:02 |
---|---|---|
=== daker_ is now known as daker | ||
_mup_ | ensemble/security-acl r291 committed by kapil.thangavelu@canonical.com | 14:32 |
_mup_ | an acl abstraction allowing grants/removals by principal name on nodes | 14:32 |
SpamapS | shhhhhhhhhhhhhhhhhhhhhhh | 17:14 |
jimbaker | SpamapS, yes quiet. heads down all around i guess | 17:20 |
SpamapS | thats a very good thing. :) | 17:24 |
Aram | hi. | 18:11 |
Aram | happen to know where niemeyer or robbiew are? :-). | 18:13 |
jimbaker | Aram, robbiew is on vacation; niemeyer is at a conf | 18:16 |
Aram | thanks. | 18:17 |
adam_g | jimbaker: is there a PPA somewhere that contains your hookProtocol fix? | 18:23 |
jimbaker | adam_g, no, i could push the branch however. still needs some more testing btw | 18:24 |
jimbaker | adam_g, then you can just use environments.yaml to use that branch, using the ensemble-branch option | 18:24 |
adam_g | jimbaker: that sounds doable. where is the branch? | 18:25 |
jimbaker | adam_g, just pushed it to lp:~jimbaker/ensemble/robust-hook-exit | 18:26 |
jimbaker | adam_g, hope that works for you! | 18:26 |
adam_g | jimbaker: great, thanks ill give it a shot later | 18:27 |
jimbaker | adam_g, cool | 18:27 |
=== daker is now known as daker_ | ||
adam_g | well, openstack via ensemble is coming together quite nicely: http://paste.ubuntu.com/650191/ | 19:49 |
adam_g | you have anyway of turning that into a graph, SpamapS ? | 19:49 |
=== franciscosouza_ is now known as franciscosouza | ||
SpamapS | adam_g: yes! | 20:07 |
SpamapS | adam_g: ensemble status --format=svg --output=file.svg will produce something.. | 20:07 |
SpamapS | adam_g: if you use the branch I made yesterday you can try out a few different layouts (fdp seems the most consistently useful) | 20:08 |
adam_g | neat | 20:08 |
SpamapS | adam_g: lp:~clint-fewbar/ensemble/dot-raw-output | 20:11 |
SpamapS | if you use tha tone you can do ensemble status --format=dot | fdp -Tsvg > file.svg | 20:11 |
SpamapS | adam_g: and btw, w00t. | 20:11 |
RoAkSoAx | any ensemble core dev around? | 21:26 |
SpamapS | hmm.. new analogy for what Ensemble is.. | 22:09 |
SpamapS | Ensemble is to config management as Home Depot is to your toolbox at home. | 22:09 |
adam_g | SpamapS: when you get into town? | 22:13 |
SpamapS | adam_g: Thursday morning | 22:24 |
SpamapS | adam_g: I unfortunately have 3 other family obligations M,T, and Wed.. :-/ | 22:24 |
SpamapS | adam_g: and Fri night.. so leaving around 6pm Friday. :-P | 22:24 |
fwereade | hi all | 22:41 |
fwereade | I need a quick second opinion about test coverage | 22:42 |
fwereade | you may or may not be aware that there's a problem in trunk, with certain tests that fail or timeout depending on the absence or flakiness of the network | 22:43 |
fwereade | it emerges that there was a commented-out line in the mocking setup, and that reinstating it (with a minor tweak) fixes the issue | 22:43 |
fwereade | however, doing this leaves the coverage only *slightly* improved | 22:45 |
fwereade | please confirm that the appropriate response is to write the necessary battery of additional tests | 22:45 |
fwereade | and that just reinstating the tweaked line is a pitiful and weaksauce dodge of the real issue, that I should be ashamed of myself for considering | 22:46 |
SpamapS | fwereade: tests that work w/o the network are critical.. eventually we want the Ubuntu buildd's to run the test suite .. and they have no network connectivity. | 22:58 |
fwereade | SpamapS: agreed | 22:59 |
fwereade | SpamapS: the question is, do I reinstate weak tests that work without a network or do I write a bunch more that also work without the network, and give us better coverage? | 22:59 |
SpamapS | fwereade: so I'd say that if you have the time to do the additional testing.. it is a noble and high cloud that awaits you in programmer heaven. But if you are pressed for time.. making the tests run w/o the network would get the tests run more often, which may be more important. | 22:59 |
fwereade | SpamapS: cheers, I won't spend too much time on it | 23:00 |
SpamapS | Do we graph test coverage anywhere? | 23:00 |
fwereade | SpamapS: but I'll have a go at least ;) | 23:00 |
fwereade | SpamapS: not that I'm aware of, but that would be interesting | 23:00 |
SpamapS | My last employer had a graph over time of test coverage. Bonuses were attached to significant increases. | 23:01 |
SpamapS | Which did very little for the graph going up.. because programming isn't motivated by the carrot and stick. | 23:01 |
SpamapS | Still, the graph was quite interesting when drilling down into a specific subsystem.. you knew how risky the change was.. | 23:02 |
fwereade | SpamapS: that's a shame | 23:22 |
fwereade | SpamapS: even if the carrot itself wouldn't work, perhaps they hoped that being seen to care about such things might be a sort of, er, motivational meta-carrot | 23:23 |
fwereade | SpamapS: ...as it were | 23:23 |
SpamapS | fwereade: well certainly, new stuff got more tests because you didn't want the percentage to go *down* | 23:34 |
bcsaller | there is a `make coverage` target which will generate a table | 23:42 |
SpamapS | So in theory, we could run back through all the commits and run it for each one, and graph that, and then do that on an ongoing basis? | 23:48 |
SpamapS | bcsaller: did I see service config settings land this week? | 23:54 |
bcsaller | SpamapS: yeah, there is still an approved branch I have to merge for `deploy` but the `set` version of things work. I expect the other will go in today and it will be ready | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!