Learn more about these different git repos.
Other Git URLs
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:
fedpkg retire
fedpkg
fedpkg module-eol
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.
--sl rawhide:<date>
fedpkg request-branch
--module-eol
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.
epel
epel8
$ 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.
--force
$ 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:
--sl rawhide:2020-12-01
$ 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
Edits:
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.
fedora:32
fedora:f34
epel:8.3
epel:el8.3
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”.
think
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.
releng-team
Thanks @sgallagh! This is a very good feedback, I've updated the description.
Metadata Update from @asamalik: - Issue tagged with: Meeting
This will be discussed at the Modularity Team meeting today:
+1
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
Metadata Update from @asamalik: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.