On Thu, 2022-03-17 at 12:34 +0100, Miro Hrončok wrote: > > Where is the sanitation, medicine, education, wine, public order, irrigation, > roads, a fresh water system, and public health that the PDC have done for us? > > > Serious question: Why do we need PDC? What actual problems does it solve? It stores the metadata of all composes that have been run, ever. (Well, when there isn't a bug in the sync, anyway). This is useful in several ways: 1. It's the best way I know of to figure out what the "previous" compose was. fedfind implements two ways of doing this, one based on PDC, one not. Here they are. You judge which is less awful: https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1293 (PDC) https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1380 (not PDC) 2. It's useful if you want to look at the history of, e.g., what packages were in what composes, or what size images were. The actual nightly composes are garbage-collected after two weeks, so unless you have your own stash of their metadata, you cannot find this information for nightly composes that are more than two weeks old anywhere but PDC. With the PDC metadata you can chart image sizes or package changes between nightly composes from five years ago, if you want. Without the PDC metadata you can only do it for composes we still have around - final releases, maybe Beta releases - and it's painful even for those because we don't actually keep the metadata for them in the live trees, you have to figure out what you want to know from HTTP requests (ugh). 3. It's actually very useful for handling exactly that case of how we screw up composes when we release them. When we take a compose and release it as a Beta or Final release, we throw some things away and move other things around, and because of that, we don't publish the metadata for it in the repos because it's not exactly correct any more. But that, well, sucks. If you ask fedfind for the metadata of a final or Beta release, what it does is find the metadata for the source compose of that release in PDC, then amend it in a way that reflects how releng hacked it up, and present you with modified, accurate metadata: https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1876 it's the path there where we *do* find `origmd` (the path where we *don't* is for handling releases that were done before Pungi 4 / PDC, and it provides much less complete, synthesized metadata). Once the original, unmodified composes have been garbage-collected from https://kojipkgs.fedoraproject.org/compose/ and https://dl.fedoraproject.org/pub/alt/stage/ , PDC is the *only* place you can get this metadata. 4. It's the only way I know of for finding out what the compose ID of a candidate compose was if all you have is its label. For example, for the Fedora 36 Beta candidate compose, its compose ID was "Fedora-36- 20220311.0", and its label was "Beta-1.1"; if you want to look up "what compose was 36 Beta-1.1?" the only solid way to do it is in PDC. This is kind of esoteric, I guess, but for boring reasons I won't go into it's something I actually need in the release validation process automation. 5. It's the most convenient way to look up "what version of packages X, Y and Z were in compose foo?", which fedfind does here: https://pagure.io/fedora-qa/fedfind/blob/main/f/src/fedfind/release.py#_1320 the only alternatives I know of are to parse HTTP requests, which is awful and doesn't get you epochs, or grab the entire `rpms.json` metadata for the compose and parse that, which works but it's nearly 200MB, which is a lot to download just to query five packages. And you can only do those two if the compose hasn't been garbage-collected (see point 2). We use this and "previous" compose discovery (point 1) in the release validation event creation code - we query the versions of several key packages (e.g. anaconda and gnome-shell) in the current and 'previous' composes, and if any of them has changed, we are more likely to create a new event than if none of them has changed. -- 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
