Re: [modularity] Managing module lifecycles — let's talk!
On Fri, Aug 31, 2018 at 05:57:57PM +0200, Adam Samalik wrote: > > I don't think we should use "rawhide" to mean "rolling updates", because it > > also has the implication of "project devel stream". > Just to make sure we're on the same page: I was talking about specifying an > EOL field, not a stream name. Is that what you mean, too? Yeah. I don't think rawhide is a good EOL field. (It's actually _better_ as a stream name.) > > I know there was pushback against naming stream branches "stable", so is > > there a good _other_ way to offer this? If I name the stream branch "5" > > after the upstream major release, how do I get people in the first case > > seamlessly on to "6" when it comes out, whenever that is? > "latest" would be the best option here: > https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_module_stream_name So, I guess "latest" and "stable" are probably good standard choices. I kind of want "latest" and "slow". :) -- Matthew Miller Fedora Project Leader ___ 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
Re: [modularity] Managing module lifecycles — let's talk!
On Fri, Aug 31, 2018 at 5:01 PM Matthew Miller wrote: > On Wed, Aug 29, 2018 at 10:26:29AM +0200, Adam Samalik wrote: > > > Would it be necessary for us to pick one or the other here? IOW, > > > whether the maintainer picked a specific date or a release, the EOL > > > would resolve to a date. If they pick none, or explicitly choose > > > 'rawhide,' then the artifact is essentially on a rolling window. > > Yeah... that's a good point. Maybe having the ability to specify EOL as a > > specific Fedora release or a date could be a good way forward. I like > that. > > > I don't think we should use "rawhide" to mean "rolling updates", because it > also has the implication of "project devel stream". > Just to make sure we're on the same page: I was talking about specifying an EOL field, not a stream name. Is that what you mean, too? > > I know this was talked about a long time ago, but I'm not sure how it came > down in practice: what's the tooling and workflow for moving users to a new > stream when a stream reaches EOL? > > For example, Rawtherapee, which has a fairly traditional major/minor > versioning scheme. Upstream provides downloads for old versions, but > doesn't > really support them. And, explicitly they say everyone should be on the > latest stable release -- they didn't support a 4.x branch when 5.0 came > out. > > From a user point of view, the three streams I might > want to choose from are: > > * Rolling always latest > * Nightly dev builds! > * A conservative stream which updates annually (or less!), ideally with > backports for critical security bugs > Yes! Also, probably not in the Rawtherapee example, but a specific version stream is an option, too, like we have with nodejs. > > I know there was pushback against naming stream branches "stable", so is > there a good _other_ way to offer this? If I name the stream branch "5" > after the upstream major release, how do I get people in the first case > seamlessly on to "6" when it comes out, whenever that is? > "latest" would be the best option here: https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/#_module_stream_name > > > -- > Matthew Miller > > Fedora Project Leader > ___ > 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 > -- 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
Re: [modularity] Managing module lifecycles — let's talk!
On Wed, Aug 29, 2018 at 10:26:29AM +0200, Adam Samalik wrote: > > Would it be necessary for us to pick one or the other here? IOW, > > whether the maintainer picked a specific date or a release, the EOL > > would resolve to a date. If they pick none, or explicitly choose > > 'rawhide,' then the artifact is essentially on a rolling window. > Yeah... that's a good point. Maybe having the ability to specify EOL as a > specific Fedora release or a date could be a good way forward. I like that. I don't think we should use "rawhide" to mean "rolling updates", because it also has the implication of "project devel stream". I know this was talked about a long time ago, but I'm not sure how it came down in practice: what's the tooling and workflow for moving users to a new stream when a stream reaches EOL? For example, Rawtherapee, which has a fairly traditional major/minor versioning scheme. Upstream provides downloads for old versions, but doesn't really support them. And, explicitly they say everyone should be on the latest stable release -- they didn't support a 4.x branch when 5.0 came out. From a user point of view, the three streams I might want to choose from are: * Rolling always latest * Nightly dev builds! * A conservative stream which updates annually (or less!), ideally with backports for critical security bugs I know there was pushback against naming stream branches "stable", so is there a good _other_ way to offer this? If I name the stream branch "5" after the upstream major release, how do I get people in the first case seamlessly on to "6" when it comes out, whenever that is? -- Matthew Miller Fedora Project Leader ___ 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
Re: [modularity] Managing module lifecycles — let's talk!
On Wed, Aug 29, 2018 at 4:35 AM Adam Samalik wrote: > On Tue, Aug 28, 2018 at 6:44 PM Paul Frields wrote: >> >> On Wed, Aug 22, 2018 at 7:26 AM Adam Samalik wrote: >> > == 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. >> >> Would it be necessary for us to pick one or the other here? IOW, >> whether the maintainer picked a specific date or a release, the EOL >> would resolve to a date. If they pick none, or explicitly choose >> 'rawhide,' then the artifact is essentially on a rolling window. > > > Yeah... that's a good point. Maybe having the ability to specify EOL as a > specific Fedora release or a date could be a good way forward. I like that. > > But apart from the format, we also need to have a good way of managing > changes of it over time. > >> It seems to me this is also an opportunity, through automation, to >> converge some conventional package activities as well. So whether >> dealing with a module or a conventional package, we might have the >> opportunity to set a EOL date, a Fedora release, or nothing/rawhide. >> The work of retiring packages or modules could be automated based on >> specifying a date (with appropriate warnings to the maintainers and >> public). > > > Traditional release branches already have an EOL — the release itself, > encoded in the name of the branch. I think that an EOL of a specific stream > branch vs. retiring an entire package are two separate problems, although we > might have a mechanism of automatically retiring a package when all its > stream branches reach EOL. > > But how would that work for the traditionally-branched packages? It's like > coming up with an EOL of a specific version for stream branches vs. coming up > with en EOL of the whole package which means all it's potential versions, > possibly the whole upstream project, because in traditional branching, any > new release branch can potentially have a new version if either the old EOLs > or a new is stable enough. > > Anyway, I like the idea, and I think we could definitely make it work for > modules and packages in stream branches. I wonder if there are compelling reasons to simplify branch management in such a way it brings us closer to upstream and less bound to the traditional release concept -- i.e. should everything be managed with stream branches? -- Paul ___ 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
Re: [modularity] Managing module lifecycles — let's talk!
On Tue, Aug 28, 2018 at 6:44 PM Paul Frields wrote: > On Wed, Aug 22, 2018 at 7:26 AM Adam Samalik wrote: > > == 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. > > Would it be necessary for us to pick one or the other here? IOW, > whether the maintainer picked a specific date or a release, the EOL > would resolve to a date. If they pick none, or explicitly choose > 'rawhide,' then the artifact is essentially on a rolling window. > Yeah... that's a good point. Maybe having the ability to specify EOL as a specific Fedora release or a date could be a good way forward. I like that. But apart from the format, we also need to have a good way of managing changes of it over time. It seems to me this is also an opportunity, through automation, to > converge some conventional package activities as well. So whether > dealing with a module or a conventional package, we might have the > opportunity to set a EOL date, a Fedora release, or nothing/rawhide. > The work of retiring packages or modules could be automated based on > specifying a date (with appropriate warnings to the maintainers and > public). > Traditional release branches already have an EOL — the release itself, encoded in the name of the branch. I think that an EOL of a specific stream branch vs. retiring an entire package are two separate problems, although we might have a mechanism of automatically retiring a package when all its stream branches reach EOL. But how would that work for the traditionally-branched packages? It's like coming up with an EOL of a specific version for stream branches vs. coming up with en EOL of the whole package which means all it's potential versions, possibly the whole upstream project, because in traditional branching, any new release branch can potentially have a new version if either the old EOLs or a new is stable enough. Anyway, I like the idea, and I think we could definitely make it work for modules and packages in stream branches. > > -- > Paul > ___ > 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 > -- 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
Re: [modularity] Managing module lifecycles — let's talk!
On Wed, Aug 22, 2018 at 7:26 AM Adam Samalik wrote: > == 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. Would it be necessary for us to pick one or the other here? IOW, whether the maintainer picked a specific date or a release, the EOL would resolve to a date. If they pick none, or explicitly choose 'rawhide,' then the artifact is essentially on a rolling window. It seems to me this is also an opportunity, through automation, to converge some conventional package activities as well. So whether dealing with a module or a conventional package, we might have the opportunity to set a EOL date, a Fedora release, or nothing/rawhide. The work of retiring packages or modules could be automated based on specifying a date (with appropriate warnings to the maintainers and public). -- Paul ___ 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
Re: [modularity] Managing module lifecycles — let's talk!
On Wed, Aug 22, 2018 at 5:48 PM Owen Taylor 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 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 need
Re: [modularity] Managing module lifecycles — let's talk!
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 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-
[modularity] Managing module lifecycles — let's talk!
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/
