#2027 RFC: Module lifecycles
Closed: Accepted 3 months ago by zbyszek. Opened 6 months ago by psabata.

The Modularity WG would like to ask FESCo for comments on the module lifecycles topic:

Please, see the linked proposal above.

Metadata Update from @bowlofeggs:
- Issue tagged with: meeting

5 months ago

We will discuss this in the FESCo meeting on Monday at 15:00UTC in #fedora-meeting-1 on

Please remember to read the proposal and discuss in ticket.

From the meeting:

We generally agree that we would like to tie EOL to Fedora releases and RHEL minor releases while also retaining module stream expansion for both together. How we do this and how we report and store these EOLs needs more discussion.

Metadata Update from @churchyard:
- Issue untagged with: meeting

5 months ago

Not much is happening in the modularity ticket. This seems to be another case where things will stall until somebody does the homework and makes a concrete proposal.

Metadata Update from @churchyard:
- Issue tagged with: stalled

5 months ago

It's been rejected because of using PDC/FPDC as a storage.

Amendment: The EOL definition will be stored as a file in dist-git alongside the modulemd.

For the original proposal:
REJECTED: Proposal in its current form is accepted (+2, 2, -3)

Metadata Update from @zbyszek:
- Issue untagged with: stalled

4 months ago

@asamalik do you plan to update the proposal documentation in https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/lifecycles-general.md? In particular, any details about file names, file formats (the syntax in the previous proposal was supposed to be just pseudo-syntax, is it now to be used in actual files?), who will parse that file and when, are missing. This is a very contentious subject, and I don't think we can approve such a big change based on one sentence.

We've discussed in our Modularity meeting and @sgallagh will be sending a PR to that proposal.

Oh, great. Let's wait for this then.

The proposal has been updated.

Metadata Update from @psabata:
- Issue tagged with: meeting

3 months ago

During the previous meeting, FESCo voted against storage in PDC/FPDC. But the updated proposal even more nebulous. Essentially, we know less from the updated proposal, because as before at least there was a concrete mechanism named, now it's "information MUST be stored persistently and made available via a stable, published API at a well-known web address". This really brings no information. Of course the information has to be stored somewhere, and of course it should be available on the web from a known address. According to the updated proposal, it might be PDC, if might be FPDC, it might be some new frontend, or it might be some gigantic git repository, with pagure as a front-end or maybe not. Sorry, but this does not clear up any of the doubts I had previously.

Once set, these values may be extended (enabling support on later releases), but may not be shortened.

That's a minor point, but I think the idea that EOL can never be shortened is simply infeasible for a project like Fedora. In a more controlled environment, like RHEL, it might be possible to guarantee support once declared like this. But in Fedora, we'll always have mistakes, we'll have people getting bored/fed-up/burnt-out/mia, we'll have shifting priorities and technologies. A new maintainer might decide that they update the EOL from F36 and F32 and nobody can force them to maintain it. A new version my come out, causing a reshuffling of the schedule. By disallowing the EOL from going back, we'll either have people never filling it in until right before retirement, or zombie modules with no support.

Metadata Update from @zbyszek:
- Issue untagged with: meeting

3 months ago

@zbyszek You pushed back against the notion that the content should be stored in PDC/FPDC. So we dropped that requirement (which had been added at FESCo's request previously). If it doesn't clear up your doubts... maybe express those doubts? We have no idea what information you want from us.

Regarding the EOL shortening, see the discussion on https://pagure.io/modularity/issue/112 where @churchyard and I discussed it. tl;dr: We're fine with there being a way to override this, but the policy should actively discourage it in all but exceptional cases.

Metadata Update from @sgallagh:
- Issue tagged with: meeting

3 months ago

I was expressing concern with the [F]PDC location because it appeared that the result would be that the EOL life information a) would be not be easily visible to module maintainers b) could only be updated with a releng ticket. And we need to reduce the number of releng tickets. I believe b) was a big concern to other people as well.

I don't feel that this was captured in the update to the proposal - it still lists the [F]PDC as one possible solution, and now allows other solutions that might require releng involvement as well... or not. If the proposal is to be vague in this area, then it should list requirements.

Note that FPDC is now uncertain. @cverna, any comments you care to share about that?

This was discussed during today's FESCo meeting:
AGREED: The proposal is approved with the additional requirement
that the maintainer can update the information at any time,
automatically, without releng or any other human involvement,
assuming the update is valid based on policy (+6, 0, 0)

Metadata Update from @zbyszek:
- Issue untagged with: meeting
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.