Hello All,
This is an update about the Module obsoletes and EOL [1] change which we proposed for F34. We have a little bit of a good news/bad news situation here.
The good news is that the groundwork for the Obsoletes and EOL has been done. DNF, libmodulemd and createrepo_c accept the format and know how to work with it. All the technical changes are submitted (we are working on documentation right now [2]), merged and can be tried out in rawhide. The format definition for the obsoletes can be found here [3].
The bad news is that we are not able to add the support of the obsolete format to the Fedora pipeline for F34. So we are postponing it to F35 for now.
The one thing that we need to discuss, before making changes to the Fedora pipeline, is how the obsoletes will be used in Fedora. As the obsoletes/lifecycles enable you to set lifecycles which are not bound to the release cycle of a Fedora release. The Modularity team mostly cares about the standards of the technology (i. e. what are the file formats, how modules are built etc.) were not here to set/mandate the policies of metadata distribution in a release pipeline.
It would be great if we could start a discussion about how modular obsoletes will be used in Fedora? Where will be they stored? Who will be able to change them? Just a couple of questions to get the discussion started. Any involvement of the Fedora community is highly appreciated.
[1] https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL [2] https://github.com/rpm-software-management/dnf/pull/1717 [3] https://github.com/fedora-modularity/libmodulemd/blob/main/yaml_specs/module...
On 08. 02. 21 16:09, Martin Curlej wrote:
It would be great if we could start a discussion about how modular obsoletes will be used in Fedora? Where will be they stored? Who will be able to change them? Just a couple of questions to get the discussion started. Any involvement of the Fedora community is highly appreciated.
IIRC the consensus in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... was that they will be stored in dist git and the module maintainers will be able to change them.
On Mon, Feb 08, 2021 at 04:09:19PM +0100, Martin Curlej wrote:
It would be great if we could start a discussion about how modular obsoletes will be used in Fedora? Where will be they stored? Who will be able to change them? Just a couple of questions to get the discussion started. Any involvement of the Fedora community is highly appreciated.
On EOL, not specifically Obsoletes, but since they're deeply related:
In general, the idea is that in Fedora context, modules are most useful when they're longer-lived than the normal 13-month release cycle (rather than the RHEL case of being shorter than 10 years). I suggest therefore:
1. Module EOL should always align with a Fedora Linux release EOL (i.e. May/November every year). That way, people aren't ending up with modules randomly ending at unpredictable times.
2. If an upstream is ending at an unaligned time, Module owners should plan to separately deal with any critical security issues for another couple of months, or EOL the module at the _sooner_ date.
3. If an upstream is something that changes faster than the Fedora Linux release cycle (shorter than 13 months), the module stream should be rolling rather than pinned to those short-lived versions.
V Mon, Feb 08, 2021 at 10:23:17AM -0500, Matthew Miller napsal(a):
On Mon, Feb 08, 2021 at 04:09:19PM +0100, Martin Curlej wrote:
It would be great if we could start a discussion about how modular obsoletes will be used in Fedora? Where will be they stored? Who will be able to change them? Just a couple of questions to get the discussion started. Any involvement of the Fedora community is highly appreciated.
On EOL, not specifically Obsoletes, but since they're deeply related:
In general, the idea is that in Fedora context, modules are most useful when they're longer-lived than the normal 13-month release cycle (rather than the RHEL case of being shorter than 10 years). I suggest therefore:
Module EOL should always align with a Fedora Linux release EOL (i.e. May/November every year). That way, people aren't ending up with modules randomly ending at unpredictable times.
If an upstream is ending at an unaligned time, Module owners should plan to separately deal with any critical security issues for another couple of months, or EOL the module at the _sooner_ date.
If an upstream is something that changes faster than the Fedora Linux release cycle (shorter than 13 months), the module stream should be rolling rather than pinned to those short-lived versions.
I don't agree. Aligning EOLs to Fedora release proofed not working for me:
When creating a stream, you are not allowed to select May/Novemeber. You can only select June/December.
Fedora releases do not align to May/November. E.g. F33 G.A. was 2020-10-20, F31 EOL was 2020-11-24. What does November mean? 2020-11-01? 2020-11-30?
How do you want to prepare a new Fedora release with respect to the streams EOLing with that Fedora release? Do you want to keep the to-be-EOLed streams in the compose of Beta? G.A.? See what happend with perl:5.28 in F33 https://pagure.io/releng/issue/9736 -- relengs EOLed it before Beta in September.
In my opinion binding module EOLs to Fedora EOLs is not doable and they should be kept free.
If you wanted to implememt the aligned EOL, you would have to wait on a new Fedora release (because the exact day of EOL is not knows until a release is made), include the to-be-EOLed streams in the new release, then set the EOL, and publish it through updates. A user experience would be: At G.A. -- I have a new F33 with perl:5.28. A week after -- perl:5.28 EOLs in 4 weeks. If you wanted to prevent from this experience, relengs would have to clean up Beta and G.A. composes from the to-be-EOLed streams.
-- Petr
On 09. 02. 21 9:48, Petr Pisar wrote:
V Mon, Feb 08, 2021 at 10:23:17AM -0500, Matthew Miller napsal(a):
On Mon, Feb 08, 2021 at 04:09:19PM +0100, Martin Curlej wrote:
It would be great if we could start a discussion about how modular obsoletes will be used in Fedora? Where will be they stored? Who will be able to change them? Just a couple of questions to get the discussion started. Any involvement of the Fedora community is highly appreciated.
On EOL, not specifically Obsoletes, but since they're deeply related:
In general, the idea is that in Fedora context, modules are most useful when they're longer-lived than the normal 13-month release cycle (rather than the RHEL case of being shorter than 10 years). I suggest therefore:
Module EOL should always align with a Fedora Linux release EOL (i.e. May/November every year). That way, people aren't ending up with modules randomly ending at unpredictable times.
If an upstream is ending at an unaligned time, Module owners should plan to separately deal with any critical security issues for another couple of months, or EOL the module at the _sooner_ date.
If an upstream is something that changes faster than the Fedora Linux release cycle (shorter than 13 months), the module stream should be rolling rather than pinned to those short-lived versions.
I don't agree. Aligning EOLs to Fedora release proofed not working for me:
When creating a stream, you are not allowed to select May/Novemeber. You can only select June/December.
Fedora releases do not align to May/November. E.g. F33 G.A. was 2020-10-20, F31 EOL was 2020-11-24. What does November mean? 2020-11-01? 2020-11-30?
How do you want to prepare a new Fedora release with respect to the streams EOLing with that Fedora release? Do you want to keep the to-be-EOLed streams in the compose of Beta? G.A.? See what happend with perl:5.28 in F33 https://pagure.io/releng/issue/9736 -- relengs EOLed it before Beta in September.
In my opinion binding module EOLs to Fedora EOLs is not doable and they should be kept free.
If you wanted to implememt the aligned EOL, you would have to wait on a new Fedora release (because the exact day of EOL is not knows until a release is made), include the to-be-EOLed streams in the new release, then set the EOL, and publish it through updates. A user experience would be: At G.A. -- I have a new F33 with perl:5.28. A week after -- perl:5.28 EOLs in 4 weeks. If you wanted to prevent from this experience, relengs would have to clean up Beta and G.A. composes from the to-be-EOLed streams.
I believe this discussion has alredy happened.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
But since we have no modularity authority anymore in Fedora, there was no conclusion.
On Tue, Feb 09, 2021 at 09:48:28AM +0100, Petr Pisar wrote:
If you wanted to implememt the aligned EOL, you would have to wait on a new Fedora release (because the exact day of EOL is not knows until a release is made), include the to-be-EOLed streams in the new release, then set the EOL, and publish it through updates. A user experience would be: At G.A. -- I have a new F33 with perl:5.28. A week after -- perl:5.28 EOLs in 4 weeks. If you wanted to prevent from this experience, relengs would have to clean up Beta and G.A. composes from the to-be-EOLed streams.
I'd rather fix this by pinning the EOL dates in advance. That's better for people's planning anyway. We've hit our release targets enough times in a row that I think we can be confident in doing this. If the release happens to slip, we can extend the EOL in practice to match to give the needed extra time.
Hi Martin,
Martin Curlej mcurlej@redhat.com writes:
[snip]
It would be great if we could start a discussion about how modular obsoletes will be used in Fedora? Where will be they stored? Who will be able to change them? Just a couple of questions to get the discussion started. Any involvement of the Fedora community is highly appreciated.
I think for modules to be most useful, these metadata should be set by the packager/maintainer of said module in git directly (and should preferably not be changed after creation). I'd be also in favor of not tying the EOL date to Fedora EOLs, as that limits the potential benefits of modules in Fedora a lot.
Cheers,
Dan