14:04:26 <tflink> #startmeeting
14:04:26 <zodbot> Meeting started Mon Sep 14 14:04:26 2015 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:26 <tflink> #meetingname fedora-qadevel
14:04:26 <tflink> #topic roll call
14:04:26 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:04:32 * kparal is here
14:04:33 * lbrabec is here
14:04:39 * garretraziel is here
14:04:40 <tflink> yep, just got distracted for a minute
14:04:45 * mkrizek is here
14:04:50 <tflink> #chair kparal lbrabec mkrizek garretraziel
14:04:50 <zodbot> Current chairs: garretraziel kparal lbrabec mkrizek tflink
14:05:09 <kparal> it seems we're missing one josef
14:05:27 <garretraziel> we are josefless
14:05:43 <tflink> :'(
14:05:45 * linuxmodder sits in back to learn more on qa process
14:05:58 <kparal> and we're being watched!
14:06:05 <kparal> behave, everyone
14:06:24 <kparal> not as usual
14:06:31 <tflink> :)
14:07:04 <tflink> let's get started
14:07:09 <tflink> #topic status updates
14:07:23 <tflink> #info old testdays instance has been deprecated, no longer exists - tflink
14:07:23 <tflink> #info new testdays instance available at http://testdays.fedorainfracloud.org - tflink
14:07:23 <tflink> #info OpenQA: created list of possible and finished installation tests: https://phab.qadevel.cloud.fedoraproject.org/w/openqa/tests/ - jsedlak
14:07:23 <tflink> #info OpenQA: KDE live and shrink tests implemented - jsedlak
14:07:23 <tflink> #info patch for emitting fedmsgs from resultsdb - mkrizek
14:07:24 <tflink> #info helped with runner refactoring and ResultYAML discussions and tickets - kparal
14:07:26 <tflink> #info verified that bodhi emails work for taskotron comments - kparal
14:07:43 <tflink> any comments/questions/additions?
14:08:31 <kparal> should I see something else than welcome page on http://testdays.fedorainfracloud.org/ ?
14:09:11 <tflink> mkrizek: I was waiting for the next revision before commenting much on the resultsdb review, were you waiting on more comments?
14:09:17 <tflink> kparal: i don't think so
14:09:23 <tflink> oh
14:09:31 <mkrizek> tflink: I was waiting on more comments :P
14:09:48 <tflink> ok, will get to that sooner
14:10:05 <tflink> testdays app is at http://testdays.fedorainfracloud.org/testdays/events
14:10:10 * tflink makes note to fix that
14:11:37 * tflink assumes no more comments, moving on
14:12:04 <tflink> #topic upgrading to fedora 22
14:12:19 <tflink> this came up earlier but I made a new discovery during the testdays deployment process
14:12:40 <tflink> with the change to dnf, our playbooks no longer work on f22
14:13:05 <tflink> it's a simple change of s/yum/dnf but it does bring up a question:
14:13:23 <tflink> thoughts on whether to spend much effort making sure that dnf and yum work?
14:13:52 <kparal> I'd say don't bother with yum anymore
14:14:01 <mkrizek> kparal: +1
14:14:11 <linuxmodder> on 22 i'd say it's worth it  but 23 +  not  worth the bother
14:14:34 <tflink> does that mean we've resolved the previous rhel vs. fedora debate?
14:14:39 <linuxmodder> 22 gives that  buffer time
14:14:53 <tflink> linuxmodder: buffer time?
14:15:10 <linuxmodder> transition to  dnf  for  users used to yum
14:15:15 * kparal forgot all about the debate
14:15:39 <tflink> linuxmodder: ansible's yum module just fails on f22, that transition is only for cli users, AFAIK
14:15:46 <mkrizek> didn't we agree on sticking with fedora? (at least f22)
14:16:06 <tflink> i remember putting off the decision more than anything
14:16:19 <tflink> ie, sticking with fedora for now because it's not trivial to switch
14:16:33 <mkrizek> yes, that's what I meant
14:17:08 <kparal> as long as we're heavy in development, I'd avoid too conservative environments. it will increase the maintenance burden
14:17:34 <tflink> kparal: i think it's a trade off
14:17:44 <kparal> we have no problems moving fast, but it's costly to keep historic compatibility
14:18:12 <tflink> at some point, I'd like to start supporting el7 in libtaskotron
14:18:51 <tflink> i think there's some interest from the centos folks when cloud support materializes and running tasks on epel7 would be great
14:19:06 <tflink> but that's not the same thing as running our infra on el7
14:19:12 <mkrizek> do we want to commit to that right now?
14:19:32 <tflink> mkrizek: to doing it right now? no. we have bigger fish to fry right now
14:19:47 <kparal> let's see whether rhel8 is not around by the time we can do all that ;)
14:19:55 <mkrizek> :)
14:20:00 <tflink> assuming it == el7 support
14:20:24 <tflink> either way, disposable clients and fedmsgs are much higher priority
14:21:17 <mkrizek> which I think was one of the reason not to upgrade to rhel now?
14:21:22 <tflink> my main concern about sticking on fedora is what may happen if there's a major change that we're not prepared for - could be an unexpected timesink
14:21:50 <tflink> the biggest reason I know of is buildbot - getting those packages to build for epel7 isn't trivial
14:21:59 <tflink> wasn't a simple rebuild, rather
14:22:00 <kparal> should not happen on the stable versions of fedora
14:22:50 <mkrizek> and we don't run the latest stable version
14:22:53 <tflink> kparal: some major change after GA? that's not really what I'm worried about - I'm more worried about an upgrade taking significantly longer than expected
14:24:06 <kparal> are we now talking operating system of disposable/persistent clients, or the trigger+buildbot server, or everything combined?
14:24:36 <tflink> kparal: everything outside of the VMs that execute tasks
14:24:43 <mkrizek> how about upgrading dev and see how well/fast that goes?
14:25:08 <tflink> f22 isn't too bad, I've already done that on non-infra systems
14:25:14 <kparal> is there any other potential problem than buildbot?
14:25:33 <kparal> because I don't understand what we're worried about. we'll quickly fix the trigger, if something changes
14:25:34 <tflink> kparal: that's the biggest one I know of
14:25:54 <kparal> and as for libtaskotron+tasks, it will need to run on latest and greatest software anyway
14:26:35 <kparal> then there's resultsdb and execdb, but I don't think we need to be too afraid for those
14:26:57 <tflink> resultsdb works on el7 - that's what testdays is :)
14:27:06 <tflink> er, testdays uses resultsdb
14:27:34 <kparal> so if it's just buildbot, and it's non-trivial to build it for el7, it seems our choice is clear
14:27:47 <tflink> that'd have to be rebuilt before too long - it was just less work to build it as el7 than go through the process of getting freeze breaks to get it working on f22
14:28:39 <kparal> ah, so it's non-trivial to make it work for el7, but it's even more complicated on fedora?
14:28:54 <tflink> kparal: during freeze, yes
14:29:19 <tflink> I would have needed to change the resultsdb roles in ansible
14:29:36 <tflink> and that needs freeze break requests, more testing etc.
14:30:53 <tflink> anyhow, the upgrade process isn't going to change for f22
14:31:01 * tflink didn't expect this to take so long :)
14:31:14 <tflink> didn't expect this topic to take up so much time, rather
14:31:23 <tflink> any other thoughts on this?
14:31:38 <kparal> this is all chinese to me, I'll ack whether you think is best approach
14:32:14 * mkrizek is lost
14:32:44 <mkrizek> can we wait until freeze is over?
14:33:24 <tflink> I think we're in pretty much the same boat as we've been - stick with fedora for now and potentially re-evaluate if the buildbot-on-el7 issue is ever fixed
14:33:34 <tflink> mkrizek: for testdays? no, that wasn't really an option
14:33:46 <tflink> it was the only thing left on the old cloud and infra wanted it to go away
14:35:47 <tflink> any other quesitons/comments?
14:36:08 <kparal> not here
14:36:12 <mkrizek> not here
14:36:52 <tflink> ok, let's move on
14:37:10 <tflink> #topic new features and rework
14:37:47 <tflink> I just wanted to see if there were any questions/comments about the ongoing new feature work and refactoring
14:38:09 <tflink> resultyaml, fedmsg and the renaming bits in disposable-develop
14:38:40 <kparal> we'll probably want to discuss the runner/governor terminology, but that can be outside of the meeting
14:39:19 <tflink> kparal: either way, it'd be good to get that figured out soon
14:40:05 <kparal> josef took such an interest in the new names and then he's no here, sigh
14:40:07 * tflink doesn't want to spend too much time debating terminology, even though he's the one who proposed something different
14:41:05 <tflink> sounds like there aren't any huge questions otherwise?
14:41:23 <garretraziel> nope
14:41:32 * tflink takes that as a no :)
14:41:32 <kparal> I guess not
14:41:35 <mkrizek> I guess nothing that can't be discused in the reviews
14:41:52 <tflink> ok, moving on then
14:41:58 <tflink> #topic tasking
14:42:26 <tflink> is anyone needing more tasks?
14:42:37 <tflink> or is everyone busy enough for the next week?
14:43:25 <kparal> busy as ever :) I'd like to review develop->disposable-develop changes and try to polish as much stuff as we can, so that the merge can happen soon and easily
14:43:59 <tflink> kparal: agreed, I want to get a system running that so we can get more testing time
14:44:20 <tflink> there are still questions in my mind that pretty much need running time to answer
14:44:51 <tflink> i think the biggest thing we're waiting on is the refactoring ticket, no?
14:45:02 * tflink didn't want to start on the merge until that was done
14:45:14 <kparal> can't say right now, but it's one of the big changes, yes
14:45:48 <tflink> what else is pending for disposable-develop?
14:46:39 * tflink has an idea to help with the dep tree but was planning to wait until post-merge for that
14:47:42 <kparal> I assume the merge will be done as a Phab diff, right?
14:48:03 <tflink> that makes sense to me
14:48:32 <tflink> assuming it's going to be as non-trivial as I think it'll be, anyways
14:48:55 <tflink> actually, does it make sense to review the merge?
14:49:09 <kparal> it will be a very large diff, so I'm a bit afraid the discussion over details can get out of hand
14:49:18 <kparal> but I don't see a better way
14:49:29 <tflink> it's not going to be a ff-able merge but it should be pretty straight forward
14:49:34 <kparal> that's why I want to pre-review the code this week first and maybe post some patches right away
14:49:59 <tflink> we could fork the repo and preview the merge that way
14:50:39 * tflink isn't sure what problems kparal is expecting
14:50:47 <kparal> if I say that my review standards for disposable-develop were much lower, and I'd like to increase them for the merge to develop, will that make me look like an annoying nitpicker?
14:51:02 <tflink> in general, isn't it 'disposable-develop wins if there are conflicts conflicts'?
14:51:06 <kparal> all of you already know me, so I guess you can't be surprised
14:51:36 <tflink> kparal: i think there would be some 'pot calling the kettle black' if I were to accuse you of nitpicking :)
14:51:55 <mkrizek> it's going to take forever to review the merge and fix kparal's nitpicks :P
14:52:10 <tflink> anyhow, i think we can figure out what to do about merging once we get the renaming out of the way
14:52:11 <kparal> heh. disposable-develop should win in conflicts in general, unless I botched some develop->disposable-develop merge
14:52:30 <tflink> mkrizek: we could always send kparal to the movies for a few days :-D
14:53:05 <tflink> anyhow, we're almost out of time and I think we can resolve the rest of this out of meeting
14:53:11 <kparal> I already had my PTO, you lost your chance. next opportunity is in december
14:53:21 <tflink> kparal: who says it has to be PTO
14:53:23 <tflink> ?
14:53:49 <garretraziel> yeah, we could distract kparal with bottle of wine
14:53:50 <tflink> "in the interest of moving forward at any cost, send the testers to the movies so they don't file any more bugs"
14:54:10 <kparal> sounds like a sound development practice
14:54:11 <mkrizek> even kparal needs to sleep sometimes...
14:54:18 <kparal> mkrizek: never!
14:54:50 <kparal> ok, I'll try to be nice
14:55:03 <kparal> for once
14:55:30 <tflink> it's helpful in the long run - just a balance between forward progress and getting stuff fixed
14:55:39 <tflink> but with 5 minutes left ...
14:55:42 <tflink> #topic open floor
14:55:47 <kparal> nothing from me
14:55:49 <tflink> any other topics to cover quickly?
14:57:13 * tflink takes that as a no
14:57:34 <tflink> thanks for coming, everyone
14:57:43 <mkrizek> thanks
14:57:51 <kparal> see you
14:57:56 * tflink sees a light at the end of the tunnel of "disposable clients are coming" :)
14:58:09 <kparal> nah, that's winter
14:58:09 * tflink will send out minutes shortly
14:58:19 <tflink> kparal: I'm really hoping it happens before then
14:58:24 <mkrizek> that sounded in a way like a word "should" :P
14:58:38 <mkrizek> er, the s word rather
14:58:46 <tflink> mkrizek: I'm trying to use not-quite-4-letter-words :)
14:59:02 <kparal> we're getting good in using metaphors to avoid that word
14:59:50 <tflink> well, we have to keep language clean - never know who's watching :)
15:00:17 <tflink> conversation can continue in #fedora-qa
15:00:24 <tflink> qa meeting now in #fedora-meeting
15:00:27 <tflink> #endmeeting