On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote: > On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek <jmracek@xxxxxxxxxx> wrote: > > > > Please can you be more specific which kind of functionality is required for particular command? Why is it important to know what user case you want to resolve it? Commands has multiple options and some of them could be unused. Specially repoquery has tons of options. Knowing critical usercase will help us a lot to not only provide the same option but to improve DNF5 behavior in comparison to DNF4. > > > > I recommend to create for each user case or command an issue - https://github.com/rpm-software-management/dnf5/issues. Please provide as much as possible information to understand the user case to be able to set a proper priority. > > Determining the scope of such big Changes is usually done by the > person who proposes the change ... > I think it's safe to assume that most commands / options are used by > at least some people / tools / scripts, so dropping features is going > to be painful, and should be avoided, if possible. Yes. And looking at this from the other angle: if you ask people what features they need, the answer will be "yes" ;) Essentially, pretty much every feature ever created has *some* user, and often people will only remember about a feature when it turns out that it is missing in the new implementation. Also, other things being equal, people prefer that the interface is unchanged. This just makes life easier for them. Thus, if we're switching to an entirely new system where reimplementing every feature and interface of the old system is not possible, people proposing the change need to figure out what *can* be implemented, and weigh the efforts required against how needed the feature really is, propose alternatives for things which are too hard or too costly to reimplement, and in the end make some judgement calls. This exploratory and design work is hard, but without it things will be much harder later on. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
