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(a)redhat.com> wrote:
On Thu, Nov 11, 2021 at 10:41 AM Lukas Ruzicka
<lruzicka(a)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_a...
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-leave(a)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
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <