On Wed, Jul 05, 2017 at 02:33:01PM -0700, Adam Williamson wrote: > With Pungi 4 we really can't do that any more. Composes have a much > more solid identity as an actual thing. 'A compose' has a compose ID, > production composes have a label, and these can't really be duplicated. > There is a bunch of metadata which is produced for the compose *as a > whole*; if we do a compose where we try 10 images and 1 fails, the > metadata for that compose will list 9 images. If we then ran another > compose just to produce that 1 missing image (with properties as > similar as possible to the original compose), the metadata for the new
I understand the value of having something that is an authoritative source of truth about release artifacts. I'm not sure at all about the value of having The Compose like this. Especially since we already do things like assuming that tests which apply to RC 1.4 are probably good for 1.5 since we know none of the relevant packages have changed. I guess we could solve this with another layer of abstraction: a super-compose which could include artifacts from various composes or other compose-like sources. > script or something, both of which would be error-prone). It's also not > actually that easy just to respin a single image; Pungi 4 isn't really > built to do that (you'd have to create a new Pungi compose config file > each time you wanted to do it), and releng really doesn't want to do it > manually below the Pungi level any more in case of inconsistencies or > errors. Maybe that just means it needs to be easier to create and update pungi compose configs? > However, as I said before, we *do* have some ways we can unofficially > provide 'missing' images. They just can't be a full part of the > official release. But they can still be "official Fedora" even if not part of an "official release". -- Matthew Miller <mat...@fedoraproject.org> Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
