On 11/26/18 11:55 AM, Paul Frields wrote: > On Mon, Nov 26, 2018 at 2:42 PM Adam Williamson >> >> While we're on the topic of unicorns, if I were the person actually in >> charge of this and had the freedom to do it how I wanted, what I'd >> really want to do is create a much more *modular* compose process, >> where inputs and outputs were defined and associated with each other, >> and you could easily define subsets to be produced at different times >> for different reasons. Not a compose, but a Compose Construction Kit. A >> big chunk of the length of "the compose" is associated with the fact >> that we define "the compose" as a single thing which produces (last >> time I counted) 70+ deliverables. If we had an easy way to say 'ok, >> right now we need a compose which produces A, B, C and D from the >> minimum necessary sets of inputs', that would be a massive improvement. >> >> This hasn't been true for a while (we actually have something like half >> a dozen or more different "composes", right now), but the system is >> still less flexible and it's still more difficult to configure >> different composes than it really ought to be. Agreed, that would be nice. The one issue I see off hand is that koji tags are kind of expensive so we can't just tag everything the way we may want to, but perhaps we can come up with some clever workflow for that. > Adam puts his finger on an important aspect of the work, which is to > "decompose the compose" (sorry). We need the ability to produce enough > A, B, C and D (abusing his example) to do integration tests for > specific inputs, such that maintainers get feedback in a reasonable > timeframe on their builds. Yeah, thats long been a desire of releng/qa... weeding out the obviously broken would be very nice. >With that, gating Rawhide can be an actual > thing. Indeed. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
