Re: DNF5 Blockers

[Paul Frields]

On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl&gt; 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 <jmracek(a)redhat.com&gt;
>  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