On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral <kpa...@redhat.com> wrote: > > "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. > I guess my question comes down to is this something The Average User™ does, or is it just something that Kamil does because he's really good at QA? If it's the former, then I'm in favor of your proposal.
> 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. > I see that as being a different case from the above, and I would definitely support blocking on that behavior. The only thing that should abruptly stop a transaction is the user hitting a cancel button. So while I'm still unclear about the first part, I'm totally on board with this part. >> We should clarify this to something like "list software installed from >> managed repositories". The wording probably needs help, but the idea > What about: > * list locally-installed software coming from the official Fedora repositories > ? Well, I think we'd want it to work for other repositories too (like Flathub, rpmfusion, etc). But there's a case for keeping the criterion limited to just the official repos because if something fails because a third-party repo does something weird, that's out of our control. So I guess this wording works if only to prevent ourselves getting hung up on a totally-out-of-our-control bug at some point in the future. >> > * start the selected installed software >> > 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). > You've convinced me. +1 to this >> 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. > I'm on board with the enable/disable part for sure. I'm not sure how I feel about the adding new repos part. I think I'm weakly opposed to including it. One, it adds to the number of things we need to test. Two, and more importantly, most third-party repos that I've come across provide an RPM or similar to add a new repo. And if for some reason it doesn't work via the GUI tool, I think saying "sorry, do it on the command line then" is reasonable for this particular use case. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ 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
