git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Patrick Steinhardt <ps@pks.im>
Date
Jul 30, 2024, 06:00 UTC
Message-ID
<ZqiBYK2HwLRk3Kqn@tanuki>
In-Reply-To
<xmqqmsm6ydm9.fsf@gitster.g>
On Wed, Jul 24, 2024 at 09:10:54AM -0700, Junio C Hamano wrote:
Show 21 quoted lines
> 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
Previous: Junio C HamanoNext: Justin Tobler
Message 9 of 19 in “Improvements for Perforce tests”
  1. 0/3 Improvements for Perforce testsPatrick Steinhardt, Jul 23, 2024
  2. 1/3 t98xx: fix Perforce tests with p4d r23 and newerPatrick Steinhardt, Jul 23, 2024
  3. Justin ToblerJul 30, 2024
  4. Patrick SteinhardtJul 31, 2024
  5. 2/3 ci: update Perforce version to r23.2Patrick Steinhardt, Jul 23, 2024
  6. Johannes SchindelinJul 24, 2024
  7. Patrick SteinhardtJul 24, 2024
  8. Junio C HamanoJul 24, 2024
  9. Patrick SteinhardtJul 30, 2024
  10. Justin ToblerJul 30, 2024
  11. Patrick SteinhardtJul 31, 2024
  12. 3/3 t98xx: mark Perforce tests as memory-leak freePatrick Steinhardt, Jul 23, 2024
  13. Justin ToblerJul 30, 2024
  14. 0/3 Improvements for Perforce testsPatrick Steinhardt, Jul 31, 2024
  15. 1/3 t98xx: fix Perforce tests with p4d r23 and newerPatrick Steinhardt, Jul 31, 2024
  16. 2/3 ci: update Perforce version to r23.2Patrick Steinhardt, Jul 31, 2024
  17. 3/3 t98xx: mark Perforce tests as memory-leak freePatrick Steinhardt, Jul 31, 2024
  18. Justin ToblerJul 31, 2024
  19. Junio C HamanoJul 31, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.