"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > 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.schindelin@xxxxxx> > --- > 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. The same comment applies to 11/21. Would it hurt readability if these steps are combined? If 09/21 were "copy travis.yml to create a moral-equivalent set-up for azure.yml", then it is an entirely different story (i.e. "we start from an equivalent setup as we have, and then tweak to match our needs better, and we can view the tweak easier as a separate step"), but I did not get the impression that it was what happened there in 09/21.
