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. > > 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.) > -- > 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 _______________________________________________ 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
