If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Announcement

Collapse

No announcement yet.

Fedora Rawhide Users Can Now Test The Experimental Zchunk Metadata Support

A couple of weeks ago this regresssion of libsolv version made it also into Fedora 28 breaking things.

You can't expect a volunteer contributor working on zchunk to drop their work and concentrate on your pet bug. People don't all have the same skillsets or interests and are not interchangeable like that.

Comment

You can't expect a volunteer contributor working on zchunk to drop their work and concentrate on your pet bug.

You are of course right!

But!

If such changes *and* other changes have a significant effect on how dnf operates, then yes! This is an issue. One of the Fedora rules says: "don't change user experiences" and this sentence is even more valid for stable Fedora releases.

So if you are going to change the behaviour how dnf interacts with packages e.g. enforcing re-installation of packages, then this is indeed something that violates your own rules - specially for stable Fedora releases. The issue has been introduced right after release of Fedora 29 (which even makes it invalid for user experiences for Fedora 29). The issue got filed in bugzilla and until now the developers haven't taken care of it. Even if it's just a one-liner of change.

So please forgive me if I sound like an ass here. But why do you people keep introducing new fancy dnf stuff *that no one besides the own developer* uses, while other issues are still left unattended ?

Comment

So please forgive me if I sound like an ass here. But why do you people keep introducing new fancy dnf stuff *that no one besides the own developer* uses, while other issues are still left unattended ?

In this case, this feature is considered widely desirable and the person contributing the feature has nothing to do with the bug you are talking about and very likely cannot merge fixes for it anyway. Even otherwise, we cannot tell a volunteer not to work on whatever fancy feature they see an interest in.

Comment

Don't let volunteers work on core components of Fedora! Or - more specific - components that will make it into RHEL sooner or later. This way you avoid messing up things.

Sorry but that is a astoundingly silly thing to say. Volunteers have done amazing work on Fedora. It is an open source project with hundreds of volunteers. Just because they don't work on your pet bug doesn't mean the feature isn't very valuable to other people.

2 likes

Comment

Sorry but that is a astoundingly silly thing to say. Volunteers have done amazing work on Fedora. It is an open source project with hundreds of volunteers. Just because they don't work on your pet bug doesn't mean the feature isn't very valuable to other people.

You can be sure that I am well aware of the situation that Fedora is based on volunteer work and that most volunteers are doing a great job! We've been using Fedora and RHEL products for many years now. I've tried to be specific on this single component that acts as a heart of package managing within Fedora. There is no alternative for it. Either it works as supposed or it doesn't.

This is not just a "pet" bug. This is a serious issue. An issue that slipped through the eyes of Fesco and made it into Fedora 28 breaking the user experience. But of course - you as a community manager - like to make it sound like this isn't anything specific.

Not to mention that this broke our own workflow. So why bother with Zjunk, if dnf itself doesn't work correctly for weeks now. That's why I said that you shouldn't let volunteers work one something that might make it from Fedora to RHEL one day. Companies that rely on RHEL systems are not really open to such kind of experiments. They simply want their own infrastructure and components to work.