On Sun, Oct 20, 2019 at 10:47:15AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/message/C5EX4WI7Z4HZZLVTUIHSMMPPUGTFENYE/. 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 ;) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
