Hi Ben,
sorry for the late reply. First let me summarize what we are going to accomplish in the near future and then I will go into
details on each of your points.
We are aware that the release of Modularity in Fedora was rough and we are working to fix that. What we are trying to
do now is to use what we learned in Fedora and RHEL and make adjustments/features/fixes in the codebase so Modularity
would be more user friendly and simpler. It is a complex task which needs a lot of time and effort.
Now to address your points.
With regards to MBS, we are in touch with the EXD team which is supporting MBS in Red Hat. Currently Mike McLean
and Kevin Fenzi are working on the deployment in Fedora infra. EXD people will announce MBS support on Fedora
devel-list soon.
For Fedora 34, we have recently planned fixes which will help Fedora as well as RHEL. There is a critical issue with the
upgrade path of the modules. This concerns both Fedora and RHEL. The fix for this is the introduction of static contexts
and phasing out of modules stream expansion. As you said, we can only provide you rough estimates for Fedora 35. We
want to revisit the implementation of the default streams as this seems a feature created controversy inside the community.
We would like to make it more straightforward for the consumer and the packager.
With regards to the deeper architectural changes, we want to get to the drawing board with Modularity. We already started
with the upgrade path fix and continue with default streams with respect to feedback and experience.
In the long run, the success criteria would be that we phase out module stream expansion from Fedora 34 and revise default
module streams so we can use modular RPMs in non-modular repositories in Fedora 35.
We need more resources to work on long term tasks. Due to the COVID-19 situation, we do not know when we could extend
the Red Hat team assigned on the Modularity project. Anyway, if there are volunteers from the community who would like to
contribute, they will be welcome to join the project.
We would also like to improve the communication with the Fedora community. Any help and feedback from the community
is really appreciated.
Thanks for sharing this Martin. I have a few questions, comments, etc
below. I like the overall direction, so these should be read as
opportunities for improvement, not as criticism.
* When this was circulated on devel[1], some people raised concerns
that MBS isn't represented. Since that's going to be a key component
of this Objective's success, it would be good to have someone from
that team explicitly part of the Objective.
* Given that the F33 release is getting close, it's probably better to
focus on F34-35 (or 36 if you're looking at 18 months). Specifically,
it would be good to see at least some rough targets for the F35
release timeframe, with the understanding that a lot of the
research/planning work for that hasn't been done yet.
* For goal #4, do you have an idea of what the architectural changes
are or what you want to accomplish with them?
* Generally speaking, 12-18 months from now, how will we know if this
Objective has been successful? Number of modules available? Improved
maintainer sentiment? Improved user sentiment? Something else?
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RF4GUWFIDIASBDKS2RUVDHTSAWCMCWL4/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
council-discuss mailing list -- council-discuss@lists.fedoraproject.org
To unsubscribe send an email to council-discuss-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/council-discuss@lists.fedoraproject.org
--
No comments:
Post a Comment