On Mon, 2018-11-26 at 11:30 -0800, Kevin Fenzi wrote: > On 11/26/18 10:58 AM, Peter Robinson wrote: > > On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson > > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > > On Mon, 2018-11-26 at 18:44 +0000, Peter Robinson wrote: > > > > On Mon, Nov 26, 2018 at 4:05 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote: > > > > > > Here's the summary from the page, which proposes we pause the release > > > > > > after F30 for these efforts: > > > > > > > > > > I know it was a big time-off holiday week in the US, but I expected a little > > > > > more interest in this post. Perhaps it seemed like too much text to digest > > > > > along with turkey and stuffing. :) I'm highlighting it with a subject > > > > > reflecting the big, direct impact, and here's some other top-level > > > > > proposals: > > > > > > > > > > * embrace Taiga (an open source kanban tool) for project planning > > > > > * fix the compose speed (target: one hour!) > > > > > > > > Can I have a unicorn? Everyone wants this bug absolutely no one has > > > > done analysis. > > > > > > I just don't believe this is true. I'm pretty sure Dennis and Kevin > > > have both looked into it before. > > > > Yes, I mean recently, I was involved in the last time we attempted > > this, and there was a number of things identified but quite a bit has > > changed since that last happened. > > Yeah, I think our goal should be 1 minute... just as realistic as one > hour. ;) > > I have not looked into things recently. However: > > * The mock fsync change (https://pagure.io/releng/issue/7909) may help > some. > > * We have plans to redo the setup on the s390x builders, which should > result in them being much faster. That should help. > > * I know pungi maintaienrs have been doing some work to make things > faster (even in the last release out this morning). > > All that said, I am not sure there's going to be a way to get it down to > an hour. I think getting it down to 3-4hours may be very helpful tho and > might be possible. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ 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
