I am really sorry, but could we start the discussion from beginning? We use many personal opinion but we provide very limited set of facts.
I will try to summary some facts related to the naming topic. We developed a new software management tool to replace DNF, MICRODNF, DNF libraries and potentially PackageKit. As you can see it is supposed to replace multiple tools (step by step) therefore picking the right name is not easy, but `DNF` is the strongest player here. If we will keep the name `DNF` for the new tool we will get some benefits. The documentation will stay intact, people will not get scared of the tool change. But as negative we will create incorrect impression of using the same tool, feature set or compatibility. The new tool will not provide all features, command, options from DNF. Some features will be implemented after an user request to ensure someone is still using them. It will not support old plugins and even not Python plugins - I want to say that it is a significant changes. Why I think that incorrect impression could happen. Because we get such a request from users of RHEL8 where we keep YUM brand. And YUM (DNF in background) in RHEL8 is very similar to YUM in RHEL7. To create a strong YUM compatibility layer it required additional 3 years of development after replace of YUM in Fedora 22. I understand that the name change can be confusing but we tried with DNF both approaches - ship the new tool with a different name - DNF (Fedora) and ship it as formal tool YUM (RHEL8) and from received feedback, RHEL8 approach was worse. And it is a reason why DNF is shipped as DNF in RHEL9. It required to rewrite the whole documentation from YUM to DNF but it was worth to do it. What we learned from Fedora deployment? Don't create any warning when people keep using the old tool name - YUM. Please if you have any example where a significantly different tool shipped with the name of the old one was successful please share it with us. If we will ship the new tool as DNF we will loose additional feature - back up option for users that want to use original DNF in Fedora 39. As I mentioned original DNF package will remain in distribution therefore if anyone need to use the original DNF they can upgrade from Fedora 38 without replacing the DNF. They only need to exclude the new tool from transaction. With using a different name it is still not impossible, but it will require rename of original DNF package and somehow inject it into transaction - not nice from my point of view but possible. If we will ship the new tool with a new name we will clearly highlight that it is a new tool and that it requires more attention (testing) from user side and community. On the other hand it will require to modify documentation, but it will also help to distinguish between dnf version 4 and version 5. Using the same name in documentation is a trap for user using Google. I will search how to do something in Fedora but I can get a reference for DNF-4 tool therefore it could be not functional. Could we rename the new tool back to DNF? Yes, we could but do we want it? Or do we want to rename DNF in Fedora back to YUM? Right now we could, because DNF is feature complete, very compatible with YUM. There is also the last fact - DNF team is responsible for the new tool and all problems related to the change is going to our direction. If there will be a complain about the new tool, or the naming we cannot blame anyone because we have rights to say no, or don't we? Please if you have other opinion related to the proposal, please don't hesitate to share it, but please provide facts, user cases and examples or examples from other tools. If we will know the issue related with the proposed approach we could find a way how to resolve it or document the problem as known issue. Best regards Jaroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
