On Mon, Nov 26, 2018 at 7:52 PM Paul Frields <stickster(a)gmail.com> wrote:
On Mon, Nov 26, 2018 at 1:59 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
> On Mon, Nov 26, 2018 at 6:53 PM Adam Williamson
> <adamwill(a)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
> > > > On Fri, Nov 16, 2018 at 09:50:33AM -0500, Paul Frields wrote:
> > > > > Here's the summary from the page, which proposes we pause
> > > > > after F30 for these efforts:
> > > >
> > > > I know it was a big time-off holiday week in the US, but I expected a
> > > > more interest in this post. Perhaps it seemed like too much text to
> > > > along with turkey and stuffing. :) I'm highlighting it with a
> > > > reflecting the big, direct impact, and here's some other
> > > > 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.