In blocker discussions during the F35 cycle, there were multiple arguments about what exactly is and is not the required functionality of a graphical package manager, and it was decided that we'd like to have an explicit criterion covering those apps in detail. You can find a proposal for this criterion below, and I'd like to hear your thoughts/concerns. This proposal was already discussed (and fine-tuned) on the test list, so you can read the existing discussion there [1] (and even an older one from November as well [2]).
Please note that we already have package management partly covered in the Basic criteria [3] and Beta criteria [4]. 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
* List locally-installed software coming from the official Fedora repositories
* 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 by enabling/disabling pre-defined official repositories 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)
The following must hold true:
* When multiple operations (covered by this criterion) are requested, all of them must finish correctly. (It's also valid to inform the user that a certain operation is not available at that moment, see the "Supported functionality and design decisions" note).
* The displayed state of software or software sources must not differ from their actual state. (E.g. an RPM package must not be shown as installed when it is not, a repository must not be shown as disabled or missing when it is enabled, etc).
* Usual GUI interactivity must not break operations covered by this criterion. (E.g. when the GUI allows the user to click some buttons while an operation is running, it must not break that operation).
* The package manager must never make the system enter an inconsistent or unbootable state. (E.g. damage the local software database, remove wrong system files, break the bootloader, etc).
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: Systems in an inconsistent state
While the package manager must not be the primary cause for breaking a system (unbootable, invalid internal structures, etc), it doesn't have to '''prevent''' these events from happening. So if there's e.g. a power outage during its operation or a package with harmful scriptlets is installed, which breaks the system, this is not the fault of the package manager and the criteria above are not considered violated. Similarly, when the package manager operates on an already broken system (e.g. with an inconsistent rpm database), the correct behavior cannot be guaranteed, and therefore the criteria also don't apply.
Note: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools][3] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also.
~~~~~~~~~~~~~~~~~~~~
Please tell me if this sounds reasonable to you. Thank you.
[1] https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/thread/ZH3LFVXEN7WOJDNYBNKZVXOFWCNVQNUZ/
[2] https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/thread/LR2FDFMOY4E55ZYBHWOOINZS27FQ6LSB/
[3] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update
[4] https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2C_removing_and_updating_software
Please note that we already have package management partly covered in the Basic criteria [3] and Beta criteria [4]. 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
* List locally-installed software coming from the official Fedora repositories
* 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 by enabling/disabling pre-defined official repositories 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)
The following must hold true:
* When multiple operations (covered by this criterion) are requested, all of them must finish correctly. (It's also valid to inform the user that a certain operation is not available at that moment, see the "Supported functionality and design decisions" note).
* The displayed state of software or software sources must not differ from their actual state. (E.g. an RPM package must not be shown as installed when it is not, a repository must not be shown as disabled or missing when it is enabled, etc).
* Usual GUI interactivity must not break operations covered by this criterion. (E.g. when the GUI allows the user to click some buttons while an operation is running, it must not break that operation).
* The package manager must never make the system enter an inconsistent or unbootable state. (E.g. damage the local software database, remove wrong system files, break the bootloader, etc).
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: Systems in an inconsistent state
While the package manager must not be the primary cause for breaking a system (unbootable, invalid internal structures, etc), it doesn't have to '''prevent''' these events from happening. So if there's e.g. a power outage during its operation or a package with harmful scriptlets is installed, which breaks the system, this is not the fault of the package manager and the criteria above are not considered violated. Similarly, when the package manager operates on an already broken system (e.g. with an inconsistent rpm database), the correct behavior cannot be guaranteed, and therefore the criteria also don't apply.
Note: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools][3] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also.
~~~~~~~~~~~~~~~~~~~~
[1] https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/thread/ZH3LFVXEN7WOJDNYBNKZVXOFWCNVQNUZ/
[2] https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx/thread/LR2FDFMOY4E55ZYBHWOOINZS27FQ6LSB/
[3] https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update
[4] https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2C_removing_and_updating_software
_______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-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/kde@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
