On Wed, Aug 22, 2018 at 5:48 PM Owen Taylor <otay...@redhat.com> wrote:
> 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? > The first proposal isn't really a proposal, it's basically the current state. As it is now, it would only handle a specific date. However, we could extend it with an "infinite" and "specific fedora release" options easily, I believe. The second one would work with all three cases with a little attention of the maintainer: * case 1, indefinite: The maintainer would keep it in rawhide and the package would continue rolling. * case 2, a specific date: The maintainer would keep it in rawhide until the EOL date approaches, after which they would just remove it from rawhide by setting its EOL to the latest release. * case 3, a specific release: The maintainer would set the EOL to be this specific release. > > 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. > Good point! > > 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. > Something like this was one of my initial thoughts as well, glad you brought it up. Having a "forced module EOL", maybe as an optional override could be a good idea. > > 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/ > -- 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
