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, - Update Policy is the same for modules as for normal packages, - major package updates can only occur at "release upgrade" time 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), - 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? Fabio > > 1. Users should have alternate streams of software available. > > 3. Packaging an individual stream for multiple outputs should be easier > > than before. > > Those *are* useful goals, but they should not be tied to specific technology, > we should only care about the end-result. > > Thus, please replace "Our goals for modularity are" with "What we hope > to achieve with modularity" or even "Our goal is for users to be able to". > > Zbyszek > _______________________________________________ > 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 _______________________________________________ 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
