I've talked about this before, but maybe the F26 cycle is time to make
it happen. Right now, we have only one way of saying "this bug is
important to the project as a whole; could we please get resources
focused on it?" — and that way is to stop the whole vehicle until
someone does something about it. This has always been kind of
problematic, even though it has served well enough so far... but as we
move to more deliverables and add things with different lifecycles, I
think we need something else.
We have the Accepted Blockers
list. The process is nicely documented at
read that if you're not familiar.
I propose we create a parallel "Critical Issues" list, using basically
the same procedures. Issues eligible for this status would be those
which do not necessarily fail a release criterion but which have
critical impact on a Fedora Edition or on a council-approved Fedora
Since Fedora is a volunteer process, this can't be backed by a hard
mandate (like the "block the release!" emergency brake), but if we
agree together to take it seriously, I think it will still provide a
useful list. Anyone with a package or component involved in the issue
will be able to see the impact, and take that into account when
prioritizing. As FPL, it'd give me a nice overview of issues that might
need extra resources or coordination.
We could either implement this by extending the existing blocker bug
process — adding a new tracker bug, add a new category in the
blockerbug app, and review candidate issues at the normal blocker
review meetings. Or, it could be done in parallel, with a
separately-configured instance of the blockerbug app and with review
in a separate meeting called as needed (or maybe just FESCo?)
As with the existing Blocker or Freeze Exception levels, we could also
introduce a second tier "Important Issues", which could have a wider
net than the rules for "Critical Issues". I'm not sure about that.
In any case, what do you all think?
Fedora Project Leader
It seems to me that Fedora has three severe distribution wide issues
relating to security updates:
1. Updates, even critical security updates, are very slow. Getting an
update out involves creating a build and an update (which is
reasonably fast for most packages), pushing the update to
updates-testing, getting karma, and pushing to updates. The latter
three can happen in parallel in the best case. The big problem as I
see it is that pushing updates is painfully slow. For reasons that
I'm sure make a lot of internal sense, updates seem to get stuck
behind broken composes and such all the time. Can this be made
IMO it should be possible for a security update to be checked,
incrementally, for sanity with respect to the rest of the package
repository, and then pushed out, without needing to do whatever
expensive work a compose does. If some other update breaks the
compose, I don't think this should cause security updates to get
2. There doesn't appear to be a working process to get updates out
quickly. As a current and pressing example, there is no build for
3. AFAIK Fedora has no means by which it can participate in embargoed
updates. For this to work, I think there ought to be private git
branches, a way to get Koji to make a private build from a private git
branch, and a way to get private karma on a private update. Then,
when an embargo is lifted, the packager could merge the private branch
in, the various infrastructure bits could notice that the very same
git commit is now public and permit all of the private builds,
updates, and karma to become public and allow an immediate push to
Some of you may have seen me around before under my preferred nick of badone as
I've lurked in open source and software circles in general for countless eons.
I started doing software support and development during the late Permian period
working on a couple of DG systems and then HP 9000s. I started using Red Hat
Linux some time in the Triassic period and have been involved in some way or
another ever since. During the Jurassic period I was an IT journeyman working in
various places and picking up way too much information on way too many things
including hardware, cabling, telecommunications, radio, etc.
In the early Cretaceous I began working for Red Hat and currently work as a
Software Engineer in the Ceph project and contribute to it, and several other
projects, on github, etc. C++ is the weapon of choice when available. I have no
idea why it has taken many millennia to get around to becoming a packager, but
it has. I would like ultimately to become more involved in the ceph-related
packages and perhaps the CentOS storage SIG and the Fedora equivalent but I've
decided to get my feet wet with a nice vim personal wiki plugin I found.
Anyway, this is me, checkin' in.
My name is Mike Miller and I have been a software developer for almost ten
years. I am fairly new as a committer to the Open Source Community but I
have developed software using many different free and open source tools. I
frequently use Linux systems, mainly CentOS and am interested in working
with Fedora more closely. I am currently a committer on the Apache Accumulo
project. On a more personal level, I live on the East coast of the United
States and love watching sports and movies and playing video games with
friends. My GitHub username is milleruntime.
I am looking forward to being a part of the community!
Yep, it's Test Day time again - most likely the final Test Day of the
Fedora 25 cycle. This Thursday, 2016-11-03, will be [switchable
graphics Test Day]!
'Switchable graphics' refers to the fairly common current practice of
laptops having two graphics adapters, one low-power one for general
purpose use, one more powerful one for use with applications that
require more oomph (e.g. games or 3D rendering applications). NVIDIA
brands this as 'Optimus', and AMD just as 'Switchable Graphics' or
'Dynamic Switchable Graphics'.
There are some [enhancements] to Fedora's support for such systems
in Fedora 25, and part of the Test Day's purpose is to test those
enhancements. The other part of the Test Day's purpose is to ensure
that support for switchable graphics on Fedora 25 Workstation with
[Wayland by default] is as good as it can be, and that in some cases
where we know Wayland support is not sufficient, fallback to X.org
works as expected.
If you're not sure whether you have a system with switchable graphics,
you can run `xrandr --listproviders`. If the output from this command
lists more than one 'provider', you likely have switchable graphics. If
you do, please come along to the Test Day and help us test, if you can
spare the time. If you believe your system has switchable graphics, but
the command only lists one provider, please come join the Test Day chat
on the day - we may be able to investigate and figure out what's going
The [Test Day page] and the test cases are still being revised and
tweaked as I write this, but as the week goes along, all the
instructions you need to run the tests will be present there. As
always, the event will be in #fedora-test-day on Freenode IRC. If you
don’t know how to use IRC, you can read [these instructions], or
just use [WebIRC].
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
EPEL6 - MongoDB 2.4.x
EPEL7 - MongoDB 2.6.x
Upstream supports only upgrade to next major version. So from 2.4 it is
supported only to 2.6.
Therefore I kept MongoDB 2.6 in EPEL7 (even two next major versions are
But MongoDB 2.6 is going to EOL (probably this week), so MongoDB in
EPEL7 will be unsupported.
How to solve this - what EPEL/Fedora guidelines says about upgrades?
Upgrade EPEL6 to EPEL7? Or keep unsupported version in EPEL7?
What is the "Payload Hash" in koji?
It looks like an MD5, but of what? It's not the rpm... I've checked.
Should koji be providing verification hashes for manual downloads of built
RPMs? I think this would be useful for testing.
Missing expected images:
Cloud_base qcow2 x86_64
Server boot x86_64
Atomic qcow2 x86_64
Server dvd i386
Server dvd x86_64
Cloud_base raw-xz x86_64
Server boot i386
Atomic raw-xz x86_64
Failed openQA tests: 1/2 (arm)
Old failures (same test failed in 25-20161030.n.0):
ID: 45129 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload
Passed openQA tests: 22/22 (x86_64), 2/2 (i386)
New passes (same test did not pass in 25-20161030.n.0):
ID: 45117 Test: x86_64 KDE-live-iso desktop_update_graphical
Skipped openQA tests: 1 of 26
Mail generated by check-compose: