El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió: > 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". This is no longer entirely true, development of the compose tools is done entirely by PNT DevOps today. Bodhi and other tools in parts of the delivery pipeline are developed by people in Fedora Engineering who also have other tasks to do. > > 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. We would need to engage with the team working on the compose tools and see what time they can dedicate to meeting Fedora's needs. Likely a end state needs to be defined. then the work can be scoped. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
