On Thu, 2019-09-19 at 09:02 -0400, Ben Cotton wrote: > On Wed, Sep 18, 2019 at 8:55 PM Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > For the record, it makes me sad that we don't have a good way to know > > whether we're in Beta or Final phase > > I feel a little called out here, so I will just say that this is > payback for all of the times you've made me sad. :-) But seriously, > I'm not sure what the best way to make that programmatic would be. One > terrible option is to consume the schedule in JSON form[1] and work > from that. There are probably some edge cases that haven't occurred to > me in the 15 seconds I've been thinking about this, and it sounds > generally unpleasant. I guess the main problem there is knowing what slug will always mean "after this date the Beta has definitely been released", in various circumstances (we slip past the 'preferred target' date? we slip past the next date? everything blows up and we slip for three months? is the schedule predictably altered the same way in all these cases?) > This might be better solved in releng tooling > somehow? I don't care who solves it, I just want it solved. ;) It's really part of a bigger problem we have about just...knowing about Fedora releases in general. PDC was supposed to solve this, only then it got abandoned by Red Hat but we're still sort of using it but apparently no-one has time to even fix that composes aren't getting imported into it and though https://github.com/product-definition-center/product-definition-center/issues/294 eventually got solved upstream, Fedora's PDC stuff never got updated to actually store the necessary information so you *still* can't tell when a release is EOL in Fedora PDC. So most things that currently want to Know Stuff About Fedora Releases are still using: https://admin.fedoraproject.org/pkgdb/api/collections which was part of pkgdb when pkgdb was a thing, but is now just this weird orphan bit of JSON which is hacked up to be served out directly from a file which someone has to remember to manually update every time we branch, cut a new release, or EOL a release. #thisisfine > > and also that the canonical > > definition of 'blocking' images and image target sizes is just a wiki > > page, and thus not reasonably consumable by code (so this code just > > duplicates and will need manually updating if the list of blocking > > images changes)... > > I may be able to make you less sad here at some point. I've been > talking to asamalik about how to move some of the release-specifc > stuff out of the wiki and into docs.fp.o. So we might be able to > either make the html output more parseable, or better to make it so > that the release blocker page is built from a JSON file that would > live in a predictable place for your script to consume. This would be *much* better. If you want to bikeshed it some more it could even arguably be done in Pungi; Pungi already has a concept of 'this deliverable is so critical we abandon the compose if it fails', so it shouldn't be too much of a stretch to add a concept of 'this deliverable is release-critical' and 'this deliverable ought to be under size X' to Pungi config as well, then the human-readable form could be parsed out of our pungi-fedora config or whatever. But I'd be happy with really anything that's better than what we have right now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
