> how long is a while? I think it's somewhere in the order of 15 minutes of commit inactivity before a new build is generated. (We of course tuned this parameter to the wants of those working most with pike core development at the time the system was devised.) I could also misremember, and it be something like five minutes, but IIRC a quarter was what was considered a good commit threshold.
> can those automatic rebuilds be delayed by a few hours? Yes, but it will stall the feedback loop on a broken checkin by the same time, which is probably bad.. > since there might be a few checkins happening in a row, and then there > is no point to start the rebuild in the middle only to need another one > an hour later. The only way of preventing that from ever happening is to have a manual build generation cycle. That's a lot of human computrons wasted and a lot of communication overhead added, to, occasionally, save some CPU cycles which were offered for free in the first place. I do not see how that would be an improvement. > i noticed several times that there are 2 or 3 rebuilds coming in a row. > i assumed they were all manually triggered, but if that is not the case > then i suspect that in most of those cases only the last rebuild was > really useful, wasting lots of cpu cycles in particular on the slower > machines which get held up with the first rebuild while the last one > would already be available for building. Build clients quite intentionally are configurable by their maintainers to poll for new builds only as often as the maintainer wants them to run, at the most often, and thus often skip several builds coming in a row. Those several builds coming in a row often are more than one because a developer found a bug in the first commit thanks to feedback from pike farm from machines that do run frequently and do report promptly. The effect of increasing the delay would slow the pace of progress. > ideally rebuilds should happen when the code is somewhat stabilized. > based on checin frequency that would be when there is no checkins for a > while, instead of right when checkins happen... Which is thus the ideal solution already implemented. :-)
