14:02:36 #startmeeting fedoraqa-devel 14:02:36 Meeting started Mon Jun 16 14:02:36 2014 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:02:41 #meetingname fedoraqa-devel 14:02:41 The meeting name has been set to 'fedoraqa-devel' 14:02:45 #topic Roll Call 14:03:10 * jskladan is here, but will need to run away a bit sooner than at the end 14:03:14 * mkrizek is here 14:03:26 * kparal 14:03:32 * pschindl is here 14:06:41 * tflink waits another minute to see if roshi shows up 14:07:02 ok, let's get started 14:07:24 #topic Release Name Format 14:07:45 the thing I wanted to propose here was to decouple the iteration name from the version of taskotron 14:07:53 it seems silly to bump the version just to release 14:08:12 is it a problem? 14:08:21 an annoyance, not much more 14:08:39 so how would we do it? 14:09:02 instead of 0.3 -> 0.4, we would have... ? 14:09:10 name the upcoming iteration/sprint "Taskotron Iteration 4" and bump versions as we go 14:09:28 0.3.0 to 0.3.1 etc. 14:09:50 what exactly "as we go" means? 14:09:55 resultsdb doesn't match the taskotron versions, anyways 14:10:08 no objections here 14:10:09 nothing specific, bump version as appropriate 14:10:41 didn't we want to release regularly? 14:11:07 we can release without bumping the minor version number 14:11:29 * roshi has no objections 14:11:42 so we keep the schedule, just change the n-v-r bump procedures? 14:11:49 exactly 14:11:57 ok, no objections 14:12:11 * jskladan has no objections either 14:12:15 Any thoughts on what to call the 2 week iterations/sprints 14:12:39 can we call it "the 0.3.1 sprint"? :) 14:12:53 proposed #agreed starting with this iteration, we will be decoupling the versions from iteration names 14:13:08 kparal: what do we call builds that we do over the course of the sprint/iteration? 14:13:29 I am fine with calling it "iteration 4" as tflink proposed 14:13:34 I guess I'm bit slow today 14:13:34 I think we should have code names 14:13:54 like this one could be, "Sprint Faster" 14:13:55 roshi: because that has worked so well for fedora as of late :) 14:14:11 I don't really care what we call it, as long it's not ubuntu-style naming 14:14:29 I'm terrible with names, so I'll probably just call it "this sprint" 14:14:44 or last sprint 14:14:44 I'd rather stick to numbers - it's easier to come up with and easier to determine sprint/iteration order 14:14:51 tflink: +1 14:14:52 wfm 14:15:10 * roshi was joking about the code names :) 14:15:32 proposed #agreed starting with this iteration, we will be decoupling the versions from iteration names but keeping a numeric name 14:16:03 #agreed starting with this iteration, we will be decoupling the versions from iteration names but keeping a numeric name 14:16:30 any thoughts on sprint/iteration terminology? I'd like to stop typing them both out 14:16:38 * tflink is used to iteration but sprint is fine 14:17:20 doesn't matter to me 14:17:22 iteration 14:17:24 I like "iteration" rather than sprint 14:17:31 I don't like sprinting 14:17:31 iteration it is 14:17:36 I was always slow in it 14:17:41 though, I might slip up and say sprint because that's what I'm used to every now and again 14:17:50 #agreed will use "Iteration X" as title for iterations 14:18:02 OK, I think that's all for this topic 14:18:29 Since jskladan has to leave, I want to insert a topic into the agenda now instead of at the end of the meeting 14:18:34 #topic Depcheck Status 14:18:50 jskladan: can you quickly summarize where you are with depcheck? 14:18:56 #chair jskladan 14:18:56 Current chairs: jskladan tflink 14:19:19 quickly/briefly 14:19:25 in the few last hours, a mysterious yum repo error occurred and it stopped working completely :) 14:19:28 *last 14:19:35 yay - so, apart of the yum error 14:20:00 there is a patch that makes Depcheck run in taksotron 14:20:11 https://phab.qadevel.cloud.fedoraproject.org/D139 14:20:48 and I'm working on code that will squash the per-rpm results to per-update results (which is a bit more complicated than one would think) 14:21:01 also, depcheck as is in D139 does not handle multilib 14:21:15 (tflink proposed patched taskyaml in comments) 14:21:16 jskladan: yeah, it's one of those things that sounds simple until you get into the details :-/ 14:21:48 the suggestion of new taskyaml is not bad (link incoming) 14:21:56 https://phab.qadevel.cloud.fedoraproject.org/file/data/2adzt4kz543fwzgwjo3o/PHID-FILE-ojgxz3ov4tylmim22yrm/depcheck.yml 14:22:21 but there IMHO is a problem, that the first depcheck run (the i386 one) will fail for all x86_64 rpms 14:22:47 so that will need to get sorted a bit better, my initial ideas are in the comments of the Differential 14:22:59 I suggest creating a separate ticket for multilib 14:23:08 * tflink hasn't had a chance to respond yet, will do so later today 14:23:28 and possibly pushing D139 as is - since the content of task-depcheck master is next to non-working now 14:23:35 sounds good to me but I would really like to see multilib depcheck by the end of iteration 4 14:23:35 (bad imports, and so on) 14:23:57 and doing multilib in separate patch/differential 14:24:52 Also, in the process of tinkering, I found out that depcheck (most probably) does not work for i386, but the weird yymrepo error is blocking me from further investigations 14:25:30 sounds like good forward progress, though 14:25:31 but tests with simple noarch library for python passes on x86_64, and fails on i386 saying that nothing provides python(abi) 14:25:51 which imho means that depecheck is not using the "main" repos at all 14:25:52 do you see any potential issues that would prevent depcheck from running in stg by ~ next wednesday? 14:26:01 further investigation is required, though 14:26:31 #info with patches, depcheck is runnable in taskotron but not quite complete yet 14:27:06 #info depcheck tickets will be split out to handle multilib runs in a separate ticket 14:27:11 Just the i386 failures but if we'd be happy with x86_64 for the moment...) 14:27:26 #info there are potentially issues with running depcheck in i386, investigation is ongoing 14:27:40 i pinged jdulaney, and am awaiting his response 14:27:53 because the underlying libsolv calls are just pure magic ffor me 14:28:08 they're generally better than yum :) 14:28:25 if the i386 problem ceases to exist, than next wedneday is IMHO very realistic 14:28:27 jskladan: can you copy me on those questions? I've also spent some time with libsolv and might be able to answer 14:28:43 tflink: ok, I will 14:29:06 that's it about depcheck from me 14:29:22 hopefully the i386 issue ends up being something simple-ish 14:29:26 jskladan: thanks for the update 14:29:33 moving on to 14:29:49 #topic Directive Documentation 14:30:25 Now that we've mostly got the "licensing happy fun time" done, we can focus a bit more on the trigger for that - directive docs 14:30:36 user facing directive docs, to be specific 14:31:14 I want to at least have initial docs rendered by the end of the week (missing data ok to finish next week) 14:31:20 even the developer facing would be nice to have improved :) 14:32:03 kparal: not sure we need dev facing directive docs unless you're talking about in-code comments 14:32:17 current discussion: https://phab.qadevel.cloud.fedoraproject.org/D93 14:32:18 yeah, it will be solved in one go 14:33:56 Are there any objections to starting on this other than the desire to not need the "empty" declarations in the embedded YAML? 14:35:21 the general approach is fine for me. I'd just do some tweaks, as described in my comment 14:35:35 and I'd like to know if I can you reST in the yaml blocks 14:35:46 or how we're going to do some markup 14:35:57 I don't know that you can 14:36:16 *you->do 14:36:33 roshi: IIRC, there is some markup that can be done but it is limited 14:36:50 yeah - I'm not sure on the specifics 14:36:53 especially the long description item will likely need some markup support 14:36:59 hyperlinks and such 14:37:14 I imagine it can be several paragraphs long 14:37:27 roshi: can you look into the markup concern? 14:37:34 links I think can just be pure rst 14:37:36 yeah 14:37:47 that lead me to my question whether it is better to have yaml blocks or pure reST text 14:37:59 #action roshi to investigate markup options for embedded yaml doc in directives 14:38:25 I would imagine they went with yml to make their docs simple, and the same 14:39:05 if it's yaml you don't have to do as much checking as a pure rst block when people send code 14:39:07 I suspect that if we went with pure reST, we'd have to write a bunch of code on the tooling side 14:39:10 that would be my guess anyway 14:39:57 and it wouldn't be as easy to keep common template, I understand that 14:40:24 it shouldn't be too difficult, I don't think 14:40:26 if we went with pure rest, we'd just have to take out the yaml parser and pull in the reST from the documentation variable 14:40:46 it -> having a template for reST 14:41:37 it sounds like there are no huge objections to the general process, though? 14:41:53 none here 14:42:35 not really 14:43:17 #info no objections to the concept of embedding user-facing documentation "source" in directive source files and rendering them at build time, specifics of the process to be worked out this week 14:43:33 bah, we're already 45 minutes in 14:43:38 jskladan: speak up if you have some concerns, or in the ticket 14:43:52 maybe he's on his way already 14:44:18 * jskladan will comment in the ticket 14:44:35 ok, moving on, then 14:44:55 #topic Production Deployment Status 14:45:11 * tflink will quickly summarize what's going on with our eventual production system 14:45:36 I'm working with infra to port parts of our playbook repo to the infra ansible repo 14:46:10 this has brought up some unexpected snags but I'm still hopeful that we can get a production system in place the first week in July 14:47:18 by using the infra repo, we get: https with no ssl cert management, performance monitoring, uptime/diskspace/memory monitoring for free 14:47:42 theoretically, it'll alow infra folks to help with infra/deployment issues more so than if we continued to use our separated repo 14:48:05 * tflink will keep folks updated as we go 14:48:15 sweet 14:48:27 #topic Iteration 4 Planning 14:48:40 #link https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-0.4/ 14:49:18 * tflink was hoping to have all the tickets filed before the meeting but that didn't quite happen 14:49:38 ok /me needs to flyyy, see you around tomorrow, gang! 14:49:40 I'm going to need some help with infra/buildbot this iteration 14:49:54 jskladan: I assume that you're ok with the depcheck tickets for this iteration? 14:50:03 I guess we'll find out if he isn't :) 14:50:42 * mkrizek is ok with helping with infra/buildbot 14:51:13 mkrizek: thanks 14:51:59 mkrizek: two quick tickets that would seem to make sense to assign to you are T220 and T223 14:52:23 * mkrizek looks 14:52:42 I think that T220 is a quick fix, a couple of hours at most 14:53:30 regarding T223, isn't that done already by running systemctl start fedmsg-hub.service? 14:53:34 kparal: would you be OK with helping roshi with directive docs and content? 14:53:54 mkrizek: I think so but haven't tested it to make sure that the cvs file authoring works that way 14:54:05 so it's as much of a "confirm this works like we think it will" as anything 14:54:23 ok, I have tested it, but will again to make sure 14:54:33 tflink: sure, even though I might need to bother the actual directive authors for some information :) 14:54:38 * mkrizek takes T220 and T223 14:54:40 * tflink just realized that he forgot an item on the ticket list 14:55:18 kparal: set phasers to annoy :) 14:55:31 we'll also need to carry on the Context discussion, for which the ball is currently on my field 14:55:43 oh yeah, forgot about that one as well 14:56:00 and I have just filed a few tickets I consider a bit important 14:56:27 I can link them here, if it's the right time 14:56:51 sure 14:57:01 this one is important for josef: 14:57:02 https://phab.qadevel.cloud.fedoraproject.org/T225 14:57:22 once we started really playing with depcheck, we (at least here in Brno office) waste a lot of time waiting for packages to be downloaded 14:57:32 this should help very much 14:57:50 an alternative would be this: 14:57:50 https://phab.qadevel.cloud.fedoraproject.org/T226 14:58:26 T225 makes sense 14:59:16 I think T225 is better to focus on than T226, it should be easier to do 14:59:43 I'd like to avoid those tickets for now 14:59:53 I understand why but depcheck is complicated enough as it is 15:00:08 why would you want to avoid T225? 15:00:15 I'd prefer to make sure that core depcheck is working before adding complexity 15:00:31 because it's another avenue for bugs 15:00:33 it does not affect depcheck directly. it just sets up a directory to download rpms to 15:00:40 so that we can cache them 15:01:00 it's koji_directive, happens before depcheck 15:01:09 you can get the same effect in development by specificing a workdir in the task yaml that has the needed rpms 15:01:20 how would you move the rpms into a workdir? 15:01:26 where would that happen, rahter 15:01:37 I can override workdir in yaml? damn 15:01:54 I advised josef to override it in runner.py, but that's of course very inconvenient 15:02:02 it's easier to do it in yaml 15:02:06 it should be override-able in yaml 15:02:20 if that doesn't work, I'm ok with making that work this iteration 15:02:31 we'll look at it tomorrow 15:02:47 but I'm a little worried about how to handle T225 in production, making sure that we aren't picking up old mash data etc. 15:03:03 T226 is too risky for now 15:03:06 the NVRs are always the same 15:03:17 the rpms never change their contents 15:03:19 sure, but where are they moved to a workdir? 15:03:27 dunno, I didn't think about that :) 15:03:40 good point 15:03:54 I'm not against the idea as a whole but we have ~ 3 weeks before F21 branch 15:04:08 KISS is the name of the game for now, as much as possible 15:04:19 even if that means more downloading in the short/medium term 15:04:37 some caching needs to be available, otherwise we can't work on depcheck. but if it works through .yaml, it's OK 15:05:51 kparal: do you think that either lbrabec or jsedlak would be able to finish T221 this iteration? 15:06:20 lbrabec is out this week 15:06:34 mkrizek: would you be ok with the yet-to-be-filed ticket on adding a 'cat taskotron.log' step to buildbot? 15:06:45 I can give it to jsedlak as the top priority if needed 15:06:57 tflink: sure 15:07:15 it will likely require a full taskotron deployment, right? 15:07:52 yep, it will 15:07:59 tflink: taskotron.log patch is not yet ready 15:08:35 bah, forgot about that even though I just added the taskotron.log ticket to the list 15:09:00 I hope that pschindl will work on it this week 15:09:51 or I was planning to reassign it to jsedlak, because he already had some experience with logging 15:10:03 * tflink will try to think of a workaround for step development 15:10:15 kparal: do you think he'd be able to get that done this week? 15:10:33 s/week/iteration 15:10:36 T221 or T119? 15:10:37 hopefully this week, though 15:10:59 T119 15:10:59 tflink: kparal why is that patch needed for the step development? don't we have support for logging into a file already? 15:11:03 I'm not certain about his schedule this week 15:11:12 tflink: I'll try to finish it this week 15:11:32 pschindl: thanks 15:11:51 so I'll ask jsedlak to work on T221 15:12:06 mkrizek: good point, the content doesn't have to be 100% there to add the step 15:12:18 config on the slaves may need to be changed but that's a minor thing 15:12:30 mkrizek: if we need something soon, we can just use a very simplified version, yes 15:13:15 I'll work on other tickets first anyway before doing the step ticket 15:13:31 it still needs /var/log/taskotron directory, though 15:13:50 what's "the step ticket"? 15:14:05 kparal: your idea of adding a 'cat taskotron.log after run' 15:14:08 kparal: "'cat taskotron.log' step to buildbot" 15:14:09 ah 15:14:11 * tflink hasn't written the ticket yet 15:14:52 and also rm taskotron.log as a pre-step to actual check run 15:15:38 kparal: that might make debugging difficult 15:15:53 but we can discuss details in the ticket once its written 15:16:10 otherwise we accumulate all previous checks' output in the log 15:16:21 sure, in the ticket 15:16:26 There are several tickets on the high priority list that don't make sense to do early 15:16:48 I figure we'll leave them unassigned for now and whoever has the cycles for them next week can take them 15:17:17 like: making sure the default config works well for local execution and verifying results quality/existence 15:17:31 sounds good 15:17:55 is there somewhere the phab interface showing the tickets status and assigned people? 15:18:01 for 0.4 release 15:18:11 kparal: I posted the link earlier 15:18:17 https://phab.qadevel.cloud.fedoraproject.org/T219 ? 15:18:21 wiki: https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-0.4/ 15:18:44 tracking ticket: https://phab.qadevel.cloud.fedoraproject.org/T219 15:18:59 wasn't there the nice automatic "project planning" interface somewhere? 15:19:10 instead of manual wiki updates? 15:19:24 I don't think so but if I'm missing something, let me know 15:19:43 unless you mean the workboards 15:19:56 that's it, I guess 15:20:31 like https://phab.qadevel-stg.cloud.fedoraproject.org/project/board/2/ 15:20:41 yeah 15:20:58 * tflink is trying to remember if there is a reason he didn't use project boards 15:21:04 mostly the extra emails, I suppose 15:21:26 those can be configured 15:21:36 ok, I hadn't looked into that yet 15:21:38 we could try it for the next iteration 15:21:43 just an idea 15:22:19 wfm 15:22:26 https://phab.qadevel.cloud.fedoraproject.org/project/board/2/ 15:22:29 so far phab has been a great tool, IMO 15:23:18 * tflink will do more ticket mongering outside of the meeting 15:23:48 to be clear, the highest priority right now is to get ready for production deployment 15:23:55 in no particular order: 15:24:03 1) directive documentation 15:24:26 2) depcheck (simple at least, multilib second, will consider other features later) 15:24:43 3) infra, buildbot and infra hacking 15:25:07 I'd like to have most code changes in develop by next tuesday 15:25:25 that gives us a couple of days for the sanity checking tickets 15:25:53 makes sense 15:25:59 since we're already 30 minutes over, is anyone unclear on what they're working on this week, at least? 15:26:53 * roshi : directive docs with kparal 15:27:22 if you're unclear on what to work on or what the priorities are, let me know 15:28:02 and if you work on something that's not already a subtask of T219, please add it as a subtask for tracking purposes 15:28:34 * tflink assumes that everyone has relevant stuff to do this week and priorities are clear enough 15:28:40 #topic Open Floor 15:28:57 * tflink will be doing a release today - actually doing it instead of forgetting like with 0.2 15:29:31 anything else that should be brought up or something I missed? 15:30:05 not here 15:31:13 thank you all for your patience with me as I get stuff figured out for these planning meetings, this is new to me as well 15:31:48 if you have feedback on how the planning meetings or the iterative process in general could be made better, please let me know 15:31:59 if there's nothing else, 15:32:20 * tflink sets the always awesome patent-pending quantum fuse for [0,5] minutes 15:33:07 tflink: you guys done? releng meeeting starts here now 15:33:29 dgilmore: yeah, I'll end the meeting 15:33:31 sorry about that 15:33:34 for $5 we'll leave 15:33:38 :p 15:33:38 * tflink will send out minutes shortly 15:33:40 #endmeeting