Our purpose in this meeting is to review
proposed blocker and nice-to-have bugs and decide whether to accept
them, and to monitor the progress of fixing existing accepted
blocker and nice-to-have bugs.(adamw,
16:05:28)
We'll be following the process outlined
at:(adamw,
16:05:28)
AGREED: 1761484 -
AcceptedBlocker (Final) - this is accepted per precedent from the
last few releases and the FESCo ticket. We will look at treating it
as an automatic blocker for future releases(adamw,
16:13:02)
(1760937) dnf-yum in F30 is now higher versioned than F31+ yum's "Obsoletes" (affects upgrades)(adamw, 16:13:08)
AGREED: 1760937 -
AcceptedBlocker (Final) - this is a close call, but we accept it as
a blocker as a violation of the Beta upgrade criterion, referencing
the footnote "The upgraded system must include all packages that
would be present on the system after a default installation from
install media, plus any packages the user previously had (minus any
obsolete content)"(adamw,
16:36:44)
(1758588) dnf system-upgrade reboot fails due to depresolv difference with download(adamw, 16:36:54)
AGREED: 1758588 -
RejectedBlocker (Final) - this is rejected as we are not aware of
any case where this problem affects one of the release-blocking F30
package sets, so it does not violate the criterion(adamw,
16:45:44)
(1750575) dnfdragora complains that dnf is locked by another process after updates(adamw, 16:45:52)
AGREED: 1750575 -
AcceptedBlocker (Final) - this is accepted as a violation of "All
applications that can be launched using the standard graphical
mechanism of a release-blocking desktop after a default installation
of that desktop must start successfully and withstand a basic
functionality test" for dnfdragora, we hold that 'install some
updates without printing a confusing error and quitting' is 'basic'
functionality for an updater(adamw,
16:59:04)
(1761327) "Object St.Button (0x5621e3249b90), has been already deallocated — impossible to get any property from it." spam in system logs(adamw, 17:00:12)
AGREED: 1761327 -
punt (delay decision) - the bug here is relatively minor, and there
are two different proposed fixes whose safety is not clear. we will
punt to give the GNOME devs a chance to provide more info and
clarity on the proposed fix here(adamw,
17:14:10)
(1759490) Fedora 31: Wayland: qtwebengine-based applications cannot be full screened(adamw, 17:14:18)
AGREED: 1759490 -
RejectedFreezeException (Final) - we don't see any convincing
benefit to granting an FE here, the only case it would really help
is someone installing a qtwebengine-based app in a Workstation live
session, which seems like a pretty unusual scenario. We think it's
fine for this to go as a regular update.(adamw,
17:18:52)
let's go over the accepted Final
blockers(adamw,
17:20:21)
we will consider all accepted blockers except
those that are VERIFIED(adamw,
17:20:56)
(1747408) Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed(adamw, 17:21:02)
this is accepted as a blocker per FESCo
decision, but debate continues as to what would constitute an
acceptable solution(adamw,
17:22:00)
fesco decided today to vote in
https://pagure.io/fesco/issue/2230 on whether the currently proposed
solution - some text pointing to an 'upgrade guide' document to be
shown at the time of running 'system-upgrade download' - is
sufficient(adamw,
17:24:10)
this is more or less in the hands of FESCo and
dnf devs at this point, we will continue to monitor(adamw,
17:28:06)
this is also fairly simple, we just need a dnf
maintainer or provenpackager to bump the version on the obsoletes
and submit an update for testing(adamw,
17:38:43)
(1750575) dnfdragora complains that dnf is locked by another process after updates(adamw, 17:39:18)
we need dnfdragora and dnf developers to come
up with a fix for this one(adamw,
17:43:39)
ACTION: adamw to ping
dnfdragora and dnf developers to work on this urgently(adamw,
17:46:08)
ACTION: frantisekz to
kidnap dnf developers and force them to fix all the bugs or else
they have to read the modularity threads over and over again
forever(adamw,
17:48:37)