| Message ID | ee5d836b779087890acdad061ef6995642942479.1721740612.git.ps@pks.im (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Improvements for Perforce tests | expand |
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. Ciao, Johannes
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
Patrick Steinhardt <ps@pks.im> writes: > 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. Yup, I was actually interpreting Dscho's message as advocating the removal of "git p4". Such a move would certainly force people who do care about it to come out. It is up to them to volunteer to help maintaining "git p4". This may be a good example to discuss "support policy" not on niche platforms but on niche features (Emily Cc'ed). Thanks.
On Wed, Jul 24, 2024 at 09:10:54AM -0700, Junio C Hamano wrote: > Patrick Steinhardt <ps@pks.im> writes: > > > 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. > > Yup, I was actually interpreting Dscho's message as advocating the > removal of "git p4". Such a move would certainly force people who > do care about it to come out. It is up to them to volunteer to help > maintaining "git p4". > > This may be a good example to discuss "support policy" not on niche > platforms but on niche features (Emily Cc'ed). As said, I wouldn't mind dropping support for `git p4` altogether. That is a much bigger discussion though, and I'm not sure whether we should just drop it at a "random" point in time without something like a grace period where people can chime in and express their wish to help out with the maintenance of it. In other words, we should probably deprecate it properly and announce our intent to deprecate it. Both our release notes and "Documentation/BreakingChanges.txt" could we viable ways to do that. And while we haven't yet decided to rip out support for Perforce, I think that the proposed patch series is somewhat sensible. I honestly really only care about marking the patches as leak-free to help my bigger goal of making the whole test suite leak-free. The other patches that make the tests compatible with newer versions of Perforce aren't all that important, but at least they help to make those tests a bit more accessible to interested folks. Patrick
On 24/07/23 04:05PM, 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 s/executablesas/executables as/ > macOS archives directly and would thus require more work. Out of curiousity, for Perforce is there a defined range of versions that the Git project supports? I guess I'm trying to figure if it even makes sense to support older version of Perforce in our tests. > > Signed-off-by: Patrick Steinhardt <ps@pks.im> > --- > ci/install-dependencies.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh > index 6ec0f85972..b59fd7c1fd 100755 > --- a/ci/install-dependencies.sh > +++ b/ci/install-dependencies.sh > @@ -7,7 +7,7 @@ > > begin_group "Install dependencies" > > -P4WHENCE=https://cdist2.perforce.com/perforce/r21.2 > +P4WHENCE=https://cdist2.perforce.com/perforce/r23.2 > LFSWHENCE=https://github.com/github/git-lfs/releases/download/v$LINUX_GIT_LFS_VERSION > JGITWHENCE=https://repo.eclipse.org/content/groups/releases//org/eclipse/jgit/org.eclipse.jgit.pgm/6.8.0.202311291450-r/org.eclipse.jgit.pgm-6.8.0.202311291450-r.sh > > -- > 2.46.0.rc1.dirty >
On Tue, Jul 30, 2024 at 05:48:38PM -0500, Justin Tobler wrote: > On 24/07/23 04:05PM, 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 > > s/executablesas/executables as/ > > > macOS archives directly and would thus require more work. > > Out of curiousity, for Perforce is there a defined range of versions > that the Git project supports? I guess I'm trying to figure if it even > makes sense to support older version of Perforce in our tests. Not that I'd know of. Which is why I'm being doubly cautious to deprecate support for older versions :) Not that many people would care, but still, I don't want to make such decisions without having any clue at all about the surrounding Perforce ecosystem. Patrick
diff --git a/ci/install-dependencies.sh b/ci/install-dependencies.sh index 6ec0f85972..b59fd7c1fd 100755 --- a/ci/install-dependencies.sh +++ b/ci/install-dependencies.sh @@ -7,7 +7,7 @@ begin_group "Install dependencies" -P4WHENCE=https://cdist2.perforce.com/perforce/r21.2 +P4WHENCE=https://cdist2.perforce.com/perforce/r23.2 LFSWHENCE=https://github.com/github/git-lfs/releases/download/v$LINUX_GIT_LFS_VERSION JGITWHENCE=https://repo.eclipse.org/content/groups/releases//org/eclipse/jgit/org.eclipse.jgit.pgm/6.8.0.202311291450-r/org.eclipse.jgit.pgm-6.8.0.202311291450-r.sh
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. Signed-off-by: Patrick Steinhardt <ps@pks.im> --- ci/install-dependencies.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)