On Mon, Apr 06, 2020 at 12:28:15PM -0400, James Cassell wrote: > On Mon, Apr 6, 2020, at 12:05 PM, Petr Pisar wrote: > > On Mon, Apr 06, 2020 at 03:02:02PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Mar 31, 2020 at 12:13:16PM +0200, Daniel Mach wrote: > [snip] > > > > Setting eol_date to the future allows informing a user about > > > > upcoming obsoleting event so they can eventually migrate manually. > > > > > > For some context (RHEL...) time-based obsoletes make plenty of sense. > > > But in Fedora we established a policy that obsoletion and other > > > significant stream changes happen at "release boundary", which for > > > each user is whenever they choose to upgrade, so not time-based. > > > > > That's a great motivation, but this is not how it works in the real world. > > > > A packager asks for a branch and sets an end-of-life date. The date is > > enforced to align with a Fedora cadence. I.e. 4th and 10th month of a year. The > > packager builds a module from that branch for _all_ Fedoras and pushes the > > builds to the stable repositories. Once the end-of-life day comes, the > > packager stops maintaining the stream. That day there is exactly one Fedora > > release that also reached the end of life. But all the newer Fedora releases > > are still supported, but the stream there is not. You have an unsupported > > stream in a supported Fedora release. There's two "layers" here: the higher layer is whether the maintainer is actually maintaining the packages. Obviously, maintainers occasionally stop maintaining packages at random points in time, and no amount of formal EOL dates and rules will change that. Hopefully, other maintainers will step in. A second lower layer is how we inform users about the package status (obsoletion, retirement, ...). We need to make sure that the mechanisms we introduce in this lower layer do not make it impossible to follow our packaging guidelines even before we get to the soft upper layer. I think we should (do?) handle it in the following way: if the module EOL is before a given Fedora version goes EOL, it should never be proposed for installation in that Fedora version. In other words, if foo:3.15 stream has EOL of 1/4/2020, it should be shown in 'dnf module list' in F<=31, but not F>=32. > > That's the outcome of decoupling a stream life cycle from a Fedora life cycle. Yeah, retrofitting fixed EOL dates onto Fedora is a form of self-flagellation. > My understanding of current policy is that it would not be permitted > to have such a module in current fedora. It could only be included > in a version of fedora where it will receive updates for the entire > life cycle of that Fedora version. Exactly. The question is whether this happens like this, or not. I scanned https://docs.fedoraproject.org/en-US/modularity, but I don't see any mention of that. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
