Hi,

so for 1, please use fedpkg request-branch for both.

as it goes for 2. I will create the corresponding pdc entries. I need some reasonable estimates about the EOL. Because just setting it to some random date in far future does not sound right. Is there any upstream EOL for the release?

Some of the modules already have such EOL date set: "eol": "2222-01-01"
As can be seen in:
https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/?branch_type=module&global_component=mariadb&branch=10.3

Based on this ticket: https://pagure.io/releng/issue/8699

--

The issue is that I really don't have such estimate at this moment.

I usually only know the point when I don't want to maintain such component anymore.

In some cases (e.g. that I also maintain the version in RHEL) I maintain a certain versions longer than the upstream does.
Also, the upstream just announced a major change to the release model - moving to a faster life cycle than the Fedora have - so it is currently unclear how I will be able to handle that.

--

I believe the issue is in the EOL system of modules itself - both technical, that I need to ping release engineers for every bit I want to change - and philosophical, that I kinda need to be able to give different components a different support status.
It would be awesome to say "the support ends now, or in a 2 months", instead of waiting for 2 years, until a Rawhide containing that version becomes EOL.

While there is a clear idea of a level of support each component in Fedora should have, the reality is often different, as volunteers so the maintenance job.

As I have users reaching me now and then, asking for this and that major version to be available, I rather make available as many of the versions (stream in this case) as possible, giving my best effort to maintain them,
even if that means that at some point the component might become unmaintainable for some reason and I just leave it rotting there as I can't re-set the EOL date sooner that ~ 2 years of any date,
than to not making them available at all when I can't give a solid EOL estimation, or needing to ping Release Engineers regularly to extend the EOL.

--

So setting a random date in far future is the best I can work with.

Sorry for the wording by "need" I meant, It would be nice to have some consistency and ideally have some EOL date that will be reached and the branches automatically retired.

However, I do understand the situation and the entries in PDC are created as of now.

https://pdc.fedoraproject.org/rest_api/v1/component-branches/?type=module&global_component=mariadb

Great, thank you !

This API request you shared is nice.
I have a huge problem in general with getting any useful information from that API through that web UI. I'll definitely save this one for later :)

I am looking forward to this F36 change, which should make the module EOL process easier:
https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL

I will just leave the commands I used to fix this, for future reference.

create branch 10.7

curl -X POST -H "Content-Type: application/json" -H "Authorization: token <token_goes_here>" -d '{"global_component": "mariadb","name": "10.7", "type": "module","critical_path": false}'  https://pdc.fedoraproject.org/rest_api/v1/component-branches/ 

create SLA for branch 10.7

curl -X POST -H "Content-Type: application/json" -H "Authorization: token <token_goes_here>" -d '{"sla": "bug_fixes", "eol": "2222-01-01", "branch": { "name": "10.7", "global_component": "mariadb", "type": "module", "critical_path": false}}'  https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/