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 > <zbys...@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-upgrades-ownership/lifecycles-general.md 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.org/message/C5EX4WI7Z4HZZLVTUIHSMMPPUGTFENYE/. > - 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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
