On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote:
> On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote: > > On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek <jmra...@redhat.com> > 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. > I agree with you Zbyszek. OTOH "identical interface" doesn't seem like a fair requirement. (I don't believe you were suggesting it was.) 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, This sounds reasonable -- describe what will be provided at a minimum. > propose alternatives for things which are too hard > or too costly to reimplement, This sounds reasonable if all we're asking is to provide suggestions or alternatives for a few things that are more prominent changes. Not alternatives for every possible function. That would divert too much energy from more useful work. > and in the end make some judgement calls. > Are you suggesting the DNF team can make these calls? That sounds like a collegial level of trust and seems okay, if so. But it seems at odds with the original request, so it should be clear who's accountable for making what calls. -- Paul
_______________________________________________ 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
