On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:
"dnf install foo bar"
This is a single operation, comparable to having multiple packages installed via graphical package manager, not scheduling multiple operations at once. It would be the same If a graphical package manager offered to select multiple packages/applications and then start the transaction.
"dnf install foo; dnf install bar"
This is equivalent to:
1. Open Graphical package manager
2. Install foo
3. Close Graphical package manager
4. Open Graphical package manager
5. Install bar
6. Close Graphical package manager
It depends on what your definition of an operation is. But in both cases, I don't see a functional difference between these and a user clicking on the Install button for foo and bar in the graphical package manager.Doing a single installation, waiting for it to finish, then doing another is something you can do with dnf and something that I'd block on with graphical package managers.And yet you voted for a RejectedBlocker just a few weeks back:
dnf exits after transaction finish, so it's equivalent to a workaround that was possible for that blocker proposal. Also, I might've added that I'd block on this once we agree on proper criterions ;)
If you changed your mind, great :-)Scheduling multiple tasks without waiting for them to finish one by one is something that I am against blocking on.What purpose does it make to punish users for something they can't know? They don't know that they should wait for the first operation to finish, and only then click on the next button. This way they are safer, because they are within the path we block on (if we used your definition). So why do we even allow them, *tempt them* to be able to click a different button in the meantime? Shouldn't we push on developers to prevent simultaneous button clicking?
Are users doing this? I don't think so, you think they do. We don't have any data we can use to say which way it is used. Nothing prevents you from testing this path and reporting bugs and working with the devs on solving it, even if it isn't a blocking path.
And I'm going to go down the rabbit hole even more. How is scheduling another install different from e.g. listing installed packages or available updates? If the user starts installation of package A, and then switches to the Installed or Updates tab in gnome-software (which executes a *concurrent* packagekit operation), and then the whole thing breaks, do we also say "you naughty human being, you shouldn't have clicked that, even if we allowed you to" and not block on it?
I don't do this, I've never seen anyone (with or without a technical background) do this. All the users I've seen do is to wait until something finishes and then switch to other tabs/sections, etc. Again, I am not saying this isn't happening, all I am saying it's not blocker material, in my opinion.
Best regards / S pozdravem,
František Zatloukal
Quality Engineer
Red Hat
_______________________________________________ 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
