Good ideas! Thanks. On Thursday, August 24, 2017 10:30:35 AM CEST Michal Novotny wrote: > On Wed, Aug 23, 2017 at 3:17 PM, Igor Gnatenko > [email protected]> wrote: > > * only one and supported / good API > > Yes, we will need to work on this...very soon.
+1, let's create an API which works for everybody. I mean, so far there were rather "declarative" ways how to specify what should happen. The problem is that if you have declarative tool/language/whatever, one needs to pay attention to standardizing something .... (and it is impossible to standardize upstream habits across the universe). > > * probably ability for some good integration with custom tools as we > > use (rpm-gitoverlay) > > > > I will need to study this more. -1, let's allow users to use whatever tool they want, don't concentrate on particular tool. > > * Faster builds (for 7-8 packages we are building, it takes ~20 minutes > > to build because we do it sequentially, but we can't do anything about > > that), probably some re-use of builders or faster spawning builds would > > help here, not sure > > We can certainly work on faster build spawning (builder reusing is already in > place). Also automatic build ordering in batch builds could also be of use > here? In any case, I agree this would help a lot. I don't see space for optimization here. The maximum speed you can get for the example of N packages, if the builds need to be serialized, is O(N). You can avoid cleaning mock caches, possibly, but I'm not sure this is what you want -> and the "spawning time" as is is very small constant in the final time complexity... Pavel _______________________________________________ copr-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
