14:02:55 <tflink> #startmeeting fedora-qadevel
14:02:55 <zodbot> Meeting started Mon Jun 15 14:02:55 2015 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:55 <tflink> #meetingname fedora-qadevel
14:02:55 <tflink> #topic Roll Call
14:02:55 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:03:03 <tflink> #chair kparal mkrizek jskladan
14:03:03 <zodbot> Current chairs: jskladan kparal mkrizek tflink
14:03:05 * jskladan tips his hat
14:03:05 * mkrizek is here
14:03:10 * kparal is here
14:04:10 <tflink> anyone want to go first for status updates?
14:04:24 <mkrizek> I can
14:04:32 <mkrizek> #topic mkrizek status report
14:04:46 <mkrizek> #info sent a patch changing log locations
14:04:46 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/T495
14:04:46 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/D382
14:04:46 <mkrizek> #info sent a patch adding distgit directive
14:04:46 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/T492
14:04:49 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/D383
14:04:51 <mkrizek> #info sent a patch adding fedmenu to blockerbugs
14:04:54 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/T466
14:04:56 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/D388
14:04:59 <mkrizek> #info sent patch  fixing "Provided Variables" in docs
14:05:01 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/T497
14:05:04 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/D391
14:05:06 <mkrizek> #info created a ticket for sorting artifacts date directories
14:05:09 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/T498
14:05:11 <mkrizek> #info still have some open reviews to be completed
14:06:10 <kparal> lots of patches! thanks
14:06:47 <tflink> thanks
14:07:06 <tflink> any other comments/questions?
14:07:21 <kparal> the log location will probably be lots of fun to come yet
14:07:32 <kparal> no questions
14:07:59 <tflink> yeah, there's been a bit of discussion in that review :)
14:08:18 <tflink> who's next?
14:08:25 <kparal> #topic kparal status report
14:08:32 <kparal> #info lots of reviews
14:08:36 <kparal> #info proposed config/cli/formula changes wrt disposable clients
14:08:36 <kparal> #link https://phab.qadevel.cloud.fedoraproject.org/T408
14:08:42 <kparal> #info investigated nested virt and whether it would work for our purposes (part of T408)
14:09:06 <kparal> feedback to T408 appreciated
14:09:37 * mkrizek puts looking at T408 on his todo list
14:09:44 <tflink> same here
14:10:06 <kparal> great, thanks. that's it from me
14:10:21 <tflink> k, thanks
14:10:53 <tflink> jskladan: you and I are left :)
14:10:59 <jskladan> #topic jskladan status update
14:10:59 <jskladan> #info T468/D387 depcheck: create per-build and per-update artifacts (will merge today)
14:10:59 <jskladan> #info T470/D389 allow checks to provide URLs for their specific per-build/update logs from artifactsdir (provided hopefuly passable version today)
14:10:59 <jskladan> #info PEP8-compliant-ish libtaskotron
14:10:59 <jskladan> #link https://phab.qadevel.cloud.fedoraproject.org/differential/diff/1036/
14:11:34 <tflink> I can't believe I missed that depcheck review - didn't notice it until about an hour ago :-/
14:12:12 <tflink> oh, cool. i didn't realize that you had made the diff for that already
14:12:15 <kparal> jskladan: have you posted the pep8 diff somewhere as well? I don't see it int the mailing list thread
14:12:53 <mkrizek> er, making libtaskotron PEP8-compliant will screw up git history (git blame), won't it :/
14:13:09 <tflink> pretty much, yeah
14:13:12 <jskladan> kparal: not yet, it is just after the autopep8 run and has ton of pep8 errors too
14:13:29 <kparal> so it is not pep8 compliant
14:13:38 <jskladan> read! compliant-ish
14:13:43 <mkrizek> :D
14:13:50 <kparal> alright
14:14:03 <jskladan> but the errors are just E501 and E402
14:14:20 <jskladan> E501 line too long
14:14:28 <jskladan> E402 module level import not at top of file
14:14:37 <kparal> the first one is quite crucial
14:14:52 <kparal> and heh, the second one we can't avoid in some places (cyclic deps) :)
14:15:02 <jskladan> and most of the 501s are (80 > 79 characters)
14:15:10 <kparal> ok
14:15:50 * tflink has code style marked for a topic later on, we can do it here or later on
14:16:12 * kparal votes for never
14:16:20 <kparal> was that a choice?
14:16:29 <tflink> :-P
14:17:00 <jskladan> kparal: don't be a naughty child, with autopep8, my only problem with pep8 is line length (no more "how to make the linter like me?" hours!)
14:17:16 * kparal will look at that diff
14:18:25 <jskladan> any questions apart of the pep8 stuff?
14:18:35 <mkrizek> nothing here
14:18:45 <kparal> nope
14:18:48 <tflink> me neither
14:19:01 <tflink> #topic status report - tflink
14:19:01 <tflink> #info more futzing with beaker.stg, networking issues appear to be worked out for now
14:19:01 <tflink> #info slight progress on testCloud, waiting for review, should have a new release soon
14:19:01 <tflink> #info a few reviews, started to do some overdue ticket cleanup
14:19:01 <tflink> #info looking into running taskotron with arm clients
14:20:13 <tflink> any questions/comments/mocking?
14:20:15 <kparal> do we want to run on arm soon?
14:20:31 <tflink> the question came up again last week
14:20:38 <tflink> we probably should, since arm7 is PA
14:20:54 <tflink> and I suspect that aarch64 isn't too far off
14:21:38 <tflink> the problem I'm worried about is figuring out which arm hosts can support virt
14:21:53 <tflink> but I guess we'll cross that bridge if/when we get there
14:22:01 <kparal> does qemu emulate it reasonably now? because otherwise it's going to be hard to develop for it
14:22:24 <tflink> AFAIK, it works but I don't know how slow it is
14:22:58 <kparal> it was very slow a year back or so
14:22:59 <tflink> yeah, I still don't understand which get-able arm boards support virt
14:23:21 <tflink> i found one ... that's completely sold out
14:23:58 <tflink> it's possible that some chromebooks might support virt
14:24:08 <pwhalen> tflink, kparal i can assist there.. internal host like midway, dev boards like cubietruck, banana pi support virt
14:24:42 <pwhalen> chromebook arent supported yet, i know a remix is in the works for the 2012 version
14:24:43 <tflink> pwhalen: ok, thanks. I was told that cubietruck may support virt but otherwise, A15 would be the way to go
14:25:12 <tflink> pwhalen: btw, which cubie? I'm a bit lost on which cubieboard the cubietruck is - I think it's the cubieboard3
14:25:21 <pwhalen> cubietruck does for sure, as does the banana pi (same SoC)
14:25:53 <tflink> ok, so the A20 supports virt? good to know
14:25:55 <pwhalen> cubietruck is the cubie3, yes..
14:25:57 <pwhalen> right
14:26:59 <pwhalen> performance isnt fantastic on the small boards with little ram, but on enterprise hw like midway it should be better..
14:27:03 * tflink has more questions but suspects right now and right here isn't the best place :)
14:27:15 <tflink> i thought that the infra arm hosts were highbank
14:27:40 <pwhalen> they are, but there are some internal midway hosts
14:27:57 <pwhalen> which are likely idle-ish
14:28:37 <tflink> ok, I'll follow up outside the meeting. for now, I was mostly interested in getting my hands on some arm machine to see if our current dev work even ran on ARM hosts
14:29:18 <tflink> any other questions/comments?
14:29:20 <pwhalen> sounds good, thanks for looking at it
14:30:06 <tflink> pwhalen: np, hopefully we can get something figured out before long
14:30:12 <tflink> ok, moving on
14:30:20 <tflink> #topic planning - code style
14:30:27 <tflink> everyone's favorite topic
14:30:53 <tflink> #info jskladan posted a first runthrough of autopep8 on the libtaskotron codebase: https://phab.qadevel.cloud.fedoraproject.org/differential/diff/1036/
14:31:18 <tflink> my primary concern about doing that right now is the mess it could/would create with the develop/disposable-devlop branch split
14:31:31 <tflink> typos aside :)
14:32:14 <tflink> #info the main idea is to have a coding standard and not spend eternity debating over what set of rules is "best"
14:32:39 <tflink> it sounds like there is general support for the concept, am I misreading/misrepresenting?
14:33:01 <kparal> I can't say I support strict pep8 enforcement
14:33:04 <tflink> or did we lose everyone in the ARM side conversation
14:33:12 <tflink> kparal: alternatives?
14:33:27 <tflink> that don't require large amounts of customization and/or discussion
14:33:54 <kparal> I think it worked quite well up to this point, no need to change anything. and then, from one case of a few lint warnings, we have this discussion again
14:34:22 <kparal> just fix the spaces between the keyvals and go on
14:36:05 <jskladan> I have few problems with pep8 - one perceived, and one actual. The perceived problem is the code's tendency to "go right" (proved wrong by the autopep run), and the sometimes weird line-breaking/indenting rules (aka "how the heck should I make the linter shut up and eat my code"). autopep8 removes that problem (and most of my issues) automagically, so it is a big win for me here.
14:36:59 <kparal> furthermore, I really don't want to read code as the one jskladan cited in the email. I value readability, not adherence to some guideline
14:37:15 <kparal> jskladan: does that mean that pep8 doesn't enforce the code to be structured as you cited in the email?
14:37:52 <jskladan> kparal: see for yourself, it IMHO does not
14:38:02 <tflink> kparal: I don't think it's _that_ bad
14:38:12 <kparal> I'll have to play with it a little, until I know what pep8 actually enforces and what not
14:38:41 <jskladan> tflink: kparal: the thing in the email is IMHO quite bad
14:38:57 <jskladan> but it can be done differently, as shown by autopep
14:39:28 <tflink> the thing in the email?
14:40:05 <jskladan> tflink: the code cited in the email
14:41:03 <kparal> I have one further point - the productivity argument is false, because we spend now much less time arguing about style in reviews (except for this one) than we will spend in the future reformatting the code until pep8 is satisfied
14:41:24 <tflink> kparal: so we fix things as we touch the code
14:41:31 <kparal> I mean new code
14:41:33 <tflink> I really don't see how it would waste that much time
14:41:54 <tflink> kparal: switch editors to something that can check pep8 as you write
14:42:03 <kparal> I write it, arc diff will complain, I fix it, it will complain again, ... until it if "fixed"
14:42:12 <tflink> kparal: switch editors to something that can check pep8 as you write
14:42:26 <mkrizek> kparal: or arc lint?
14:42:27 <kparal> tflink: that is still more work than just writing and making sure it's readable, without counting indentation
14:42:34 <tflink> or write an extension for $editor-of-choice
14:42:35 <kparal> mkrizek: yes, or that
14:42:51 <tflink> kparal: until you get used to the style rules
14:43:07 <kparal> I use spyder and it has pyflakes integration. I had to disable pep8 integration because it was driving me crazy
14:43:25 <jskladan> kparal: once again - autopep IMHO makes this a moot point - no need to get your hands dirty, run a handy-dandy script
14:43:46 <jskladan> you can even specify the lines, on which to run it
14:43:50 <kparal> I'm not saying it can't be done. but it's not "less work" in my eyes
14:43:58 <kparal> it's more work
14:44:04 <tflink> in the short term, maybe
14:44:10 <tflink> in the long term, I don't think so
14:44:28 <jskladan> *shrugs* I don't really see it that way
14:44:52 <tflink> jskladan: which way?
14:44:56 <jskladan> but I can put the effort in making a git-commit hook, that will run it for you
14:45:08 <jskladan> tflink: /me is too slow - i don't think it is "more work"
14:45:16 <jskladan> if a tool does it for you
14:45:22 <tflink> ok, wasn't sure. thanks for clarifying
14:45:43 <kparal> if everyone wants it, I'll not oppose it. but for me, I don't see it worth the time, quite the opposite
14:46:26 <jskladan> tflink: my bad, no worries
14:47:09 <tflink> it sounds like we're getting closer to a conclusion :)
14:47:25 <tflink> the remaining objection is the 79 char length restriction?
14:47:57 <mkrizek> are we talking using autopep now or fixing as we go conclusion?
14:48:15 * tflink would prefer fixing it as we go
14:48:24 <kparal> I liked jskladan's link, especially point 1 in there: https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
14:49:05 <kparal> so while I can see some benefit in having a consistent style, I don't believe in "0 exceptions" rule
14:49:08 * tflink fails to see how that is against what he's proposing
14:49:17 <tflink> I never said "0 exceptions"
14:49:19 <kparal> 0 exceptions rule was proposed
14:49:28 <tflink> i said no exceptions unless it's needed
14:49:38 <kparal> " - no code be accepted with lint errors unless there is absolutely no
14:49:38 <kparal> other way to get around it"
14:49:41 <tflink> meant to say, anyways
14:50:19 <mkrizek> I am afraid that if we allow some exceptions that there will be discussions about those exceptions :) (I am not saying I want 0 exceptions)
14:50:23 <tflink> i don't want to spend time arguing about what's more readable and what's worth ignoring lint errors for
14:50:37 <tflink> ie, pretty much what mkrizek said
14:50:39 <tflink> :)
14:50:44 <kparal> so it is 0 exceptions
14:50:51 <tflink> no, it's not
14:51:09 <tflink> stuff like the import error for solving cyclic deps is not a problem
14:51:34 <tflink> but a "default to no exceptions and minimize discussion/debate about it"
14:52:10 <kparal> what I don't understand is why it is so important. the important part is readability, not style compliance. why should we debate over linter warnings which make the code more readable?
14:52:31 <kparal> example
14:52:33 <kparal> https://phab.qadevel.cloud.fedoraproject.org/file/data/yar3gaju7rtjcsn33bjk/PHID-FILE-lvpsyhkk3czoi2t54zu3/D389_rdb-directive_lintfixes.diff
14:52:36 <tflink> proposed: s/make the code more readable/make the code more consistent/
14:52:42 <kparal> "TAP is OK." line and below
14:52:52 <kparal> it doesn't make sense to wrap them, it's the documentation
14:52:59 <kparal> it's unreadable wrapped
14:53:19 <kparal> it makes sense to trip the [libtaskotron .... ] part , that would be great
14:53:25 <kparal> but it doesn't make sense to wrap it
14:53:39 <kparal> so, will we enforce pep8 there? and what's the benefit?
14:53:47 <tflink> consistency
14:53:54 <kparal> and what's the benefit?
14:54:08 <kparal> because I see consistency as a way to readability
14:54:24 <kparal> that's the goal for me, not consistency
14:54:29 <tflink> they're related, sure. not quite the same thing
14:55:01 <kparal> s/trip/trim
14:55:28 * tflink proposes that we move this back to the list since the qa meeting starts in 5 minutes
14:55:31 <mkrizek> I guess most of the problems would come from line length and so we can make line length an exception?
14:55:41 <tflink> in flake8, yes
14:55:55 <tflink> yes we can, rather
14:56:46 <jskladan> kparal, tflink - this specific issue (line length in a documentation), I think is the exact "minimal place for discussion"
14:57:06 <tflink> #info farther discussion on qadevel@, hopefully not a debate until the end of known time :)
14:57:25 <mkrizek> jskladan: +1
14:57:37 <jskladan> :D
14:57:55 <tflink> if line length is the big issue, I'm not going to fight the strict 79 char width so long as we can set a width and adjust tooling
14:58:02 <tflink> but trying to move on to ...
14:58:13 <tflink> #topic planning - tasks
14:58:31 <jskladan> but if we all could agree on PEP8/{E501}, and "reasonable line length for code", that has my full support, if need be
14:58:31 <tflink> is anyone needing tasks or does everyone have enough for this week?
14:58:52 <jskladan> I could do with some
14:59:10 <jskladan> guessing that the D289 won't take long to accept
14:59:39 * mkrizek still has stuff to do
14:59:56 <jskladan> just as a note - I'm going on PTO Friday[this week]->Thursday[next week]
15:00:08 <tflink> ah, good to know
15:00:12 <kparal> jskladan: I think there are some follow up tasks after T470 is done, if you want
15:00:41 <kparal> written at the end of the ticket
15:00:50 <jskladan> kparal: sure, gladly. If there are no other pressing matters
15:01:00 <kparal> not sure about that
15:01:03 * tflink could probably use a bit of help on the disposable clients - it's not getting finished as quickly as I'd like :-/
15:01:26 <tflink> hoping for a testCloud release this week, though
15:02:12 <mkrizek> tflink: as soon as I am finished with my ongoing tasks, I can help
15:02:32 <tflink> we can sync up after the meeting though
15:03:04 <tflink> #info pester tflink if anyone runs out of tasks to do :)
15:03:17 <tflink> since we're over time and the qa meeting has started ...
15:03:21 <tflink> #topic open floor
15:03:26 <tflink> anything else to bring up quickly?
15:03:36 <kparal> not here
15:03:58 <mkrizek> nope
15:04:01 <tflink> ok, I'll send out minutes shortly
15:04:16 <tflink> apologies for cutting off discussion a bit
15:04:20 <tflink> #endmeeting