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 7:52 PM Paul Frields <stickster@xxxxxxxxx> wrote:
>
> 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

There's no facts or details, to quote "The reported speed increase for
transactions is substantial. This may solve (or greatly reduce) the
compose speed problem, TBD." but it doesn't report the context of the
"speed increase for transactions" .... like which transactions?
There's a lot of I/O heavy processes in the compose, like createrepo,
that don't run any rpm tracsactions what so ever.
_______________________________________________
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