On Wed, Oct 12, 2022 at 05:21:58PM -0400, Paul Frields wrote: > On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek < > zbyszek@xxxxxxxxx> 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@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. > > > > I agree with you Zbyszek. OTOH "identical interface" doesn't seem like a > fair requirement. (I don't believe you were suggesting it was.) I wasn't. An identical interface (or part thereof) is in fact often easiest for both sides, both people writing the interface and people consuming the interface. But in various cases it's too hard to provide an identical interface. Thus: try to provide an identical or at least a backwards-compatible interface, but deviate if necessary. > > 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. Well, maybe. I think some such answer will need to be provided for pretty much every feature that people ask about. Maybe not at level of all implementation details, but at the feature level certainly. > > 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. I think the DNF team should make those calls but then submit the resulting plan for public discussion and vote by FESCo. 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
