+1. The issue is completely incomprehensible unless one knows the solution, so I think we need to make an effort to get this fixed for F31 final.

cc @dmach @jmracek since this is DNF issue. I think the best way for F30/F31 timeline for DNF is always do reset of all modules streams during upgrade if user's installation uses "default" module stream.

@ignatenkobrain That's actually a really good idea as a short-term workaround. It doesn't solve the full problem (we want to stay locked on the stream if it was explicitly selected), but it's probably good enough for the F30->F31 upgrade.

@psabata and @langdon What do you think about this strategy?

Can we please keep the technical discussion in one place? That would be https://bugzilla.redhat.com/show_bug.cgi?id=1747408

@ignatenkobrain That's actually a really good idea as a short-term workaround. It doesn't solve the full problem (we want to stay locked on the stream if it was explicitly selected), but it's probably good enough for the F30->F31 upgrade.
@psabata and @langdon What do you think about this strategy?

This sound like hack that is completely out of concept of modularity. I believe that one of primary feature was to provide alternative content with fixed API across distribution releases.

  * AGREED: The upgrade issue identified here is significant enough for
    FESCo to declare it a blocker. FESCo will vote to determine if a
    proposed solution or workaround is sufficient to unblock the
    release. At minimum, we require that a non-expert user is provided
    sufficient information to accomplish the upgrade without resorting
    to Google (+7, 0, -0)  (contyk, 16:08:01)

Leaving the Meeting flag for the next week's meeting.

A proposal was made in https://bugzilla.redhat.com/show_bug.cgi?id=1747408#c67. Let's give it a yay or nay.

We have agreed that "FESCo will vote to determine if a proposed solution or workaround is sufficient to unblock the release" and a workaround was proposed by the dnf team.

The workaround is described in:

https://bugzilla.redhat.com/show_bug.cgi?id=1747408#c42 and https://bugzilla.redhat.com/show_bug.cgi?id=1747408#c67

My vote is -1, this is not a sufficient workaround to unblock the release. My reasons:

1. I don't consider displaying a generic link at a beginning of the upgrade process as a proper hint. The user is buffled by the cryptic error message at the end of the log. They need to receive a pointer at that point.
2. It doesn't solve/workaround the problem when upgrading via gnome-software.

Both was stated repeatedly in the bug, by different people.

-1 for the same reasons. We can and must do better.

Ditto. -1

DNF team cannot resolve problem with gnome-software! Please set up another blocker for gnome-software component.

What about alternative solution?
Modules axa, bat will be built not only with libgit2:0.28, but also with libgit2:0.26. This also resolves the issue.

The blocker was assigned to distribution. Nobody's saying the DNF team should resolve problem with gnome-software.

As for your alternative solution: 1. I fail to parse it. 2. please keep the technical discussion in the bugzilla.

-1 as well.

An alternative workaround was submitted, it resets the libgit2 module.

New proposal: FESCo accepts the dnf system-upgrade fix but GNOME Software upgrade needs to be fixed to unblock the release. Technically, this means marking https://bugzilla.redhat.com/show_bug.cgi?id=1762751 as F31FinalBlocker.

+1

+1 for the workaround.

+1 for the workaround.

I'll vote separately in 1762751 for F31FinalBlocker.

Tagged with meeting so we can decide tmrw. This is time sensitive.

+1 to the workaround.

Also, can FESCO decide if an alternative workaround for the issue proposed by DNF team (creating libgit2 compat package[0] , the same thing that was done in Fedora 30) is sufficient if GNOME Software fix is not delivered on time?

Thanks a lot!

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1747408#c72

Solution 1: In Fedora 30 the same problem was resolved by compat package "libgit2_0.28". The release of compat package "libgit2_0.28" into Fedora 31 resolves dependency issue. DNF team would prefer to use the same dirty solution for Fedora 31 rather than introducing other dirty hack. This solution also resolves the problem with gnome-software.

We discussed this during today's meeting:
AGREED: (+5, 1, -1)
ACTION: nirik to ask kalev about workaround in
packagekit/gnome-software and block release on this fix. If it is
complicated, ignatenkobrain will create libgit2_0.28 package.

there are updates on the way, statement was voted, no need to meet about this again.

Announced.