| === 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 | ||
| 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:14 |
| balloons | elfy, as a product? | 19:18 |
| elfy | or as a standalone thing | 19:18 |
| 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:19 |
| 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 | 19:20 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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.. | 20:29 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| balloons | elopio, ping | 22:14 |
| elopio | balloons: pong. I'm not sure if it's the same topic as on the other chanel. | 22:57 |
| 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:10 |
| 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:11 |
| thomi | elopio: pep8 gives you two options, this is one of them | 23:20 |
| 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:21 |
| elopio | I think that brendan made a good point here | 23:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:30 |
| thomi | elopio: indeed | 23:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| elopio | thomi: ok, yes, with that we should be as strict as possible. | 23:35 |
| elopio | I'll keep the dependencies in mind. As we don't usually unit test the test helpers, I sometimes forget about the dependencies. | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!