Update on Modular Obsoletes and EOL change

[Martin Curlej]

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/mod...


-- 

Martin Curlej

Software Engineer, Product Owner

Modularity

Red Hat

<https://www.redhat.com>

mcurlej(a)redhat.com
<https://red.ht/sig>

[Miro Hrončok]

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/[e-mail].o...

was that they will be stored in dist git and the module maintainers will be able 
to change them.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Matthew Miller]

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.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Petr Pisar]

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:
>  
>  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.
>   
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

[Miro Hrončok]

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:
> >
> > 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.
> >
>  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/[e-mail].o...



But since we have no modularity authority anymore in Fedora, there was no 
conclusion.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Matthew Miller]

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Dan Čermák]

Hi Martin,

Martin Curlej <mcurlej(a)redhat.com&gt; 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