What are the possibilities for how a stream is maintained? The cases I can think of:
* Indefinite - rolling forward with upstream - "master" "stable" etc. * Tied to an upstream version and it's EOL - a "2.1" stream of django * [less common] tied to a particular version of Fedora - the "29" stream of flatpak-runtime How do your proposed mechanisms handle these cases? It seems like by trying to automatically determine an EOL, the intent of module maintainer might not be respected - e.g. you might include a package with a short EOL intending to rebase to newer versions as necessary. What if we just had a streams.yaml file checked into the master branch of git and gave the maintainer the flexibility to set an EOL (with defaults if no streams.yaml is present, perhaps.) We could still write tools to check the EOL against that of dependencies and components, but that would just be used to flag problems. Owen On Wed, Aug 22, 2018 at 6:39 AM, Adam Samalik <asama...@redhat.com> wrote: > 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 > [2] https://docs.fedoraproject.org/en-US/modularity/making-modules/ > adding-new-modules/#_repositories_and_stream_branches_existing_packages > > > -- > > Adam Šamalík > --------------------------- > Software Engineer > Red Hat > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists. > fedoraproject.org/message/K4FUOQHQSRAAI3PUUGXAC6CXEN27Y2JH/ > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/SEWRAWT3YHAD2H5PG7JS6CUZA7WQJR2H/
