After the release of Fedora Linux 35, I conducted a retrospective survey. I wanted to see how contributors felt about the release process and identify possible areas we can improve. There was no particular reason to start this with F35 except for that’s when I got around to doing it. So how did F35 go? Let’s look at the results from the 63 responses.
Although I intended the survey to be about the process of producing Fedora Linux 35, many of the open-ended answers were about the end result. The good news is that the comments were largely positive. But for the purposes of this post, we’ll focus just on the process-related responses.
I asked respondents to rate the stress of F35 compared to previous releases. 21 people (33%) said it was the same and 19 (30%) said it was less stressful. Only 9 people (14%) felt F35 was more stressful.
I wondered about how the stress varied by role, so I separated it by the role identified in one of the questions. The choices were package maintainer, QA tester, Beta user, and other. Respondents could select multiple roles.
|Package Maintainer||QA Tester||Beta User||Other|
QA testers were more likely to see F35 as being the same stress as previous releases. Overall, the percentage distribution held pretty close across the different roles.
Beta delay impact
The F35 Beta was delayed, which shortened the post-Beta “thaw” to one week. I was curious how that affected contributors. Overall, it mostly didn’t. The majority of respondents had a neutral opinion. The number of people who thought it make their work harder was roughly the same as the number of people who thought it made their work easier.
As you might expect, package maintainers were more likely to say it made their work harder. Beta testers favored the delay a bit, and QA testers were evenly split.
What could make it easier to contribute?
A few key themes popped up in the answer to this question. The first was having more time in the day or more free time. I’m sorry to say that there’s not much I can do for you there.
The second theme was better onboarding and communication. Some of that will be addressed as a result of the QA team’s retrospective. In particular, we’re developing training and documentation for Bugzilla usage. One of the other comments focused on making sure the release notes properly called out potentially breaking changes (for example, firewalld 1.0).
Improving the ease of contribution is important for attracting and retaining new contributors. If we end up setting a goal of doubling the number of active contributors, we must make improvements here.
What went well? How could we improve?
It’s important for retrospectives to include what went well, not just went poorly. I thought this comment was particularly apt: “No heroics.” In part due to our willingness to delay the release when blockers were still unfixed, people generally felt less of a need to work long nights. There was more time to get the tests done.
On the other hand, we weren’t entirely without rushes. WirePlumber had several late fixes that nearly caused it to be a last-minute drop from the final release. And some contributors feel that the QA team focuses on the x86_64 architecture too much, to the detriment of ARM testing. And one person commented “more QA testing” would help, which is always true.
One specific suggestion was to “leave old libs in -compat packages until 3rd party repositories such as Rpmfusion have had a chance to rebuild their packages.” This seems like a good policy.
11 people offered suggestions for the F36 retrospective survey. Most of them are either comments or out of scope. But I do plan to have some different questions next time. In particular, if events or policy changes that happen between now and April have an impact. With the stress question in particular, I’m less concerned about the specific values and more with the trends that develop over time.
If you’d like to poke at the data yourself results (with some fields excluded for privacy) are available on my Fedorapeople page.
If you left contact information for follow up, I’ll be starting those conversations this week.