The purpose of this survey was to get feedback on Modularity. The survey was published on public Fedora devel and an internal Red Hat mailing lists in April 3, 2020, and also shared on Fedora’s devel-announce and epel-devel mailing lists. We received 193 responses in 3 weeks. Read more below or download the PDF of the results.
The survey consisted of four sections:
- Information about the respondent (optional)
- Modularity & the respondent
- Problems with Modularity that the respondent may have experienced
- Glossary review – what does the respondent think the terms mean
The survey followed privacy / GDPR rules:
- The raw data including any personal information provided, were shared only with Red Hat’s Modularity team (approximately 10 people) to evaluate the survey
- The raw data are not to be provided to anyone else at Red Hat or any 3rd parties
- Only aggregated (anonymous) results of the survey are published
Structure of respondents
21.9% respondents shared their email address from redhat.com domain, 22.9% from other domains and 55.2% were anonymous.
Contribution to projects
Roles of respondents
33.5% of respondents answered that their primary role is developer, 32.5% packager, 11.5% system administrator and 7.9% power user (can use shell, has some admin skills). The remaining part was fragmented in other various roles. Because the survey was published on devel and rhel-devel mailing lists, the developers are mostly system components developers. Many of developers/packagers cover a packager/developer role as the secondary one. It means that the survey did not cover developers of end user applications.
Satisfaction of respondents with Modularity
12.4% of respondents answered “I like it”, 38.9% “Neutral” and 48.7% “I dislike it”.
15.1% of respondents confirmed that Modularity solves problems for them, 70.3% answered negatively and 14.6% “I do not know”.
Highlighted benefits in the survey:
- Parallel availability (7 respondents)
- Life cycle (4 respondents)
Conclusions and plans
We were very pleased with the large quantity of participants who took the time to complete this survey. This excellent feedback is helping us to focus on multiple problems and solutions to help improve the Modularity experience for both end users and developers. Below is a summary of problems interpreted from the survey results and plans to resolve them.
The description of Modularity and the terms used causes confusion to many users and negatively impacts the user experience.
Plan: Fix Modularity documentation, improve clarity by creating a glossary. We are going to use the survey feedback as an input.
Problems with system upgrade
Plan: System upgrade improvement is scheduled in Fedora 33 [Module Obsoletes and EOL].
Problems finding modular or non-modular RPMs hidden by an active module Stream
Solution: The problem is fixed in Fedora 32 already by the patch.
Problems with modular RPMs overriding non-modular RPMs
It works per design. Any change proposals should be discussed first.
Problems with querying modular RPMs (most likely repoquery)
Plan: Lower priority, stretch goal in Fedora 34.
Problems with building, managing and distributing modules
There are currently missing end-user tools that can manage modules. New tools need to be developed to cover:
- build modules locally
- manage (edit, create) modulemd data locally
- download individual modules from remote repositories
- manage custom repositories with cherry-picked modules
Problems with switching module Streams
Plan: The problem is considered to be fixed in Fedora 33 or 34.
Problems with source control management (most likely dist-git)
Plan: Branching policy needs to be reviewed.