On Thu, 2019-09-19 at 09:02 -0400, Ben Cotton wrote:
On Wed, Sep 18, 2019 at 8:55 PM Adam Williamson
<adamwill(a)fedoraproject.org> 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/is...
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