On 2022-01-20 11:54 a.m., Kamil Paral 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
I've done generic, app-specific and custom installers and lots of
install environments on a lot of architectures for about 45 years of my
50 years working as a mission-critical developer and maintainer. There
a lots of people who do not understand the Unix way of doing things or
how to take advantage of the Unix filesystem to do things a lot better
than Windows, and try to make installation or upgrades behave more like
ancient Windows patches. There are also a growing number of Fedora
users who are now discarding the GUI updater in favour of dnf installs,
primarily due to the GUI updater having extreme and unnecessary reboot
requirements.
The suggested criteria list is pretty generic, and offhand I can't think
of a current GUI or CLI installer that does not conform to these
requirements.
What this list does NOT cover are the pain points of the current
product, such as avoiding reboots. Currently, the Fedora GUI installer
always reboots twice, even though 80% of the updates do not require
reboots at all, and similar to the Debian-based distros, tools such as
the needs-restarting component of the yum-utils package exist to show
that shared libs or open files are out-of-date and either app or full
system reboots are required to put the system into a supportable state.
Unlike other distros, there are certain apps, like parts of the Gnome
desktop and Firefox, that do not respect a policy of no API changes in a
given release, and these apps tend to break routinely because of this
broken development model being considered acceptable. If I look at
Ubuntu practices for example, they introduce a needs-rebooting flag that
is set when a memory-mapped file is altered, or when an API change is
intentionally introduced. However, having multiple versions of shared
libs in use at the same time is not an error, but a really good
Unix/Linux feature that is not a valid criteria for a reboot. The
current GUI installer behaves more like Windows, and does not allow this
situation when it most certainly should. Fedora should consider fixing
these packages that routinely allow developer errors instead of
downloading the resulting problems to the end user, and the installer
tools should not be aiding and abetting bad development practices.
Just my humble opinion as a past master of installers or all types and
sizes.
--
John Mellor
_______________________________________________
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
