Re: [PATCH v2] hooks: propose project configured hooks

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 15, 2021, 22:28 UTC
Message-ID: <YHi+EJwmAmmU0Ar+@camp.crustytoothpaste.net>
In-Reply-To: <CAPyFy2Bf8t_2HggKG7LMY4u=9qBJ0-+xcx-gCv_kh7KYHg1-hw@mail.gmail.com>

On 2021-04-15 at 20:37:54, Ed Maste wrote:

Show 29 quoted lines

> On Thu, 15 Apr 2021 at 15:41, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Ed Maste <emaste@freebsd.org> writes:
> >
> > > On Thu, 18 Mar 2021 at 21:29, brian m. carlson
> > > <sandals@crustytoothpaste.net> wrote:
> > >> > +* Works across Windows/Linux/macOS
> > >>
> > >> Git supports other platforms as well.
> > >
> > > In particular, FreeBSD is an example of a platform that is not in the
> > > above list, but included in Git's CI. Is there an explicit list of
> > > supported platforms (and perhaps a notion of support tiers)?
> >
> > It is not like there is a Git company who employs developers to
> > support certain platforms.  This is the mailing list for the open
> > source development community for Git, and Developers come and leave
> > over time [*].
> 
> I'm sorry that my query wasn't clear; I have no expectation of Git
> volunteers providing support (in the commercial sense) for any
> particular platform.
> 
> What I am interested in is the Git community's expectations around
> platform support, with respect to new features, changes that break one
> or more platforms, and similar. I submitted portability improvements
> for FreeBSD, and certainly expected that if a change introduced a
> regression on one of Linux, Windows, or macOS it would not be
> accepted.

We don't have a fixed set of supported tiers like, e.g. Rust. We have CI for some platforms, and we have people who routinely run Git, including RCs and development branches like next, on various platforms and report back. If something breaks CI, obviously you are expected to fix it, and if someone says you broke their platform, you are expected to unbreak it (for open source systems like FreeBSD where you can spin up a VM) or at least work with the interested party to unbreak it.

Otherwise, support is best effort. While I don't use FreeBSD, I'm reasonably aware of what functionality it does and doesn't support, and I'll try to avoid inserting Linuxisms into our code. Similarly, sometimes people ask us to support some obsolete OS which doesn't have security support (e.g., CentOS 5), and sometimes we accept patches for that. (I am personally opposed to supporting systems without security support, but other developers feel differently.) We will generally accept reasonable portability patches for most OSes with little fanfare.

Developers often will CC maintainers of specific OSes (most often, Windows) if they want to make sure that the patches being proposed meet that platform's needs.

I have broken macOS in an edge case in the past due to its case-insensitive file system behavior, and nobody noticed until the release. Since our testsuite lacked a test for that case and nobody running macOS pre-releases on a regular basis hit that case (two files in the repository differing only in case) and complained, it got shipped broken, although we did promptly fix it.

That's the kind of support level we have. Basically, we do our best, and if there's a problem and someone shouts, we'll fix it.

-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US