Re: Proposal: delay F31 release to work out infrastructure and lifecycle challenges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux