This is another attempt at creating a new release criterion specific for graphical package managers. We already discussed it in November, but we couldn't agree easily on some particular details, and then I was gone for a long time:
Here is my new attempt. The new criterion text is longer, but I believe it is overall somewhat weaker (to accommodate some of the previous concerns), just more explicit. As before, please note that we already have package management partly covered in the
Basic criteria [1] and Beta criteria [2]. 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).
* 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: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools][1] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also.
* 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: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools][1] regarding software types, 'appropriate' behavior, scope and so on are all generally applicable to this criterion also.
~~~~~~~~~~~~~~~~~~~~
If you compare it to the previous proposal, the new one avoids talking about "sequential or concurrent" operations. That leaves some more wiggle room when arguing that specific approaches are too niche (Frantisek's concern), i.e. it no longer clearly covers these approaches completely. However, it still makes sure that multiple operations are covered at least at a basic level (which should cover our famous "install and then remove the same package"). The tool can also say "no can do", and when that happens to be some internal error message, we can discuss how clear it is to the user.
I updated the "list installed software" and "configure sources" requirements with suggestions from Ben.
It also explicitly mentions that just basic clicking through GUI must not abort running operations (which was something that got good consensus). And adds an obvious statement about not breaking the system, which was implied in the past but I assumed it's better to have it clearly visible (this one could be moved to Beta, possibly).
Finally it adds a requirement that the package manager must not mislead the user by showing e.g. something as installed when it is not. You can say this was also implied in the past (otherwise the 'install' or 'list' operation is not working correctly). but again, this is just to avoid "it works well, just displays it wrongly" arguments in the future.
What do you think?
_______________________________________________ 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
