On Wed, Nov 3, 2021 at 4:02 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
On Wed, Nov 3, 2021 at 7:32 AM Kamil Paral <kparal@xxxxxxxxxx> wrote:
>
> * install, remove and update software, even if multiple operations are scheduled sequentially or concurrently
I don't like the "multiple operations" part but to be honest I'm not
sure if that's because I worry about how many delays it will cause or
if I legitimately don't think that's a sufficiently common use case.
"Multiple operations" is one of the reasons for proposing this criterion. In this release, and previous releases, we often had a bug that you can install a package, but then you can't remove it. But if you restarted the package manager, or your session, then it worked. And people said "well, both install and remove work, you just can't use them together, so... it's fine according to the criteria!". That's why I list it explicitly as blocking Final. I don't think it's fine.
Another scenario could be when you hit Install on app A, and before it is done, you hit install on app B. Imagine if the first operation would get stopped abruptly. The same argument could be used as above (which is a real argument, not a made-up one). Again, that's why I mention it explicitly.
> * list software installed on the system
We should clarify this to something like "list software installed from
managed repositories". The wording probably needs help, but the idea
is that we want it to know what RPMs and flatpaks are installed. But
if someone installs a package from source or a tarball, we don't
expect the package manager to know about it. I know that's not what
you're saying, but it's worth being clear here so that future readers
are clear on the intent.
What about:
* list locally-installed software coming from the official Fedora repositories
?
> * start the selected installed software
Is this a common case? I almost never use a graphical package manager
myself, so I don't know.
I use it from time to time, it's faster than retyping the app name into the gnome overview (and it also takes a few seconds to show up there, so you must not be too fast or you need to start over). It's also convenient when trying out 5 different drawing applications or similar. But the fact that it's prominently shown made me include this. I think it would be a really poor experience if you install some app, hit Open/Launch, and nothing happens. (At the same time, this one use case is not as important as the others, so if most people dislike it, I'm not going to fight for it - I'd just give you a sad panda face).
> * configure software sources (enable/disable/add/remove repositories, set default sources) and then adjust the available software pool accordingly
Do we want to make it clear that it's not intended to allow the user
to *add* a new repository? Or is that understood?
GNOME Software doesn't allow the user to add any additional repository. KDE Discover allows the user to add an arbitrary Flatpak repository, or Flathub directly with a specialized button. My idea was to not distinguish between different buttons, simply if it is present and serves for repo configuration, it must work. However, if you think it's better, we can exclude the Add button explicitly, or we can name which exact buttons/operations must work.
Of course, the design decisions footnote also applies here, so if some of the operations are intentionally restricted for certain repos, then again, it should work as designed (or the impact needs to be considered by the blocker review team).
Or have I misunderstood your question?
Thanks for making good points.
_______________________________________________ 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
