On Mon, Nov 26, 2018 at 5:01 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > On Mon, Nov 26, 2018 at 9:48 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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 problem". > 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. josh _______________________________________________ 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
