15:03:07 <adamw> #startmeeting Fedora QA meeting
15:03:07 <zodbot> Meeting started Mon Jul 17 15:03:07 2017 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:07 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
15:03:09 <adamw> #meetingname fedora-qa
15:03:09 <zodbot> The meeting name has been set to 'fedora-qa'
15:03:11 <adamw> #topic Roll Call
15:03:13 <adamw> morning folks, sorry i'm a bit late
15:03:15 <adamw> who's around?
15:03:19 * kparal is here
15:03:21 * sumukher is here
15:03:23 * tflink is around
15:03:24 * tenk is here
15:03:36 <mattdm> I'm here. I have another (internal, video) meeting at the same time though
15:03:59 <adamw> good lord, surely internal video is going a little far
15:04:16 <mattdm> adamw: seriously, you'd think there'd be some respect for privacy
15:04:52 <adamw> although, i suppose, it *was* your choice to sign up for ColonoscopyCon
15:05:17 <mattdm> i meant "not a fedora meeting". the joke is actually a little too close to the truth for some of this stuff :)
15:05:47 * roshi is here
15:06:35 <adamw> alrighty
15:06:38 <adamw> let's get going, then
15:06:40 <pjones> they're making you swallow the camera instead?  a bit harder to get it to the right place that way, isn't it?
15:06:45 <adamw> #topic Previous meeting follow-up
15:07:26 <adamw> so, two for me:
15:07:56 <adamw> #info "adamw to draft 'hand waive clause' (thanks roshi) for release process documentation covering late-discovered blockers and loop sumantro in on the process" - not done yet, I spent all last week working on mariadb rebuilds...will file a pagure ticket to track further progress
15:07:59 <adamw> aaaand:
15:08:09 <adamw> #info "adamw to look at enhancing revalconsumer to send announcement mails to other lists" - ditto
15:08:22 <adamw> roshi, two for you (one shared):
15:08:31 <adamw> "roshi to look at setting up a 'missing test alert system' of some kind (for validation tests that are not getting run)"
15:08:37 <adamw> "roshi and sumantro to write Heroes of Fedora posts for Fedora 26"
15:08:59 * sumukher was supposed to work on the HoF which I will submit by tommorrow to roshi and adam
15:09:24 <roshi> I was on PTO most of last week, and didn't get to the alert system yet
15:09:55 <adamw> roger
15:10:19 <adamw> #info "roshi to look at setting up a 'missing test alert system' of some kind (for validation tests that are not getting run)" - not done yet, roshi was on vacation most of last week
15:10:39 <adamw> #info "roshi and sumantro to write Heroes of Fedora posts for Fedora 26" - sumantro is working on this and will send out drafts for review tomorrow
15:10:42 <adamw> thanks folks
15:10:47 <adamw> any other followup issues?
15:10:56 * roshi doesn't have anything
15:11:24 <sumukher> test day announcements , when do they go out this time ? as we have a short time , do they go out today or tomorrow?
15:11:46 <adamw> hmm, good point
15:11:49 * roshi needs to look at the calendar again...
15:11:54 <adamw> as in, the call for test days?
15:11:59 <sumukher> yes
15:12:03 <sumukher> since we have no alpha
15:12:14 <sumukher> do we really have to care about branched point anymore?
15:12:30 <adamw> branching point is still a thing
15:12:48 <adamw> the test day dates are actually related to the Change process dates, not the milestone dates so much
15:12:52 * satellit late but listening
15:13:22 <sumukher> adamw so can we start calling for test days this week itself.
15:13:40 <sumukher> we kinda have a bit less time?
15:13:49 <adamw> yeah, i think that would make sense
15:14:28 <adamw> the only issue is that we're still in the Change review process, so we don't know yet which Changes will ultimately be accepted, but i think it's fine
15:14:32 <roshi> how much shorter is this cycle compared to past cycles?
15:14:45 <adamw> #action sumukher to go ahead and send out the call for Test Days, as this is a short cycle and there's likely a lot of change to test
15:14:57 <sumukher> roshi, 2 months shorter
15:15:02 <sumukher> AFAIK
15:15:33 <mattdm> It depends what you count from
15:15:57 <roshi> I usually start at the beginning
15:16:03 <adamw> .fire roshi that's crazy
15:16:03 <zodbot> adamw fires roshi that's crazy
15:16:09 <roshi> 0 or 1, generally
15:16:55 * roshi has been fired for less
15:17:08 <mattdm> from f27's start as current rawhide to planned release date will be ~ 8 months
15:17:32 <mattdm> for f26, it was 11.5 months
15:18:06 <adamw> all aboard the s.s. calamity!
15:18:08 <mattdm> for f25, it was 9 months
15:19:31 <mattdm> (I can keep going back if that's in any way useful. F24 was 11, F23 was just under 8...)
15:19:38 <mattdm> (uh under 9 i mean)
15:19:46 <roshi> F20 was ...4?
15:19:47 <adamw> #topic Fedora 27 planning
15:19:58 <roshi> 2013-08-20 branch to a 2013-12-17 release?
15:20:00 <adamw> since we're talking about the 27 schedule anyhow...
15:20:06 <adamw> roshi: he's not measuring branch to release
15:20:13 <adamw> he's measuring branch of the *previous* release to release
15:20:18 <roshi> aha
15:20:28 <adamw> (at the point N branches, we can say that rawhide 'is' N+1, to some extent)
15:20:35 <roshi> kk
15:20:52 <roshi> I was thinking those numbers seemed much larger than I recall actually having to work on them
15:20:56 <roshi> from the QA side
15:21:21 <roshi> since we're basically locked to the treadmill from N branch to N release and can only touch N+1 during lulls in the work on N
15:21:32 <mattdm> roshi: but from the schedule, f20 *was* that short actually
15:21:47 <mattdm> oh wait no it's just not written the same way on the schedule page
15:21:51 <mattdm> *confusing*
15:22:07 <adamw> welp
15:22:15 <adamw> however long we have to do it, we have to test this thing somehow!
15:22:25 <adamw> so, we've got some major changes coming up in the f27 cycle
15:22:42 <adamw> mattdm, since you're here and probably have a better handle on them than me, could we possibly impose upon you to give us an overview?
15:23:53 <mattdm> Sure.
15:24:13 <mattdm> There's a bunch of the normal things we see like version bumps of ruby and java and stuff. and new gnome
15:24:15 <adamw> #chair mattdm
15:24:15 <zodbot> Current chairs: adamw mattdm
15:24:18 <adamw> #chair roshi
15:24:18 <zodbot> Current chairs: adamw mattdm roshi
15:24:37 <mattdm> but the really big changes are:
15:24:50 <mattdm> 1. Dropping the alpha. Whooo.
15:25:04 <mattdm> 2. Arbitrary branching, and possibly building actual Fedora Server from modularity
15:25:19 <mattdm> (I'm very concerned about whether the second part of that is really possible.)
15:25:39 <mattdm> 3. CI for Fedora Atomic Host (including possible _gating_ of commits)
15:26:15 <mattdm> I'm not clear on how much arbitrary branching will affect F27 outside of modularity and server as separate things
15:26:44 <adamw> so does anyone want any of those things / terms explained?
15:28:14 <sumukher> arbitrary branching .. any link where I can read about it?
15:28:29 <mattdm> #link https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching
15:28:40 <sumukher> thanks mattdm
15:29:51 <mattdm> Initially, I think we'll just have *modules* in non-fNN-named branches
15:30:01 <mattdm> but there's the potential for RPMs to use the same thing
15:30:07 <mattdm> but that's scary :)
15:30:16 <adamw> so far as 'dropping the Alpha' goes, we are still working on the details of that
15:31:09 <adamw> so for now there's still an Alpha blocker tracker bug and an Alpha criteria page; we should really come up with an overall plan for what to do about those bits (and other Alpha-specific things)
15:31:14 <roshi> seems like more than that is currently being detailed :p
15:31:39 <adamw> #info F27 big change #1: dropping Alpha
15:32:02 <adamw> https://fedoraproject.org/wiki/Changes/NoMoreAlpha
15:32:12 <adamw> #info F27 big change #2: arbitrary branching and modular Server
15:32:17 <adamw> https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching
15:32:36 <adamw> https://fedoraproject.org/wiki/Changes/Modular_Server
15:32:47 <adamw> #info F27 big change #3: CI for Atomic Host
15:32:55 <mattdm> https://fedoraproject.org/wiki/CI
15:33:13 <adamw> https://fedoraproject.org/wiki/Changes/FedoraAtomicCI
15:33:21 <adamw> (not a real change page, it seems, but has the info)
15:33:41 <adamw> so those aren't exactly 'features' that we can 'test', really, but major process changes we'll have to adjust to
15:34:06 <adamw> roshi, are you up to speed on the Atomic CI stuff?
15:34:33 <roshi> tbh, it's kinda hard to tell what percentage of the information I'm privy to
15:34:47 <roshi> rough order of activities:
15:35:05 <roshi> 1) port internal RH tests to Upstream
15:35:24 <roshi> https://roshi.fedorapeople.org/upstreamfirst
15:35:29 <roshi> ^ status of that effort
15:35:46 <roshi> 2) Do CI with those tests
15:36:29 <roshi> I don't know/have any real details on what the CI is going to look like
15:37:04 <adamw> okay
15:37:08 <adamw> i guess tflink may know a bit more\
15:37:19 <adamw> still, that's probably the one with the *least* impact on us directly i woulds ay
15:37:25 <mattdm> The good news with that one is that I don't think any of those changes are going to *block* anything exactly
15:37:29 <roshi> afaik, it's still being sussed out
15:37:32 <mattdm> it's just major work going on in the timeframe
15:37:39 <tflink> yeah, CI is a devel effort, not a QE effort - or so I've been told
15:38:11 <adamw> so
15:38:11 * tflink knows very little about the details other than it's going to be using the standard interface, run in centos CI and results will make it back to fedora somewhow (bodhi, I think)
15:38:30 <adamw> taking them one at a time
15:38:45 <roshi> so for that, the upstream first initiative is the biggest one that affects us - but we're really just tracking status
15:38:59 <roshi> and being ready to answer questions and help point people in the right direction
15:39:19 <adamw> for #1, we're gonna need to figure out what adjustments to make to all our processes and schedules and so on to account for Alpha not being there. as I foolishly put my name on that damn Change, I suppose I'll get to come up with some plans for that.
15:39:37 <adamw> #action adamw to draft up some proposals for adjusting QA processes, policies etc. to lack of Alpha release
15:39:38 <mattdm> adamw++
15:39:38 <zodbot> mattdm: Karma for adamwill changed to 3 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:39:51 <mattdm> \o/ foolishness
15:39:55 <adamw> inorite
15:40:33 <adamw> #2 is kinda similar: we need to look at the Server validation process and make any necessary adjustments for the new technologies, which is probably gonna amount to testing deployment of modules
15:40:40 <adamw> again i already have that on my todo list via the Server WG...
15:40:52 <adamw> #action adamw to look into adjustments to Server validation for Modular Server
15:41:13 <adamw> and for #3, I don't think there's anything we specifically need to do, as roshi said
15:41:20 <adamw> other thoughts? anyone have ideas about #1 or #2?
15:42:07 <adamw> one thing we'll have to discuss for #1 is, what *happens* to the Alpha requirements? in theory the 'no more Alpha' change involves keeping all releases *permanently* at Alpha quality after branching, so do we try and come up with a process to enforce that, beyond the automated testing? or do we just shift everything up to beta?
15:42:08 <mattdm> I know adamw is an inhuman qa robot machine, but I'm a little worried about both major things being owned here by one person
15:42:23 <tflink> #2 worries me a bit WRT to support tooling but hopefully that'll be figured out before they become problems
15:42:39 <adamw> mattdm: me too, i'm not sure we have a way out of it on such a short timeframe though :/
15:43:06 <adamw> tflink: when you say 'support tooling'...?
15:43:28 <tflink> adamw: thing that assume fedora release based on dist-git branch
15:43:30 <tflink> things
15:43:43 <tflink> most of it is well out of our control, though
15:43:57 <tflink> the only thing I know of is taskotron related
15:44:06 <roshi> I think the alpha stuff just gets turned into the CI criteria for releasing a nightly rawhide, right?
15:45:02 <mattdm> roshi: I agree with "criteria for nightly rawhide" but let's be careful with terminology for CI
15:45:18 <adamw> tflink: ah, you're thinking of the arbitrary branching part, i see
15:45:29 <tflink> yep. wasn't that #2?
15:45:31 <roshi> the no more alphas, is because rawhide shouldn't have any bugs that would block alpha, right?
15:45:35 <tflink> or did I miss something
15:45:39 <adamw> roshi: well in theory yes, but there are *some* alpha criteria it'd be hard to automate
15:45:52 <adamw> at least, iirc there are. i'm gonna have to go through the list and see.
15:45:53 <roshi> good thing we're not writing the code then :p
15:46:29 <adamw> and of course automated testing is never 100% even for the things it covers; we won't catch bugs that don't affect VMs, for e.g...
15:46:54 <adamw> so it seems fairly likely that it'll still be possible for Branched to have bugs that would have been Alpha blockers; what do we do in such a situation, is the question
15:46:57 <roshi> beaker is supposed to handle that bit, for the bare metal testing
15:47:09 <mattdm> (terminology: specifically, let's use CI for: testing on the change stream side, gating merges into the tree — as opposed to validation testing on the other side)
15:47:49 <adamw> roshi: we are not doing anything with beaker at present. the whole 'no more Alphas' thing is based on the testing we really currently have, which is openQA and autocloud (when it comes to testing composes). not notional things we might do in future.
15:47:59 <roshi> ah
15:48:09 <mattdm> adamw: for that question: can we keep tracking them in the Blocker Bugs app?
15:48:17 <roshi> so I would say those "hard to automate" criteria just get moved to Beta
15:48:24 <adamw> we could, yeah. we'd have to make some adjustments to call it...something else.
15:48:33 <mattdm> yeah that was what I was just typing :)
15:48:47 <mattdm> since they're not actually _blocking_ anything in a meaningful way
15:49:13 <adamw> what i was thinking (just now) is we could make the thing that decides whether we release each nightly compose check for 'alpha blocker bugs', or whatever we start calling them instead
15:49:22 <adamw> and not release the compose if there are any
15:49:48 <adamw> but i'm not sure that helps anything, if we're talking about bugs we only spot *after* they already made it into a compose...
15:49:54 <mattdm> What does "not release the compose" mean?
15:50:02 <adamw> well, that's how this whole thing is going to work
15:50:34 <mattdm> people can still get to the "non released" bits to test and work on fixing the problems, right?
15:50:39 <adamw> right now, every successful Branched compose is synced to the development/(release number) tree on the mirrors, that's what i refer to as 'releasing the compose'
15:50:51 <mattdm> *nod*
15:51:07 <mattdm> and the kojipkgs tree will be there for people who need it
15:51:16 <adamw> in No More Alphas, there will be a decision point there; the compose happens, if it's successful we don't immediately sync it, but wait for the test results, and only sync it if it 'passes' the tests (for whatever definition of 'passes' we decide on)
15:51:44 <adamw> well sure, but the scenario i'm interested in really is what happens if an 'alpha blocking' bug makes it into one of the composes that gets synced.
15:51:51 <adamw> still, we don't have to decide it all right now
15:52:00 <roshi> the question I have, is we sync because we don't want to overload the server with downloads, what're we doing to mitigate that for *this* effort?
15:52:15 <roshi> or do we want everyone downloading from koji?
15:52:27 <adamw> roshi: that's not really it
15:52:38 <adamw> we sync *candidate composes* to *stage* to help with distribution
15:53:06 <adamw> we sync nightlies to development/rawhide and development/27 or whatever because...that's how we 'release' rawhide and branched
15:53:18 <mattdm> We definitely don't want everyone downloading from koji. If this is creating too much load we can probably do some sort of "stage" environment somewhere
15:53:24 <adamw> in general, very few people do anything with non-'released' nightly composes
15:53:56 <roshi> ah, ok
15:54:02 <adamw> i suppose there's a possibility in this model that people will jump on the non-released nightlies if we have a long delay between released composes
15:54:11 <adamw> but that's all kinda stuff to keep an eye on in future, i think
15:54:43 <mattdm> yeah.
15:55:45 <adamw> so yeah, if anyone has any ideas for making this not The AdamW Show, please get in touch - i'm just worried to assign either of the tasks to anyone else as they both require quite a lot of background knowledge of the existing processes
15:55:50 <adamw> so i didn't want to inflict all that reading on anyone
15:56:41 <adamw> we should probably go through the 'regular' f27 changes soon too
15:56:50 <adamw> but i hope this gave everyone an understanding at least of the 'big stuff' that will be coming up
15:56:59 <adamw> #topic Storage test matrix update status
15:57:02 * sumukher nods
15:57:23 <adamw> this is a really quick one; I just wondered what's happening to the updates to the validation tests to cover blivet-gui in anaconda
15:57:27 <adamw> that was supposed to get done last cycle
15:57:58 <sumukher> i updated https://pagure.io/fedora-qa/issue/503 with all the draft test cases , awaiting reviews
15:58:10 * mattdm notes that it's *really* easy to make a system that won't boot with blivit-gui
15:58:26 <roshi> yeah, I thought it was just waiting on review after sumukher and I drafted them up
15:58:55 <adamw> sumukher: whoops, i guess i was looking for a mailing list post
15:58:58 <adamw> if there was one, i missed it
15:59:28 <adamw> #info draft test cases for blivet-gui in anaconda are at https://pagure.io/fedora-qa/issue/503 , please take a look and provide feedback
15:59:35 <adamw> thanks you two
15:59:38 <adamw> #topic Open floor
15:59:43 <adamw> anyone have anything else, in the last 20 seconds? :P
15:59:50 <roshi> sumukher++ for doing most of the work :)
15:59:56 <roshi> sumukher++
16:00:04 * satellit is there a working live f27 build?
16:00:14 <sumukher> its sumantrom roshi  :D
16:00:20 <adamw> oh, i see the change date on the ticket - "6 hours ago". now i feel less bad for missing it. :P
16:00:22 <roshi> aha
16:00:30 <roshi> sumantrom++
16:00:30 <zodbot> roshi: Karma for sumantrom changed to 1 (for the f26 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:00:32 <sumukher> thanks :)
16:00:46 <adamw> satellit: the most recent rawhide nightly *more or less* worked, i think, there are some bugs but it's not DoA: https://www.happyassassin.net/nightlies.html
16:01:07 <sumukher> adamw roshi sent out the test day email , awaiting approval
16:01:12 <adamw> awesome, thanks
16:01:14 <roshi> kk
16:01:28 <satellit> thanks   wks failed to boot latest from koji after install
16:01:46 <sumukher> onboarding call ticket has been filed , its what I wanted to do first week of Aug as we have tons of new contributors
16:01:55 <tenk> quick question about the matrix
16:02:28 <sumukher> tenk fire away
16:02:30 <tenk> i have seen that LXQt is a new spin but not a lot of things to test on the tet matrice
16:03:11 <tenk> i was suprise that there no test day for this new spin for example
16:03:17 * sumukher concurs , its a new spin whose test day didnt happen
16:03:23 <adamw> sumukher: sounds like a good idea, thanks
16:03:44 <adamw> we can add lxqt to the 'non-blocking environments' in the desktop matrix
16:04:03 <sumukher> that was mostly cz we did gnome test day 1 day before release ,hence the idea of starting way ahead of time
16:04:26 <adamw> do you two want to contact the lxqt spin maintainer and propose an lxqt spin test day?
16:05:15 <sumukher> I did *try* to get in touch with him, lupinix responded but then we lost touch
16:06:54 <adamw> maybe try again? :)
16:07:06 <adamw> #action adamw to add lxqt to desktop test matrix
16:07:12 <adamw> (there, an easy one :>)
16:07:20 <adamw> #action sumukher and tenk to look into setting up an lxqt spin test day
16:08:07 * adamw sets fuse
16:08:11 <adamw> thanks for coming everyone
16:08:17 <sumukher> adamw, sure
16:09:16 <adamw> #endmeeting