On Wed, Aug 22, 2018 at 7:26 AM Adam Samalik <asamalik@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
