"Johannes Schindelin via GitGitGadget" <gitgitgad...@gmail.com> writes:
> From: Johannes Schindelin <johannes.schinde...@gmx.de> > > The Windows job currently takes a whopping ~1h20m to complete. Which is > *far* longer than the next-longest job takes (linux-gcc, ~35m). As such, > it makes sense to start the Windows job first, to minimize the overall > run time (which is now pretty safely the run time of the Windows job). Is the reason why Windows job gets started first is to make sure that it, which is known to take the longest time, never has to wait before starting while other jobs run, in case there is limited parallelism? The last part of this sentence is what readers of this step will need in order to be convinced by the justification given, because (1) if the jobs run totally serially, the order does not matter much---if anything, running shorter jobs first would give results from more jobs sooner, and (2) if the jobs run totally in parallel, the order does not matter as long as we have enough parallelism. > This commit is best viewed with `--color-moved`. > > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> > --- > azure-pipelines.yml | 172 ++++++++++++++++++++++---------------------- > 1 file changed, 86 insertions(+), 86 deletions(-) For those who are seeing this azure-pipelines series for the first time, it would probably be unclear what the point of adding an entire file in 09/21 and them moving lines around in 10/21 is. If somebody asked me why, I wouldn't be able to explain why it is a good idea. Would it hurt readability if these two steps are combined?
