On Mon, Nov 26, 2018 at 1:59 PM Peter Robinson <pbrobinson@xxxxxxxxx> 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. One of the large factors -- which I think was noted in the page -- was RPM scriptlets. Stephen Gallagher met with WIll Woods and James Antill just recently to talk about this. The time savings was substantial. Combining that with reducing the size of "speculative composes" that could be used for CI and other pre-ship purposes could get us to where we want to be. Stephen's carrying a heavy duty project at the moment but when that's done in a few weeks, this will be getting more attention. > > > The fact of the matter is that the compose has a LOT of > > > I/O and I/O is slow and the cost to upgrade the infrastructure to get > > > high through put I/O is expensive and no one has ever offered the > > > budget to resolve that problem. The fact of the matter with this is > > > that we now produce a lot of release artifacts and that takes time, > > > some of it can probably be run more in parallel, and possibly some > > > things run at different times but without a combination of investment > > > in infrastructure, and maybe even hacking and slashing of components > > > this is not simply a check box. > > > > That's why the proposal is to skip an entire release to give us time to > > work on it. If it was easy, that wouldn't be necessary. > > > > There are of course at least *two* possible solutions to "there's lots > > of I/O". One is "throw money at making the I/O faster", the other is > > "figure out how to do less I/O". > > > > One hour is a *target*, not a *requirement*. I don't think anyone's > > going to consider the time wasted if we wind up getting it down to two > > hours instead of one. > > > > (Though personally I'd like ten minutes. And two unicorns.) Just so. -- 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
