On Tue, Oct 15, 2024 at 7:57 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. > 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
