Re: What's cooking in git.git (Jan 2020, #04; Wed, 22)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 5, 2020, 21:01 UTC
- Message-ID
- <xmqqeev8694x.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <nycvar.QRO.7.76.6.2001250133510.46@tvgsbejvaqbjf.bet>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 19 quoted lines
>> Do they have to shout that loudly in the name? >> >> We could rename these jobs to e.g. 'linux-clang-py2' and the like, but >> I think it would bring little benefit, if any. In our Travis CI >> builds these Linux/OSX Clang/GCC jobs come from the build matrix, >> therefore the jobname is not visible on the Travis CI web interface or >> API, only in the build logs. There are some pages on Azure Pipelines >> that do show the jobname (and some that could, but hide it instead), >> but it's just too convoluted (or sometimes even impossible, well, for >> me anyway) to get there. >> >> And if the requested Python binary can't be found, which will >> eventually happen with 'python2', then the non-zero exit code of >> 'which' will abort the build, no matter how the job is called. > > I am mostly worried about contributors whose PRs break for "magic" > reasons. If it is not clear where the difference between `linux-gcc` and > `linux-clang` lies, that can cause unintended frustration, and I do not > want to cause that.
So, what, if any, decision have we reached?
If linux-gcc and linux-clang labels are not visible, linux-clang-py2 and osx-py3 would not be, either, so...