wanted to thank you all for supporting the FCOS Test Day which turned out
to be a very successful event! As we looked back, we thought there might be
room for more community participation in FCOS QA. On those lines, we were
wondering if there are good ways for other Fedora teams and for the
community in large to get a good picture of how quality validation and
decisions are done for the FCOS stable stream, and how people who are
interested can participate in this process.
In particular, I tried to find some documentation on:
* The pool of bugs which are currently reported against the testing and
* The subset of aforementioned bugs which were decided to be "blockers" and
must be fixed before the stream can be promoted to stable
* Where this blocker decision-making takes place and how people can get
* What are the procedures and rules for this blocker decision-making process
Unfortunately, I was not able to find any. I might be looking at a wrong
location. Can you please point me to the correct place, if such
Since FCOS might soon be an official Fedora edition, it would be great to
have insight into the FCOS community release process. But this is far from
just a QA team thing. This process transparency is important for recruiting
new passionate community members who can help you run and improve things.
Another use case might be a party affected by a bug who might feel
motivated to visit such a blocker discussion and argue their case about why
they think such a bug should not hit the stable stream.
We can put together all the relevant documents in one place that is
accessible to the public so that the community is aware of important
decisions made during the release process and feel included. I imagine that
there could be a "Participate!" section in the FCOS docs page  which
would point people to areas where they can help FCOS, and one of those
areas could be quality control. What do you think?
As an example, the current quality validation workflow in Fedora includes a
regular "blocker review" meeting in a dedicated IRC channel, where bugs
proposed as "blockers" get discussed . Anyone can propose a bug as a
blocker and we regularly receive bug nominations from the community. The
blocker review meeting is open to anybody and we try to base our votes on
"release criteria"  after assessing that particular case and its
circumstances. Release criteria help us bring a bit more consistency into
this blocker decision-making and it saves us some time from looking up
historical evidence ("how did we vote last time on a similar bug?"). All
currently proposed and accepted blockers are visible from our custom page
. This whole process is a collaborative effort between Release
Engineering, Quality Assurance, Development, and Project Management. Please
note that while I'm describing our current process as an example, I'm not
implying you need to do it in the same way. I'm just showing how we do it
in general. Also, our documentation is quite complex and lengthy, but
essentially it can be just a couple of paragraphs with links, to steer
people into the right direction.
Looking forward to hearing your thoughts. Thanks!
We would like to try to use next week's IRC meeting (wednesday 08/26 16:30
UTC #fedora-meeting-1) to experiment with a planning session. The goal
being to identify which issues or features are most important to the
community at this time. This should help to highlight what is important for
the community to tackle together in the future and is also a good place to
have a discussion about priorities of the different issues.
If you would like to add an issue to the meeting agenda please use the
following hackmd document https://hackmd.io/aVJiL9DUQpCDSafSBcs6ZQ
Hope to see you all during next week's meeting :-)
The team has created a new git repository for us all to use as a place to have high level
and well summarized design discussions for large changes to Fedora CoreOS (and RHEL CoreOS by
The goal of this repo is to be lower volume and also be a place for us to propose concrete changes
with well defined problem statements. Usually each proposal will be the result of some team members
getting together to brainstorm options to consider and perform brief investigations of possible solutions
beforehand so that each option can be weighed with sufficient information. This should help us keep
track of large changes.
The coreos/fedora-coreos-tracker repo is still the right place to report issues and make requests for
features, but if the fix or feature requires a significant change we may break out the design into a
coreos/enhancements PR for further discussion of the concrete proposed solution(s).