Hi, folks! So I've (finally) got ready an initial round of draft
changes to various wiki pages for the purpose of implementing the 'No
More Alphas' Change. You can find all the drafts in the NoMoreAlphas
For each page I cloned the original text and saved it as the first
edit, so you can use the 'History' tab's diff feature to see the actual
changes to each page (just compare the current state to the first
To summarize the changes, at least as I remember them, and call out
some significant choices:
* Obviously, all Alpha-related points on the schedule template on the
Fedora Release Life Cycle page were removed. For schedule points that
were previously derived from Alpha points that got removed, I adjusted
them to derive from some other still-remaining point.
* My proposal for 'what do we do about release criteria / validation'
is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed
'Basic Release Criteria' (note: not versioned, I don't think it should
be), and we document that *all* composes - not just Beta and Final
candidate composes, but also Rawhide and Branched nightlies - will be
automatically tested for (and release of them gated on) compliance with
them. Which is more or less what's proposed in the Change. All external
references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is
what changed on the other criteria pages, and on the test matrix
template pages). Practically speaking, we currently have automated
testing for *most* of the existing Alpha criteria, but a few items
aren't covered. We can choose to move these to the Beta criteria, or
leave them on Basic and just accept that *actual* coverage doesn't
quite meet what we aspire to. I do *NOT* propose to have any kind of
blocker tracking bug for the Basic release criteria; it doesn't seem to
fit in the process, there is no Alpha release to block, and we can't
realistically block nightly composes on manual test results. So a
tracker bug wouldn't really have any reason to exist. In the case where
a violation of the Basic criteria makes it into composes despite the
automated testing, it should be marked as a Beta blocker.
* There is a problem with what to do about the Change schedule: our two
sources for it don't actually agree on what the schedule *is*. The
Changes Policy page - https://fedoraproject.org/wiki/Changes/Policy -
claims that the 'Completion deadline' "falls on the same day as the
Alpha milestone freeze", but the Fedora Release Life Cycle page -
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle - claims it
falls on the same day as the branch point, which is two weeks *before*
the Alpha freeze. Given this inconsistency I didn't really feel
confident proposing a draft for the Changes/Policy page yet; probably
it'd be good for FESCo(?) as owners of the Change process to decide
when they actually want the key dates of the Change process to be, In A
World Without Alphas. If FESCo wants to figure that out and let me
know, I can draft the changes.
Please do look these over and provide any kind of feedback! Thanks.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
I was playing around in the new Pagure https://src.fedoraproject.org/ and I
created a fork of a repo to test. However, I don't need or want this fork.
How do I delete it? There doesn't appear to be an option.
Greetings. Is https://github.com/fedora-selinux/selinux-policy-contrib
the right place to contribute to the Fedora SELinux policy?
I added a pull request for a small update needed for a new release of
cups-pdf, but I am not sure someone is monitoring that. There is another
one from rhatdan there so I presume is the right place.
Kernel 4.13 was released this past weekend. This kernel has been
built for rawhide and is building for F27 as well. We will be
following the same upgrade procedure as in the past. F25 and F26
will get rebased to 4.13 after a few stable releases, typically
4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.
I'm planning change the default value of httpd_graceful_shutdown boolean
in Fedora Rawhide because of improving SELinux configuration. Rawhide
builds with this change will be available in ~5 days.
Together with Dan Walsh, we agreed on that httpd_graceful_shutdown
boolean should be by default turned off. This boolean allows HTTPD to
connect to port 80 for graceful shutdown, but it's breaking the
functionality of another boolean called: httpd_can_network_connect. This
boolean allows HTTPD scripts and modules to connect to the network using
TCP and it's turned off by default.
Turning this boolean off can cause some troubles, on web-servers where
processes with httpd_t SELinux domain connecting to tcp ports: 80, 81,
443, 488, 8008, 8009, 8443, 9000
If you would like to turn in on again, use semanage command:
# semanage boolean -m --on httpd_graceful_shutdown
If you have any questions, feel free to contact me.
Software Engineer, Security Technologies
Red Hat, Inc.
Currently, AFAIK, the suggested method to upload new sources for a
package is using 'fedpkg new-sources' which uploads new sources from
your local system. I wonder if there is a method to upload new sources
from a URL rather than your local filesystem? It is specially useful for
According to the Change for F27 , all golang packages have been rebuilt
against golang 1.9beta2. In the meantime, go 1.9 stable has been released
upstream (Aug. 24, 2017) .
I suspect that some of the issues I am having with go / my golang packages
in fedora would be fixed by the update to the final release, since upstream
test suites targeting go 1.9 stable in travis aren't hitting any of those
What's the plan for rebasing golang to the stable release? The src.fd.org
repository of golang  hasn't been touched since the F27 Mass Rebuilds,
and the final update to 1.9 stable isn't mentioned in the Change page at
all ... additionally, the F27 release cycle is progressing more quickly
than I realized (and I suspect some people might not have realized yet