On Thu, 2017-07-06 at 10:05 -0400, Matthew Miller wrote: > 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.
Expect my resignation letter attached to a copy of the fedfind source, with a note saying "I'm damned if I'm writing ANOTHER layer of this crap". :P > > 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? Pungi is inherently a complicated thing, because it's a tool for doing a whole bunch of different tasks for two rather different distributions. There's a limit to how much we can unilaterally mess around with this stuff (because we're sharing a tool with RHEL, here) and a limit to how much we can simplify it, I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
