On Wed, Aug 22, 2018 at 7:26 AM Adam Samalik <asama...@redhat.com> 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
