new release criterion proposal: Graphical package managers

[Kamil Paral]

In blocker discussions during the F35 cycle, there were multiple arguments
about what exactly is and is not the required functionality of a graphical
package manager, and it was decided that we'd like to have an explicit
criterion covering those apps in detail. You can find a proposal for this
criterion below, and I'd like to hear your thoughts/concerns. This proposal
was already discussed (and fine-tuned) on the test list, so you can read
the existing discussion there [1] (and even an older one from November as
well [2]).

Please note that we already have package management partly covered in the
Basic criteria [3] and Beta criteria [4]. 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: Systems in an inconsistent state
While the package manager must not be the primary cause for breaking a
system (unbootable, invalid internal structures, etc), it doesn't have to
'''prevent''' these events from happening. So if there's e.g.
a power
outage during its operation or a package with harmful scriptlets is
installed, which breaks the system, this is not the fault of the package
manager and the criteria above are not considered violated. Similarly, when
the package manager operates on an already broken system (e.g. with an
inconsistent rpm database), the correct behavior cannot be guaranteed, and
therefore the criteria also don't apply.

Note: Refer to Basic footnotes
The footnotes for the [similar Basic criterion covering console tools][3]
regarding software types, 'appropriate' behavior, scope and so on are all
generally applicable to this criterion also.
~~~~~~~~~~~~~~~~~~~~


Please tell me if this sounds reasonable to you. Thank you.


[1]
https://lists.fedoraproject.org/archives/list/[e-mail]...
[2]
https://lists.fedoraproject.org/archives/list/[e-mail]...
[3]
https://fedoraproject.org/wiki/Basic_Release_Criteria#software-install-re...
[4]
https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing...

[Ben Cotton]

On Tue, Feb 8, 2022 at 3:46 AM Kamil Paral <kparal(a)redhat.com&gt; wrote:
>  Please tell me if this sounds reasonable to you. Thank you. 
Everything looks good except for

>  * Install, remove and update software 
There should be a comma after "remove". I am Team Oxford Comma. :-)

But I think this describes our goals correctly and as unambigiously as
possible. Thanks for pushing this through a million edits!

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Adam Williamson]

On Tue, 2022-02-08 at 07:37 -0500, Ben Cotton wrote:
>  On Tue, Feb 8, 2022 at 3:46 AM Kamil Paral <kparal(a)redhat.com&gt;
> wrote:
>  > 
>  > Please tell me if this sounds reasonable to you. Thank you.
>  
>  Everything looks good except for
>  
>  > * Install, remove and update software
>  
>  There should be a comma after "remove". I am Team Oxford Comma. :-) 
.fire bcotton
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Adam Williamson]

On Tue, 2022-02-08 at 07:37 -0500, Ben Cotton wrote:
>  On Tue, Feb 8, 2022 at 3:46 AM Kamil Paral <kparal(a)redhat.com&gt;
> wrote:
>  > 
>  > Please tell me if this sounds reasonable to you. Thank you.
>  
>  Everything looks good except for
>  
>  > * Install, remove and update software
>  
>  There should be a comma after "remove". I am Team Oxford Comma. :-) 
.fire bcotton
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net