On Tuesday, July 30, 2024 5:25 PM, Junio C Hamano wrote:
>Emily Shaffer <nasamuffin@xxxxxxxxxx> writes:
>
>>> > +Note that this document is about maintaining existing support for
>>> > +a platform that has generally worked in the past; for adding
>>> > +support to a platform which doesn't generally work with Git, the
>>> > +stakeholders for that platform are expected to do the bulk of that
>>> > +work themselves. We will consider such patches if they don't make
>>> > +life harder for other supported platforms, and you may well find a
>>> > +contributor interested in working on that support, but the Git community as a
>whole doesn't feel an obligation to perform such work.
>>>
>>> The part after "... and you may well find" reads a bit muddy. I
>>> couldn't tell if it is talking about the initial port, or continued
>>> support, or both.
>>> ...
>> I like that message, but what I was trying to say with that sentence
>> was "if you get lucky, some volunteer might want to help you with the
>> initial port".
>
>FWIW, I do not quite like that message; I agree that it would be good to tell them
>that they may not entirely be on their own, if they ask nicely, but no promises ;-).
>
>> It seems worth at least pointing out that that would be the exception,
>> not the rule, but I probably already do that well enough with the
>> previous sentence ("the platform stakeholders are expected to do the
>> bulk of the work"). Let me reword the last sentence, then:
>>
>> "We will consider patches that port a new platform if they don't make
>> life harder for other support platforms or for Git contributors. Some
>> Git contributors may volunteer to help with the initial or continued
>> support, but that is not a given. Support work which is too intrusive
>> or difficult for the project to maintain may still not be accepted."
>
>OK, at least that clarifies the point I was puzzled about.
Pulling in a paragraph from earlier on:
> >This is hard to understand and I wonder if we can clarify. I get what you want to
> >say: suppose we rely on library X that is getting regular feature and security updates
> >in reasonable cadence, say every 6 months there is an upstream release of library X,
> >but a niche platform has ported the library only once long time ago, and hasn't
> >updated it ever since. Now the Git project may consider helping a port to such a
> >platform if the initial port of library X was 8 years ago, but will not if it was 12 years
> >ago.
This is a tough one. If a library is actively maintained and subject to security fixes, OS providers
like the NonStop team will, as a general practice, provide security fixes. It might not be as frequent
as I would personally like, but a 12 year old library with security holes would not really survive
to be a problem. Others, where stability is well established, let's say iconv (a bad example, I
know), will not get the attention to have it fixed until there is a customer reported issue (or
me stomping up and down a lot). I think that the 8 vs. 12 year difference is fairly arbitrary
and might not be appropriate.
In some situations, if functionality is provided by an existing library, and is augmented, the
platform maintainer could provide another compatibility component to supply the capabilities.
It would be a strain, and in some cases impractical, but might be possible.
I think a bigger issue is where there are dependencies introduced that are either not
generally portable or depend on infrastructure that is also not portable. There is a long list
of projects that are all interrelated and specific to the Linux space - all of which scare me
as adding any of those would exclude git from platforms where those are not possible to
port. Rust and GO, which have difficult-to-port code generators are two (Rust itself is
problematic as one needs consent from the Rust maintainers to even add a platform, if you
read deeply enough into the "porting" documentation). Products that must use gcc or
clang with unavoidable syntax features that are not supported by ANSI C compilers and
libraries are also things that keep me up at night because there really is no way to work
around those. In some cases, some JSON and YAML libraries ended up having to be forked
and are now (not happily but) maintained by my team - not a git issue.
Ultimately, my goal as a platform maintainer is to be able to sleep at night without
worrying that git support will be completely turned off by a feature that uses some
incompatible library as part of the git core. Git LFS has had to be put aside because of
the GO dependency, but because LFS is not core git, it is survivable. I think that if such
incompatibilities are introduced, there should be a mechanism to isolate them, and
exclude them from the git core.
Please remember that git is now a central component to a vast number of organizations
that depend on it for serving features to customers. To be blunt, it is not 2007 anymore,
and git exists almost everywhere of significance. That point needs to be stressed. The
pervasiveness of git has dramatically increased over the past 5 years, more than I think
most people realized. On NonStop, 5 years ago, there was perhaps <10% participation.
If you look now, the number has gone up, probably to somewhere around 60-70%. We
cannot ignore that - I sincerely hope not anyway. There are even companies that will
look at your GitHub footprint exclusively as your definitive resume for hiring purposes - I
actually think that is really interesting and do not want to put that at risk either (although
admittedly entirely beside the point of this thread).
With Respect,
Randall
