During the Modularity WG meeting yesterday [1], we've touched the topic of module lifecycles. Even though there are some ideas in the air as well as some code written, we haven't reached a state in which we would know how exactly to deal with it. So I'd like to discuss it here with a wider audience, and review it again in the next Modularity WG meeting.
== Introduction: (feel free to skip this if you know what I'm talking about)
In concept, modules live more or less independently from the Fedora release. So while traditional packages in Fedora are branched for each Fedora release (such as f27, f28, etc.), and each branch is maintained for the lifetime of its release (~13 months), modular packages and modules themselves are branched in any way it makes most sense for the software (mostly major version, such as nodejs 6, nodejs 8, nodejs 10, etc.) — we call these "stream branches" in dist-git and "streams" when we talk about modules. This has two implications, one of which is the topic of this email:
1) One module stream can be built and maintained for multiple Fedora releases — that means it's lifecycle can be longer than just a single Fedora release — and that's what this email is about
2) One Fedora release can have multiple streams of modules — also cool, but not discussed in this email
If you're a visual type, watch this short animation (38 seconds): https://www.youtube.com/watch?v=5VQljp1p_ok
== The problem + what we've decided already
Simply put, we need to have a way of indicating how long each module stream lives. This should be probably defined at the package level, because packages the actual software that is being maintained.
At Flock 2017 we've discussed this topic and reached a following decision: Module stream's lifecycles should be somehow aligned with Fedora releases — in particular, they should be retired only at the end of a release. That way we prevent a situation where different module streams could be retired at any point in time, which would be pretty messy. On the other hand, introducing new streams at any time should be possible, the same way as we add new packages today.
== Approaches
Option 1: The current, yet unfinished approach
We specify an EOL (end of life) date for each stream branch of individual packages. This is done when requesting a new stream branch for a package [2] by passing "--sl rawhide:2020-12-01" to fedpkg. This value is stored, but not yet consumed by anything.
The next step would be having the build system to be smart enough to:
1) Figure out the module's EOL based on its packages' EOLs.
2) Only build the module for the Fedora releases that have their EOL before the module stream's EOL.
There is a caveat, however: Giving dates like this might be hard for the maintainer. The upstream project might not have one, etc. In that case the maintainer needs to come up with a date — even one closer in the future, and increase it gradually (and think about it, and do it for all the packages), or one much further in the future which could imply promises the maintainer had no intention to make.
Option 2: More dynamic, based on rawhide
Simply put, we wouldn't specify an EOL as a date, but as a Fedora release. And if a maintainer indicates that a certain stream branch of a package is maintained in rawhide, it would mean it's maintained for all active Fedora releases + the next one + potentially forever or until it's retired in rawhide.
The build system would then do the same thing as above:
1) Figure out the module's EOL based on its packages' EOLs.
2) Only build the module for the Fedora releases that have their EOL before the module stream's EOL.
Let's discuss the overall concept, the two approaches above or propose your own, or anything else that you think is relevant.
Cheers!
Adam
[1] https://meetbot.fedoraproject.org/fedora-meeting-3/2018-08-21/modularity_wg.2018-08-21-14.01.html
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/K4FUOQHQSRAAI3PUUGXAC6CXEN27Y2JH/
