Subject: Re: [PATCH 2/3] ci: update Perforce version to r23.2

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 24 Jul 2024 11:01:32 +0200

On Wed, Jul 24, 2024 at 10:39:54AM +0200, Johannes Schindelin wrote:
> Hi Patrick,
> 
> On Tue, 23 Jul 2024, Patrick Steinhardt wrote:
> 
> > Update our Perforce version from r21.2 to r23.2. Note that the updated
> > version is not the newest version. Instead, it is the last version where
> > the way that Perforce is being distributed remains the same as in r21.2.
> > Newer releases stopped distributing p4 and p4d executablesas well as the
> > macOS archives directly and would thus require more work.
> 
> An alternative would be to simply stop installing `p4` in CI. I would
> actually be in favor of that, for multiple reasons:
> 
> - The pace of reviews and integration of `git-p4` patches has slowed down
>   over the couple of years. For example,
>   https://lore.kernel.org/git/20210510183638.156a6b1d@ado-tr/ has not seen
>   any traction in over three years (most likely because we no longer have
>   any active contributor with a vested interest in `git-p4`), and
>   https://github.com/gitgitgadget/git/pull/1028 and
>   https://github.com/gitgitgadget/git/pull/1070 have not even been
>   submitted to the Git mailing list (most likely because of the hurdles to
>   contribute).
> 
> - Over the years, it has been made harder and harder to install Perforce
>   in CI. I spent a good deal of time trying to keep the Homebrew taps up
>   to date (which was hard because Perforce kept replacing the archive
>   behind that URL with newer versions, which always broke Homebrew's SHA
>   check until it was adjusted accordingly).
> 
> - The `git-p4` tests use quite a bit of time and electricity in all those
>   CI builds. Therefore, it seems desirable to me to stop running these
>   tests as part of the CI builds.

I don't think that is a good idea. If we stop installing p4, the result
is that _nobody_ will ever run the tests at all. The tests, and by
extension git-p4 itself, would start to bitrot and we wouldn't notice
any kind of regressions at all anymore.

If we want to consider going down that route, I'd rather say we should
do it all or nothing: either we rip out git-p4 and the tests, or we
leave both of them in. I couldn't care less about git-p4 itself, so I
would not mind ripping it out altogether. But there may be users of this
script out there that do care, so I don't want to make that decision
unilaterally.

Patrick