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_application_functionality
[2] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update
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_application_functionality
[2] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update
_______________________________________________ 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
