On Wed, Aug 22, 2018 at 5:48 PM Owen Taylor <otaylor@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 <asamalik@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



--

Adam Šamalík
---------------------------
Software Engineer
Red Hat

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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-leave@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