15:01:34 <adamw> #startmeeting Fedora QA Meeting
15:01:34 <zodbot> Meeting started Mon Sep  9 15:01:34 2019 UTC.
15:01:34 <zodbot> This meeting is logged and archived in a public location.
15:01:34 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:34 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
15:01:39 <adamw> #meetingname fedora-qa
15:01:39 <zodbot> The meeting name has been set to 'fedora-qa'
15:01:43 <adamw> #topic Roll call
15:01:46 <bcotton> .hello2
15:01:47 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:55 <adamw> goooood morning everybody
15:01:56 <tablepc> .hello2
15:01:57 <zodbot> tablepc: tablepc 'Pat Kelly' <pmkellly@frontier.com>
15:01:57 <frantisekz> .hello2
15:01:59 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
15:02:03 <cmurf> .hello
15:02:04 <zodbot> cmurf: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
15:02:08 <adamw> once again bcotton defends his 'fastest hello' title
15:02:09 <dan1mal> .hello2
15:02:10 <zodbot> dan1mal: dan1mal 'Danny Lee' <dreamer@panix.com>
15:02:10 <cmurf> that's new
15:02:21 <cmurf> .hello2
15:02:22 <zodbot> cmurf: Sorry, but you don't exist
15:02:22 * kparal is here
15:02:27 <cmurf> that's what i was after!
15:02:33 <cmurf> .hello chrismurphy
15:02:34 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
15:02:40 <bcotton> adamw: i have to be good at *something*
15:02:45 <coremodule> cmurf, try .holados
15:02:52 <cmurf> .holados
15:03:02 <cmurf> pff i fell for it!
15:03:06 <coremodule> *doh* i wasn'
15:03:09 <coremodule> t serious!~
15:03:15 * satellit_ listening
15:04:30 <adamw> .bonjour
15:04:38 <adamw> how's everyone doing?
15:04:53 <tablepc> O Genki desu
15:05:36 <tablepc> (full of energy)
15:05:54 <frantisekz> it was all fine, but I am starting to be sad a little, after looking at stuff and seeing F31 Beta is going to be delayed :/
15:05:58 <frantisekz> :D
15:06:08 <adamw> controversial!
15:06:12 <cmurf> no sad pandas!
15:06:31 <adamw> alllrighty, let's get rolling
15:06:34 <adamw> #topic Previous meeting follow-up
15:07:04 <adamw> #info "adamw to start a discussion about btrfs question with anaconda and kernel teams to consider the idea of removing or hiding it in the installer" - I did that, and it turned into a pretty big discussion that's still ongoing. I'll try and get down to practical proposals when possible
15:08:09 <adamw> we also have: "coremodule and/or kparal to check with coreos team and update us on current status and plans for automated ec2 testing"
15:08:09 <coremodule> buttery-goodness
15:08:11 <adamw> coremodule, kparal?
15:08:28 <kparal> yes, that happened
15:08:32 * kparal gets a link
15:08:56 <kparal> https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/thread/TOGJ5K7HM3OXNLIYZV3IEPCQ5YGY3JXV/
15:09:45 <kparal> so tldr: they don't test on EC2 automatically yet, but should be soon
15:10:16 <adamw> #info "coremodule and/or kparal to check with coreos team and update us on current status and plans for automated ec2 testing" - this was done and the answer was 'not yet but soon', see https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/thread/TOGJ5K7HM3OXNLIYZV3IEPCQ5YGY3JXV/
15:10:46 <adamw> it would be good i guess to dig a little deeper into 'what instance types will those tests run on', but that's also something we can ask them to tweak down the road i figure
15:11:39 <adamw> any other followup from last week?
15:11:42 <adamw> er, last time
15:11:59 <kparal> adamw: "We default to using m4.large instances, but it's configurable via CLI flag."
15:13:14 <adamw> yeah, i meant we could dig in further beyond that :)
15:14:30 <kparal> that would require someone who actually knows what he's talking about...
15:14:42 <adamw> when has that ever stopped us before?!
15:14:50 <kparal> true
15:15:56 <adamw> alrighty then, moving along
15:16:43 <adamw> #topic Fedora 31 status
15:18:00 <adamw> so, f31 status is "not bad"
15:18:07 * satellit_ soas "does not login to liveuser"
15:18:12 <adamw> several of the more prominent blockers got fixed since last week, but we still have several on the list
15:18:35 <adamw> cmurf, is https://bugzilla.redhat.com/show_bug.cgi?id=1745554 still happening for you with the 3.33.92 megaupdate?
15:18:49 <adamw> oh doh sorry
15:18:53 <adamw> that's lruzicka's bug not yours
15:19:29 <cmurf> powersave/blank problem is not happening, logout problem still happens
15:21:20 <adamw> ok
15:21:46 <adamw> so, yeah, in general i'd say f31 status is that stuff more or less works, we are working through the blocker list, i'm not aware of any big systemic issues at this point
15:22:12 <adamw> well. hm
15:22:58 <adamw> there is the default module stream upgrade issue, i guess.
15:24:25 <adamw> sgallagh: ping?
15:24:28 <zodbot> adamw: Ping with data, please: https://fedoraproject.org/wiki/No_naked_pings
15:24:40 <adamw> you're not my mom, zodbot! you don't get to tell me what to do!
15:25:15 <pingou> don't be mean, it's trying its best
15:25:30 <sgallagh> adamw: I’m in training this week. Can’t really respond, sorry
15:25:38 <sgallagh> Try contyk
15:25:49 <adamw> contyk: ping with data
15:26:01 <adamw> hah. stupid zodbot! your stupid brain is so stupid.
15:26:07 <contyk> yo
15:26:17 <adamw> contyk: so, this is the QA meeting, we're on 'f31 status'
15:26:21 <dan1mal> I've been seeing more articles about robot abuse, and watching my friends' kids talk to alexa....its real.
15:26:38 <adamw> one thing i'm wondering is, where are we with the problem of default module streams changing between releases? i.e. specifically libgit2?
15:26:39 <coremodule> lol
15:27:29 <contyk> adamw: nowhere yet; there were some ideas on how this could be handled, e.g. recording the preference of "whatever the default is" when you enable a stream but it needs more work
15:27:59 <adamw> so...for now we have a module which changed default stream between releases, but no mechanism in place for handling that? okay. we'll have to think about that
15:28:50 <contyk> adamw: I think the module provides compat packages to work in either case?
15:28:53 <adamw> #info the 'default module stream upgrade problem' is not yet resolved or really being actively worked on (that is, the situation like libgit2 where the default module stream changes from one release to the next but this cannot be 'followed' on upgrade)
15:29:11 <adamw> contyk: hmm, i'm not sure. i'm pretty sure i had a problem with it when i upgraded this system
15:29:16 <adamw> but maybe they've changed since...
15:29:19 <frantisekz> hmm, recording the preference, I remember talking about that with dnf team, they said no (and I understand why, but that's for some other meetings)
15:29:56 <adamw> #info aside from that, f31 status is 'generally OK without major systemic issues', blocker bugs are being addressed one by one
15:30:01 <adamw> anything else on f31, folks?
15:30:09 <contyk> that'd be the only way forward but as I said, it needs more work, especially in the UX
15:30:18 <contyk> then all the corner cases when modules are somehow enabled for you
15:30:18 <adamw> as always, please test the candidate composes and file results in the wiki :)
15:30:23 <contyk> then DNF needs to support it
15:32:15 <adamw> #topic Criteria proposals: Xen / EC2, btrfs
15:32:25 <adamw> (not 'Criterial proposals' as I wrote in the agenda...)
15:33:20 <adamw> so, for xen/ec2...given what we heard back from coreos team...i think i might suggest that for now we go ahead with replacing the existing xen criteria with an ec2 criterion and a fairly small range of expected instance types to be tested by hand
15:33:26 <adamw> we can always extend the set later for automated testing
15:33:32 <adamw> thoughts?
15:34:01 <kparal> who's going to test those?
15:35:12 <adamw> whoever's handy, like the other tests?
15:35:37 <kparal> how do we get access to AWS?
15:35:42 <adamw> a bit of a problem right now is that the Cloud images are technically still our release-blocking cloud-y deliverables, but all the active work is really on coreos
15:36:09 <adamw> ask amazon nicely? :D
15:36:43 <adamw> seriously, though - i think RH has some sort of arrangement with amazon already, i think we may either already have some test account access or be able to set it up
15:36:49 <bcotton> should the fcos folks submit an f32 change proposal to drop cloud as release-blocking and add fcos?
15:36:51 <kparal> ok, next time I see an empty test matrix, I'll send an email to support@amazon.com starting with "pretty please"
15:36:58 <bcotton> kparal++
15:36:58 <zodbot> bcotton: Karma for kparal changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:37:04 <adamw> i approve!
15:37:13 <adamw> but i guess we should check with whoever's technically responsible for cloud at this point and anyone else who might know
15:38:15 <adamw> bcotton: well, it's slightly more complicated than that in that coreos is I think going to follow the 'two-week Atomic' release style, right?
15:38:37 <adamw> that makes things fuzzy because it means the images actually in the traditional 'every X months' release aren't terribly important
15:38:42 <bcotton> afaik, but they don't tell me much :-)
15:38:58 <adamw> we need to re-engineer the process documentation to kinda cope with this split release schedules approach but that has never got done
15:39:00 <bcotton> alternately, we can just drop cloud as release blocking if it's not getting love
15:39:22 <adamw> eh, i'm not in love with that either
15:39:24 <adamw> sigh, things are hard
15:39:32 <bcotton> aye
15:39:56 <adamw> #action adamw to poke some people about whether we have or can set up an account for EC2 testing so people don't have to spend money to test it
15:41:21 <coremodule> adamw, what I used to do for EC2 testing is get an account with amazon, then just make sure that I use under the minimum chargeable cap for bandwidth... which I think was like 2gb/month. As long as you delete the machines after you test them, its totally free...
15:41:23 <adamw> #info on btrfs, the discussion branched out quite a long way and we're still working towards concrete proposals
15:41:26 <dan1mal> Perhaps this could be an avenue: https://aws.amazon.com/government-education/nonprofits/
15:41:42 <coremodule> and even when I forgot to delete the machines, the total was like $3USD...
15:42:45 <adamw> on btrfs it seems like there's still generally a consensus for not blocking on it any more, somehow
15:42:55 <adamw> but we need to pin down the details of exactly how to get there, and whether that involves removing or hiding it in the installer
15:44:57 <cmurf> well actually kernel and anaconda teams aren't exactly on the same page
15:45:09 <cmurf> kernel folks are saying, if you find people to support it properly it can block
15:45:45 <cmurf> anaconda won't answer the question, if people will support it, will you merge the patches; they're sticking with 'btrfs is not a priority' coded language instead
15:47:18 <cmurf> and they want the issue taken to fesco - so there's actually a process and policy issue going on here way outside the scope of carving out criterion
15:47:35 <adamw> where are you getting this?
15:47:47 <adamw> there's a lot of emails, i did not catch any references to fesco yet
15:48:39 <cmurf> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/DKKSIOJ5TGS67AT7JS2N4RVNXRUKHPEM/
15:49:49 <adamw> ah. note, dcantrell is not actually on the installer team any more, AFAIK.
15:50:33 <adamw> of course, he still gets to have opinions :) but i believe that's his personal opinion, not representative of a fedora team. at least that's my best understanding.
15:50:42 <adamw> (not that it's necessarily a bad idea.)
15:51:41 <cmurf> FESCo already said it's a working group decision, kernel team already said it's a working group decision, working group decided
15:51:57 <adamw> that was all several years ago, though, right?
15:52:41 <cmurf> hilarious - when people bring up this subject once per year, they get told 'we're sick of talking about this every year' and then it goes three years and it's 'oh that's old news, expired'
15:53:01 <adamw> well, that's not really what this is
15:53:03 <cmurf> It's in the technical specification.
15:53:16 <adamw> a specific proposal was made to stop blocking on btrfs
15:53:42 <adamw> no-one said 'we're sick of talking about it every year'
15:54:07 <cmurf> actually yeah the kernel team did
15:54:20 <adamw> past decisions are never stone tablets in fedora, so if someone proposes something that's somehow in conflict with a past decision it seems reasonable to interpret it as a suggestion to revisit that decision
15:54:28 <adamw> ? the kernel team are the ones who suggested not blocking on btrfs any more in the first place.
15:56:01 <adamw> (though, this does bring up a good point - as btrfs is mentioned in the workstation tech spec, have we heard from workstation yet?)
15:56:15 <adamw> for the record, the mention dates to early 2014.
15:56:40 <tablepc> Can the blocking status be removed even if Anaconda can't/won't be modified? If not I don't understand the point.
15:57:05 <adamw> tablepc: yeah, it can
15:57:30 <adamw> technically it's very easy: we basically just add "EXCEPT BTRFS!" to the existing criteria and call it a day
15:57:45 <adamw> i don't think that's a *great* outcome, but it is logically consistent and enforceable
15:58:19 <adamw> whoops, we are also close to time
15:58:31 <adamw> i guess we'll have to carry this on next time
15:58:34 <adamw> (and on the lists)
15:58:40 <adamw> #topic Open floor
15:58:47 <adamw> #info jumping ahead to open floor due to lack of time
15:58:56 <adamw> any important business we need to deal with>?
15:59:54 <kparal> nope, all my important stuff went to blocker bugs :)
16:00:24 <adamw> tablepc: i was gonna mention your unmount thing but let's follow up on list
16:00:45 <tablepc> Okay
16:01:10 <adamw> blocker review is starting up now in #fedora-blocker-review
16:01:40 <coremodule> .hello2
16:01:41 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:01:49 <coremodule> forgot to do that
16:06:50 <adamw> thanks for coming, folks
16:06:52 <adamw> #endmeeting