On Thu, Jan 20, 2022 at 10:26 PM Kamil Paral <kpa...@redhat.com> wrote:
> 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: > > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/LR2FDFMOY4E55ZYBHWOOINZS27FQ6LSB/#LR2FDFMOY4E55ZYBHWOOINZS27FQ6LSB > > 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). > * 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. > ~~~~~~~~~~~~~~~~~~~~ > > 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? > > > [1] > https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-remove-update > [2] > https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2C_removing_and_updating_software > _______________________________________________ > 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 > This seems to be an improved version compared to the last one. I think as adamw mentioned, we should move ahead with it and update it when the need comes. -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>
_______________________________________________ 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
