On Wed, Aug 12, 2020 at 10:39 AM Lubos Kocman <lubos.kocman@suse.com> wrote:
All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting
## Participants
dleuenberger, adrian, ddemaio, lkocman,maxlin, deneb_alpha
## Dirk
We need to have a closure on the topic. Dirk will send email, we have to start with Tumbleweed and document it. Feedback regarding 5% of build failures seems to be seen as too relaxed.
Ludwig: Perhaps having build failure for more than x-weeks on Ring:0/Ring:1 or any submission to it (:Adis) could retract the state. Dominique: ppc64le was blocking stagings for a week until we could get build done. Otherwise we usually have it done in few days. Richard: we have to have Ring0/Ring1 always working. If we don't have the infra for :Staging than we can't make architecture Tier1. Dirk: We do not have this detail (topic above) documented. Ludwig: It's implicit. Dirk: Agreement with Guillaume on aarch64/TW is that architecture is treated as a primary. Dominique: We have a current agreement to have aarch64 images next to x86_64, not necessarily as treat it as primary, that would then be outcome of this effort.
Ludwig: we may be aiming for 3 tier policy, not the 2 tier policy. With x86_64 being the reference. Ludwig: let's have followup discussion on mailing list.
It sounds like there's no way you can graduate any architecture. From my perspective, a supported architecture needs to exist in openSUSE:Factory. It needs to be part of the staging workflow, and needs to release at the exact same time. I would give up on this multi-tier idea of supportability. You already have everything you're capable of: usable and supported (x86 arches) and unsupported and randomly broken (everything else).
* DNF for SLE / Leap Next (PM-2044) - Status is NEW - List of benefits was put together by Neal Gompa and Daniel Mach - Request was raised to PM attention - A lot of discussion over the entire July (this topic got really good visibility). A TODO list from mls that is making it really difficult No offering of solutions if there are dependency problems (dnf just exits)
This has generally been considered undesirable historically because it's impossible to automate reliably, and DNF has been automation-centric from its inception. I'd be interested in understanding what makes that feature compelling, given that every time I've had to use it, it doesn't work or leads to a broken system...
No concept of package vendors
This is in-progress.
No support for products
WTF are these?
Completely different handling of maintenance updates, i.e. no support of patches
patches as zypper calls them are advisories in dnf terms. Zypper: zypper patch:openSUSE-PatchU-1234 DNF: dnf install --advisory=openSUSE-PatchU-1234 \* All normal package management actions work with advisories, such as install, upgrade, and remove.
No support for patterns
These are just metapackages, but it wouldn't be hard to add a subcommand similar to the "group" one to manage these.
No support for translations
Wut?
No support for modalias() supplements to install needed kernel modules
How does this even work?
No support for language supplements
We already do this in Fedora, so I don't know what you're talking about here.
metalink support in librepo only for a complete repository, i.e not file based. This does not fit our download redirector
openSUSE does not use metalinks with Zypper *at all*, precisely because your MirrorBrain setup is broken for this use-case.
No support for services
Wut?
No support for product licenses
Wut? Is this the SUSE metadata extension for packages to have EULAs? Or something else?
No support for L3 tags
Wut?
Different lock handling
Yeah, but Zypper's soft-lock behavior is possible to implement too. The solver favor/disfavor and lock/unlock functionality from libsolv is plumbed into libdnf (it was done for rpm-ostree), but that hasn't been propagated to other libdnf consumers (dnf, microdnf, packagekit) yet.
Does not understand a repo consisting of multiple media
This shouldn't be hard to add to librepo, no?
I don't see how YaST can work with libdnf
This makes no sense to me. What do you mean by that? -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org