On Mon, Nov 26, 2018 at 7:47 PM Mohan Boddu mboddu@bhujji.com wrote:
On Mon, Nov 26, 2018 at 2:30 PM Kevin Fenzi kevin@scrye.com wrote:
On 11/26/18 10:58 AM, Peter Robinson wrote:
On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson adamwill@fedoraproject.org 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@fedoraproject.org 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.
I totally agree, also as Peter mentioned, IOT composes are just taking 1 hour as its just consuming the repo rather than generating newRepo as the normal nightly composes does. If we can generate the newRepo on the fly whenever a package gets build and just use the repo to generate the artifacts either individually (splitting the compose) or parallely (as we are doing right now mostly) that would really help.
Unfortunately the newRepo/installer bit is likely the most I/O intensive, but I think it we split it out into it's own process, see mail I just sent, it would be a good start, and then also a good separate standalone focus for optimizations.
Peter