Re: [PATCH] git-compat-util.h: GCC deprecated only takes a message in GCC 4.5+

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Oct 03 2022, brian m. carlson wrote:

> [[PGP Signed Part:Undecided]]
> On 2022-10-03 at 21:23:18, Aleajndro R Sedeño wrote:
>> From: Alejandro R. Sedeño <asedeno@mit.edu>
>> 
>> Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
>> Signed-off-by: Alejandro R Sedeño <asedeno@google.com>
>
> It might be helpful to explain what system you're targeting when you see
> this.  CentOS 7 has GCC 4.8, and I'm not aware of any systems with an
> older compiler receiving publicly available updates still.  We've fairly
> recently only been testing and targeting GCC 4.8 for that reason.

We've had some friendly disagreements in the past about what our policy
should be for supporting such "EOL" software[1][2]. I'm not replying to
repeat any of that discussion, just noting it for context and that I'm
*not* raising that point here :)

What I do want to say to provide others context is that I think you're
conflating your own views & project policy here, e.g. if you run:

	git log --grep='gcc [0-9]' -i

You can see recent patches that have been accepted where we're adjusting
things for GCC's older than 4.8, so it's not the case that we're "only
[...] targeting GCC [versions >=]4.8".

I think you might be mixing up the oldest software we're taking patches
for with the oldest version we run in CI, although I didn't find if we
actually run GCC 4.8 in CI anymore. It appears to have been used with
ubuntu-18.04, but as of ef465848312 (ci: update 'static-analysis' to
Ubuntu 22.04, 2022-08-23) I don't think we pin that version anywhere.

Anyway, however us "in the know" work out what versions we support I
don't want someone to search the ML archive & come to the conclusion
that a patch for a compiler older than whetever IBM's bundling wouldn't
be welcome.

I think it's fair to say that we've taken e.g. major IBM/RedHat releases
into account in the past, e.g. for what libcurl version(s) to support,
per [2]. But we've never considered distro releases to be a hard cut-off
for support.

The actual "policy" has been some fuzzy combination of:

 * What OS's / distro's are used by anyone, for which e.g. RHEL releases
   are a very useful heuristic, and on some platforms (e.g. Windows?)
   vendor EOLs matter more than on others.

 * How much of a hassle older software or a platform is to support,
   e.g. this project has usually happily taken trivial patches such as
   this one, but in the case of PCRE we moved more aggressively from
   PCRE v1 to v2, as supporting both required duplicate code (see
   7599730b7e2 (Remove support for v1 of the PCRE library, 2021-01-24)).

 * That someone cares or sends in patches for. I know of various current
   breakages with software that's "supported" (bits of Solaris, AIX and
   HP/UX userland come to mind), but nobody's cared enough to fix it (in
   those cases, many/all of the "official packages" simply use GNU
   userland/libraries instead)

1. https://lore.kernel.org/git/YPimBp+TkaJ9ycuM@camp.crustytoothpaste.net/
2. https://lore.kernel.org/git/YPimBp+TkaJ9ycuM@camp.crustytoothpaste.net/