On Tue, Nov 27, 2018 at 9:59 AM Owen Taylor <otaylor@xxxxxxxxxx> wrote: > A lot of discussion about improving the compose process seem to end up > with a "reality check" - that ideas have already been tried but don't > work because of requirements a) b) c) d). You can't have the pony, but > maybe if a lot of effort is put into it, you can have a faster rocking > horse. > > If want to fundamentally improve the Fedora workflow we need compose > ponies, we can't just have rocking horses! > > Perhaps it would make sense to leave the current 8-10 hour compose in > place for the forseeable future, and work on a new system in parallel > where the primary constraint is to be as fast as possible. Hopefully > most problems with the slow compose will get sorted out in the fast > composes, and the slow compose will become more reliable. Perhaps in a > distant future, we can make the new system do everything Indeed, this is basically the investigation I've proposed. I also think > I don't know what the system would look like exactly, but you could > imagine things like: > > * Composed of several micro-composes (micro-compose-services?) to > avoid blocking on everything completing successfully. > > * Able to do speculative composes for CI > > * Either x86_64-only, or with decoupled architectures so that we can > throw x86_64 hardware (or cloud resources) at it, and make it super > fast. > > * No IO /mnt/koji during the compose - having a big network share be > central to the process creates a performance bottleneck, makes it hard > to move to the cloud, and potentially adds a lot of "noise" to > figuring out what is going on where things are slow because of some > other entirely different thing is goin gon. > > Add your own bullet points :-) I would like to redefine a couple working assumptions: * Big tools are unwieldy and inevitably silo knowledge. The people behind them are often smart, hard-working, and care about great results. But bedrock FOSS principles say we get more value from rapidly iterating tools to which many people can/do contribute. We should see if we can avoid big tools that solve everything. * Reproducibility is something we can better enforce at development time than use time. It's pretty easy to pick one or more git heads at a certain time (for a tool, a containerized environment, etc.). Let's not get one hand tied behind our back at the outset via outmoded assumptions. Every other bullet point on your list, Owen, I agree with 100%. -- Paul _______________________________________________ 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
