git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org, Emily Shaffer <nasamuffin@google.com>
Subject: Re: [PATCH 2/3] ci: update Perforce version to r23.2
Date: Tue, 30 Jul 2024 08:00:00 +0200	[thread overview]
Message-ID: <ZqiBYK2HwLRk3Kqn@tanuki> (raw)
In-Reply-To: <xmqqmsm6ydm9.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-07-30  6:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 14:05 [PATCH 0/3] Improvements for Perforce tests Patrick Steinhardt
2024-07-23 14:05 ` [PATCH 1/3] t98xx: fix Perforce tests with p4d r23 and newer Patrick Steinhardt
2024-07-30 22:41   ` Justin Tobler
2024-07-31 10:28     ` Patrick Steinhardt
2024-07-23 14:05 ` [PATCH 2/3] ci: update Perforce version to r23.2 Patrick Steinhardt
2024-07-24  8:39   ` Johannes Schindelin
2024-07-24  9:01     ` Patrick Steinhardt
2024-07-24 16:10       ` Junio C Hamano
2024-07-30  6:00         ` Patrick Steinhardt [this message]
2024-07-30 22:48   ` Justin Tobler
2024-07-31 10:15     ` Patrick Steinhardt
2024-07-23 14:05 ` [PATCH 3/3] t98xx: mark Perforce tests as memory-leak free Patrick Steinhardt
2024-07-30 22:54   ` Justin Tobler
2024-07-31 10:37 ` [PATCH v2 0/3] Improvements for Perforce tests Patrick Steinhardt
2024-07-31 10:37   ` [PATCH v2 1/3] t98xx: fix Perforce tests with p4d r23 and newer Patrick Steinhardt
2024-07-31 10:37   ` [PATCH v2 2/3] ci: update Perforce version to r23.2 Patrick Steinhardt
2024-07-31 10:37   ` [PATCH v2 3/3] t98xx: mark Perforce tests as memory-leak free Patrick Steinhardt
2024-07-31 20:50   ` [PATCH v2 0/3] Improvements for Perforce tests Justin Tobler
2024-07-31 22:32     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZqiBYK2HwLRk3Kqn@tanuki \
    --to=ps@pks.im \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nasamuffin@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).