Gentle ping. Can we get this one in? I'm relying on this schedule info at https://fedorapeople.org/groups/schedule/f-39/f-39-all-milestones.json for https://src.fedoraproject.org/rpms/fedora-appstream-metadata

Schedule is now updated with a change that brings everything up to date so it should all be correct now.

Hum, this PR hasn't been merged and thus the data in https://fedorapeople.org/groups/schedule/f-39/f-39-all-milestones.json is still incorrect.

We rely on this data for https://src.fedoraproject.org/rpms/fedora-appstream-metadata so we would need this PR to get in.

I'm unable to merge this pr as another pr was merged that should have fixed this issue and now there is conflicts for this one. Any suggestions to fix your issue? The schedule is correct for F39.

So @amoloney seems you included these changes in this commit - for future reference it's good git practice not to combine unrelated changes in one commit, that commit claims to be "Updating nominations period", unless you examine the actual changes you'd have no idea it also changes the F39 release dates.

Looking into it a little further, the reason @siosm is having problems here is that the build script no longer actually generates the f-39-all-milestones.json file; I think this is because https://pagure.io/fedora-pgm/schedule/c/02853bd commented out the all-milestones bits of pgm-build-fedora, supposedly as part of addressing https://pagure.io/fedora-pgm/schedule/issue/66 . So the file on the servers is a stale one from whenever the data was last generated before that change was made; the publish action doesn't wipe existing data before pushing the new data, so if a file is removed from the generation process, it isn't dropped from the server, it just goes stale (maybe we should change that).

@bcotton , sorry to ping you over in containerland, but I'm not sure whether I should just put all-milestones back, or whether we need to do something more sophisticated, or just tell @siosm he can't use that file any more and remove it from the server?

@siosm can you use https://fedorapeople.org/groups/schedule/f-39/f-39-key.json instead? If not, the best approach might be to create a separate file for this specific use case.

Thanks for the investigation. I'll look at using another file or potentially Bodhi for this info.

I'm looking at this and only releases starting with F38 and later have the end of line item. F37 and below don't have it: https://fedorapeople.org/groups/schedule/f-37/f-37-all-tasks.html

So this is again not ideal.

https://fedorapeople.org/groups/schedule/f-37/f-37-key.json (correct F37 json url).

Anyway, I'll workaround it in the code. I would be nice to reduce the complexity of this format here so that we make it easier to update and use programamtically.

I'm looking at this and only releases starting with F38 and later have the end of line item. F37 and below don't have it: https://fedorapeople.org/groups/schedule/f-37/f-37-all-tasks.html

I suggest opening an issue to request it. It shouldn't be much trouble for @amoloney to add it for F37 (and other releases, but those are already EOL so I'm not sure how useful that would be at this point)

I would be nice to reduce the complexity of this format here so that we make it easier to update and use programamtically.

You can file an issue against the tool used to generate it, but I'm not sure if anyone at Red Hat is still maintaining it. As you know, the PgM function was gutted earlier this year :sweat_smile:

For earlier releases you can get the EOL date from the N+2 release - the F39 schedule has the F37 EOL date in it, as "Fedora Linux 37 EOL auto closure". But really, unless you need it SUPER in advance for some reason, I'd say getting it from Bodhi is by far the easiest way.

But really, unless you need it SUPER in advance for some reason, I'd say getting it from Bodhi is by far the easiest way.

Also: the schedule is almost certainly a lie far in advance, since it's assuming we hit the early target date, which almost never happens.

Thanks, I filed new issues.