Michael Catanzaro píše v Út 02. 05. 2017 v 19:32 -0500:
Hi,
Wow, nice list! Thanks for putting this together. A few
comments/complaints from me:
On Tue, May 2, 2017 at 9:47 AM, Jiri Eischmann <eischmann(a)redhat.com>
wrote:
> UPDATES
> Quite a few people complained about having to restart to install
> updates. I know objective reasons for this, but it's important to
> understand that it's perceived as annoying by users and we should
> strive for minimizing the number of packages that need to be
> updated
> offline.
First priority should be to fix our update frequency. Currently the
policy is this:
* Daily notifications of available security updates
* Daily notifications of all flatpak updates (no restart required,
but
still annoying)
* Weekly notifications of other (normal) updates
I'd be interested in seeing statistics on how frequently we have
security updates, but my guess is that there is a new security
update
every 2-3 days, so in practice we prompt users to reboot 2-3 times
per
week. Maybe even more? I have not been keeping track.
Problem is: most security updates are not high-priority. We do need
daily notification for the most serious security updates, but the
vast
majority of security updates do not require expedited release. Our
updates already have metadata to indicate the severity of the
security
issue (low/medium/high), so we should start notifying daily only for
the high priority security updates and see how well that goes.
We also do not need weekly notifications of normal updates. Let's
dial
this back to monthly instead. With these changes, I expect we would
have an order of magnitude fewer reboots.
Even the nightly flatpak apps need to not trigger daily
notifications.
These should either be updated monthly like everything else, or
updated
silently in the background (because why not?)
It'd be worth to analyze more. I'm not sure there is one size that fits
all needs. There are certainly users (my mom for instance) who just use
Fedora and don't care about updates at all, so for them the best are
updates as least frequent as possible as long as we keep them safe.
Then there is a group of people who welcome daily updates, but don't
want to go through the hassle of restarting for them.
And I also often hear that people miss automatic updates of Flatpaks
because if you use a couple of nightly versions, manual updating every
day is just tiresome.
> UPGRADES
> One of the most frequent request was an LTS version. When I asked
> why,
> the answer was typically that upgrades still bring
> incompatibilities,
> regressions, lost settings. The most frequently mentioned offender
> was
> NM, other mentioned problems were mostly hardware related
> (regressions
> in graphics, dockin station support, sound).
Well the LTS is definitely CentOS. There seems to be little value in
us
trying to compete with ourselves by offering a second LTS. I don't
know
how to make this more clear to users.
Well, I think we have consensus here. The solution should not be Fedora
LTS. There are deployments where Fedora is not simply suitable and we
should just recommend RHEL/CentOS as the LTS version.
Upgrades of Fedora have improved a lot in the recent years, but
apparently they're not still on the level at which users feel
comfortable just upgrading instead of using LTS. I'd like to look at
the NM problems, I've never had a problem with it, but NM losing
settings etc. after upgrading was really one of the most frequent
complaints.
> * Some extensions make the Shell crash.
Well that's the result of turning off the version checks. There's no
way to avoid this without removing support for extensions entirely,
or
requiring extension authors to validate compatibility. We decided to
get rid of that step, so more crashes are to be expected.
What we should probably do is have a mechanism for flagging
extensions
as broken, so that they can be removed from
extensions.gnome.org
until
they are fixed.
> * You have to restart to switch from GNOME Classic to GNOME
> (perhaps a
> bug in F25?).
Definitely a bug of some sort.
> WAYLAND
> Not really big surprises here:
> * Missing remote desktop (one of the most frequent comments at
> all).
> * Missing color picker support.
There's no color picker...? Why not? That seems really weird. This
is
GtkColorChooser? I'm trying it right now, via GtkWidgetFactory, and
it's working perfectly fine. Is this maybe some third-party
application
that's broken?
What they meant was the color picker which allows you to pick a color
of a random pixel on the screen like in GIMP. That's not possible with
Wayland AFAIK.
> LOCALIZATION
> Users don't get a fully localized system after installing Fedora.
> Many
> languages don't have all l10n packages on the installation ISO and
> users have to run 'sudo dnf install langpacks-*' manually to
> install
> missing packages, but most users don't have a clue about this and
> just
> think that the missing localization is not in Fedora at all. Mainly
> LibreOffice suffers from this not being localized at all. This is a
> long known problem and we should really fix it and install the
> missing
> packages automatically either during installation or in the initial
> experience.
All supported languages need to be on the installation ISO, even if
it
makes the ISO twice as large. Non-English locales like Czech should
not
be second-class citizens in Fedora. We should fix this. A larger ISO
would be unfortunate for users stuck on metered connections, but
this
is something you only have to download once.
I've been an ambassador for EMEA and I know how big problem this is for
people in developing countries. They're often stuck with connections
like <=1 Mbps. Having an ISO that is 3-4 GB in size could actually make
them download another distro instead.
Ubuntu also downloads the l10n packages post-install.
> There have been a couple of other complaints about
locatization,
> everything language specific. But localization seems to be very
> important to users and they're very sensitive to untranslated
> pieces
> of
> UI, especially if it's what's perceived as part of the system, it
> makes
> the system look amateurish.
On the other hand, it's not our job to provide a good translation
into
every language for every app. Hopefully the Czech-speaking community
can step up to help the Fedora and GNOME translation project. I know
that GNOME at least has a very active Czech translator, Marek; he
would
probably like to hear specific feedback.
> PDF
> Many complaints about PDF support, mostly:
> * Evince doesn't support non-ascii characters in PDF forms, this is
> a
> major problem for many people.
> * Some PDF forms refuse to work with anything but Acrobat Reader
> although they may work just fine with Evince, faking a reader's
> identity might be a solution here.
> * Incomplete support for PDF 1.7.
One problem here is that some PDFs use Adobe JavaScript. 99% of
these
PDFs are malicious and use it to install Windows viruses, but some
of
them are legit. Evince does not support JavaScript. (And frankly,
that's probably for the better.) I don't know how many PDFs this
affects.
> * Firefox should have tabs integrated into the title bar just like
> on
> Window.
We should ship with Epiphany preinstalled. Firefox on GNOME is such
a
joke. How many months was the GNOME integration theme broken last
year?
;)
> * Cannot connect to GOA accounts after log out and log in to the
> account (it's a known systemd bug, but a pretty annoying one and we
> have had it for several releases already).
This is an accepted F26 blocker, so it's going to get fixed one way
or
another.
> BUG HANDLING
> A couple of users complained that bug reports in RHBZ get ignored
> which
> discourages them to report problems.
We must close all GNOME packages to bug reports. GNOME problems just
have to be reported upstream. We can't handle the volume on Red Hat
Bugzilla, which half the relevant maintainers do not check.
We also need to do some major, major work on ABRT client-side, maybe
even rewrite the client side app from scratch.
Michael
_______________________________________________
desktop mailing list -- desktop(a)lists.fedoraproject.org
To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org