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.
_______________________________________________
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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
