6:10 p.m.
Hi,
We should all read today's featured Ars article:
http://arstechnica.com/information-technology/2016/08/fedora-24-review-th...
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
6:54 p.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:54 p.m.
On Tue, Aug 30, 2016 at 7:10 PM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
Hi,
We should all read today's featured Ars article:
http://arstechnica.com/information-technology/2016/08/fedora-24-review-th...
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
8:35 p.m.
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
12:37 a.m.
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.
12:52 a.m.
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!
2:06 a.m.
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(a)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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/desktop@lists.
fedoraproject.org
--
*Hugo*
12:36 a.m.
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.
1:43 a.m.
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
3:29 a.m.
On 31 August 2016 at 07:43, Tomas Popela <tpopela(a)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.
9:39 a.m.
Richard Hughes píše v St 31. 08. 2016 v 09:29 +0100:
On 31 August 2016 at 07:43, Tomas Popela <tpopela(a)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(a)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
2791
days inactive
2795
days old
desktop@lists.fedoraproject.org
10 comments
8 participants
participants (8)
-
Adam Williamson -
Hugo Alejandro -
Jiri Eischmann -
Josh Boyer -
Matthew Miller -
Michael Catanzaro -
Richard Hughes -
Tomas Popela