16:01:03 <adamw> #startmeeting Fedora QA Meeting
16:01:04 <zodbot> Meeting started Mon Dec  9 16:01:03 2019 UTC.
16:01:04 <zodbot> This meeting is logged and archived in a public location.
16:01:04 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:04 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
16:01:07 <adamw> #meetingname fedora-qa
16:01:07 <zodbot> The meeting name has been set to 'fedora-qa'
16:01:10 <adamw> #topic Roll call
16:01:16 <adamw> morning lovely qa people...and cmurf
16:01:19 <cmurf> .hello chrismurphy
16:01:20 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:01:21 <cmurf> :D
16:01:38 * coremodule is here, good morning!
16:02:02 <tablepc> .hello2
16:02:03 <zodbot> tablepc: tablepc 'Pat Kelly' <pmkellly@frontier.com>
16:02:38 <frantisekz> .hello2
16:02:39 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:03:16 <adamw> hi hi hi
16:03:18 <adamw> how's everyone doing
16:03:55 <tablepc> Great day and I'm not getting any typing help.
16:04:26 <adamw> my furry keyboard assistant is locked out for the moment...
16:05:07 <adamw> alrighty, let's get rolling
16:05:12 <adamw> #topic Previous meeting follow-up
16:05:21 <tablepc> There are four little hands here attached to twin 2.5 year old boys
16:05:49 <adamw> 2.5 years? MORE than old enough to go work down the mines!
16:06:04 <cmurf> !
16:06:06 <tablepc> We mine chocolate
16:06:18 <adamw> #info "kparal to reply to the list with his suggestions for revisions to the proposed shutdown test case" - he did this, and we'll be coming back to the topic later
16:06:31 <lruzicka> .hello2
16:06:32 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:06:39 <adamw> #info "tablepc to do a new draft of the proposed test case after seeing kparal's suggestions" - this also happened, and once again we'll be coming back to it
16:06:42 <adamw> any other follow up?
16:06:47 <coremodule> this is 2019, almost 2020. we send them to the oil fields now.
16:06:50 <adamw> =)
16:07:14 <lruzicka> I apologize, but my wife is in hospital with our newborn and I have to keep an eye on the older one, so I might look here with one eye only.
16:07:51 <cmurf> lruzicka: one eye is a lot of dedication under those circumstances!
16:07:53 <tablepc> Congratulations!
16:10:55 <adamw> yup!
16:11:01 <adamw> sorry, just had to clean up a git explosion
16:11:03 <adamw> alrighty
16:11:18 <tablepc> Did it make a big mess?
16:11:21 <adamw> #topic Proposed asynchronous blocker review process
16:11:21 * tflink shows up late
16:11:35 <adamw> tablepc: eh, just a normal-sized one
16:12:05 <adamw> alright, so we have this list discussion going on about how we could possibly set up an 'asynchronous' blocker bug process instead of / alongside the 'synchronous' one
16:12:17 <adamw> that is, a way of reviewing and voting on blockers that doesn't require everyone to be in the same 'place' at the same time
16:13:00 <coremodule> adamw, in general, how do you feel about the proposal?
16:13:10 <adamw> we can already do this in a limited way by people just commenting in bugzilla with votes, but it's a bit messy and we historically don't do it a lot because some folks don't like the emails and comments that aren't really to do with fixing the bug
16:13:24 <adamw> i think it's worth giving the idea a shot and seeing how it goes
16:13:53 <adamw> i do think we should keep it to something light, simple and easy to change since we have the uncertainty over the future of various issue trackers
16:14:11 <adamw> what does everyone else think so far?
16:14:30 <coremodule> I like the idea too, I think we should still meet like we do usually, only to accept/reject the already voted for bugs.
16:15:36 <cmurf> if the async method can cut down live review to 2/3rds or even 1/2 of what it is now, that'd be a win I think
16:15:48 <coremodule> have to set a rule that no votes will be allowed or something like that (or only the revoking of a vote is allowed), but that way we have a real-time outlet for final questions/explanations.
16:16:52 <frantisekz> I am pretty much +1 for the proposal, we can decide on most of the blockers in an async way and deal with rest during the meeting, if there is something to discuss
16:17:39 <adamw> ok, it's sounding like we have a consensus here
16:17:51 <adamw> i haven't run any blocker review for f32 yet because we just haven't had a lot of blocker bugs requiring discussion
16:17:52 <tflink> I'm also +1 to the idea. I have my concerns about integration with another external system but it'll come down to total long term cost
16:18:29 <adamw> but sounds like we should give this a shot before we really ramp up f32 blocker review
16:18:46 <lruzicka> +1 too, I do not mind the meetings, but if we could cut on their time ... brilliant
16:19:26 <adamw> #agreed there is a solid consensus that the async blocker process proposal is a good idea and we should go ahead and give it a shot
16:19:28 <lruzicka> and thank you for congratulations :D
16:19:33 <adamw> gonna action kparal in his absence, i think he won't mind
16:19:46 <lruzicka> he won't, adamw
16:20:05 <adamw> #action kparal to go ahead and set up some version of the proposed process for a trial run for early f32 review
16:20:06 <cmurf> if the async portion is a chunk of bug discussion/clarification to prepare for meetings, that expedites meetings, that might be quite effective without needing substantially changed infrastructure?
16:20:21 <adamw> we'll have to see how it goes
16:20:23 <cmurf> ok
16:20:36 <adamw> i do think just doing the whole thing async is viable for several cases
16:20:55 <adamw> i think it's one of those things that will be easiest to sort out by actually doing it in practice
16:22:17 <adamw> #topic Proposed disk unmount test case
16:22:25 <adamw> so this has seen quite a bit of revision in the week :)
16:22:26 <tablepc> https://fedoraproject.org/wiki/User:Tablepc/Draft_testcase_reboot
16:22:37 <adamw> do you think it's currently ready, pat, or is it still being worked on?
16:23:26 <tablepc> The idea is to not have folks interpreting the results, but rather have the result more defined as a "yes or No"
16:24:10 <lruzicka> it has gotten rather shortened, since I last saw it.
16:24:15 <tablepc> I have only one question yet and that is about if we want to get "passno" for XFS and check it in some way?
16:24:37 <cmurf> no it's not applicable
16:24:57 <cmurf> XFS expects to do journal replay first, if that fails, then you have to manually run xfs_repair
16:25:08 <cmurf> fsck.xfs is a no op
16:25:13 <tablepc> I that case I don't know of anything more to do.
16:25:23 <cmurf> man fsck.xfs is kinda funny actually
16:25:45 <cmurf> "do nothing, successfully"
16:26:03 <cmurf> it's the same for btrfs
16:26:46 <adamw> hell, some mondays it'd take me four tries to implement 'do nothing, successfully' i think
16:27:06 <tablepc> Especially on Mondays
16:27:21 <cmurf> ext4 also does journal replay *if* it has a journal; because of the possibiity it doesn't is why I think there's still a startup time fsck by default
16:28:22 <tablepc> I never get a do nothing
16:28:59 <cmurf> ?
16:29:13 <cmurf> oh haha nevermind
16:29:16 <adamw> so i have a few proofreads on it
16:29:26 <tablepc> cmurf, did I cover all the items.
16:29:28 <adamw> but the overall approach now looks good
16:29:50 <adamw> i feel slightly worried about relying on error message text, though. error message text isn't generally considered 'api' by upstreams and can change without warning
16:30:22 <adamw> i might suggest we hedge a bit by adding an admon to say you can also go through the journal manually and look for suspicious errors from filesystems
16:31:05 <cmurf> makes sense
16:31:08 <tablepc> I can do that.
16:31:21 <adamw> #action adamw to send a reboot test case draft with some copyediting corrections to tablepc's draft
16:32:20 <lruzicka> adamw, for automation, we won't be able to manually check the logs though
16:32:36 <adamw> i think we're close to this being ready to go, though, thanks for all the work, tablepc, cmurf and kparal
16:32:44 <lruzicka> so if the test case says "check manually" then we will not be able to fully automate
16:32:49 <adamw> lruzicka: yeah, that's why i'd add it as an admon boxout, so the automated test doesn't *have* to do it :P
16:32:57 <adamw> it's all in the phrasing!
16:33:01 <lruzicka> adamw, cool :D
16:33:23 <adamw> any more on this before we move on?
16:33:41 <tablepc> Okay WHat's an admon box out?
16:34:17 <tablepc> I can read something later
16:35:16 <lruzicka> tablepc, it is something like a side note -> admonition (usually note, warning, error message, or somethin like that)
16:35:36 <tablepc> Okay thanks
16:35:46 <lruzicka> tablepc, it's used quite a lot in documentations
16:36:20 <adamw> tablepc: don't worry, i'll include it in my draft
16:36:34 <tablepc> I understand and use such from time to time. Just never saw that term before
16:36:39 <adamw> tablepc: it's one of those things you see in other test cases and the matrices where there's a colored box-out with a title and some info in it
16:36:48 <adamw> the wiki template is called 'admon' so I tend to call them 'admons' :P
16:37:02 <adamw> (it's short for 'admonishment' i think)
16:37:12 <tablepc> Okay thanks
16:37:16 <adamw> or admonition, yeah
16:37:34 <tablepc> I usually think of admon as "bad dog"
16:38:05 <lruzicka> tablepc, yeah .... I think it is close, because you usually pest users with boxes like that :D
16:38:11 <tablepc> but now I understand the local
16:38:34 <adamw> ok, moving on then!
16:39:02 <adamw> #topic F31 eclipse module default stream / protobuf issue
16:39:10 <adamw> so, did everyone hear about this?
16:39:29 <lruzicka> I might ... go ahead and I'll see
16:39:36 <tablepc> No I switched to THonny
16:40:16 <lruzicka> isn't it for F32?
16:40:49 <cmurf> yes i heard
16:40:52 <cmurf> affects f31
16:41:05 <tablepc> Should I go back to Eclipse so we can have more folks trying it out each rev?
16:41:39 <adamw> tablepc: i think we have enough folks with it already
16:41:43 <adamw> this got noticed pretty fast :)
16:41:47 <Southern_Gentlem> adamw, i saw it in updates for Mate in my updated isos
16:41:59 <adamw> so, for anyone who didn't hear about it...
16:42:45 <adamw> #info late last week, the eclipse module was given a 'default stream' for F31; this means that module stream was now the default source for all packages it contains, rather than the non-modular repos
16:43:34 <lruzicka> ok, I though this will be done in F32
16:43:45 <lruzicka> thought
16:43:47 <adamw> #info it turned out the module included a build of the protobuf package, with some features removed; so now we had a reduced-functionality protobuf as the default. this caused problems for folks who had anything that required the missing bits of protobuf installed
16:43:50 <adamw> it was done for both :(
16:44:25 <Southern_Gentlem> anyway to undo?
16:44:27 <lruzicka> sigh
16:45:09 <adamw> #info the default stream was quickly removed again, but the current implementation of modularity doesn't handle the removal of a default stream automatically - anyone who updated while it was set and got the module stream enabled is stuck with it until they deactivate the module manually
16:45:29 <frantisekz> so, that dnf module reset should help if I a m not mistaken?
16:45:33 <lruzicka> this should be explained in their documentation
16:45:40 <adamw> yeah, or dnf module disable
16:45:44 <lruzicka> dnf module reset will help, frantisekz
16:46:13 <lruzicka> disable is even better, if non-modular packages for protobuf and eclipse still exist
16:46:27 <frantisekz> anyway, I feel like there should be a way to do this defined by modularity spec/supported by dnf
16:46:50 <adamw> #info the official recommendation from modularity team is to run `dnf module disable eclipse` followed by `dnf downgrade protobuf`
16:47:17 <adamw> i think 'dnf distro-sync' might be a better second step, but i haven't yet checked for sure that it *works*, i'm not sure if distro-sync is 'module aware' (which is actually an interesting point on its own)
16:47:19 <lruzicka> which means, that there is no non-modular protobuf in the same version
16:47:34 <adamw> if distro-sync only cares if the *repo* is enabled or not, it won't resync modular packages, i think
16:48:18 <lruzicka> if you install modular packages and you disable the module, the packages still stay there.
16:48:25 <Southern_Gentlem> **glad i disabled modules by default **
16:48:58 <adamw> lruzicka: i mean, i'm interested what happens on a distro-sync
16:49:25 <adamw> whether dnf knows to consider which module streams are enabled or disabled in deciding what packages to up/downgrade on a distro-sync or if it only considers *repos*
16:49:31 <adamw> anyhoo, i guess i can play with that later
16:49:49 <adamw> i just wanted to flag the issue up for folks so you know it's happening, and what to recommend to help folks hit by it
16:49:50 <lruzicka> adamw, distro-sync, imho, will not install default modular streams, but it is a nice setup for a test
16:50:15 <adamw> lruzicka: i'm thinking of the case where you have packages from a module installed, then you disable the module, then run distro-sync
16:50:30 <adamw> will it know to down/upgrade the packages from the module to whatever's in the non-modular repos?
16:50:56 <adamw> that's obviously what it *ought* to do in that scenario, but i dunno if it *does*
16:52:11 <adamw> i suppose the other issue here is whether we have some comment/agreement on this situation as a team that we want to relay to modularity/fesco folks
16:52:38 <adamw> about fiddling with default streams in stable releases, for instance, or the fact that there's no mechanism for cleaning up a mess like this
16:55:47 <adamw> welp, let's leave it there for now
16:55:52 <adamw> lots of people have brought up those points on devel@ anyway
16:56:05 <cmurf> quick openfloor :D
16:56:13 <adamw> we're low on time and i think sumantro isn't here, so let's go straight to
16:56:15 <adamw> #topic Open floor
16:56:16 <adamw> yep :)
16:56:18 <adamw> anything?
16:56:20 <cmurf> .bug 1779570
16:56:38 <cmurf> uhh, ok well extensions busted in firefox
16:56:42 <cmurf> Martin Stransky 2019-12-09 13:12:21 UTC comment 36
16:56:44 <cmurf> firefox-71.0-14.npgo at https://koji.fedoraproject.org/koji/packageinfo?packageID=37 should fix this.
17:07:49 <adamw> #endmeeting