17:12:49 #startmeeting fedoraqa-devel 17:12:49 Meeting started Mon Jan 13 17:12:49 2014 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:12:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:12:49 #meetingname fedoraqa-devel 17:12:49 The meeting name has been set to 'fedoraqa-devel' 17:12:50 #topic Roll Call 17:13:01 * Viking-Ice here 17:13:02 aqui 17:13:29 * kparal is here 17:13:38 * mkrizek is here 17:14:24 pschindl: ping 17:14:31 * roshi is here 17:14:36 * pschindl is here 17:14:47 let's wait a few minutes for folks to show up since my schedule-fu seems to be completely off today 17:14:52 ahoyhoy 17:17:12 ok, I think we have most of the folks I was expecting 17:17:23 kparal: any idea if jskladan is planning to attend? 17:17:36 I was about to ask the same :) 17:17:40 I don't know 17:18:43 I suspect not at this point, I'll have to sync up with him later, I guess 17:19:29 #topic Taskotron Status 17:19:46 pretty much picking up where we left off last week 17:19:51 as a reminder 17:20:07 #info Taskotron Phase 1 is due to be delivered 2014-03-01 17:20:35 #link https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan#Phase_1:_AutoQA_Replacement 17:21:38 phase 0 is mostly complete, tickets need a bit of updating, still 17:21:46 #info phase 0 is mostly complete, tickets need a bit of updating, still 17:21:52 so, what about depcheck? 17:21:54 #link https://phab.qadevel.cloud.fedoraproject.org/T7 17:22:40 * tflink is almost done with the notifications stuff, needs to get a couple of fedmsg things figured out - will pester threebean about it later today 17:22:40 I guess I could try to write something dead simple based on repoclosure 17:22:55 kparal: handsome_pirate has been working on it 17:23:50 How long has this been going? 17:23:54 a few minutes 17:24:00 So, I haven't missed much? 17:24:03 nope 17:24:07 handsome_pirate: do you have some depcheck-ng news? 17:24:08 Coolio 17:24:14 handsome_pirate, just everything important 17:24:20 lol 17:24:26 kparal: Give me a sec 17:24:34 so much for my plan 17:24:35 handsome_pirate, oh we also signed you up for bunch of stuff 17:24:37 but we can do this now 17:24:47 #topic Depcheck rewrite status 17:25:00 tflink: feel free to organize the meeting according to you, not us :) 17:25:30 https://bitbucket.org/fedoraqa/depcheck-mk-2 17:25:38 depcheck mk 2 lives there 17:25:45 * handsome_pirate needs to do another push 17:26:02 It's based on libsolv for the actual dependency solving back end, same as dnf 17:26:21 handsome_pirate: have you gone through the depcheck scenarios yet to make sure it passes? 17:26:30 Unlike the original depcheck, I'm not twisting it to do my bidding, but, rather, using it the way it is meant to be used 17:26:38 tflink: About half of them 17:26:53 tflink: Most of them it passes; three did not 17:27:08 I'm working on those three before I continue 17:27:17 Two were conflicts related 17:27:20 any guesses on eta? 17:27:20 do we have a link for those scenarios? 17:27:36 kparal: https://bitbucket.org/fedoraqa/depcheck_scenarios 17:27:38 #info initial depcheck scenarios have been coded up 17:27:44 #link https://bitbucket.org/fedoraqa/depcheck_scenarios 17:27:50 tflink: Friday is my goal for my next major git push 17:28:32 tflink: One of the failures looks to be with libsolv; I'm working on that, as well 17:28:44 The other two need to be handled with some logic in depcheck 17:28:53 did you ever attempt integration with the runner demo code? 17:29:19 I have started, but need to finish 17:29:41 I'll try to get that done by Friday, as well 17:29:58 #info current depcheck-mk-2 code is passing some of the depcheck scenarios, rest are being worked on 17:30:27 better progress than I expected, good :) 17:30:42 as a side note, f18 goes eol tomorrow IIRC 17:30:55 current autoqa depcheck doesn't run on anything newer than f18 17:31:11 Yeah, I had twelve hours riding a train this past weekend to work on this 17:31:13 but we should be OK leaving the test clients at f18 for a little while 17:31:29 tflink: I guess, or disable the test completely 17:31:30 er, autoqa test clients 17:31:40 eh, it works as well as it's ever worked 17:32:34 handsome_pirate: any additional things that you want to add for depcheck? 17:32:37 Once I get through all the scenarios and get it so it runs as a taskotron task, I'm going to work on getting proper output 17:33:04 My plan for next week is to work on outputting tap 17:33:14 handsome_pirate: unit tests and documentation? 17:33:28 I guess I should start working on them, as well 17:33:51 Docs at this point are a somewhat outdated README stub and if you run depcheck -h 17:34:17 I do run it through pylint every once in a while and fix the biggest complaints 17:34:45 good to hear 17:34:57 any other updates? 17:35:05 That's it for right now 17:35:12 ok, let's move on 17:35:15 I have the next two weeks of work fairly well mapped out 17:35:32 #topic Documentation 17:36:11 I think it became pretty clear to me and everyone else that I'm a bit farther behind on documentation (design docs and usage) than I thought I was 17:36:40 I wanted to cover the things that aren't waiting on me for docs first, to make sure they got covered and this is one 17:36:54 roshi has volunteered to look into documentation systems for taskotron 17:37:09 * roshi waves 17:37:11 #link https://phab.qadevel.cloud.fedoraproject.org/T39 17:37:20 #chair kparal roshi 17:37:20 Current chairs: kparal roshi tflink 17:37:42 tflink: If this is the case, should I hold off on too much docs for depcheck so I can be sure to match the rest of taskotron? 17:37:51 the idea is to have a system for building docs that can be run from CI and can work for all types of docs we need 17:38:02 I'll help with doc writing where I can...just point me to a task 17:38:03 yeah we need to keep this update for at least baseWG which probably will be the only valid WG effort 17:38:07 handsome_pirate: if you write it in generic ReSt, it should be OK 17:38:07 handsome_pirate: if you write them in md, rst then there shouldn't be an issue 17:38:17 Roger 17:38:20 I'll ping you danofsatx :) 17:38:31 roshi: I realize you just started, but any updates? 17:38:47 or guesses on when you might have something to show? 17:38:57 the Docs team is also addressing this issue of how to get shorter tutorials and whatnot - so I'm hoping we can integrate with them easy 17:39:15 looking into dexy (http://dexy.it) right now 17:39:26 outside wiki content? 17:39:31 it seems to fit what we're looking for 17:39:32 yeah 17:39:42 wiki is great for some things, but not all 17:39:43 it says sexy there on top good enough tool for me 17:39:49 haha 17:40:01 #info roshi is looking into using dexy 17:40:09 #link http://dexy.it 17:40:15 has it been packaged for the distro? 17:40:19 lol 17:40:40 it's in pip 17:41:02 if we need a fedora package for it - I would be interested in that (never done that before) 17:41:02 I thought we had to ship that ourselves 17:41:07 eventually, we will be populating qadevel with docs for qadevel projects 17:41:32 tflink: perhaps it's a good idea to go over the vision for qadevel docs and whatnot 17:41:45 yeah, we'd eventually need to have any tool packaged 17:41:51 any tool we use 17:41:56 I would prefer we have unified documentation for QA community in general 17:42:11 roshi: you want to go over that or should I? 17:42:12 so if doxy is the future I think we should move all doc from the wiki to that 17:42:21 as would I Viking-Ice 17:42:32 sure, as far as I know it :) 17:42:43 we can discuss that, but I'm not sure that we really need to be moving everything out of the wiki 17:42:53 we -> wider qa community, not just the folks here 17:43:10 right but fragmented way is not the way to go 17:43:14 with taskotron and other projects coming down the pipe for qa devel we will have a need for more and more "getting started" and tutorial documentation for all the tools 17:43:21 so one landing place one documentation place etc 17:43:40 I'll get there in a second Viking-Ice - but you're right 17:43:48 Viking-Ice: I don't see the problem with using different tools for different purposes if that ends up making sense 17:44:17 we need a tool that docs can be written along with the code for the project, something that's easy to write and easy to integrate into CI 17:44:19 tflink, you dont want to have our community members running around half the internet to start participating 17:44:26 dexy fits that pretty well 17:44:36 tflink, but anyway we will cross that bridge when we get there 17:44:44 agreed 17:44:54 the Docs team is also trying to find a means of doing similar things with the Guide 17:45:40 so in a perfect world, any docs we write for QA in general (tutorials, etc) they would also be able to use 17:45:54 * handsome_pirate is +1 for this 17:46:08 this documentation for qadevel is a good proving ground for testing a new documentation system 17:46:16 right 17:46:26 does that about cover it tflink? or am I off? 17:46:30 roshi: where they overlap, sure 17:46:34 right 17:46:59 it would be along the lines of "Hey, we have these tuts we use. You can easily use them if yo ulike." 17:47:02 just a couple of things that I may not have mentioned when we talked about this earlier 17:48:35 within the scope of qadevel docs, there are three main types that I want to cover: user docs (tutorials, triage guide), task maintainer docs (how to use the bits and pieces) and devel docs (how to write code, extensions etc.) 17:49:03 docs live with code, separate them and they tend not to get updated 17:49:15 have a higher tendancy to not get updated, rather 17:49:58 the idea for qadevel stuff is to have a method for taking those docs, building them and hosting them in a common place 17:50:29 and use as common of a toolset as we can so that we're not learning 5 different things 17:51:02 so on any change, CI would pull in changes from the main docs repo and any child repos, build and deploy those docs on qadevel 17:51:21 roshi: does that match what you understood from earlier? 17:51:26 yep 17:51:34 * handsome_pirate is +1 for this 17:51:34 any questions within the scope of docs for qadevel? 17:52:22 * tflink is going to start using the system to write up design docs and the other bits that need to be documented now while roshi is working on the method for making those docs into a more human understandable format (ie, html) 17:52:44 when you say "system" what are you meaning? 17:52:56 rst -> html 17:53:07 if we deploy manually at first, I'm OK with that 17:53:22 ok 17:53:52 roshi: anything else in the way of updates or questions? 17:54:21 not at this point - fleshing out dexy atm, looking for anything else that might be better 17:54:32 if anyone has suggestions, let me know :) 17:55:01 then I'll write up a blog post with a comparison and send it to the list 17:55:12 right now I think we've talked about dexy and sphinx 17:55:38 #action roshi to write up comparison between dexy and sphinx, send out to list when complete 17:56:10 if there's nothing else on this topic, let's move on to tasks/checks 17:56:32 #topic Taskotron Tasks/Checks 17:56:49 This is one large area of work that I don't think is stuck waiting on me to write stuff up 17:57:18 #info initial tasks will be the checks from AutoQA PUATP (minus depcheck, which is being rewritten) 17:57:38 should we distribute the tasks now? 17:57:49 #info these checks are: rpmlint, upgradepath and possibly repoclosure 17:57:52 I might be a good candidate for upgradepath rewrite 17:58:07 * handsome_pirate is already busy with depcheck 17:58:20 kparal: yeah, I was planning to ask for volunteers and hoping you would be willing 17:58:37 rpmlint is mostly done - I've been using that as the demo task 17:59:21 the basic idea is to extract the checks and any needed common funtions from autoqa so that it'll run in taskotron 17:59:41 bah, I missed one 17:59:47 do we want to include rpmguard? 18:00:00 it's not being reported in autoqa, but it is implemented 18:00:09 I think not for the initial run, let's keep it simple 18:00:50 good point 18:00:52 #undo 18:00:52 Removing item from minutes: 18:01:30 #info the target checks for phase 1 are: rpmlint, upgradepath, depcheck (mk 2) 18:01:51 the wiki also says repoclosure 18:02:08 yeah, I was tempted to leave that one off for phase 1, though 18:02:08 but we don't report it right now 18:02:27 #action tflink to move repoclosure to later phase in wiki docs 18:02:30 * handsome_pirate thinks we should leave off repoclosure for now 18:02:41 * kparal nods 18:03:33 kparal: would you also be interested in/willing to document the scenarios for upgradepath and create some scenarios like jskladan did for depcheck? 18:04:02 * shisatum waves 18:04:08 tflink: is there a simple task I can do? 18:04:57 tflink: I'll try 18:05:02 shisatum: depends on what your background is (in terms of what you can do or are willing to learn), to be honest 18:05:14 #link https://phab.qadevel.cloud.fedoraproject.org/T15 18:05:26 #link https://phab.qadevel.cloud.fedoraproject.org/T14 18:06:12 for now, let's keep the task git repos in bitbucket 18:06:28 I'm not convinced that's going to be their final place, but it works for now 18:06:44 and that seems to be where everything else has ended up 18:08:33 shisatum: are you OK with talking about tasks for you after the meeting? 18:08:45 tflink: I have novice/intermediate Python skills and a bit of HTML, mostly. My biggest project (in GWBASIC) was a control/macroing program (via keyboard) for a simple robot. I'm still becoming familiar with the Linux landscape, but would like to learn as much as I can as quickly as possible. 18:08:55 tflink: That is perfect. 18:09:26 for the record, I'm referring to "tasks" as in the unit of work for taskotron here 18:09:38 not just assignments and things for people to work on 18:10:25 #info possible checks for a future phase: repoclosure, rpmguard, abicheck 18:10:58 alrighty, moving on to the next topic 18:11:10 tflink: Also, I was asked about depcheck potentially checking to see if all required deps are listed in the rpm spec file 18:11:11 #topic Taskotron Runner 18:11:34 handsome_pirate: that seems to be rather out of scope for depcheck 18:11:47 tflink: That's what I thought 18:11:50 if I'm understanding correctly, the build system should catch that 18:11:57 Indeed 18:12:05 And, that's what I said 18:12:27 at least we had the same answer :) 18:12:35 LOL 18:12:48 this still needs some brain-dumping from me, but there are things which can be done 18:12:59 #info demo code is public, but incomplete 18:13:15 #link https://bitbucket.org/fedoraqa/libtaskotron-demo 18:13:52 outside of any common methods that we need to pull in for upgradepath or depcheck, there are 4 major components which need work 18:14:12 resultsdb integration, bodhi integration, logging and moving to dynamically loaded modules 18:14:53 my goal is to have the runner be distro agnostic by only loading fedora specific stuff if it's called for in the task 18:15:16 which also makes virtualenv creation easier if you're not dealing with code for koji or bodhi 18:15:26 which are so much fun to install in virtualenvs 18:15:58 oh, variable substitution as well - that makes 5 big parts 18:16:42 mkrizek: is this something that you'd be interested in helping out on? 18:17:05 #action tflink to move repo from libtaskotron-demo to libtaskotron 18:17:16 tflink: yes, I would 18:18:10 mkrizek: ok, I'll get some tickets written up today and send you the list of ones that are complete enough to start working on now 18:18:26 tflink: sounds good, thanks 18:18:38 I think that's about it for the runner right now 18:19:14 tflink: seems like we compete who's going to create more tickets in phab today :) 18:19:35 we have ~ 40 minutes left, I was planning to cover beaker quickly and move on to devops/infra, short term plans and some strategy stuff 18:20:07 that leaves out some status stuff, but that's all waiting on me for documentation, anyways so I figured that emails/blog posts/docs could work just as well 18:20:11 any objections? 18:20:33 mkrizek: yeah, I noticed all the emails to qadevel@ :) 18:20:38 no 18:20:43 ok, moving on 18:20:56 #topic Fedora Beaker Installation 18:21:35 I had been originally planning to put this off a bit but after talking to kparal last week, it makes sense to get this moving sooner than later 18:22:17 there are multiple groups within RH who want to start using the installation to run their test cases against fedora 18:22:44 since this would benefit us, it seems like a good idea to get this more done 18:22:55 most of the todo right now is infra-ish work, 18:22:57 though 18:23:30 I think we should do just the necessary work to allow them to work on this stuff and fix what's necessary. I don't want to imply we should invest heavily into this right now 18:23:37 writing an ansible playbook for beaker deployment, getting FAS groups set up for ACLs and getting FAS integration 18:23:54 * kparal saw tflink's emails to infrastructure list 18:23:57 kparal: good point. I'm just thinking of getting it to a usable state 18:24:02 right 18:24:42 #link https://lists.fedoraproject.org/pipermail/infrastructure/2014-January/013885.html 18:24:54 that's the email I sent out to the infra list 18:25:29 the second part about isolation is going to take some time and I don't see as absolutely needed right now if we control access to the system to folks who are known and trusted 18:26:29 any volunteers to work on getting stuff set up and working? 18:26:59 the beaker devs have volunteered to help maintain the installation 18:27:11 tflink: I may have some cycles next week 18:27:19 tflink: But, I couldn't get to it until then 18:27:27 handsome_pirate: I'd rather you stay focused on depcheck, to be honest 18:27:32 tflink: Roger 18:27:40 I'm not saying that you couldn't do it, just that depcheck is a much higher priority 18:28:07 Indeed 18:28:14 I assume that silence means no volunteers? 18:28:33 the question is, does anyone have any experience with ansible 18:28:57 other than me? not that I'm aware of 18:29:07 which is someting that we need to fix at some point 18:29:11 yeah 18:29:27 * kparal tries to stay away from infrastructure stuff :) 18:30:22 ok, I'll work on this as I have time unless someone comes forward as a volunteer 18:30:43 but documentation and getting everything else to the point that they can be handed off is a higher priority 18:31:16 at some point, I'll start pestering someone to learn ansible and start helping with infra stuff 18:31:27 bus rule and all 18:31:35 :) 18:31:46 if there's nothing else, I'll move on to the next topic 18:32:08 #topic Devops and Infrastructure 18:32:11 I'm about to apply to the infra team, I could take this on 18:32:46 danofsatx: awesome, I want to start making things more infra-compliant 18:32:56 instead of the current stand-alone stuff that I've been using 18:33:01 I have to see if they'll accept me though ;) 18:33:39 they probably will, especially if you have a mentor lined up 18:34:16 there are a few general things I wanted to touch on here 18:35:10 first, as I think everyone is aware, we're using phabricator to track tickets and do code reviews 18:35:31 #link http://phabricator.org/ 18:35:46 #link https://phab.qadevel.cloud.fedoraproject.org/ 18:36:09 it's not perfect, but I couldn't find anything better and it's worlds better than trac+reviewboard 18:36:50 after a snafu with jenkins for blockerbugs, I started setting up a buildbot for qadevel projects 18:37:11 it's still in staging, though 18:37:16 #link https://qadevel-stg.cloud.fedoraproject.org/builds/ 18:37:43 if we weren't using buildbot as the core of taskotron, I would have just continued to use infra's jenkins instance 18:38:03 but it seems stupid to become proficient in both systems 18:38:13 what was the problem in jenkins? 18:38:33 it was registering passes when the whole build has been failing since september 18:39:00 which wasn't a jenkins issue - it had to do with how the tests were being setup and executed 18:39:46 but this way, we have some more flexibility in our CI system and we can re-use the experience we'll get with buildbot when we eventually start hacking on buildsteps 18:40:40 at the moment, most of the qadevel and taskotron stuff is deployed with ansible playbooks 18:41:22 #link https://bitbucket.org/tflink/fedoraqa-ansible 18:41:46 it's mostly up to date but at some point, we should move over to infra's playbooks instead of a standalone system 18:42:18 if you're interested in working on those playbooks, let me know and I'll get you the needed details to work on it 18:42:46 I'm hoping that we'll get some new servers next year - our current infra is all at least 3 years old. most of it is 4 years old 18:43:10 tflink: Are these complete enough to use to set up a full taskotron system localy for devel? 18:43:22 so there will be some planning on that front, but I that's mostly an internal RH issue since they'd be paying for it 18:43:46 handsome_pirate: the playbooks? not quite. they're missing variables and the private stuff 18:43:57 tflink: Roger 18:44:08 the docs allude to the variables but IIRC, that doc is out of date 18:44:22 #action tflink to update playbooks and docs so that folks can setup dev systems 18:44:52 the last infra-ish thing is task git repositories 18:44:57 tflink: post meeting, mind if I badger you for the info on setting up a devel taskotron instance? 18:45:23 the design of taskotron is such that each task has it's own repo and that repo is cloned every time the task is run 18:46:00 which means that I'd rather not pound the snot out of bitbucket but I also don't want to move the repos around every time the system is redeployed 18:46:17 so the working plan is to have a local mirror of the bitbucket task repos for now 18:46:55 so the canonical upstream will be bitbucket and the taskmaster will mirror changes to those upstreams 18:47:04 any concerns or questions about that? 18:47:07 handsome_pirate: sure 18:47:34 ok, moving on 18:47:59 #topic Coding Policy/Strategy Going Forward 18:48:19 one of the things that I want to start is improving our code quality 18:48:43 I'm not placing any blame (I'm as much to blame as anyone) but there was some suboptimal code in autoqa 18:49:01 nicely put ;) 18:49:12 to keep that from happening again, I'd like to propose some rules going forward 18:49:29 1) all code must be reviewed before being used 18:49:48 2) all projects must be in CI for style checking (pylint) and unit test running 18:50:15 3) all projects (with the exception of tasks) should use the git-flow branching strategy 18:50:25 #link http://nvie.com/posts/a-successful-git-branching-model/ 18:50:35 #link https://github.com/nvie/gitflow 18:50:49 * kparal needs to study that again 18:50:55 4) all code should adhere to a common style guide 18:51:10 and the obvious part about exceptions where needed 18:51:40 the CI will happen pre-commit or post-commit? 18:51:47 ad 1), are we going to have minimal number of reviewers that needs to review the code before pushing to develop? 18:52:04 kparal: that'll depend on how we set things up 18:52:22 mkrizek: ideally, yes but we have a limited number of folks to draw on for reviews 18:52:33 true 18:53:03 this'll need hashing out for the details and some docs on how to do reviews etc. but I wanted to bring this up before drafting anything for the lists 18:53:06 we can set up multiple accounts 18:53:51 oh, another thing that I'll send out to the list (we're short on time) is minimum python version, eventual python3 work and possibly using python-future 18:54:07 #link http://python-future.org/index.html 18:54:08 kparal: :)) 18:54:09 I just find some pylink requirements stupid. so it depends whether we just check it, or also enforce it 18:54:17 *pylint 18:54:26 yeah, I suspect that we'll want to have some custom pylint configuration 18:54:52 but it sounds like there is general support for the idea? 18:54:54 e.g. 80 chars on a line should be enough for everyone :) 18:55:04 tflink: yes 18:55:06 tflink: I'm +1 18:55:13 wasn't the standard updated for 120? 18:55:19 to 120, rather 18:55:19 tflink: dunno 18:55:30 pylint still requires 80 18:55:33 either way, it'll be a topic for discussion 18:56:03 since we have 5 minutes left, any objections to moving on? 18:56:10 no 18:56:12 #topic Short Term Plans 18:56:21 in a nutshell, this is what I have in mind: 18:56:39 #info get a new demo system up and running to start testing taskotron as a whole 18:56:48 #info get docs and planning done 18:57:07 #info continue with the work described earlier (checks, runner etc.) 18:57:23 * tflink will be locked in a dungeon until the docs are more complete :) 18:57:51 any questions here? 18:58:31 I realize that I've left out major components but the summary of those is mostly "tflink needs to braindump and write stuff up" 18:58:32 tflink: At some point, a devel insance for running tasks against koji? 18:58:49 handsome_pirate: see the line from 2 minutes ago :-P 18:58:55 DOH 18:59:04 * handsome_pirate goes back into his hole 18:59:10 :-D 18:59:19 otherwise, it's time for ... 18:59:22 #topic Open Floor 18:59:34 Any topics that folks want to bring up? 19:00:58 * handsome_pirate is good 19:01:01 * tflink assumes that silence == no 19:01:30 I'll be working on docs and tickets, please find me if you have questions 19:01:42 thanks 19:01:46 we'll schedule another qadevel meeting if/when appropriate 19:02:18 if there's nothing else, 19:02:27 * tflink sets fuse for [0,5] minutes 19:02:43 * kparal thinks it's time to have some bacon 19:02:51 thanks for coming, everyone. I hope it wasn't too boring 19:03:29 ++ 19:04:08 * tflink will send out minutes shortly 19:04:11 #endmeeting