Re: [PATCH 00/13] Update versions of libcurl and Perlg

From: Alejandro R. Sedeño <asedeno@mit.edu>
Date: Oct 16, 2024, 02:00 UTC
Message-ID: <CAOO-Oz0t8V28P7VEACAu69_dD47ZuPPazN9vy_c1dLCeAU5N_Q@mail.gmail.com>
In-Reply-To: <Zw8BMEYHaH2ImMmY@tapette.crustytoothpaste.net>

On Tue, Oct 15, 2024 at 7:57 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 16 quoted lines

> Nobody, outside of the FreeBSD maintainer, has even bothered to set up
> CI for a platform other than the three major ones.  The patches to fix
> SunOS 5.10 also don't include any tests or CI.  I don't think it's
> reasonable for us to go out of our way to support these systems if
> nobody using those platforms has bothered to provide even the most
> rudimentary check that they work.  How can we expect developers who
> don't use these systems to even know if they work without some basic
> tests, even if it's for only one architecture, especially given that in
> many cases it involves adding just three lines to the workflow file?
>
> I think the answer is that we can't.  Since we don't have anyone who has
> demonstrated that there's basic interest in helping the contributors
> support their platform by setting up tests or volunteering to be the
> maintainer, we can't support those platforms specifically and we're
> essentially left with just honouring the policy that we've set, which is
> what I'm doing here.

The machine I use to build for SunOS takes, let's be generous and say an hour to build git from a fresh checkout. If I'm iterating on trying to fix something, run make, and see that it's building daemon.o, I know I've got another hour or so before I find out if my change worked, and maybe discover what the *next* new issue is. There are faster SunOS machines, but not the one I happen to have available. You would not want this machine in any sort of CI system. That said, until sometime this summer, I was building every release of git on that machine within days, often hours, of it being tagged, for *nearly 15 years*. If something broke, I'd fix it, test the build (which could take hours if I had to iterate), and submit a patch. You can find them in the logs. It was, fortunately, not that often, which is a testament to git remaining portable. Thank you all for that.

As I mentioned in my report regarding the SunOS build, I'm personally ready to abandon that particular use of my time, though if it's fixed, it'll go back onto my semi-automated build scripts for git releases, and I'll continue to submit patches as needed. It's not a CI, and no, I don't have notifications for and don't build RCs, but it's something.

Show 12 quoted lines

> It's also reasonably easy to build new versions of Perl with things like
> perlbrew or other toolchain tools, and those are the common suggestion
> that people use when they have a toolchain that's out of date.  I've
> worked at a company which did some very unusual things with Perl
> (specifically compiling it to C for performance) and who I think had at
> one point used the oldest Perl I'm aware of being used at a Perl shop
> (at the time, 5.6) for major development, and I know they're now using a
> modern Perl and wouldn't be affected.  In fact, people doing Perl
> development professionally are overwhelmingly using very modern Perl, so
> the practical implication is that we only need to consider the distro
> Perl here, since everyone will be using something at least that new (or
> will have an easy way to build such a version).

Building a new perl is easy. Telling the system-controlled apache mod_perl to trust me and use my perl, less easy. (gitweb.perl.)

-Alejandro