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....
Wait, did I just reply to you quoting your earlier mail? Oops,
I did. Smooge is right, this thread has started looping.
Zbyszek
> > - 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 ;)