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.or...
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?