=== chihchun is now known as chihchun_afk === _salem is now known as salem_ === chihchun_afk is now known as chihchun === salem_ is now known as _salem === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === vrruiz_ is now known as rvr === chihchun is now known as chihchun_afk === _salem is now known as salem_ === charles_ is now known as charles === chihchun_afk is now known as chihchun === DanChapman|afk is now known as DanChapman === Ursinha-afk is now known as Ursinha === chihchun is now known as chihchun_afk === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === roadmr is now known as roadmr_afk === Ursinha-afk is now known as Ursinha === roadmr_afk is now known as roadmr [19:14] 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] how would I do that [19:18] elfy, as a product? [19:18] or as a standalone thing [19:19] balloons: no idea really - never had to do much with the image tracker [19:19] mmm [19:19] actually it would be better if it was standalone if that's possible [19:20] 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] but we need to be able to test it and check results [20:23] elfy, so is it a new image then, or simply a new test for the minimal iso? [20:23] it uses the minimal then pulls our new package [20:25] 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] Yea, I don't want to arbitrarily create a new product either.. Might consider discussing it on -release [20:26] with a mail perhaps [20:26] mmm [20:27] no new products please ;) [20:27] you know what - I'm rapidly losing interest [20:27] knome, lol.. I think I'd prefer to see it as a testcase [20:29] a testcase or a "build" [20:29] 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] or a testsuite.. === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [22:14] elopio, ping [22:57] balloons: pong. I'm not sure if it's the same topic as on the other chanel. [23:10] balloons, robotfuel: that's the problem when we try to follow style guidelines that are not on pep8 [23:10] it's open to discussion [23:10] pep8 should cover every small detail :) [23:11] 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] elopio: pep8 gives you two options, this is one of them [23:21] elopio: I like the other option less. [23:21] elopio: so, yes, it's mandated by pep8, but there is another option, but I try and avoid it in AP [23:23] I think that brendan made a good point here [23:24] where? [23:24] 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] elopio: well, that's up to the project manager. Personally, I'll block MPs to autopilot [23:25] but maytbe others aren't as picky as me [23:25] if pep8 lets the developer choose, I think that there's no good way to keep things fully consistent. [23:25] 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] 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] every. single. time :) [23:30] 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] however, here we are working with many more developers than autopilot [23:30] we can't make all the reviews, nor change everything later. [23:31] elopio: indeed [23:32] for something as trivial as the parenthesis indentation rules, it probably doesn't matter. [23:32] for structural things though, I'd encourage you to be picky [23:32] especially since, if you can explain clearly why you're being picky, you're training the developers at the same time [23:33] balloons: robotfuel: on the sudoku app I'm following the autopilot convention because I had already started after Chris' comment. [23:33] but I think that we should embrace incosinstency in this case. [23:33] thomi: any examples of those structural things? [23:33] elopio: like injecting dependencies in functions rather than hard-coding the call chain, for example [23:34] elopio: or like a class that does more than one thing, or the use of inheritance where composition is more appropriate [23:34] things like that. [23:35] thomi: ok, yes, with that we should be as strict as possible. [23:36] I'll keep the dependencies in mind. As we don't usually unit test the test helpers, I sometimes forget about the dependencies.