Just talking to @mohanboddu and he wants to store it in PDC. And he knows how we could make it work with fedpkg module-eol so packagers can update it themselves. So let's do that?

Three important topics came up during our meeting:

1. How to make it work with existing schema. Currently EOL's are stored as in date format, can we extend module EOL's to use the same field or do we need another field.
   1. It seems possible to use dates, for example, when a module maintainer wants to support the module:stream up until f30, we will use f30 release EOL date and store that value in the module:stream EOL value. But what happens when the maintainer wants to support it until f37, which is not recorded yet?
2. There might be two modules using the same rpm/branch. The rpm/branch EOL must always be the latest of the two modules EOL. Whenever a EOL on those modules gets changed, EOL of the rpm/branch should be recalculated and updated if necessary.
   1. Probably we can achieve this using a message bus listener and whenever there is an event on module EOL, trigger the service and recalculate and update rpm/branch EOL.
3. Aftermath of module EOL.
   1. With rpms, when they are retired all the builds gets untagged and blocked in koji for that release. How can we achieve this in modules?

I thought about it for a bit and I believe we definitely need to store the EOL info for each module:stream as indicated in the proposal, such as:

        fedora: "f31"
        epel8: "el8.1"

... and then we can calculate the date @mohanboddu talks about from it — both for modules and RPMS — to be used by other pieces of infra.

Three important topics came up during our meeting:

How to make it work with existing schema. Currently EOL's are stored as in date format, can we extend module EOL's to use the same field or do we need another field.
It seems possible to use dates, for example, when a module maintainer wants to support the module:stream up until f30, we will use f30 release EOL date and store that value in the module:stream EOL value. But what happens when the maintainer wants to support it until f37, which is not recorded yet?

Using date is not really good since EOL dates cannot be predicted. For example it is impossible to give the exact EOL date of f28 (1 month after f30 is GA). So I think we should definitely keep the Fedora releases here and maybe look at extending this to other artefacts.

There might be two modules using the same rpm/branch. The rpm/branch EOL must always be the latest of the two modules EOL. Whenever a EOL on those modules gets changed, EOL of the rpm/branch should be recalculated and updated if necessary.
Probably we can achieve this using a message bus listener and whenever there is an event on module EOL, trigger the service and recalculate and update rpm/branch EOL.

Aftermath of module EOL.
With rpms, when they are retired all the builds gets untagged and blocked in koji for that release. How can we achieve this in modules?

We've just talked about it with @cverna @pingou @mohanboddu @sgallagh @psabata and this is the outcome:

We'll store the information as a metadata to module branches in dist-git — a functionality that we'll implement as a Pagure plugin.

We'll provide a computed value for package branches as an API call.

TL;DR:

We see there is a difference between the current EOL date in PDC and the "module EOL". The first is an information about a package retirement date, and the other indicates the last release for which a module stream is build — they are very different.

About storing it, we discussed storing it in dist-git as proposed in this issue as well as PDC but didn't like either option for various reasons. We'd like to have it in a database but we don't want to rely on PDC as that might go out of service in an effort of minimizing infra services. Having it as metadata in dist-git seemed as the best option.

There are other use cases for the metadata such as branch ownership — so we'll join all of these together into one pagure-dist-git plugin.

Some useful links:

• pagure plugin template: https://pagure.io/pagure-dummy-thirdparty/
• pagure taiga plugin as an example of a plugin using a database: https://pagure.io/pagure-taiga
• existing pagure-dist-git plugin: https://pagure.io/pagure-dist-git/

Proposed and accepted change for Fedora 33: https://pagure.io/fesco/issue/2364