Re: [PATCH v4 10/21] ci: move the Windows job to the top

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux