#129 UX design of setting module EOL — please review
Closed: Fixed 8 months ago by asamalik. Opened 9 months ago by asamalik.

I’d like to get some input on my UX (user experience) design proposal for managing module EOL.

My goal is to get the UX right before we start to implement anything. As with many things, I expect there to be compromises, and if I had to chose, I’d rather make computers suffer, not our packagers. So I’m putting them first.

For more information, see the Lifecycles in Fedora Modularity document with a more high-level overview.


Setting a module EOL feels very similar to retiring a package, with the exception that packagers will be able to also "retire" the module at a specific moment in the future, not just at the moment of doing it.

Because package retirement is done by fedpkg retire, I propose using fedpkg in this case as well, specifically adding a new sub-command fedpkg module-eol that will support the following operations:

  1. Set or modify an EOL to a specific Fedora release
  2. Set or modify an EOL to “forever or until I say otherwise”
  3. Set or modify an EOL to “do not build”

There will be policy restrictions for some of the operations above. For example, shortening an EOL needs to be either forbidden or allowed on an exception basis.

Running those commands will have an immediate effect.

I also propose to remove the mandatory --sl rawhide:<date> argument from fedpkg request-branch and replace it with an optional --module-eol parameter.

Specific examples

All the following fedpkg module-eol commands are to be executed in a local copy of the module’s dist-git repository, in the stream branch they should affect.

Based on the Lifecycles in Fedora Modularity document, module EOL is set separately for Fedora and EPEL releases.

Set the EOL to Fedora 32:

$ fedpkg module-eol fedora:f32

Extend the EOL to Fedora 34:

$ fedpkg module-eol fedora:f34

Set the EOL to “forever or until I say otherwise”

$ fedpkg module-eol fedora

Set the EOL to Fedora 32 and disable builds in EPEL (once we have modules in EPEL):

Note: The epel example is a placeholder. We might use epel, epel8, or any other viable name when EPEL 8 comes to existence.

$ fedpkg module-eol fedora:f32
$ fedpkg module-eol epel:0

Set the EOL to EPEL 8.3:

$ fedpkg module-eol epel:el8.3

Shorten the EOL from f35 to f34. This operation requires an additional --force flag as shortening module lifecycles is expected to be disallowed by a Fedora policy without a granted permission. Based on that policy — which will be defined outside this ticket — this option might be restricted only to rel-eng users based on that policy.

$ fedpkg module-eol --force fedora:f34

Requesting a new branch in dist-git/rpms will no longer have the --sl rawhide:2020-12-01 parameter:

$ fedpkg request-branch --repo=NAME -- BRANCH

Requesting a new branch in dist-git/modules will have a new optional parameter. Not specifying it defaults to “forever or until I say otherwise”.

$ fedpkg request-branch --namespace modules --repo NAME -- BRANCH
$ fedpkg request-branch --namespace modules --module-eol fedora:f34 --repo NAME -- BRANCH


2018-03-27: Applying feedback from sgallagh.
2018-04-03: Added a note about the epel example is a placeholder based on the Modularity Team meeting.

Did you mean to have fedora:32 some places and fedora:f34 in others? I think we need to be clear what we expect this value to be. Similarly, an example of what EPEL would look like could be helpful. Is it epel:8.3 or epel:el8.3, for example.

I also propose removing the existing --sl rawhide:2020-12-01 parameter from the fedpkg request-branch command used when requesting a new package branch, and adding a new, optional parameter that will be only used when requesting a new module branch.

I think you are referring forward to the last example here, but it's a bit confusing. If so, I agree, but there's some difficulty in comprehension. Maybe rephrase it as: "Remove the mandatory --sl rawhide:<date> argument from fedpkg request-branch and replace it with an optional --module-eol parameter." (Also, we should make it clear that, if not specified, it defaults to “forever or until I say otherwise”.

Regarding "shortening" the EOL... I think it would be useful if fedpkg module-eol required a --force flag to do this. If someone tries to set it shorter by accident, I think that should be rejected by default and reminded that Fedora policy disallows doing this without a granted exception. We may even want to restrict this feature to somehow being permitted only by releng-team members, so that we can make EOL shortening require a rel-eng ticket. We agreed in the other ticket that this must be possible, but that doesn't mean we have to make it readily-accessible.

Thanks @sgallagh! This is a very good feedback, I've updated the description.

Metadata Update from @asamalik:
- Issue tagged with: Meeting

8 months ago

This will be discussed at the Modularity Team meeting today:

  • This feels final, just need a formal +1 from the group

The Modularity Team has approved UX design of setting module EOL +4 0 -0

Metadata Update from @asamalik:
- Issue untagged with: Meeting
- Issue assigned to asamalik

8 months ago

Metadata Update from @asamalik:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

8 months ago

Login to comment on this ticket.