https://fedoraproject.org/wiki/Changes/RPM-4.16
devel discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/65TZGKWLEMQPCATPY3QHRKA7VEAHMAED/

https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb
devel discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YYOEZO2FO2E2T6KO25434EBDTIOWK5OM/

As far as process goes, this was indeed announced on the 16th, which is more than a week ago and FESCo can vote on this. Apologize for the delay.

You get my immediate +1 for the RPM 4.16 change.

+1 to both.

For the sqlite thing, I forgot to ask on the devel thread: Are you willing to work with infra/releng to enable bootstrap mock in Koji to avoid crazy problems with the database mismatch between buildroot and buildhost?

@churchyard I don't think anything like that is enabled.

I think Ben is on PTO, which is why some things have not been processed in the last 1-2 weeks.

FWIW, I'm +1 for both RPM 4.16 and the SQLite change.

Just to clarify, this is absolutely not a criticism to any individuals involved. This is a process flaw, and happens to some degree every time we are ahead of the "regular" change schedule like this. Which is maybe another thing for FESCo to discuss: for big changes like this, the optimal window to land in rawhide is right after branching, while most of the action is on the just-branched release. But the change process clearly expects and only properly works for the more common scrambling-to-deadline schedule.

Will be happy to help rel-eng/infra to the extent we can, but at least I have no idea what's actually involved with that so wouldn't even know where to start. At any rate, even if sqlite was approved today we wouldn't be switching to that until at least a couple of weeks of shakedown for 4.16 first.

Also, we are in talks with rel-eng already over this via the mandatory ticket: https://pagure.io/releng/issue/9308

This is a process flaw, and happens to some degree every time we are ahead of the "regular" change schedule like this. Which is maybe another thing for FESCo to discuss: for big changes like this, the optimal window to land in rawhide is right after branching, while most of the action is on the just-branched release. But the change process clearly expects and only properly works for the more common scrambling-to-deadline schedule.

I submit changes for Python way ahead (as I like to do them after branching as well). I don't think it works any less. It's just really that Ben is on PTO now. The only process flaw I see is that there is no dedicated person to do this in such cases.

+1 for the SQLite change as well

I submit changes for Python way ahead (as I like to do them after branching as well). I don't think it works any less. It's just really that Ben is on PTO now. The only process flaw I see is that there is no dedicated person to do this in such cases.

Right, maybe it is us not filing early enough to cover for a possible PTO. But given the pace of Fedora, a month from filing to getting to first review does seem excessive, whatever the cause. There really should be an official backup person for the wrangler since its such a critical spot for the entire process.

There really should be an official backup person...

I agree.

+1 for the SQLite change as well

Let me change that a bit actually: +1 if the the database rebuild may be done by upgrade tooling thing is solved. I don't think us telling the users to run rpmdb --rebuilddb at earliest opportunity is smooth.

Yup, I don't disagree. I left it open on purpose as there would be any number of ways to achieve the rebuild with varying degrees of automation and opt-out opportunities, depending on what is desireable.

One possibility could be adding a rebuild step to dnf system-upgrade plugin, rebuilding the db after distro upgrades is not a bad idea regardless of db format changes (at least BDB performance would gradually degrade unless rebuilt every now and then). That would leave people doing the (unspeakable) distro-sync upgrade to deal with database format manually, which might be just the right balance of freedom. Or not, I dunno. Other possibilities include planting a one-shot service that does the db rebuild on the next reboot and decommissions itself afterwards in the rpm package itself. Suggestions welcome.

+1 for the rpm 4.16 change.

For the sqlite change, no vote yet. I'm all for it, but as described, the change will not happen for most users (unless they do the manual rebuild step, but who reads release notes if nothing visible broke?).

EDIT: I think it's better to discuss this on fedora-devel. I removed the rest of the reply.

I think it's better to discuss this on fedora-devel.

Sorry about that, my fault.

+1 for RPM 4.16

If I'm understanding right, if a user doesn't do rpm --rebuilddb, they will still be functional with the previous BDB database. If that's correct, then I'm +1 on sqlite also; certainly it would be best if we could migrate everyone automatically, but as long as they aren't broken I don't think it's worth holding up for that.

Yes, things will remain fully functional even if the db isn't converted, rpm will just nag about the condition ("warning: Found bdb Packages database while attempting sqlite backend: using bdb backend", could be enhanced to suggest --rebuilddb too) as long as either db is converted or configuration set to remain on BDB.

The consensus seems to be wanting automatic upgrade and I certainly prefer that too, I simply had my doubts about Fedora being okay with that. I'll be happy to add automatic conversion with an opt-out possibility to the sqlite change proposal if that's what FESCo wants.

Went ahead and updated the sqlite proposal to cover automatic conversion:
https://fedoraproject.org/w/index.php?title=Changes/Sqlite_Rpmdb&diff=569640&oldid=568747

My vote is +1 to both changes in that case. Thanks.

+1 to both

We're at +4 for the RPM 4.16, and +3 for the other change.

+1 to both.

+1

+1 here also, but PLEASE coordinate with releng/infra on the switch to sqlite...

We discussed this during today's FESCo meeting:
APPROVED (both parts) (+7, 0, 0).