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@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