Postings by Matthew Miller

Fedora 31 is officially here!

Thank you to the entire community of Fedora contributors who
collaborated to create, once again, our best operating system
release yet.

Read the official announcement at:

* <a href="" title=""></a>

or just go ahead and grab it from:

* <a href="" title=""></a>

Fedora 30 officially released!

It's been six months, and like clockwork, we release Fedora 30 today!

Thank you to the thousands of people who worked to bring this release
together. Fedora doesn't happen by magic: it happens because of you!

Read the official announcement at:

* <a href="" title=""></a>

or just go ahead and grab it from:

* <a href="" title=""></a>

Fedora Lifecycles: imagine longer-term possibilities

Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk about how we might address
some of the users and use cases we're missing out on.

When I talk to people about this, I often get "hey, you should do LTS
or go to rolling releases.” As I've said before, on the surface that's
a weird thing to say, since the actual user impact of those two
different things is mostly _opposite_.

Red Hat bugzilla upgrade coming -- test now!

Red Hat is planning on upgrading Bugzilla to BZ5 in September. There's
a test instance running now at <a href="" title=""></a>

Since Fedora is a major user and stakeholder here, it'd be helpful if
we make sure everything works for us. If you find any bugs, report at
<a href=";version=5.0" title=";version=5.0">;version=5.0</a>

Fwd: [CentOS-devel] CFP for Dojo @ closes this weekend

Anyone interested in bringing Fedora topics that may be of interest to
the CentOS community to this conference?

----- Forwarded message from Rich Bowen < ... at redhat dot com> -----

Fwd: Welcome to Fedora CoreOS

In case you missed this on the annouce list. Or also, read at
<a href="" title=""></a> in glorious

----- Forwarded message from Matthew Miller < ... at fedoraproject dot org> -----

Fedora 28 is officially here!

It's almost Mother's Day, and that means it's time for Fedora 28,
which is officially released today.

Congratulations to everyone who contributed to this amazingly
smooth and polished release. You all are awesome.

Read the official announcement at:

* <a href="" title=""></a>

or just go ahead and grab it from:

* <a href="" title=""></a>

Should we have a release manager for each release? (or, "who owns rawhide"?)

As shown at <a href="" title=""></a>, we haven't
had a successful compose for almost two weeks. AIUI this is mostly
worked out now, but it raises the question: who should be keeping track
of this and coordinating fixes? For the releases, the blocker bug
process basically handles this, so functionally the ownership ends up
with QA (and the various heroes of QA who then track down all the
problems). For rawhide, we don't have any such thing. Is it rel-eng? Is
it FESCo? Is it the FPgM?

Fedora 27 is officially released!

Fedora 27 is here! Thanks and congratulations to all of the
people in the Fedora community who worked so hard to bring
this together.

Read the official announcement at:

* <a href="" title=""></a>

or just go ahead and grab it from:

* <a href="" title=""></a>

We're also releasing a beta of Fedora Modular Server, which
you can get from:

* <a href="" title=""></a>

Minor schedule procedure tweak (rain dates and such)

It turns out that the "Rain Date" concept is confusing to some people
(particularly where that idiom is not familiar). I propose that for F28
and onward, we keep the basic concept, but ditch that term. Instead, we

* Release Date Target 1
* Release Date Target 2 (a week later).

As now, these will exist for both Beta and Final, and final will only
be pushed back if Beta Target 2 is missed.

Then (and also new), if the Beta does slip past Target 2, we add a new
"Target 3". If Beta slips to Target 3, Final slips to Target 2 (and we
don't yet add a Target 3).

Fedora Modular Server: status and game plan?

From ... at lists dot

FWIW, AFAICT the current state of this is that we had some F27
modular composes that 'succeeded' (the last being 20170831.n.0), but
none of them contained any images at all. Since 20170831.n.0, the
compose has failed each day, apparently due to
<a href="" title=""></a> .

: Service levels and EOL expectations?

I'm looking at:

<a href="" title=""></a>

While not a part of the modulemd specification yet, modules will
eventually carry a Service Level (SL) value and an End of Life
(EOL) value.

The work in Changes/ArbitraryBranching will enable packagers to
select independent SLAs and EOLs for both their rpm branches as
well as their module branches.

Arbitrary Branching and solving the "Change Checkpoint? Better hit the gas!" problem

Our Change process has the basic assumption that if a Change isn't
working, we will be able to back out. But, in practice, when there are
problems, we often find it that it's easiest to shrug and go forward,
scrambling to fix problems in the change itself as well as any fallout.
I won't say this is a _failure_ exactly — with the Change process, at
least, we do have that checkpoint where we know the scramble is needed
rather than waiting until the very last minute.

Fedora, apps, and the Flatpak opportunity

Containers (and particularly, Docker-style containers with Kubernetes
orchestration) are rapidly taking over the server world. This is not
hyperbole, and while one might fairly throw "everything old is new
again", it's not a fad. This is a real generational shift.

We're at the forefront of this with Fedora Atomic Host (and OpenShift
Origin in Fedora as well). This is awesome.

I think these technologies are going to come to the desktop, too.

Fedora 26 is officially here!

Fedora 26 is here! Read the official announcement with
hyperlinks and fancy formatting and details and (especially)
thanks to the community at:

<a href="" title=""></a>

or just go ahead and grab it from

<a href="" title=""></a>

super-drafty F28 and F29 schedules

It's probably no surprise if you've ever heard me talk that I really
think hitting early May / late October is important for our release

A proposal for stream naming

Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.

An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26).

off-topic suggested reading: why containers really are revolutionary

I know that a lot of us in the Fedora world are from traditional IT

Please note that F26 schedule does not affect F27 change deadlines

I just wanted to call out in particular this bit from Jan's note:

This means that system-wide changes for Fedora 27 should be submitted
to FESCo *before* the Fedora 26 final release. Changes which require a
mass rebuild should be in _this_ month.

Updating the Fedora Project Mission statement — please read and join the discussion

I just posted in the council-discuss mailing list about the work we did
last month towards an updated Fedora Project mission statement. Please

<a href=" ... at lists dot" title=" ... at lists dot"> ... at lists dot fedo...</a>

and join the conversation there. Thank you!

Understanding the Fedora Modularity initiative (video + slides)

Hi everyone. The Fedora Council holds monthly video-based meetings
where we host a report from one of our various subprojects or official
objectives. This month, Langdon White presented on Modularity.

If you're a Fedora contributor busy in other areas and haven't paid
much attention, you might be wondering what Modularity is, exactly.
Modularity is an effort to address the "moves too fast!

CVE-2016-8655, systemd, and Fedora

In case you haven't seen: there was a recent kernel vulnerability in a
feature called "AF_PACKET". Most services don't need to use the raw
sockets this makes available, and on his blog*, Lennart Poettering notes
that systemd actually has a feature where services can whitelist or
blacklist address families, protecting them from not just this exploit
but similar classes.

The upcoming systemd v232 will include this by default for systemd's
own unit files. But, of course, that's a tiny subset of services in
Fedora. So....

Question 1: How can we take advantage of this feature in specific?

Two more concrete ideas for what a once-yearly+update schedule would look like

Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building

Option 1: Big batched update

1. Release F26 according to schedule
<a href="" title=""></a>

2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates


Some preliminary Fedora 25 stats — and future release scheduling

The stats I get are about a week behind, which means I now have
information about the first week of the Fedora 25 release. See the
graph here:

<a href="" title=""></a>

(and please note the caveats about what you're looking at — the numbers
on the left shouldn't be construed as "number of Fedora systems" or
anything like that).

I'd draw it in ASCII art, but the detail is hard to reproduce. :)

Anyway, there's great news: the F25 uptake is rapid.

Fedora 25 released!

Fedora 25 released!

The Fedora Project is pleased to announce the immediate availability of
Fedora 25, the next big step our journey into the containerized, modular

Fedora is a global community that works together to lead the advancement
of free and open source software.

today I learned: {{FedoraVersionNumber}} macro in wiki

Ooh! This is handy:

<a href="" title=""></a>

The current version of [[Fedora]] is

The next version of [[Fedora]] is '''{{FedoraVersionNumber|next}}'''.

where is /1 coming from?

Someone on Reddit noted that there's a zero-length file named `1` in /
on their F25 system. I just looked on mine, and I have one too. It's
not owned by any RPM. And I checked on an F24 box, and it's got that
too. Anyone know where this is coming from?

PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

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...

orphaning ec2-metadata, system-autodeath, s3cmd


Thanks everyone!

Fedora 24 is a wonderful release. Thanks to everyone for all of your
hard work!