On Wed, Aug 29, 2018 at 4:35 AM Adam Samalik <asama...@redhat.com> wrote: > On Tue, Aug 28, 2018 at 6:44 PM Paul Frields <sticks...@gmail.com> wrote: >> >> 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. > > > 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
