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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-04-15 at 20:37:54, Ed Maste wrote:
> On Thu, 15 Apr 2021 at 15:41, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >
> > Ed Maste <emaste@xxxxxxxxxxx> writes:
> >
> > > On Thu, 18 Mar 2021 at 21:29, brian m. carlson
> > > <sandals@xxxxxxxxxxxxxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux