[19:14] <elfy> balloons: so if I wanted to add for example xubuntu-core to the xubuntu bit of http://iso.qa.ubuntu.com/qatracker/milestones/315/builds
[19:14] <elfy> how would I do that
[19:18] <balloons> elfy, as a product?
[19:18] <elfy> or as a standalone thing
[19:19] <elfy> balloons: no idea really - never had to do much with the image tracker
[19:19] <elfy> mmm
[19:19] <elfy> actually it would be better if it was standalone if that's possible
[19:20] <elfy> balloons: basically we are doing a really basic xubuntu - the bones of the thing we're doing is https://sigma.unit193.net/~unit193/core.html
[19:20] <elfy> but we need to be able to test it and check results
[20:23] <balloons> elfy, so is it a new image then, or simply a new test for the minimal iso?
[20:23] <elfy> it uses the minimal then pulls our new package
[20:25] <elfy> didn't think about it like that actually - so it'll end up being a new testcase obviously - I don't think I can add what needs to be added product wise though
[20:26] <balloons> Yea, I don't want to arbitrarily create a new product either.. Might consider discussing it on -release
[20:26] <balloons> with a mail perhaps
[20:26] <elfy> mmm
[20:27] <knome> no new products please ;)
[20:27] <elfy> you know what - I'm rapidly losing interest
[20:27] <balloons> knome, lol.. I think I'd prefer to see it as a testcase
[20:29] <knome> a testcase or a "build"
[20:29] <elfy> if we get that far I'll just ask people on our mailing list where we've some control over what we need
[20:29] <knome> or a testsuite..
[22:14] <balloons> elopio, ping
[22:57] <elopio> balloons: pong. I'm not sure if it's the same topic as on the other chanel.
[23:10] <elopio> balloons, robotfuel: that's the problem when we try to follow style guidelines that are not on pep8
[23:10] <elopio> it's open to discussion
[23:10] <elopio> pep8 should cover every small detail :)
[23:11] <elopio> thomi: on autopilot, do you have a good reason for putting the closing parentheses on it's own line? or is just a preference?
[23:20] <thomi> elopio: pep8 gives you two options, this is one of them
[23:21] <thomi> elopio: I like the other option less.
[23:21] <thomi> elopio: so, yes, it's mandated by pep8, but there is another option, but I try and avoid it in AP
[23:23] <elopio> I think that brendan made a good point here
[23:24] <thomi> where?
[23:24] <elopio> for things that are not automatically checked by flake8, it doesn't make a lot of sense to try to enforce them blocking MPs.
[23:24] <thomi> elopio: well, that's up to the project manager. Personally, I'll block MPs to autopilot
[23:25] <thomi> but maytbe others aren't as picky as me
[23:25] <elopio> if pep8 lets the developer choose, I think that there's no good way to keep things fully consistent.
[23:25] <thomi> brendan has a good point, but in my experience I've found that it pays to be *more* picky with code contributions, not less
[23:26] <thomi> in fact: every single time I've thought "yeah, OK, I'll let this in... I don't like it, but it's probably good enough" I've regretted it later, and ended up making the changes myself.
[23:26] <thomi> every. single. time :)
[23:30] <elopio> thomi: yeah, I would prefer everything to be consistent. In that particular case, I find the other option prettier, but still prefer to follow a single rule.
[23:30] <elopio> however, here we are working with many more developers than autopilot
[23:30] <elopio> we can't make all the reviews, nor change everything later.
[23:31] <thomi> elopio: indeed
[23:32] <thomi> for something as trivial as the parenthesis indentation rules, it probably doesn't matter.
[23:32] <thomi> for structural things though, I'd encourage you to be picky
[23:32] <thomi> especially since, if you can explain clearly why you're being picky, you're training the developers at the same time
[23:33] <elopio> balloons: robotfuel: on the sudoku app I'm following the autopilot convention because I had already started after Chris' comment.
[23:33] <elopio> but I think that we should embrace incosinstency in this case.
[23:33] <elopio> thomi: any examples of those structural things?
[23:33] <thomi> elopio: like injecting dependencies in functions rather than hard-coding the call chain, for example
[23:34] <thomi> elopio: or like a class that does more than one thing, or the use of inheritance where composition is more appropriate
[23:34] <thomi> things like that.
[23:35] <elopio> thomi: ok, yes, with that we should be as strict as possible.
[23:36] <elopio> I'll keep the dependencies in mind. As we don't usually unit test the test helpers, I sometimes forget about the dependencies.