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