On Wed, Aug 29, 2018 at 4:35 AM Adam Samalik <asamalik@xxxxxxxxxx> wrote: > On Tue, Aug 28, 2018 at 6:44 PM Paul Frields <stickster@xxxxxxxxx> wrote: >> >> 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. > > > 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@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
