git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Ed Maste <emaste@freebsd.org>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Derrick Stolee" <stolee@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Albert Cui" <albertqcui@gmail.com>,
	"git mailing list" <git@vger.kernel.org>
Subject: Re: [PATCH v2] hooks: propose project configured hooks
Date: Thu, 15 Apr 2021 22:28:32 +0000	[thread overview]
Message-ID: <YHi+EJwmAmmU0Ar+@camp.crustytoothpaste.net> (raw)
In-Reply-To: <CAPyFy2Bf8t_2HggKG7LMY4u=9qBJ0-+xcx-gCv_kh7KYHg1-hw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

On 2021-04-15 at 20:37:54, Ed Maste wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2021-04-15 22:29 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 22:03 [PATCH] hooks: propose repository owner configured hooks Albert Cui via GitGitGadget
2021-03-18 22:29 ` Junio C Hamano
2021-03-18 23:45   ` Albert Cui
2021-03-19  1:28 ` brian m. carlson
2021-03-19 10:27 ` Ævar Arnfjörð Bjarmason
2021-04-06  0:35   ` Albert Cui
2021-04-07 22:47     ` Ævar Arnfjörð Bjarmason
2021-06-21 19:36       ` Jonathan Tan
2021-06-21 20:35         ` Ævar Arnfjörð Bjarmason
2021-03-26  1:43 ` [PATCH v2] hooks: propose project " Albert Cui via GitGitGadget
2021-03-29 23:20   ` Emily Shaffer
2021-04-01 20:02     ` Albert Cui
2021-03-30 15:24   ` Derrick Stolee
2021-04-05 22:45     ` Albert Cui
2021-04-05 23:09       ` Junio C Hamano
2021-04-05 23:40         ` Albert Cui
2021-04-06  0:13           ` Junio C Hamano
2021-04-06  0:27             ` Albert Cui
2021-04-06 23:15       ` brian m. carlson
2021-04-07  7:53         ` Ævar Arnfjörð Bjarmason
2021-04-07 13:09           ` Derrick Stolee
2021-04-07 18:40             ` Albert Cui
2021-04-07 20:02               ` Junio C Hamano
2021-04-07 22:23                 ` Ævar Arnfjörð Bjarmason
2021-04-15 16:52             ` Ed Maste
2021-04-15 19:41               ` Junio C Hamano
2021-04-15 20:37                 ` Ed Maste
2021-04-15 20:50                   ` Junio C Hamano
2021-04-15 22:28                   ` brian m. carlson [this message]
2021-04-02  9:59   ` Ævar Arnfjörð Bjarmason
2021-04-05 23:42     ` Albert Cui
2021-04-02 10:30   ` Ævar Arnfjörð Bjarmason
2021-04-03  0:58     ` Albert Cui
2021-04-24  1:38   ` [PATCH v3] " Albert Cui via GitGitGadget
2021-04-28  2:48     ` Junio C Hamano
2021-05-05 19:11     ` [PATCH v4] " Albert Cui via GitGitGadget
2021-06-03  3:31       ` Jonathan Tan
2021-06-03 20:16         ` Albert Cui
2021-06-03 22:10           ` Jonathan Tan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YHi+EJwmAmmU0Ar+@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=albertqcui@gmail.com \
    --cc=avarab@gmail.com \
    --cc=emaste@freebsd.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).