My personal preference is *works decently* of course. My old self keeps calling from the history of times something like "I have told you that Linux kicks ass and Windows kick balls."
On Thu, Nov 11, 2021 at 5:07 PM Kamil Paral <kpa...@redhat.com> wrote: > On Thu, Nov 11, 2021 at 10:41 AM Lukas Ruzicka <lruzi...@redhat.com> > wrote: > >> I assume we are talking about a GUI software manager and not DNF. >> > > Yes. > > >> I also assume that we want to deliver a user friendly package manager >> that is a pleasure to work with. >> On that assumption: >> >> *Scenario 1: Blocking*. You do not want to restart an application any >> time you want to start doing another operation with it. >> *Scenario 2: Not sure. *If, in that situation, the application showed a >> message that freshly installed packages must settle first and that it needs >> restarting the application, I would think this is not blocking. Without >> explanation, this feels like blocking. >> > > If it said "sorry, an application restart is needed to perform this > operation", then yes, I'd also consider it not blocking, because it would > work according to the design goals. It's a poor UI, but not a bug. But that > was not what I meant. I meant seeing a cryptic error, e.g. "database lookup > returns null", or even our old friend "package not found". I.e. nothing > that would explain to the general user what is wrong and what needs to be > done. > > >> *Scenario 3: Blocking* if interactions like these are possible. >> *Scenario 4: Blocking*. Dtto. >> *Scenario 5: Not blocking* - a common bug candidate. This is a little >> wrongly implemented Scenario 6. >> *Scenario 6: Not blocking* - actually this feels like a fair behaviour >> to me, although that train has gone and now we expect a little more. >> > > Yes, as I explained in my follow-up email, it is a fair behavior, exactly > as you say. > > >> *Scenario 7: Blocking* - clearly >> >> If we just want to deliver a package manager that somehow "works" and do >> not bother about its user friendliness, then I switch *Scenarios 3 and 4 >> to not blocking, but common bugs candidate.* >> > > Sigh, with conditional answers you're making my life even more difficult > :-D > > Given that we currently block on applications having nice icons [1], I > hope that our standards for GUI apps functionality is not as low as to > require the user to not even breathe when they click on a button. I might > be wrong, though :-) > > What is your preference? Works decently (3 and 4 blocking) or works > barebones (3 and 4 not blocking)? (I'll just note that we're talking about > Final criteria here. "Works barebones" is already available for Beta.) > > [1] See the last sentence in > https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality > > _______________________________________________ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-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/test@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-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/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
