Hi, FESCo. Today at the F29 Final blocker review meeting, we noted that the DNF team has submitted this update to fix several blocker and FE bugs. The update is a rebase of both DNF and libdnf to new versions, including multiple changes and new features that do not relate to blocker or FE bugs.
This is against the usual policy that only blocker and FE fixes should be accepted through the milestone freezes. As DNF is a major component of Fedora and a significant part of some key F29 Changes, we would like to ask FESCo to consider this and decide on the best course of action. Should we accept the DNF 4.x / libdnf 0.22.x rebase into F29 Final, or request that they create something like DNF 3.6 / libdnf 0.20 feature branches with only F29 blocker/FE fixes instead?
@sgallagh @mattdm @dmach @kparal @sdharane
I think it's too late to accept a backwards incompatible release (I assume that's why it's changed to 4.0?) into Fedora 29. I'm of the persuasion that 4.0 should wait for Fedora 30 at this point.
DNF version has changed to get parity with yum versioning (DNF 4 == YUM 4 > YUM 3). It doesn't come with any major changes, you can consider it another 3.x release but with a different version.
It contains mainly bugfixes incl. those related to modularity and backward compatibility.
Thanks @dmach for explaining, at the same time, do we have impact assessment of this change? If the impact only means waiting to see how QA would find issues and then taking a call, I'm afraid its too late given the final release date is just around the corner.
While I think this is not ideal, I'm +1 to accepting the other changes in as well (provided we resolve this ticket in a timely manner leaving testing time).
We could also ask releng for a compose with this included to see if it passes basic compose tests.
Could other FESCo members please vote in ticket? or you need more information?
+1
Before voting, I would like to know what patches are being included that aren't for fixing FE's or blockers. I'd also like to know what the risks/benefits are if we accept those patched. In general, it seems unwise to include patches in such a core component that weren't approved by the FE/blocker process.
Metadata Update from @jforbes: - Issue tagged with: meeting
This is the list of commits in 4.0.4. Those are pretty much all bug fixes, with the exception of the --changelog stuff (a463d1cc65) and dnssec stuff (adc3247e9b..c55fd6194e). The changelog stuff could be considered almost a bugfix, but the second one is more worrying — it brings in new deps and is quite a bit of new code.
--changelog
dnssec
I guess we can accept the update to 4.0.4 for F29, but OTOH, it wouldn't be that much work to make a branch without the dnssec changes.
Metadata Update from @jforbes: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.