Hi Junio, On Wed, 23 Jan 2019, Junio C Hamano wrote: > "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. See my response to the other mail you sent (which seemed to be a first draft of this mail I am replying to?). > > 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. Indeed, that *was* the intention. I tried to clarify that, by just *not* adding the Windows-specific part in the commit that adds azure-pipelines.yml, as it really should imitate .travis.yml closely. Ciao, Dscho