On Thu, 2022-07-07 at 10:49 -0700, Stewart Smith via devel wrote: > Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> writes: > > In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible > > notification when a Fedora stops being supported. Various proposals > > for online checks were discussed in the bug, but I think we might make > > do with something much simpler. > > We've been thinking a lot in this space in Amazon Linux, and have done > some things that are starting to be a bit wider in scope in the AL2022 > time frame, and that we've wanted to bring back as ideas to Fedora. > > One of which is simply how you tell someone there's something new they > could move to. If doing so by the command line, you need to somehow work > out what X to pass to `dnf system-upgrade ... --releasever=X`, while I'd > much rather be able to put it in, say, the motd, and have other tooling > be able to know through the same system that "why yes, you are up to > date on patches on version X, but version Y is available" > > The GNOME Software Center parses the hard coded URL of > https://admin.fedoraproject.org/pkgdb/api/collections/ > which does already have an EOL tag on older Fedora releases, so this > could be used today to print warnings all over the place if the format > was standard enough and documented... and that other distros could use > it easily enough with a custom URL without patching gnome-software... > > I would be totally in favor of some simple standard metadata we could host > somewhere, easily configure into various bits of software that would > prominently display it to users (or report back to some central thing, > like various agents do with "dnf checkupdate" and "rpm -qa" output, that > point to support statements about the OS. > > We actually have a skeleton design for such a thing (it says what > updates and upgrades are available), but we've lagged on > both posting to devel@ that it's something we've been working on, and I > need to go and poke the person who needs to click the "publish this repo > to github" button for the DNF plugin. I'll go do that now, as it would > certainly add to this conversation. The problem with this is that it's a very fuzzy, messy space that's hard to put limits and requirements on. The URL you mentioned is a case in point. That has more or less assumed the status of running joke among a small group of people who care about it. When you go to that URL, what you're getting now is a static JSON document that is hand-maintained in the fedora ansible tree: https://pagure.io/fedora-infra/ansible/blob/main/f/roles/pkgdb-proxy/files/pkgdb-gnome-software-collections.json when a release is branched, released, or EOLed, somebody from releng has to remember to edit that file, and get the edit right. These days that...usually...happens. Way back in the mists of time, what you got at that URL was a view on the release database of the pkgdb app, but that app hasn't existed for, uh, quite a lot of years now. When it was decommissioned, we discovered several things were relying on that API endpoint, which we replaced with a static JSON file just until it could be replaced with something less dumb. Yup, still here. The original planned replacement, IIRC, was PDC, which has now had an entire lifecycle (conceived, created, deployed, given up on, and nearly retired) without ever fully implementing all the release lifecycle tracking bits that various pkgdb consumers wanted. (It's been a while, but IIRC, there were issues with distinguishing between 'EOL', 'current stable', 'branched' and 'rawhide' releases from PDC data). There are various sources of some kind of truth regarding the Fedora release cycle. Bodhi has one - you can query https://bodhi.fedoraproject.org/releases/ with content-type JSON and you'll get some JSON back with some properties of various things Bodhi considers to be "releases", including a "state". I maintain one which is used by my 'fedfind' tool/library that various bits of infra (mostly QA things, but also a few others) use. It is a *different* hand-edited bit of JSON, which I created after being annoyed at the collections one being updated wrongly a few times: https://fedorapeople.org/groups/qa/metadata/release.json There's the CurrentFedoraVersion template on the wiki: https://fedoraproject.org/wiki/Template:CurrentFedoraVersion There's also, I think, some variables for 'current' releases in the Fedora infra ansible deployment. There are some fun issues you run up against when you play around in this sandbox long enough. One, for instance - when *exactly* is a new Fedora release "released"? Is it when the 'fedora' repo is frozen and Bodhi is kicked over to pushing new 'stable' updates to the 'updates' repo instead? (That's Bodhi's definition). Is it when the releases/NN tree on the public mirror system is available? (That's the one I use, more or less, for fedfind). Is it when the release announcement goes out? The point here being, if you think about it hard enough, the question of what 'states' a distro (or any software product) can be in is quite a difficult one and probably has a lot of answers. Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS, which have their own somewhat different release/life cycles? What about module lifecycles? What is it about *lifecycles* that's important, anyway? Don't we maybe want to just have a sort of generic system for "important events"? I kinda have a dream here, where there would be one canonical system for registering 'Fedora-related events', and all 'truths' about what releases are stable and EOL and whatknot in various systems, along with lots of other stuff, could be derived from it. That thing would be a really dumb list of 'events', where an event is really just something like this: "thing X reached state Y" where X and Y are both free text. The system would publish a message for each event, and it could also be queried. So when a Fedora release went EOL, as part of the SOP for doing that, an event: "fedora36 reached state eol" or something like that would be created, the system would publish that, and anyone who wanted to figure out what releases are eol could query the system for all things in state 'eol' and work it out. You could *also* use the system for things like: "fedora36 reached state stringfreeze" or whatever. I built a very dumb implementation of this: https://pagure.io/fedora-qa/releasestream and meant to try and improve it a bit and get it deployed and then start trying to get people to actually use it for stuff, but ran into ENOTIME issues. I'm still hoping to get back to it at some point... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
