Re: [PATCH] fsmonitor: eliminate call to deprecated FSEventStream function

From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Victoria Dye <vdye@github.com>
Cc: "Jeff Hostetler" <git@jeffhostetler.com>,
	"Jeff Hostetler via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Stefan Sundin" <git@stefansundin.com>,
	"Bagas Sanjaya" <bagasdotme@gmail.com>,
	"René Scharfe" <l.s.r@web.de>,
	"Jeff Hostetler" <jeffhostetler@github.com>,
	"Eric DeCosta" <edecosta@mathworks.com>
Subject: Re: [PATCH] fsmonitor: eliminate call to deprecated FSEventStream function
Date: Fri, 02 Dec 2022 21:34:56 +0100	[thread overview]
Message-ID: <221202.86359xfs5c.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <4711d955-02b2-f599-7f89-b442dd0b6215@github.com>

On Fri, Dec 02 2022, Victoria Dye wrote:

> Ævar Arnfjörð Bjarmason wrote:
>> 
>> On Fri, Dec 02 2022, Jeff Hostetler wrote:
>> 
>>> On 12/2/22 1:02 PM, Ævar Arnfjörð Bjarmason wrote:
>>> So, based on the ages of those two Apple releases, I'd like to think
>>> that we're fine just switching over and not having to ifdef-up the
>>> config.mak.uname.  (If it were a more recent change in the OS, then
>>> yeah the answer would be different.)
>>>
>>> Thoughts ???
>> 
>> That seems reasonable to me, but it came out in 2001, and we'd be moving
>> the dependency to a 2007 version.
>> 
>> Is that OK? No idea, I don't know how old of an OSX version people
>> reasonably run & want to compile Git on.
>
> I appreciate the diligence, but I don't think continuing this discussion
> will be productive use anyone's time.

It's quite useful in general to know the lower boundaries of what
versions of OS's are supported at all.

For example, we support non-GNU iconv implementations that have some
weird edge cases. As the config.mak.uname shows OLD_ICONV is required
for OSX 10.4 or later. If we know we'd like to draw a hard line at OSX
10.5 we can scratch it off the list of platforms we care about.

Anyway, that larger topic aside. All I'm suggesting here is that the
proposed patch seems to at least soft-deprecate versions of OSX we
supported before. Maybe that's fine, but the commit message didn't get
across whether that was considered, part of the plan etc.

> Apple doesn't seem to provide official end-of-life dates for their OS
> versions, but we can extrapolate from the list of obsolete hardware [1] that
> it likely doesn't support OS versions older than 2014; that's corroborated
> by their official set of release notes going only as far back as 10.14,
> released in 2018). In other words, I think it's safe to say that a version
> supplanted in 2009 is old enough to not warrant Git support.

I wish :)

It may happen to be true for OSX, and I suspect that OS has a relatively
aggressive timeline as OS's go, as opposed to AIX or something, which
people tend to run long past EOL.

But our support for OS versions has neither historically or currently
mirrored EOL dates.

A lot of those are *very* aggressive, e.g. FreeBSD's releases go EOL
around a year or so after release, and we certainly support building on
way older FreeBSD than that:
https://www.freebsd.org/security/unsupported/

For some other in-tree software we're >10 yrs past EOL:
https://lore.kernel.org/git/221124.865yf4plw1.gmgdl@evledraar.gmail.com/

In general I think OS EOL's are most useful as an indicator of what
versions of that OS you'd want to run in some Internet-connected
high-vulnerability scenario.

But git gets ported and backported to a long tail of systems way beyond
that. Eventually we do need to let got, but we've generally drawn the
line at some fuzzy notion of when users don't care anymore, along with
whether it's worth the effort to find out.