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