Hi,
We should all read today's featured Ars article:
http://arstechnica.com/information-technology/2016/08/fedora-24-review-the-y...
There's a few inaccuracies, but no more than normal for distro reviews. It's good feedback at any rate.
Highlights:
* Author plainly states that he thinks Fedora is better than Ubuntu and Mint * Author thinks we released too soon, should have waited for a kernel upgrade. (I don't think it makes sense to consider the kernel in the schedule....) * Author mentions the Skylake fiasco in recommending that users wait a couple months before updating to the new release; familiar suggestions that our distro is unstable. In a sense it's Intel's fault for the bad update, but other distros did not ship this broken update. This could probably have been avoided if our update system was more conservative. It's nuts that we have important packages going from testing to stable in less than a day and we should fix this. * Author praised GNOME Photos and GNOME Calendar... even though they're not installed by default. (Let's change that!) He also praised Maps. * Author says Flatpak support in Software is still unstable. That's being worked on. * Author is disappointed that Flatpaks don't use the system fontconfig settings, says it makes Flatpak apps look inconsistent. * Author heaped praise on the new font settings. He didn't notice the changes that went into Freetype, though, so GNOME got perhaps more praise than deserved, but I can live with that. ;) * Author is also pleased with QGnomePlatform
Some inaccuracies I found:
* Author dinged us for not having Chromium, but we do have Chromium in our repos. It's because it (presumably) has no appdata file, so it doesn't appear in Software. Who wants to fix it? * Author dinged us for not having VLC, but this is really unfair; he's probably not aware of the legal issues. * Author doesn't realize that our graphical upgrades are already working for F23 -> F24, suggests users must wait until F25 to see how well the upgrade works. * Author thinks the PackageKit command-not-found helper we've had for years is new and related to dnf. * Author thinks spins are variants of WorkStation... and somehow decided to camel-case our name * Author thinks we're on an eight-month release cycle (sad!)
Michael
On Tue, Aug 30, 2016 at 06:10:37PM -0500, Michael Catanzaro wrote:
There's a few inaccuracies, but no more than normal for distro reviews. It's good feedback at any rate.
Thanks Michael -- I agree, and appreciate the nice summary.
On Tue, Aug 30, 2016 at 7:10 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
Hi,
We should all read today's featured Ars article:
http://arstechnica.com/information-technology/2016/08/fedora-24-review-the-y...
There's a few inaccuracies, but no more than normal for distro reviews. It's good feedback at any rate.
Highlights:
- Author plainly states that he thinks Fedora is better than Ubuntu
and Mint
- Author thinks we released too soon, should have waited for a kernel
upgrade. (I don't think it makes sense to consider the kernel in the schedule....)
I'm not quite sure what you mean. We consider the kernel for every schedule. What we haven't done yet is hold up the release for a particular kernel. There's nothing to say that we wouldn't do that if it made really good sense to do so. Just like GCC or Gnome or any other major package. One could argue Skylake support might have been one of those reasons, particularly since we don't respin install media.
- Author mentions the Skylake fiasco in recommending that users wait a
couple months before updating to the new release; familiar suggestions that our distro is unstable. In a sense it's Intel's fault for the bad update, but other distros did not ship this broken update. This could probably have been avoided if our update system was more conservative. It's nuts that we have important packages going from testing to stable in less than a day and we should fix this.
We often joke, but part of the burden of attempting to be first means we're the first to hit issues before other distros do (first to fail). I agree microcode_ctl should have been in testing longer than a day. Adding it to critpath would enforce that. I think it's somewhat folly to assume that any reasonable amount of time in testing is going to catch every issue like this.
Some inaccuracies I found:
- Author dinged us for not having VLC, but this is really unfair; he's
probably not aware of the legal issues.
He most likely is, given the suggestion of waiting a few months and then having rpmfusion sorted out.
- Author thinks we're on an eight-month release cycle (sad!)
And that it's still too short. Neither one of those things is really sad.
josh
On Tue, 2016-08-30 at 20:54 -0400, Josh Boyer wrote:
I'm not quite sure what you mean. We consider the kernel for every schedule. What we haven't done yet is hold up the release for a particular kernel.
^ That's what I mean. The kernel is pretty solid and you kernel folks take care of it for us, so us desktop developers don't need to worry about it or schedule around it (except in extraordinary circumstances... Skylake support you say?).
We often joke, but part of the burden of attempting to be first means we're the first to hit issues before other distros do (first to fail). I agree microcode_ctl should have been in testing longer than a day. Adding it to critpath would enforce that. I think it's somewhat folly to assume that any reasonable amount of time in testing is going to catch every issue like this.
When I mentioned updates spending less than a day in testing, I meant that in the general case; sorry it sounded like I implied that happened to this particular update. In fact it looks like it spent two days in testing. Still, I think it's reasonable that everything should spend at least a week in testing.
Of course it won't catch every issue, but it would help.... (And it probably would not have caught this one: it was hardware-specific, and not triggered until the next kernel upgrade, and so it took over a week for the first bug report to appear.)
Michael
On Tue, 2016-08-30 at 20:35 -0500, Michael Catanzaro wrote:
Of course it won't catch every issue, but it would help.... (And it probably would not have caught this one: it was hardware-specific, and not triggered until the next kernel upgrade, and so it took over a week for the first bug report to appear.)
We could probably improve this case quite easily with a package test case. I'll write one.
On Fri, 2016-09-02 at 22:37 -0700, Adam Williamson wrote:
On Tue, 2016-08-30 at 20:35 -0500, Michael Catanzaro wrote:
Of course it won't catch every issue, but it would help.... (And it probably would not have caught this one: it was hardware-specific, and not triggered until the next kernel upgrade, and so it took over a week for the first bug report to appear.)
We could probably improve this case quite easily with a package test case. I'll write one.
https://fedoraproject.org/wiki/QA:Testcase_microcode_update should show up for future microcode_ctl updates. In fact this should be an interesting test of how Bodhi parses the test case page names, since I think this is the first time we've done a package-specific test case for a package with an underscore in its name. Let's see!
By the statements of this article, I have decided to install Chromium from fedora repositories. However, I have not had a good experience because there is no way and documentation about the (hated) proprietary multimedia codecs needed to have a good web experience.
Will they be added at an extra repository as RPM Fusion?. I have also seen with good eyes this project: https://github.com/Samsung/ChromiumGStreamerBackend
For now I'll stick with that offered by RussianFedoraRepo version.
2016-09-03 2:52 GMT-03:00 Adam Williamson adamwill@fedoraproject.org:
On Fri, 2016-09-02 at 22:37 -0700, Adam Williamson wrote:
On Tue, 2016-08-30 at 20:35 -0500, Michael Catanzaro wrote:
Of course it won't catch every issue, but it would help.... (And it probably would not have caught this one: it was hardware-specific, and not triggered until the next kernel upgrade, and so it took over a week for the first bug report to appear.)
We could probably improve this case quite easily with a package test case. I'll write one.
https://fedoraproject.org/wiki/QA:Testcase_microcode_update should show up for future microcode_ctl updates. In fact this should be an interesting test of how Bodhi parses the test case page names, since I think this is the first time we've done a package-specific test case for a package with an underscore in its name. Let's see! -- desktop mailing list desktop@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/desktop@lists. fedoraproject.org
On Tue, 2016-08-30 at 20:54 -0400, Josh Boyer wrote:
- Author mentions the Skylake fiasco in recommending that users wait a
couple months before updating to the new release; familiar suggestions that our distro is unstable. In a sense it's Intel's fault for the bad update, but other distros did not ship this broken update. This could probably have been avoided if our update system was more conservative. It's nuts that we have important packages going from testing to stable in less than a day and we should fix this.
We often joke, but part of the burden of attempting to be first means we're the first to hit issues before other distros do (first to fail). I agree microcode_ctl should have been in testing longer than a day. Adding it to critpath would enforce that. I think it's somewhat folly to assume that any reasonable amount of time in testing is going to catch every issue like this.
If it's not in the critpath list it should be, because it's *clearly* part of the critical path per that definition:
"Packages within the critical path are required to perform the most fundamental actions on a system. Those actions include: ... post- install booting"
In case anyone hadn't noticed, comps now works on a pull request basis, through pagure, so anyone can submit a PR to fix this:
https://pagure.io/fedora-comps
fork and submit a PR from your fork, github-style.
Hi,
On Tue, 2016-08-30 at 18:10 -0500, Michael Catanzaro wrote:
- Author dinged us for not having Chromium, but we do have Chromium
in our repos. It's because it (presumably) has no appdata file, so it doesn't appear in Software. Who wants to fix it?
That's strange as the appdata file is included in the Chromium package and installed as /usr/share/appdata/chromium-browser.appdata.xml
0 $ rpm -qf /usr/share/appdata/chromium-browser.appdata.xml chromium-52.0.2743.116-10.fc24.x86_64
Also I will work with Richard on having that file in the official Chromium tarballs.
Tom
On 31 August 2016 at 07:43, Tomas Popela tpopela@redhat.com wrote:
That's strange as the appdata file is included in the Chromium package and installed as /usr/share/appdata/chromium-browser.appdata.xml
I guess the reviewer needs to update the appstream-data file before it's going to be visible.
Richard.
Richard Hughes píše v St 31. 08. 2016 v 09:29 +0100:
On 31 August 2016 at 07:43, Tomas Popela tpopela@redhat.com wrote:
That's strange as the appdata file is included in the Chromium package and installed as /usr/share/appdata/chromium-browser.appdata.xml
I guess the reviewer needs to update the appstream-data file before it's going to be visible.
Richard.
desktop mailing list desktop@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproje ct.org
Chromium made it to Fedora proper just recently. The author said he'd been using Fedora for months, so maybe he just made the assertion earlier and then didn't notice Chromium was already available.
Jiri
desktop@lists.fedoraproject.org
-
Adam Williamson -
Hugo Alejandro -
Jiri Eischmann -
Josh Boyer -
Matthew Miller -
Michael Catanzaro -
Richard Hughes -
Tomas Popela