During the F35 release cycle, there was a dissatisfaction that we use the "basic functionality" criterion [1] too broadly when discussing package manager issues (like multiple issues in plasma-discover). I was asked in the latest QA meeting to propose a specific criterion to cover package managers in detail. Here it is.
Please note that we already have package management partly covered in the Basic criteria [2] and Beta criteria [3]. Please read those first, including footnotes. The following new criterion is proposed against the Final milestone:
~~~~~~~~~~ The default graphical package manager for a given software type must appropriately: * install, remove and update software, even if multiple operations are scheduled sequentially or concurrently * list software installed on the system * list available software (possibly in categories, a curated list, etc) * display metadata relevant to the selected software (e.g. the description, screenshots, the size) * start the selected installed software * configure software sources (enable/disable/add/remove repositories, set default sources) and then adjust the available software pool accordingly * notify the user when system updates are available (taking into account the intended frequency of such notifications)
Note: Supported functionality and design decisions All requirements apply only if such a functionality is supported by the package manager; it does not imply that the package manager must support all this functionality. The requirements don't apply if some functionality is intentionally modified as a design decision (e.g. if some software sources can't be disabled as an intentional precaution to users breaking their system). If there is a bug violating the design decisions in one of the covered areas (e.g. a software source which is supposed to be always enabled can be disabled), it's up to the blocker review team to consider whether this bug makes the user experience or system safety considerably worse.
Note: Refer to Basic footnotes The footnotes for the [similar Basic criterion covering console tools][2] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also. ~~~~~~~~~~
The criterion covers a lot of functionality. I'm coming from the notion that the package manager (together with the web browser) is the most important app on desktops, issues in it are very hard to work around for users and provides core system functionality. That's why I think we should have high standards for it.
Please let me hear your thoughts. Thanks.
[1] https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_appl... [2] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remov... [3] https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2C...
On 11/3/21 6:31 AM, Kamil Paral wrote:
During the F35 release cycle, there was a dissatisfaction that we use the "basic functionality" criterion [1] too broadly when discussing package manager issues (like multiple issues in plasma-discover). I was asked in the latest QA meeting to propose a specific criterion to cover package managers in detail. Here it is.
Please note that we already have package management partly covered in the Basic criteria [2] and Beta criteria [3]. Please read those first, including footnotes. The following new criterion is proposed against the Final milestone:
The default graphical package manager for a given software type must appropriately:
Should this read "for a given release type"? "Software type" feels ambiguous.
- install, remove and update software, even if multiple operations are
scheduled sequentially or concurrently
- list software installed on the system
- list available software (possibly in categories, a curated list, etc)
- display metadata relevant to the selected software (e.g. the
description, screenshots, the size)
- start the selected installed software
Should they all really function as launchers as well? I know GNOME's does, not sure how common that is across the board.
- configure software sources (enable/disable/add/remove repositories,
set default sources) and then adjust the available software pool accordingly
- notify the user when system updates are available (taking into
account the intended frequency of such notifications)
Note: Supported functionality and design decisions All requirements apply only if such a functionality is supported by the package manager; it does not imply that the package manager must support all this functionality. The requirements don't apply if some functionality is intentionally modified as a design decision (e.g. if some software sources can't be disabled as an intentional precaution to users breaking their system). If there is a bug violating the design decisions in one of the covered areas (e.g. a software source which is supposed to be always enabled can be disabled), it's up to the blocker review team to consider whether this bug makes the user experience or system safety considerably worse.
Note: Refer to Basic footnotes The footnotes for the [similar Basic criterion covering console tools][2] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also.
The criterion covers a lot of functionality. I'm coming from the notion that the package manager (together with the web browser) is the most important app on desktops, issues in it are very hard to work around for users and provides core system functionality. That's why I think we should have high standards for it. Please let me hear your thoughts. Thanks. [1] https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality [2] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update [3] https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2C_removing_and_updating_software
Looks really good otherwise.
On Wed, Nov 3, 2021 at 7:32 AM Kamil Paral kparal@redhat.com 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.
- 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.
- start the selected installed software
Is this a common case? I almost never use a graphical package manager myself, so I don't know.
- 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?
On Wed, Nov 3, 2021 at 12:32 PM Kamil Paral kparal@redhat.com wrote:
The default graphical package manager for a given software type must appropriately: * install, remove and update software, even if multiple operations are scheduled sequentially or concurrently
I am definitely against blocking on "multiple operations concurrently". I don't see this as a frequently used "blocking material", I'd rather leave this can of races unopened.
Apart from that, I am slightly against blocking on "sequentially".
- start the selected installed software
If the Graphical package manager exposes such a feature.
Others seem fine, thanks for summarizing this into a more formally defined criterion.
One more note though, can you post this to the desktop and kde lists (or tickets) for their opinions? This shouldn't be put into effect unless our blocking desktop maintainers agree imo. For example, KDE folks might want to block on a smaller subset of this criterion (I don't know if they do).
Thanks!
On Wed, Nov 3, 2021 at 3:48 PM Brandon Nielsen nielsenb@jetfuse.net wrote:
On 11/3/21 6:31 AM, Kamil Paral wrote:
During the F35 release cycle, there was a dissatisfaction that we use the "basic functionality" criterion [1] too broadly when discussing package manager issues (like multiple issues in plasma-discover). I was asked in the latest QA meeting to propose a specific criterion to cover package managers in detail. Here it is.
Please note that we already have package management partly covered in the Basic criteria [2] and Beta criteria [3]. Please read those first, including footnotes. The following new criterion is proposed against the Final milestone:
The default graphical package manager for a given software type must appropriately: Should this read "for a given release type"? "Software type" feels ambiguous.
"Software type" is defined at [2], and the criteria from [2] and [3] use the same phrasing. (See my original mail for link references). I'm not opposed to changing all occurrences of this, if we have a better term :-)
- install, remove and update software, even if multiple operations are
scheduled sequentially or concurrently
- list software installed on the system
- list available software (possibly in categories, a curated list, etc)
- display metadata relevant to the selected software (e.g. the
description, screenshots, the size)
- start the selected installed software
Should they all really function as launchers as well? I know GNOME's does, not sure how common that is across the board.
Both GNOME Software and KDE Discover provide that functionality. I think the idea is that you hit Install, and then you hit Launch/Open, instead of searching for the new launcher in your system menu. It's good for trying out different apps, etc.
If the button is there, it should work, in my opinion.
Looks really good otherwise.
Thanks.
On Wed, Nov 3, 2021 at 4:02 PM Ben Cotton bcotton@redhat.com wrote:
On Wed, Nov 3, 2021 at 7:32 AM Kamil Paral kparal@redhat.com 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.
On Wed, Nov 3, 2021 at 5:15 PM Frantisek Zatloukal fzatlouk@redhat.com wrote:
On Wed, Nov 3, 2021 at 12:32 PM Kamil Paral kparal@redhat.com wrote:
The default graphical package manager for a given software type must appropriately: * install, remove and update software, even if multiple operations are scheduled sequentially or concurrentlyI am definitely against blocking on "multiple operations concurrently". I don't see this as a frequently used "blocking material", I'd rather leave this can of races unopened.
I'm not sure if you understood it correctly (or if I even expressed it correctly). The operations are of course executed sequentially, always (that's how our package managers work). But they can be *scheduled* concurrently, i.e. you can install GIMP, and before it is downloaded and installed, you can also schedule installation of Inkscape. I think this is not an unusual use case, to schedule several operations at once. E.g. I just installed a new system and want to install my favorite applications. Or I decided that I want to play a different game, so I hit Install on OpenArena and also click Remove on SuperTuxKart.
Is this really what you are against, or have you understood it differently? I can try to phrase it better.
Now that you made the point, I now realize that there *is* really a case where multiple operations can be *executed* concurrently. If you schedule installation of an RPM and a Flatpak at the same time, they are performed concurrently (tested with GNOME Software). So we could rule those out and say this is a case when it's not blocking. But honestly, this is a very small technical distinction that we're able to make (sequential RPMs versus concurrent RPM+Flatpak), but our users won't. And now that we have Flatpaks even in official Fedora, and they are even selected by default in GNOME Software, our users will start to hit this use case more and more frequently. I think it would be weird to say "we block on gnome-software blowing up if you press Install on these two packages (before the first operation is finished), but we don't block if you do the same thing on these other two packages (because one of them is an official Flatpak)". I'd rather just cover both cases. It's not like we don't have experience with race conditions (this very cycle!), and if it is hard to reproduce or hard to fix, then it's just the usual "shrug, sorry" approach as always.
Apart from that, I am slightly against blocking on "sequentially".
See my response above. Imagine that we'd ensure only the first dnf operation works correctly, but any later one can blow up. Why would we want to allow that with a graphical package manager?
- start the selected installed software
If the Graphical package manager exposes such a feature.
Sure, exactly as the footnote says. Or do you have a better phrasing for the footnote to make it even clearer?
Others seem fine, thanks for summarizing this into a more formally defined criterion.
Thanks.
One more note though, can you post this to the desktop and kde lists (or tickets) for their opinions? This shouldn't be put into effect unless our blocking desktop maintainers agree imo. For example, KDE folks might want to block on a smaller subset of this criterion (I don't know if they do).
Sure, I will. I wanted to fine-tune it in the test list first, though.
On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral kparal@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.
On Thu, Nov 4, 2021, 11:40 Kamil Paral kparal@redhat.com wrote:
I'm not sure if you understood it correctly (or if I even expressed it correctly). The operations are of course executed sequentially, always (that's how our package managers work). But they can be *scheduled* concurrently, i.e. you can install GIMP, and before it is downloaded and installed, you can also schedule installation of Inkscape. I think this is not an unusual use case, to schedule several operations at once. E.g. I just installed a new system and want to install my favorite applications. Or I decided that I want to play a different game, so I hit Install on OpenArena and also click Remove on SuperTuxKart.
Is this really what you are against, or have you understood it differently? I can try to phrase it better.
Yeah I understood it correctly. I am not saying it's not a valid use case, just that I don't think that it's a common enough use case to be made blocking.
See my response above. Imagine that we'd ensure only the first dnf
operation works correctly, but any later one can blow up. Why would we want to allow that with a graphical package manager?
You can't schedule multiple dnf operations at once. 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. Scheduling multiple tasks without waiting for them to finish one by one is something that I am against blocking on.
On Thu, Nov 4, 2021 at 2:19 PM Ben Cotton bcotton@redhat.com wrote:
On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral kparal@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.
I find it hard to draw the line somewhere between all these cases. So aborting a previous operation is not ok, but not even starting a second operation is ok? Installing and removing the same package is not blocking? What about installing two different packages, would that block? What about installing A and removing B? I don't honestly think it's a good idea to dig into the million of sub-cases here.
Just imagine we're not talking about the package manager but a file manager instead. If you could either create a file, or remove a file, but you couldn't create&remove the file, or you couldn't remove 2 different either sequentially or together, that would clearly be a blocker (I hope). It would be quite obvious that this is a basic functionality. So why isn't this a basic functionality for the package manager? And why do we have (it seems) a different quality bar for dnf vs graphical package managers? I don't think these bugs would be waived for dnf.
I can't speak for the mythical average user, but yes, I believe performing multiple operations in a single session is quite common. Like installing 2 different applications. Or to provide a real-world example, my father likes to play some chess. And so he searches gnome-software for "chess", installs the first app in the result list. He doesn't like it much, so he removes it and installs the second one. I really don't buy that this is not a common enough scenario (replying to Frantisek here as well).
Actually, the fact that gnome-software has been so broken in the past, forced my father to learn some dnf commands. Last week, a non-IT colleague in the office asked me "what the magical command to update the system was, once more?" because gnome-software was stuck again. I personally don't use gnome-software on my home computer, ever. One reason is that I prefer to be in control and see all the text output of dnf, but the second reason is that I don't trust it enough. And I don't think it's ok. I consider gnome-software and PackageKit (it's hard to separate the two and point fingers exactly) to be one of the biggest problems in Fedora Workstation. They are *very* unreliable for the end user, and their problems are extremely hard to debug and almost impossible to reproduce for power users like us. If we don't attempt to improve the situation, it won't. And if we keep saying that it's ok to not be able to install and remove a package in the same session, then I believe Fedora is only suitable for people who don't rely on these tools, like you, or me, or probably most people in this discussion. But not for others.
(To be clear, I don't want to belittle all the work that gnome-software/packagekit developers have done in the past. Especially this cycle, we squashed many gnome-software related bugs, and Milan, the main developer, has been very helpful and active. I'm just stating the fact that graphical package management is unfortunately what I see as the most unreliable part of our desktop).
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.
Agreed. This is the minimal set that we block on, but of course we prefer the tool to be more functional than just the minimal set.
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.
I think I agree with you. Enabling/disabling pre-defined repos is the most important part here. Adding a repo is nice to have, but we don't need to guarantee it, because everything we officially support and block on is already provided with the pre-defined repos. Additional repos only extend that with unofficial packages, and so there's nothing lost from the officially supported set, if the adding functionality is broken (also, that functionality is mostly not present in our current package managers anyway). Deleting a repo is not that important, if you can disable it. KDE Discover offers "setting a default source", i.e. switching whether RPMs or Flatpaks should be installed by default (if the app exists as both). But I think that's a quite minor feature that doesn't need to be blocking.
So let's reduce the original requirement into something like this: * configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly
Does it sound better?
On Thu, Nov 4, 2021 at 3:02 PM Frantisek Zatloukal fzatlouk@redhat.com wrote:
On Thu, Nov 4, 2021, 11:40 Kamil Paral kparal@redhat.com wrote:
I'm not sure if you understood it correctly (or if I even expressed it correctly). The operations are of course executed sequentially, always (that's how our package managers work). But they can be *scheduled* concurrently, i.e. you can install GIMP, and before it is downloaded and installed, you can also schedule installation of Inkscape. I think this is not an unusual use case, to schedule several operations at once. E.g. I just installed a new system and want to install my favorite applications. Or I decided that I want to play a different game, so I hit Install on OpenArena and also click Remove on SuperTuxKart.
Is this really what you are against, or have you understood it differently? I can try to phrase it better.
Yeah I understood it correctly. I am not saying it's not a valid use case, just that I don't think that it's a common enough use case to be made blocking.
I replied to Ben regarding this, please read that response, thanks.
See my response above. Imagine that we'd ensure only the first dnf
operation works correctly, but any later one can blow up. Why would we want to allow that with a graphical package manager?
You can't schedule multiple dnf operations at once.
"dnf install foo bar" "dnf install foo; dnf install bar"
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: https://pagure.io/fedora-qa/blocker-review/issue/560
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?
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'm making fun of it a little. But overall, graphical apps are (and supposed to be) interactive, which demands a different approach in certain areas. In a file manager, would you also argue that the user must not click anything until a file operation is finished? In picture viewer, that a photo can't be advanced until the current one if fully loaded? In a web browser, that a tab can't be switched until the webpage is fully loaded? You'll say "but that's much more common". Yes, perhaps. But at the same time, a package manager working correctly is probably the most important one of all of that. So it's not just about the common paths (many of our criteria aren't).
On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral kparal@redhat.com 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: https://pagure.io/fedora-qa/blocker-review/issue/560
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.
On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral kparal@redhat.com 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:
- Open Graphical package manager
- Install foo
- Close Graphical package manager
- Open Graphical package manager
- Install bar
- Close Graphical package manager
dnfdragora supports doing install + upgrade + removal in the same transaction. This is equivalent to using "dnf shell" to construct a transaction in the CLI.
It is technically possible to do this with PackageKit too, but neither Discover nor Software expose this as far as I know.
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_appl...
"Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention."
a. I take "basic functionality" as a compound noun, equivalent to "fundamental purpose". b. If the package manager has a reproducible crash, it's a blocker. I'm having difficulty parsing the double negative above. Does it means "it may crash with non-basic user intervention"? I have no idea how to categorize basic and non-basic interventions.
Insofar as this applies to GNOME Software and KDE Discover, anything a GUI application lets a user do, is in the course of achieving its fundamental purpose. I'd say any bug that is not a cosmetic bug is a release blocking bug for these components, when the problem is experienced on a release blocking desktops.
I'd be OK distinguishing between two categories: bugs with a documented workaround are OK for beta; but only cosmetic bugs are OK for final. Also, a suitable error message indicating that a requested action can't be completed, along with a hint for an alternative course of action, requires a high burden to make the error a blocker bug (not impossible but it's a higher bar than just silently failing, crashing, or leaving the system in some disfunctional in between state).
If some offered functionality doesn't work, fix it or rip it out.
-- Chris Murphy
On 2021-11-08 9:31 a.m., Neal Gompa wrote:
On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral kparal@redhat.com 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:
- Open Graphical package manager
- Install foo
- Close Graphical package manager
- Open Graphical package manager
- Install bar
- Close Graphical package manager
dnfdragora supports doing install + upgrade + removal in the same transaction. This is equivalent to using "dnf shell" to construct a transaction in the CLI.
It is technically possible to do this with PackageKit too, but neither Discover nor Software expose this as far as I know.
Did I miss something in this thread? Given that the current Gnome graphical package manager requires a full and expensive reboot in between every install for virtually every package for mostly-defective reasons, how would you actually install two packages sequentially like that? Are you suggesting that the current and IMHO poorly-thought-through package manager be finally replaced? If so, hoorah!!!
I'm all for stealing the code from tracer or the Ubuntu installer to identify what needs restarting, and maybe putting out a flag to prevent bug submissions while the running packages are not up-to-date. I believe that would completely eliminate the mandatory reboots, and allow the package manager to move forward properly.
On Mon, Nov 8, 2021 at 10:50 AM John Mellor jmellor@rogers.com wrote:
On 2021-11-08 9:31 a.m., Neal Gompa wrote:
On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal fzatlouk@redhat.com wrote:
On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral kparal@redhat.com 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:
- Open Graphical package manager
- Install foo
- Close Graphical package manager
- Open Graphical package manager
- Install bar
- Close Graphical package manager
dnfdragora supports doing install + upgrade + removal in the same transaction. This is equivalent to using "dnf shell" to construct a transaction in the CLI.
It is technically possible to do this with PackageKit too, but neither Discover nor Software expose this as far as I know.
Did I miss something in this thread? Given that the current Gnome graphical package manager requires a full and expensive reboot in between every install for virtually every package for mostly-defective reasons, how would you actually install two packages sequentially like that? Are you suggesting that the current and IMHO poorly-thought-through package manager be finally replaced? If so, hoorah!!!
No. We are not suggesting it. I am merely explaining what's possible.
Note that Discover *does* let you turn off offline updates if you wish, though we default to offline updates.
Even with online updates, Discover and Software do not let you select multiple actions before executing it.
I'm all for stealing the code from tracer or the Ubuntu installer to identify what needs restarting, and maybe putting out a flag to prevent bug submissions while the running packages are not up-to-date. I believe that would completely eliminate the mandatory reboots, and allow the package manager to move forward properly.
We will *not* change the default back to online updates for Discover or Software.
On Mon, Nov 8, 2021 at 3:26 PM Frantisek Zatloukal fzatlouk@redhat.com wrote:
"dnf install foo; dnf install bar"
This is equivalent to:
- Open Graphical package manager
- Install foo
- Close Graphical package manager
- Open Graphical package manager
- Install bar
- Close Graphical package manager
Or perhaps I could counter this with: gnome-software = bash (running the whole time), dnf = packagekit (performing one operation at a time). And then I'd use some even more absurd and nonsensical analogy :-) Let's... not continue in this fruitless comparison. My original purpose was to compare the tools focusing on the end result, and of course assuming they are used in the manner in which they are *intended* to be used. Which, for a CLI tool, is obviously a CLI-based approach, and for a GUI tool, a GUI-based approach (which includes interactivity and concurrency, if it allows it, as is usual for GUIs).
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.
OK. I disagree that the deciding factor here should be "I don't think people use it often". I think it should be a combination of "how often people do it" and "what impact it has if it breaks". We don't know how often people do it, we only have personal experience, and we clearly won't agree on that. Perhaps we can agree at least that it's not something esoteric that would only a couple of power users know about (perhaps like "dnf shell"). But the second part is more important for me here. With a package manager, the impact can be serious system damage. That overrides the "people might not use it often" part, at least for me. Let's see what others think.
On Mon, Nov 8, 2021 at 4:28 PM Chris Murphy lists@colorremedies.com wrote:
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_appl...
"Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention."
a. I take "basic functionality" as a compound noun, equivalent to "fundamental purpose". b. If the package manager has a reproducible crash, it's a blocker. I'm having difficulty parsing the double negative above. Does it means "it may crash with non-basic user intervention"?
Yes, I believe it says that.
I have no idea how to categorize basic and non-basic interventions.
With much difficulty, that's why we're having this thread :-)
Insofar as this applies to GNOME Software and KDE Discover, anything a GUI application lets a user do, is in the course of achieving its fundamental purpose. I'd say any bug that is not a cosmetic bug is a release blocking bug for these components, when the problem is experienced on a release blocking desktops.
"anything a GUI application lets a user do" is a potential trap. You can submit app ratings in gnome-software, and I'm quite sure we don't want to block the release on that. That's why I proposed an exact list.
On Mon, Nov 8, 2021 at 11:39 AM Kamil Paral kparal@redhat.com wrote:
On Mon, Nov 8, 2021 at 4:28 PM Chris Murphy lists@colorremedies.com wrote:
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_appl...
"Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention."
a. I take "basic functionality" as a compound noun, equivalent to "fundamental purpose". b. If the package manager has a reproducible crash, it's a blocker. I'm having difficulty parsing the double negative above. Does it means "it may crash with non-basic user intervention"?
Yes, I believe it says that.
I have no idea how to categorize basic and non-basic interventions.
With much difficulty, that's why we're having this thread :-)
Insofar as this applies to GNOME Software and KDE Discover, anything a GUI application lets a user do, is in the course of achieving its fundamental purpose. I'd say any bug that is not a cosmetic bug is a release blocking bug for these components, when the problem is experienced on a release blocking desktops.
"anything a GUI application lets a user do" is a potential trap. You can submit app ratings in gnome-software, and I'm quite sure we don't want to block the release on that. That's why I proposed an exact list.
When installing, removing, or updating software? If I click an install button, the selected app should be installed or it's a blocking bug. Same for removal, same for updating. If it lets you click install for multiple programs in sequence, they should all be successfully installed. If that's not possible, then don't let users queue up multiple programs for installation.
I agree that if it crashes when submitting app ratings, I'd consider it cosmetic.
On Tue, Nov 9, 2021 at 4:47 AM Chris Murphy lists@colorremedies.com wrote:
When installing, removing, or updating software? If I click an install button, the selected app should be installed or it's a blocking bug. Same for removal, same for updating. If it lets you click install for multiple programs in sequence, they should all be successfully installed. If that's not possible, then don't let users queue up multiple programs for installation.
I tend to agree, but others don't: https://pagure.io/fedora-qa/blocker-review/issue/560 https://meetbot.fedoraproject.org/fedora-meeting/2021-10-21/f35-final-go_no_...
That's why an explicit action list seems like the best forward, if we can agree on it.
On Mon, Nov 8, 2021 at 8:37 AM Kamil Paral kparal@redhat.com wrote:
I find it hard to draw the line somewhere between all these cases. So aborting a previous operation is not ok, but not even starting a second operation is ok? Installing and removing the same package is not blocking? What about installing two different packages, would that block? What about installing A and removing B? I don't honestly think it's a good idea to dig into the million of sub-cases here.
Just imagine we're not talking about the package manager but a file manager instead. If you could either create a file, or remove a file, but you couldn't create&remove the file, or you couldn't remove 2 different either sequentially or together, that would clearly be a blocker (I hope). It would be quite obvious that this is a basic functionality. So why isn't this a basic functionality for the package manager? And why do we have (it seems) a different quality bar for dnf vs graphical package managers? I don't think these bugs would be waived for dnf.
I agree with František's comment that the DNF case is different enough in how it functions that it's not a fair comparison. I do think that aborting a previous operation is not okay, but refusing to start a second operation until the first is done is. Ideally with a clear message explaining why, but not necessarily.
So I still disagree with you, but my position is softening. I'd rather we have a clearly-defined and understood set of criteria that I disagree with in some places than to try to make every criterion match my preferences. :-) So while I disagree, I'm happy to move forward with this.
So let's reduce the original requirement into something like this:
- configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly
Does it sound better?
Yes, that works for me.
On Tue, Nov 9, 2021 at 3:47 PM Ben Cotton bcotton@redhat.com wrote:
So I still disagree with you, but my position is softening. I'd rather we have a clearly-defined and understood set of criteria that I disagree with in some places than to try to make every criterion match my preferences. :-) So while I disagree, I'm happy to move forward with this.
Hmm, let's try something different first. I'll provide a list of scenarios below, and I'd like everyone participating in this discussion to respond whether they think that scenario should be blocking or non-blocking (for Final), and ideally why. Perhaps we can distill some reasonable requirements if we don't talk about it abstractly or with dnf-like comparisons, but with actual examples.
Scenario 1: User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Install on pkg B. That returns an error. After closing and re-opening the package manager, pkg B can be installed. (In other words, only one operation can be performed, and then the manager needs to get restarted).
Scenario 2: User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Remove on pkg A. That returns an error. After closing and re-opening the package manager, pkg A can be removed. (This problem only affects two subsequent operations on the same package. Performing multiple operations on distinct packages works fine).
Scenario 3: User clicks Install on pkg A. Before that is finished, she navigates the interface elsewhere. E.g. seeing the home screen, searching for something, showing the installed apps, showing the updates, etc. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed. It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.
Scenario 4: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed, and pkg B installation is started (and finished correctly). It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.
Scenario 5: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. A cryptic error shows up (the user doesn't understand it), e.g. "installation constraint failed: failed to acquire a lock: pkg B". It's a bug, not a design decision. Repeating that action only shows the error again. Pkg A is eventually installed OK, but pkg B installation wasn't even started. Once pkg A is installed, pkg B installation can be started and finished OK.
Scenario 6: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. An understandable dialog pops up: "Please wait until pkg A installation is finished". Once pkg A is installed, pkg B installation can be started.
Scenario 7: User clicks Install on pkg A. Before that is finished, she performs a different valid action. That can be navigating to a different screen, or clicking Install on pkg B (the particular action is not important in this scenario). That second action triggers a bug and pkg A installation is incorrectly aborted in a non-clean manner. The system ends up in an *inconsistent* state, i.e. internal databases (like the rpmdb or dnfdb) are damaged. No further package operations (installations/removals/updates) are possible, everything results in a cryptic error. Rebooting the system doesn't help.
On Wed, Nov 10, 2021 at 5:49 PM Kamil Paral kparal@redhat.com wrote:
Hmm, let's try something different first. I'll provide a list of scenarios below, and I'd like everyone participating in this discussion to respond whether they think that scenario should be blocking or non-blocking (for Final), and ideally why. Perhaps we can distill some reasonable requirements if we don't talk about it abstractly or with dnf-like comparisons, but with actual examples.
My take:
Scenario 1:
User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Install on pkg B. That returns an error. After closing and re-opening the package manager, pkg B can be installed. (In other words, only one operation can be performed, and then the manager needs to get restarted).
Blocking. The package manager doesn't fulfill its basic role - install packages (notice the plural). Restarting the manager is a decent workaround - for Beta testers.
Scenario 2: User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Remove on pkg A. That returns an error. After closing and re-opening the package manager, pkg A can be removed. (This problem only affects two subsequent operations on the same package. Performing multiple operations on distinct packages works fine).
Blocking. A bug that occurs with multiple operations on the same package is a special case of the above. If I can't install and uninstall the same package over and over again, the package manager again doesn't fulfill its basic role. Restarting the manager is a decent workaround - for Beta testers.
Scenario 3: User clicks Install on pkg A. Before that is finished, she navigates the interface elsewhere. E.g. seeing the home screen, searching for something, showing the installed apps, showing the updates, etc. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed. It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.
Blocking. The user performed completely valid actions, offered by the GUI. The user is not expected (even though many do) to stare at a static screen. Quite the contrary, GUIs are expected to be interactive basically all the time (even if they just show a spinner or similar). Aborting the installation fails basic expectations.
Scenario 4: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed, and pkg B installation is started (and finished correctly). It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.
Blocking. It's the same case as above, just slightly modified. Aborting the installation fails basic expectations. The GUI supports queuing actions, it is very visible and obvious how to do it, and so this is a failure within basic interactions with the package manager.
Scenario 5: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. A cryptic error shows up (the user doesn't understand it), e.g. "installation constraint failed: failed to acquire a lock: pkg B". It's a bug, not a design decision. Repeating that action only shows the error again. Pkg A is eventually installed OK, but pkg B installation wasn't even started. Once pkg A is installed, pkg B installation can be started and finished OK.
Blocking. Everything said above applies here as well. The consequences are a bit different (a displayed error vs an aborted action), but both fail to perform the intended task, which was within basic interactions with the package manager.
Scenario 6: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. An understandable dialog pops up: "Please wait until pkg A installation is finished". Once pkg A is installed, pkg B installation can be started.
Not blocking. This is a somewhat fake scenario :-) There is no bug, it behaves according to program design. So it's fully covered by the footnote I wrote. I included it to demonstrate a difference between seemingly similar cases, but one is a bug and one is a correct behavior. (Of course, even better would be to disable Install buttons while some operation is in progress, and avoid those dialogs, but that's not the point here).
Scenario 7: User clicks Install on pkg A. Before that is finished, she performs a different valid action. That can be navigating to a different screen, or clicking Install on pkg B (the particular action is not important in this scenario). That second action triggers a bug and pkg A installation is incorrectly aborted in a non-clean manner. The system ends up in an *inconsistent* state, i.e. internal databases (like the rpmdb or dnfdb) are damaged. No further package operations (installations/removals/updates) are possible, everything results in a cryptic error. Rebooting the system doesn't help.
Blocking. The system must not get damaged, if only standard operations are performed (and at least with gnome-software, it's designed to only contain basic interactions, i.e. it's hard to stray into some niche power-user corner case approach; that might be a bit different with plasma-discover, or of course dnf).
On Wed, Nov 10, 2021 at 11:50 AM Kamil Paral kparal@redhat.com wrote:
On Tue, Nov 9, 2021 at 3:47 PM Ben Cotton bcotton@redhat.com wrote:
So I still disagree with you, but my position is softening. I'd rather we have a clearly-defined and understood set of criteria that I disagree with in some places than to try to make every criterion match my preferences. :-) So while I disagree, I'm happy to move forward with this.
Hmm, let's try something different first. I'll provide a list of scenarios below, and I'd like everyone participating in this discussion to respond whether they think that scenario should be blocking or non-blocking (for Final), and ideally why. Perhaps we can distill some reasonable requirements if we don't talk about it abstractly or with dnf-like comparisons, but with actual examples.
Scenario 1: User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Install on pkg B. That returns an error. After closing and re-opening the package manager, pkg B can be installed. (In other words, only one operation can be performed, and then the manager needs to get restarted).
Scenario 2: User clicks Install on pkg A. She waits until that is done. Pkg A gets installed correctly. Then she clicks Remove on pkg A. That returns an error. After closing and re-opening the package manager, pkg A can be removed. (This problem only affects two subsequent operations on the same package. Performing multiple operations on distinct packages works fine).
Scenario 3: User clicks Install on pkg A. Before that is finished, she navigates the interface elsewhere. E.g. seeing the home screen, searching for something, showing the installed apps, showing the updates, etc. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed. It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.
Scenario 4: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. Because of this interaction, pkg A installation process is incorrectly aborted (cancelled), i.e. it doesn't get installed, and pkg B installation is started (and finished correctly). It's a bug, not a design decision. The system is in a consistent state, internal databases are valid.
Scenario 5: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. A cryptic error shows up (the user doesn't understand it), e.g. "installation constraint failed: failed to acquire a lock: pkg B". It's a bug, not a design decision. Repeating that action only shows the error again. Pkg A is eventually installed OK, but pkg B installation wasn't even started. Once pkg A is installed, pkg B installation can be started and finished OK.
Scenario 6: User clicks Install on pkg A. Before that is finished, she clicks Install on pkg B. An understandable dialog pops up: "Please wait until pkg A installation is finished". Once pkg A is installed, pkg B installation can be started.
Scenario 7: User clicks Install on pkg A. Before that is finished, she performs a different valid action. That can be navigating to a different screen, or clicking Install on pkg B (the particular action is not important in this scenario). That second action triggers a bug and pkg A installation is incorrectly aborted in a non-clean manner. The system ends up in an *inconsistent* state, i.e. internal databases (like the rpmdb or dnfdb) are damaged. No further package operations (installations/removals/updates) are possible, everything results in a cryptic error. Rebooting the system doesn't help.
My take, all except 6 are blocking.
On Wed, Nov 10, 2021 at 2:02 PM Chris Murphy lists@colorremedies.com wrote:
My take, all except 6 are blocking.
Ooh I like this game where I don't read all the posts, and end up agreeing with Kamil having not seen the answers first.
I assume we are talking about a GUI software manager and not DNF. I also assume that we want to deliver a user friendly package manager that is a pleasure to work with. On that assumption:
*Scenario 1: Blocking*. You do not want to restart an application any time you want to start doing another operation with it. *Scenario 2: Not sure. *If, in that situation, the application showed a message that freshly installed packages must settle first and that it needs restarting the application, I would think this is not blocking. Without explanation, this feels like blocking. *Scenario 3: Blocking* if interactions like these are possible. *Scenario 4: Blocking*. Dtto. *Scenario 5: Not blocking* - a common bug candidate. This is a little wrongly implemented Scenario 6. *Scenario 6: Not blocking* - actually this feels like a fair behaviour to me, although that train has gone and now we expect a little more. *Scenario 7: Blocking* - clearly
If we just want to deliver a package manager that somehow "works" and do not bother about its user friendliness, then I switch *Scenarios 3 and 4 to not blocking, but common bugs candidate.*
_______________________________________________
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@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
On Thu, Nov 11, 2021 at 10:41 AM Lukas Ruzicka lruzicka@redhat.com wrote:
I assume we are talking about a GUI software manager and not DNF.
Yes.
I also assume that we want to deliver a user friendly package manager that is a pleasure to work with. On that assumption:
*Scenario 1: Blocking*. You do not want to restart an application any time you want to start doing another operation with it. *Scenario 2: Not sure. *If, in that situation, the application showed a message that freshly installed packages must settle first and that it needs restarting the application, I would think this is not blocking. Without explanation, this feels like blocking.
If it said "sorry, an application restart is needed to perform this operation", then yes, I'd also consider it not blocking, because it would work according to the design goals. It's a poor UI, but not a bug. But that was not what I meant. I meant seeing a cryptic error, e.g. "database lookup returns null", or even our old friend "package not found". I.e. nothing that would explain to the general user what is wrong and what needs to be done.
*Scenario 3: Blocking* if interactions like these are possible. *Scenario 4: Blocking*. Dtto. *Scenario 5: Not blocking* - a common bug candidate. This is a little wrongly implemented Scenario 6. *Scenario 6: Not blocking* - actually this feels like a fair behaviour to me, although that train has gone and now we expect a little more.
Yes, as I explained in my follow-up email, it is a fair behavior, exactly as you say.
*Scenario 7: Blocking* - clearly
If we just want to deliver a package manager that somehow "works" and do not bother about its user friendliness, then I switch *Scenarios 3 and 4 to not blocking, but common bugs candidate.*
Sigh, with conditional answers you're making my life even more difficult :-D
Given that we currently block on applications having nice icons [1], I hope that our standards for GUI apps functionality is not as low as to require the user to not even breathe when they click on a button. I might be wrong, though :-)
What is your preference? Works decently (3 and 4 blocking) or works barebones (3 and 4 not blocking)? (I'll just note that we're talking about Final criteria here. "Works barebones" is already available for Beta.)
[1] See the last sentence in https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_appl...
My personal preference is *works decently* of course. My old self keeps calling from the history of times something like "I have told you that Linux kicks ass and Windows kick balls."
On Thu, Nov 11, 2021 at 5:07 PM Kamil Paral kparal@redhat.com wrote:
On Thu, Nov 11, 2021 at 10:41 AM Lukas Ruzicka lruzicka@redhat.com wrote:
I assume we are talking about a GUI software manager and not DNF.
Yes.
I also assume that we want to deliver a user friendly package manager that is a pleasure to work with. On that assumption:
*Scenario 1: Blocking*. You do not want to restart an application any time you want to start doing another operation with it. *Scenario 2: Not sure. *If, in that situation, the application showed a message that freshly installed packages must settle first and that it needs restarting the application, I would think this is not blocking. Without explanation, this feels like blocking.
If it said "sorry, an application restart is needed to perform this operation", then yes, I'd also consider it not blocking, because it would work according to the design goals. It's a poor UI, but not a bug. But that was not what I meant. I meant seeing a cryptic error, e.g. "database lookup returns null", or even our old friend "package not found". I.e. nothing that would explain to the general user what is wrong and what needs to be done.
*Scenario 3: Blocking* if interactions like these are possible. *Scenario 4: Blocking*. Dtto. *Scenario 5: Not blocking* - a common bug candidate. This is a little wrongly implemented Scenario 6. *Scenario 6: Not blocking* - actually this feels like a fair behaviour to me, although that train has gone and now we expect a little more.
Yes, as I explained in my follow-up email, it is a fair behavior, exactly as you say.
*Scenario 7: Blocking* - clearly
If we just want to deliver a package manager that somehow "works" and do not bother about its user friendliness, then I switch *Scenarios 3 and 4 to not blocking, but common bugs candidate.*
Sigh, with conditional answers you're making my life even more difficult :-D
Given that we currently block on applications having nice icons [1], I hope that our standards for GUI apps functionality is not as low as to require the user to not even breathe when they click on a button. I might be wrong, though :-)
What is your preference? Works decently (3 and 4 blocking) or works barebones (3 and 4 not blocking)? (I'll just note that we're talking about Final criteria here. "Works barebones" is already available for Beta.)
[1] See the last sentence in https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_appl...
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@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
Scenario 1:This is not stated to be a bug, but I think most people, including me, would see it as a bug. That said this makes a bad impression on the user; especially a new user. I don't believe this is a blocker, but should be a Freeze Exception bug and a Priority bug.
Scenario 2: Same as Scenario 1.
Scenario 3: This makes a very bad impression on the user; especially a new user. Since there is no error message and the user may not be aware of the problem until they try to use the application, I believe this is a blocker.
Scenario 4: Same as Scenario 3.
Scenario 5: This may result in the user closing the package manager when the message appears so package A doesn't get installed. This makes a very bad impression on the user; especially a new user. The user knows there is a problem, but they may conclude the the package manager is unusable. I believe this is a blocker.
Scenario 6: This makes a very bad impression on the user. Fedora is supposed to be an advanced multitasking OS that can run multiple threads on multiple processors. This is not a blocker, or a bug, but the package manager needs some improvement.
Scenario 7: This is a blocker
-
Ben Cotton -
Brandon Nielsen -
Chris Murphy -
Frantisek Zatloukal -
John Mellor -
Kamil Paral -
Lukas Ruzicka -
Neal Gompa -
Pat Kelly