Re: new criterion proposal: Graphical package managers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <kparal@xxxxxxxxxx> wrote:
On Thu, Nov 11, 2021 at 10:41 AM Lukas Ruzicka <lruzicka@xxxxxxxxxx> 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.)


_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


--

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka@xxxxxxxxxx   

_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux