[00:00] <barry> #startmeeting
[00:00] <MootBot> Meeting started at 18:00. The chair is barry.
[00:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[00:00] <barry> jml, rockstar, mwhudson hi!
[00:01] <mwhudson> barry: hello
[00:01] <rockstar> Hi barry
[00:01] <jml> hi
[00:01] <barry> so, shall i do a quick update from ameu?
[00:01] <jml> yes please
[00:02] <barry> there was no ui meeting on monday, so nothing to report there
[00:02] <barry> * `__iter__()` in model objects?
[00:02] <barry> we agreed that __iter__ should be avoided except in the case of IFnordSets iterating over IFnords
[00:02] <barry> i should say "except possibly"
[00:02] <barry> no mandate, but it's okay
[00:03] <jml> what was the reasoning?
[00:03] <barry> for things that aren't naturally collections, it's hard to know from looking at the call site what you're iterating over
[00:04] <barry> cprov had a specific example that came up in a review and __iter__() just made things harder to understand
[00:04] <barry> * mkstemp()/open() combination leaks file-descriptors
[00:05] <barry> reviewers have to watch out for these calls when the code does not clearly close the open fd they return
[00:05] <rockstar> Ah yes.  I reviewed a fix for this last week.
[00:05] <barry> general call for questioning the opening/leaking of resources
[00:05] <barry> when you see it in a review, make sure that the resource is being closed
[00:06] <jml> barry, one nice workaround in test code is to have a wrapper method that calls mkstemp and then calls addCleanup appropriately
[00:06] <jml> and then returns what mkstemp returns
[00:06] <barry> jml: right.  that was brought up (or something along those lines)
[00:06] <jml> naturally, that won't stop prod leaks
[00:07] <barry> flacoste suggested using mkdtemp  and then creating files as needed in the directory, blowing the whole dir away in the cleanup
[00:08] <jml> I tend to do that.
[00:08] <barry> yep
[00:08] <barry> * Guidelines changes for tests checking systems pre-requisites (specific umasks, app configurations)
[00:09] <barry> this came up because maxb got bit by a umask sensitivity in the tests
[00:09] <barry> and i remembered fixing a bunch of these ages ago when i first joined
[00:09] <barry> (cause my umask isn't 022)
[00:10] <barry> the general rule is, if the code requires a specific umask, then put it in the code and test for it, otherwise fiddle the umask in the test
[00:10] <barry> the general guideline is, don't assume the user env is the default ubuntu user env
[00:10] <jml> ok.
[00:10] <mwhudson> i guess the hard part is that most of the time you won't realize you're depending on the umask
[00:10] <mwhudson> but it's a good principle i guess
[00:11] <barry> mwhudson: right.  i think in general we're pretty good right now.  maxb found one failing test in archives which was checking a file perm, and thus relying on umask
[00:11] <mwhudson> oh right
[00:11] <barry> * Invalid markup; The