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@xxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
