On Sun, Oct 20, 2019 at 11:35:37AM +0200, Fabio Valentini wrote:
On Sun, Oct 20, 2019 at 11:09 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>
> On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote:
> > On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote:
> > > This is not true. It should be *possible* to have a fully modularized
> > > distribution, but that isn't a specific goal for Fedora or RHEL.
> >
> > Because this keeps coming up, we talked about this at the Fedora Council
> > meeting today. Our goals for modularity are:
> > 2. Those alternate streams should be able to have different lifecycles.
>
> Hmm, it sounds like the Council hasn't taken into account the constraints
> on lifecycle of modules that we have slowly discovered during the last
> two years, constraints that are now part of FESCo-approved policy.
>
> Essentially, modules in Fedora are only allowed to EOL at EOL of Fedora release.
> And to preserve stability for users, a.k.a. following the Update Policy,
> modules should only change to new major version at Fedora releases.
> This is exactly the same as for "normal" rpms.
>
> The lifecycle of modules in Fedora must be the same as lifecycle of
> Fedora releases, so no "different lifecycle" is possible.
Ok, just to be sure that I understand this correctly:
- module EOL dates must align with fedora release EOL dates,
Yes, this was voted in
https://pagure.io/modularity/issue/112#comment-553234
Allow maintainers to specify that a module stream will live until
the EOL date of a particular Fedora release or EPEL minor release,
with special cases for "just keep building until I say otherwise"?
and
approved in
https://pagure.io/modularity/issue/112#comment-562677.
(I'm providing exact links because it's hard to find.)
- Update Policy is the same for modules as for normal packages,
- major package updates can only occur at "release upgrade" time
I'm not sure if that is specified in plain text anywhere.
The last image in
https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-u...
shows that at least.
But the gist of
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy
applies to modules too: if there's a module that has been released for
some Fedora version, a major user-visible change would be just a disruptive
for users as a major user-visible change in any packages. This certainly
applies to streams like "/stable" and "/version-nnn".
Maybe somebody from the Modularity team can provide clarification here
and links to policy.
If I'm not suffering from too low blood levels of caffeine right
now,
then from these 3 constraints follows:
- default streams are basically useless (since they cannot target
multiple fedora releases in most cases, due to the Update Policy),
In general, yes. If the package versions have incompatibilities and/or
user-visible changes, a different stream is needed for each Fedora
release. There was a subthread about this recently, starting at
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o....
- flexible lifecycle advantages of modules do not apply to fedora,
since module EOL dates must align with fedora release EOL dates.
Then, what *is* the benefit of using modules for "default" versions of
fedora packages, if "default" streams have to usually be maintained
separately for different fedora branches, just like normal packages,
but with the *additional* overhead of Modularity - and additional work
for maintainers of dependent packages?
That is one of questions we are trying to answer in this thread ;)
Zbyszek