16:01:49 #startmeeting Fedora QA Meeting 16:01:49 Meeting started Mon Feb 11 16:01:49 2019 UTC. 16:01:49 This meeting is logged and archived in a public location. 16:01:49 The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:49 The meeting name has been set to 'fedora_qa_meeting' 16:01:51 #meetingname fedora-qa 16:01:51 The meeting name has been set to 'fedora-qa' 16:01:53 #topic Roll call 16:02:04 * sumantro is here 16:02:34 morning folks 16:02:39 who's around for meeting funtimes? 16:03:00 hey adamw! I'm 16:04:07 .hello2 16:04:08 frantisekz: frantisekz 'FrantiĊĦek Zatloukal' 16:04:59 A fragment of cmurf is here, not sure where the others went. 16:05:10 .hello gkaukola 16:05:11 GlenK: gkaukola 'Glen Kaukola' 16:05:36 cmurf: oh dear. and our cmurf catcher is off sick today, too... 16:05:39 hi glen! 16:05:50 frantisekz: where's everyone else? birch meeting room? :D 16:06:12 .hello2 16:06:13 bcotton: bcotton 'Ben Cotton' 16:06:21 * bcotton is lurking while paying actual attention to FESCo meeting 16:06:47 hi ben 16:07:51 adamw: kparal has gone home, lruzicka is on PTO, lbrabec is here :) 16:08:17 .fire kparal 16:08:17 adamw fires kparal 16:08:31 coremodule: tflink: ping? 16:08:51 sorry, wasn't paying attention 16:09:05 .fire tflink 16:09:05 adamw fires tflink 16:09:06 :D 16:09:53 well with all the fired people, it should be a short meeting before blocker review :D 16:09:54 works for me, now I can continue not paying attention :-D 16:10:16 .fire frantisekz just cuz 16:10:16 adamw fires frantisekz just cuz 16:10:29 alrighty, let us proceed with our highly efficient meeting! :) 16:10:34 :'( ... lbrabec_ , let's go birch then... 16:10:37 * tflink is suddenly suspicious that adamw is trying to make this meeting incredibly short 16:10:43 #topic Previous meeting follow-up 16:11:24 "lruzicka to look at implementing app start/stop test for KDE and possibly Xfce next, then consider more extensive testing of core apps" 16:11:29 since he's PTO, i'll get this one 16:11:59 lruzicka has something wip... don't know if he made pr yet though 16:12:02 #info "lruzicka to look at implementing app start/stop test for KDE and possibly Xfce next, then consider more extensive testing of core apps" - this has been delayed because changes in Rawhide broke the GNOME test twice, and lruzicka has had to spend his time fixing that instead 16:13:14 #info "adamw to contact sumantro about Changes that are obvious test day candidates" - sorry, this one fell through the cracks, will make sure to take a look at the list this week 16:14:14 .hello2 16:14:14 lbrabec: lbrabec 'Lukas Brabec' 16:14:35 hi lukasb 16:15:54 #topic Fedora 30 status and Change review 16:16:23 so, the mass rebuild has now been done, signing was a problem for a while due to a signer machine dying at just the wrong moment, but that's all cleaned up now, and we have a compose 16:16:47 the compose completely failed openqa because apparently an icon on the hub screen got slightly less black, or something? i only had a minute to look at it before the meeting so will fix that up in a minute. 16:18:15 'fedfind images' is no longer a one liner! yes! 16:19:05 hmmwhat? 16:19:07 oh right 16:19:08 heh 16:19:44 #info mass rebuild is complete and a post-rebuild compose is available, we don't know how well it works yet due to an openQA needle issue 16:21:21 we are now past all Change proposal deadlines 16:21:58 #info the Change list at https://fedoraproject.org/wiki/Releases/30/ChangeSet should now be fairly complete, barring a few self-contained Changes still undergoing review, I believe 16:22:20 there are a few changes still pending approval from FESCo, which should happen today 16:22:33 and two late changes that will be submitted to fesco today :-( 16:22:43 nevermind, i lied 16:22:49 auto-rejected! 16:23:01 nothing submitted to them, i just didn't update the title of the item on my todo list :-) 16:23:21 of ones we didn't discuss last time, a couple catch my eye: 16:23:22 https://fedoraproject.org/wiki/Changes/Zchunk_Metadata 16:23:34 https://fedoraproject.org/wiki/Changes/SwitchCryptsetupDefaultToLUKS2 16:24:24 the former could plausibly cause buggy dnf behaviour, the latter we should check it all works as intended with various boot methods and rescue mode 16:24:30 and testing both on upgrade would be good too. 16:25:04 adamw both can be test day candidates right? 16:26:49 * nirik notes the zchunk metadata has been enabled in rawhide for a while, but not sure if all the support landed yet 16:27:06 sumantro: i'm not sure about zchunk, encryption probably yes 16:27:19 i think zchunk is more a kind of "look out for issues in daily use" thing 16:27:30 and be aware of it when thinking about what might be causing some bug or other that you come across 16:27:32 biggest gotcha with LUKS2 will be if someone does an F30 install but tries to rescue with something other than F30 media for a while 16:27:56 cmurf: good point, that should probably go in the docs... 16:28:07 can i ask you to point that out to docs team or something? 16:28:40 also I had to untag some things to get rawhide to compose... so might be some more rocky waters ahead until those things are actually fixed. 16:29:11 yessir 16:29:47 nirik: do you have bug #s or anything for those so we can track them? 16:30:08 I didnt file an anaconda one, I guess I should have... 16:30:23 #action cmurf to ask docs team to make sure F30 docs talk about effect of LUKS2 encryption on using older releases' rescue mode on F30 installs 16:30:26 https://bugzilla.redhat.com/show_bug.cgi?id=1674322 was one 16:30:42 * nirik goes to file the anaconda one 16:30:58 cmurf: Release Notes issue for that change is https://pagure.io/fedora-docs/release-notes/issue/282 16:32:23 hey, free action item :D 16:32:26 cmurf.... but, cryptsetup in F29 is already capable of handling LUKS2 imo... 16:32:46 so... it should handle it just fine if i am not mistaken 16:32:56 it's just not default 16:33:38 frantisekz: good point - the official media will have an older version of cryptsetup, it's vaguely possible there's been a format change since then only accounted for in updated versions 16:34:11 it would probably be a good idea to just go check :D 16:34:12 I'll make a note of that and ask upstream if that's true or false 16:34:16 and there's F28 too of course. 16:34:23 I don't think it's in F28 16:34:51 at least through updates, there is cryptsetup 2.0.6 16:35:05 LUKS2 was released as a beta in cryptsetup 2.0 but I don't know what subversion of 2.0 LUKS2 stabilized 16:35:07 I can check what's on media, but I think it should support luks2 too 16:35:17 I can ask the maintainer 16:36:09 yeah i'd ask "minimum recommended for user recovery" rather than an absolute minimum "it'll work, maybe, dunno, yeah it should" 16:36:20 #action frantisekz to check if F28/F29 support mounting and interacting with LUKS2 created by F30 installation 16:36:32 i'd recommend just testing it :D 16:36:43 I will bet donuts that F28 anaconda has no idea about it 16:37:37 alrighty, so, let's move on and try to get through the agenda... 16:37:39 for rescue it might not need to, I've been using LUKS2 for a few drives for a while they unlock with the same cryptsetup commands as before, only the format command changes 16:37:48 yes move on 16:38:12 #topic Release criteria / test case proposal status 16:39:45 sorry, just digging up the referencs 16:40:11 so, we have a few proposals that are kinda hanging 16:40:53 there was a proposal from jlanda to block on cron 16:41:04 which got two mostly-positive responses, but then stalled 16:41:26 jlanda: are you around? 16:41:34 https://bugzilla.redhat.com/show_bug.cgi?id=1674605 (anaconda bug) 16:41:39 thanks nirik 16:42:06 #info jlanda proposed blocking on broken cron in November 2018, proposal received two positive responses but then stalled 16:42:40 the proposal was basically to have a criterion requiring cron to work as expected, simply put. anyone have thoughts on that? 16:44:59 I will support it 16:46:35 there's also an outstanding proposal to block on printing, which i asked sgallagh to re-push but he didn't get around to yet i guess 16:46:39 sgallagh: around? 16:46:47 -ish 16:47:07 any chance you could follow up on that? 16:47:14 I could have sworn I started a thread on that that didn't go anywhere productive. Am I misremembering? 16:47:26 the mail i'm looking at is from 2018-11-16 which says 16:47:29 (by me) 16:47:34 "So as with the optical media proposal we had quite a lively discussion 16:47:34 on this one, then it got stuck a bit. Stephen, can you take a look at 16:47:34 all the followups and either restate or revise the proposal? Thanks!" 16:47:41 do you recall poking it after that? I don't see any follow-up 16:47:56 could we make the criterion a bit more generic than cron without making it useless? that kind of logic seems like it could apply to more things than just cron 16:48:18 tflink: that's more or less what kparal said, but...i dunno how to make it generic without being too vague and causing us to make judgment calls all day long 16:48:22 adamw: Entirely possible that it fell off my radar. That was an extremely over-busy period 16:49:00 sgallagh: fair enough - basically i wanted to give you the opportunity to either consider some of the feedback and revise, or say 'nope i still think the original proposal is good', and then we could make a call on it after 16:49:29 tflink: if you *can* think of a way, though, maybe reply to the thread :) 16:49:30 adamw: maybe a list of long-time common tools? tar, curl etc. instead of not limiting it to a single program 16:49:41 or am I just repeating more of what has already been suggested 16:50:05 that sounds way too much like work to me ... 16:50:05 kparal said "In desktop, we say that all 16:50:05 preinstalled apps must work at least in their basic functionality. I wonder 16:50:05 if we can do the same with server/command line environment. Something like 16:50:05 "all command line tools that are installed by default and are considered 16:50:07 :) 16:50:08 'basic', i.e. most power users know them and use them, must work at least 16:50:08 in their basic functionality"." 16:50:17 which, yeah, i just worry it's a bit vague 16:50:25 there's a *LOT* of command line tools 16:50:38 we'd be letting ourselves in for a whole world of 'basic functionality' decisions 16:50:39 anyhoo 16:50:48 yeah, that sounds like no fun at all 16:50:57 * tflink moves to list 16:50:59 i think i sort of like the straightforward cron criterion, for now... 16:52:28 #info sgallagh proposed a printing criterion that prompted some lively discussion, we asked if he could consider the feedback and revise or restate it in November, he was very busy at the time but will try to get to it now 16:52:45 isn't the thread from 2018-11-19, not 2018-11-16 or am I missing something? 16:52:53 nvm 16:52:54 I'm currently rereading that thread and I'll update it 16:53:03 * tflink blames jet lag and getting home late last night 16:53:11 I think I'll make a couple minor tweaks, but it seems mostly acceptable as-is 16:53:35 #info similarly, mattdm proposed we drop optical media from the release criteria and that also prompted a lot of discussion, we asked matt to revise that proposal also in November but he didn't get to it yet 16:53:44 #action adamw to ping mattdm re optical media criterion proposal 16:53:52 mattdm: are you around by any chance? 16:54:57 My 2 cents: QA to stop testing it, let users test it and if a problem is found it'll be a blocker. Something like that. 16:55:10 i'm arond for five minutes 16:55:47 I definitely don't have "revise that proposal" on my radar for things I need to do, so thanks for the reminder :) 16:55:54 Back in ancient times when I tested the optical criterion, I used DVD-RW so I wasn't making a coaster each time. 16:57:17 adamw: OK, replied with minor updates. We'll see where that goes. 16:57:20 cmurf: i still hate that idea on the grounds it's a great invitation to findin blockers at the last minute 16:57:21 sgallagh: thanks 16:57:32 mattdm: consider yourself reminded :) 16:57:33 #undo 16:57:33 Removing item from minutes: ACTION by adamw at 16:53:44 : adamw to ping mattdm re optical media criterion proposal 16:57:51 alrighty, that's the main outstanding things, so let's give sumantro two quick minutes 16:57:57 The kernel 4.20 test day happened witha a lot of testers participating. The upcoming test days are Gnome 3.32 test day is on 2019-02-25 , followed by Fedora IoT edition Test Day on 2019-03-13 and i18n on 2019-03-19. There are a lot of new introduction emails and there will be an on-boarding call somewhere mid of March. 16:58:09 #topic Test Day / community event status 16:58:21 #info kernel 4.20 Test Day is complete, with good participation 16:58:33 #info upcoming test days are Gnome 3.32 test day is on 2019-02-25 , followed by Fedora IoT edition Test Day on 2019-03-13 and i18n on 2019-03-19 16:58:38 #info there will be an on-boarding call somewhere mid of March. 16:58:39 adamw: new concept, weak blockers (i.e. if found inside a certain window of time before final release, it is not a blocker) 16:58:41 thanks sumantro! 16:58:53 adamw, np :) 16:59:00 cmurf: we sort of have that actually (we added some weasel wording to that effect a few cycles back) but i still don't like *inviting* the problem 16:59:10 any questions on community events? 17:01:35 nothing from my side 17:02:19 adamw, we will have some more test days in between these and I will update them on the calendar 17:02:47 ok, cool. 17:02:49 alright, we're over time 17:02:57 did anyone have anything else mega-urgenty? 17:04:33 in that case, thanks for coming, everyone! 17:04:35 #endmeeting