On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral <kparal@xxxxxxxxxx> 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@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
