On Tue, Oct 27, 2020 at 01:52:00PM +0100, Martin Curlej wrote:
> From my point of view right now it seems that this information should not
> be a part of the module (disgit, repository metadata). It is prone to human
> error when we leave this in the hands of a packager. So this would need a
> review of Engineering to be reliable.
>
Did you mean a Release Engineering, or a general engineering like FESCo?
Why module obsoletes are dangerous for mere packagers, while package obsoletes
are safe? Can you elaborate?
> Next is that a lot of 3rd parties like to handle the EOL and Obsoletes of
> packages/modules by other means, which makes this redundant.
What are the other means which the 3rd parties use?
> Also, as the release cycle of Fedora is so fast, I am not sure this is
> a necessary feature at all
>
Obsoletes are necessary. People always remember the failed semiannual
distribution upgrade.
But people forget that a Fedora release is supported for 18 months. That's
a longer period than some upstreams support. But even longer lasting upstream
is a problem. (See bellow why.) In other words I believe it's necessary to
support an EOL in the middle of a Fedora release. Not only at the the release
EOL.
Also don't forget about EPEL. 10 years is a long time.
-- Petr
Here is the bellow
Let's look at an example when an upstream supports a version for two years with
a year overlap:
1 2 3 4 5 6 7 8 ← Fedora releases
A A A A ← Upstream supports version A
B B B B
C C C C
If Fedora enforced module EOL at Fedora EOL, versions would be added into
Fedora like this:
1 2 3 4 5 6 7 8
A A A A
a . . . ← Fedora adds A into 1 and supports it up to EOL of 1
B B B B
b b b . . .
C C C C
c c c . . .
This reads: When the upstream released B, the packager would add it into all
supported Fedoras 1 and 2, brached Fedora 3, but never to Rawhide 4. That
means it would be missing from Fedora 4 because Fedora 4 would last longer
than the upstream. In other words, Fedora would stop supporting software
soonner than the upstream.
That's pretty awkard.
Now look at the case when Fedora can EOL a module at na arbitrary date:
1 2 3 4 5 6 7 8
A A A A
a a a .
B B B B
b b b b b .
C C C C
c c c c c .
When upstream releases B, the packager adds it into Fedoras 1, 2, and 3 as we
have seen. In addition he adds it into 4 and when Fedora 5 and 6 become
available it can also host the version B because it's supported by the
upstream and because Fedora states that B will be supported in Fedora 3 for
the whole 18 months, in Fedora 4 for only 12 months and in Fedora 5 for only
6 months. The version B will be removed from Fedora 6 still when it is
Rawhide.
This is how an alignment of Fedora modules to upstream versions looks like.
Thus I conclude that Fedora should support module EOLs at an arbitrary date if
it ever wants to offer an independed life cycle for modules.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
