15:03:07 #startmeeting Fedora QA meeting 15:03:07 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:07 The meeting name has been set to 'fedora_qa_meeting' 15:03:09 #meetingname fedora-qa 15:03:09 The meeting name has been set to 'fedora-qa' 15:03:11 #topic Roll Call 15:03:13 morning folks, sorry i'm a bit late 15:03:15 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 I'm here. I have another (internal, video) meeting at the same time though 15:03:59 good lord, surely internal video is going a little far 15:04:16 adamw: seriously, you'd think there'd be some respect for privacy 15:04:52 although, i suppose, it *was* your choice to sign up for ColonoscopyCon 15:05:17 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 alrighty 15:06:38 let's get going, then 15:06:40 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 #topic Previous meeting follow-up 15:07:26 so, two for me: 15:07:56 #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 aaaand: 15:08:09 #info "adamw to look at enhancing revalconsumer to send announcement mails to other lists" - ditto 15:08:22 roshi, two for you (one shared): 15:08:31 "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 "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 I was on PTO most of last week, and didn't get to the alert system yet 15:09:55 roger 15:10:19 #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 #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 thanks folks 15:10:47 any other followup issues? 15:10:56 * roshi doesn't have anything 15:11:24 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 hmm, good point 15:11:49 * roshi needs to look at the calendar again... 15:11:54 as in, the call for test days? 15:11:59 yes 15:12:03 since we have no alpha 15:12:14 do we really have to care about branched point anymore? 15:12:30 branching point is still a thing 15:12:48 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 adamw so can we start calling for test days this week itself. 15:13:40 we kinda have a bit less time? 15:13:49 yeah, i think that would make sense 15:14:28 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 how much shorter is this cycle compared to past cycles? 15:14:45 #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 roshi, 2 months shorter 15:15:02 AFAIK 15:15:33 It depends what you count from 15:15:57 I usually start at the beginning 15:16:03 .fire roshi that's crazy 15:16:03 adamw fires roshi that's crazy 15:16:09 0 or 1, generally 15:16:55 * roshi has been fired for less 15:17:08 from f27's start as current rawhide to planned release date will be ~ 8 months 15:17:32 for f26, it was 11.5 months 15:18:06 all aboard the s.s. calamity! 15:18:08 for f25, it was 9 months 15:19:31 (I can keep going back if that's in any way useful. F24 was 11, F23 was just under 8...) 15:19:38 (uh under 9 i mean) 15:19:46 F20 was ...4? 15:19:47 #topic Fedora 27 planning 15:19:58 2013-08-20 branch to a 2013-12-17 release? 15:20:00 since we're talking about the 27 schedule anyhow... 15:20:06 roshi: he's not measuring branch to release 15:20:13 he's measuring branch of the *previous* release to release 15:20:18 aha 15:20:28 (at the point N branches, we can say that rawhide 'is' N+1, to some extent) 15:20:35 kk 15:20:52 I was thinking those numbers seemed much larger than I recall actually having to work on them 15:20:56 from the QA side 15:21:21 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 roshi: but from the schedule, f20 *was* that short actually 15:21:47 oh wait no it's just not written the same way on the schedule page 15:21:51 *confusing* 15:22:07 welp 15:22:15 however long we have to do it, we have to test this thing somehow! 15:22:25 so, we've got some major changes coming up in the f27 cycle 15:22:42 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 Sure. 15:24:13 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 #chair mattdm 15:24:15 Current chairs: adamw mattdm 15:24:18 #chair roshi 15:24:18 Current chairs: adamw mattdm roshi 15:24:37 but the really big changes are: 15:24:50 1. Dropping the alpha. Whooo. 15:25:04 2. Arbitrary branching, and possibly building actual Fedora Server from modularity 15:25:19 (I'm very concerned about whether the second part of that is really possible.) 15:25:39 3. CI for Fedora Atomic Host (including possible _gating_ of commits) 15:26:15 I'm not clear on how much arbitrary branching will affect F27 outside of modularity and server as separate things 15:26:44 so does anyone want any of those things / terms explained? 15:28:14 arbitrary branching .. any link where I can read about it? 15:28:29 #link https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching 15:28:40 thanks mattdm 15:29:51 Initially, I think we'll just have *modules* in non-fNN-named branches 15:30:01 but there's the potential for RPMs to use the same thing 15:30:07 but that's scary :) 15:30:16 so far as 'dropping the Alpha' goes, we are still working on the details of that 15:31:09 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 seems like more than that is currently being detailed :p 15:31:39 #info F27 big change #1: dropping Alpha 15:32:02 https://fedoraproject.org/wiki/Changes/NoMoreAlpha 15:32:12 #info F27 big change #2: arbitrary branching and modular Server 15:32:17 https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching 15:32:36 https://fedoraproject.org/wiki/Changes/Modular_Server 15:32:47 #info F27 big change #3: CI for Atomic Host 15:32:55 https://fedoraproject.org/wiki/CI 15:33:13 https://fedoraproject.org/wiki/Changes/FedoraAtomicCI 15:33:21 (not a real change page, it seems, but has the info) 15:33:41 so those aren't exactly 'features' that we can 'test', really, but major process changes we'll have to adjust to 15:34:06 roshi, are you up to speed on the Atomic CI stuff? 15:34:33 tbh, it's kinda hard to tell what percentage of the information I'm privy to 15:34:47 rough order of activities: 15:35:05 1) port internal RH tests to Upstream 15:35:24 https://roshi.fedorapeople.org/upstreamfirst 15:35:29 ^ status of that effort 15:35:46 2) Do CI with those tests 15:36:29 I don't know/have any real details on what the CI is going to look like 15:37:04 okay 15:37:08 i guess tflink may know a bit more\ 15:37:19 still, that's probably the one with the *least* impact on us directly i woulds ay 15:37:25 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 afaik, it's still being sussed out 15:37:32 it's just major work going on in the timeframe 15:37:39 yeah, CI is a devel effort, not a QE effort - or so I've been told 15:38:11 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 taking them one at a time 15:38:45 so for that, the upstream first initiative is the biggest one that affects us - but we're really just tracking status 15:38:59 and being ready to answer questions and help point people in the right direction 15:39:19 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 #action adamw to draft up some proposals for adjusting QA processes, policies etc. to lack of Alpha release 15:39:38 adamw++ 15:39:38 mattdm: Karma for adamwill changed to 3 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:39:51 \o/ foolishness 15:39:55 inorite 15:40:33 #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 again i already have that on my todo list via the Server WG... 15:40:52 #action adamw to look into adjustments to Server validation for Modular Server 15:41:13 and for #3, I don't think there's anything we specifically need to do, as roshi said 15:41:20 other thoughts? anyone have ideas about #1 or #2? 15:42:07 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 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 #2 worries me a bit WRT to support tooling but hopefully that'll be figured out before they become problems 15:42:39 mattdm: me too, i'm not sure we have a way out of it on such a short timeframe though :/ 15:43:06 tflink: when you say 'support tooling'...? 15:43:28 adamw: thing that assume fedora release based on dist-git branch 15:43:30 things 15:43:43 most of it is well out of our control, though 15:43:57 the only thing I know of is taskotron related 15:44:06 I think the alpha stuff just gets turned into the CI criteria for releasing a nightly rawhide, right? 15:45:02 roshi: I agree with "criteria for nightly rawhide" but let's be careful with terminology for CI 15:45:18 tflink: ah, you're thinking of the arbitrary branching part, i see 15:45:29 yep. wasn't that #2? 15:45:31 the no more alphas, is because rawhide shouldn't have any bugs that would block alpha, right? 15:45:35 or did I miss something 15:45:39 roshi: well in theory yes, but there are *some* alpha criteria it'd be hard to automate 15:45:52 at least, iirc there are. i'm gonna have to go through the list and see. 15:45:53 good thing we're not writing the code then :p 15:46:29 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 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 beaker is supposed to handle that bit, for the bare metal testing 15:47:09 (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 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 ah 15:48:09 adamw: for that question: can we keep tracking them in the Blocker Bugs app? 15:48:17 so I would say those "hard to automate" criteria just get moved to Beta 15:48:24 we could, yeah. we'd have to make some adjustments to call it...something else. 15:48:33 yeah that was what I was just typing :) 15:48:47 since they're not actually _blocking_ anything in a meaningful way 15:49:13 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 and not release the compose if there are any 15:49:48 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 What does "not release the compose" mean? 15:50:02 well, that's how this whole thing is going to work 15:50:34 people can still get to the "non released" bits to test and work on fixing the problems, right? 15:50:39 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 *nod* 15:51:07 and the kojipkgs tree will be there for people who need it 15:51:16 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 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 still, we don't have to decide it all right now 15:52:00 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 or do we want everyone downloading from koji? 15:52:27 roshi: that's not really it 15:52:38 we sync *candidate composes* to *stage* to help with distribution 15:53:06 we sync nightlies to development/rawhide and development/27 or whatever because...that's how we 'release' rawhide and branched 15:53:18 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 in general, very few people do anything with non-'released' nightly composes 15:53:56 ah, ok 15:54:02 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 but that's all kinda stuff to keep an eye on in future, i think 15:54:43 yeah. 15:55:45 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 so i didn't want to inflict all that reading on anyone 15:56:41 we should probably go through the 'regular' f27 changes soon too 15:56:50 but i hope this gave everyone an understanding at least of the 'big stuff' that will be coming up 15:56:59 #topic Storage test matrix update status 15:57:02 * sumukher nods 15:57:23 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 that was supposed to get done last cycle 15:57:58 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 yeah, I thought it was just waiting on review after sumukher and I drafted them up 15:58:55 sumukher: whoops, i guess i was looking for a mailing list post 15:58:58 if there was one, i missed it 15:59:28 #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 thanks you two 15:59:38 #topic Open floor 15:59:43 anyone have anything else, in the last 20 seconds? :P 15:59:50 sumukher++ for doing most of the work :) 15:59:56 sumukher++ 16:00:04 * satellit is there a working live f27 build? 16:00:14 its sumantrom roshi :D 16:00:20 oh, i see the change date on the ticket - "6 hours ago". now i feel less bad for missing it. :P 16:00:22 aha 16:00:30 sumantrom++ 16:00:30 roshi: Karma for sumantrom changed to 1 (for the f26 release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:00:32 thanks :) 16:00:46 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 adamw roshi sent out the test day email , awaiting approval 16:01:12 awesome, thanks 16:01:14 kk 16:01:28 thanks wks failed to boot latest from koji after install 16:01:46 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 quick question about the matrix 16:02:28 tenk fire away 16:02:30 i have seen that LXQt is a new spin but not a lot of things to test on the tet matrice 16:03:11 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 sumukher: sounds like a good idea, thanks 16:03:44 we can add lxqt to the 'non-blocking environments' in the desktop matrix 16:04:03 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 do you two want to contact the lxqt spin maintainer and propose an lxqt spin test day? 16:05:15 I did *try* to get in touch with him, lupinix responded but then we lost touch 16:06:54 maybe try again? :) 16:07:06 #action adamw to add lxqt to desktop test matrix 16:07:12 (there, an easy one :>) 16:07:20 #action sumukher and tenk to look into setting up an lxqt spin test day 16:08:07 * adamw sets fuse 16:08:11 thanks for coming everyone 16:08:17 adamw, sure 16:09:16 #endmeeting