7:06 a.m.
Hello folks,
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
next stream
* 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
involved
* 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
documentation exists?
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 [1] 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 [2][3]. 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" [4] 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
[5]. 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!
Kamil
Fedora QA
[1] https://docs.fedoraproject.org/en-US/fedora-coreos/
[2] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[3] https://fedoraproject.org/wiki/Blocker_Bug_FAQ
[4] https://fedoraproject.org/wiki/Fedora_Release_Criteria
[5] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist