On Thu, Apr 09, 2020 at 12:05:07PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > if the module EOL is before a given Fedora version goes EOL, it should > never be proposed for installation in that Fedora version. In other words, > if foo:3.15 stream has EOL of 1/4/2020, it should be shown in > 'dnf module list' in F<=31, but not F>=32. > I think you wanted to write F<=30. F30 ends in 2020-04. Isn't "dnf" stage too late? Should it be filtered sooner? E.g. enforced by Bodhi? Current Bodhi prevents from pushing updates into EOL-ed Fedoras. Or it could be prevented from building in MBS. When MBS expands platform:[] to all supported Fedoras, it could also take other stream's EOL into account. Not only platform EOL. It could save Koji resources. > > My understanding of current policy is that it would not be permitted > > to have such a module in current fedora. It could only be included > > in a version of fedora where it will receive updates for the entire > > life cycle of that Fedora version. > > Exactly. The question is whether this happens like this, or not. > I scanned https://docs.fedoraproject.org/en-US/modularity, but I don't see > any mention of that. > While your approach simplifies the decisions a user should do, it also prevents from providing streams that have a shorter life than Fedora. E.g. non-LTS Java only has a life span for 6 months. How should be delivered these "rapidly" developed projects? -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
