On Mon, Nov 26, 2018 at 5:01 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Mon, Nov 26, 2018 at 9:48 PM Matthew Miller <mattdm(a)fedoraproject.org> wrote:
> On Mon, Nov 26, 2018 at 08:02:26PM +0000, Peter Robinson wrote:
> > 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.
> It seems like there's a lot of room to optimize those things too. For
> example, extract the needed metadata into a database and update that at
> build time rather than compose time, and run createrepo against that instead
> of rpms directly.
Completely agree there's a LOT of improvement that can be done, but I
don't see why that development work cannot be done in parallel and put
it into production when each of the various different components are
Because the people that would be tasked with doing the development are
also tasked with cranking out the release. It's a "need more people
ready to go. Ultimately a lot of those sort of ways of optimising
things are things that have been known for some time but no one has
actually stepped up to do the dev work and it it into production
shape. Stopping the standard distro work won't miraculously make that
other work happen and appear.
Well, I kind of disagree. Barring magical people that appear out of
the woodwork that know how the tools work and how they need to be
improved, I don't see an alternative. Not doing a release to focus on
our tech debt seems like a good tradeoff. If there are others that
really WANT to continue cranking the release with the tools as they
are today... that might be something that could be pursued. It would
still require net new contributors to a critical area.