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