On Thu, Jan 20, 2022 at 9:55 AM 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?
Looks good to me. -- Chris Murphy _______________________________________________ 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
