On Wednesday, July 31, 2024 1:20 PM, Emily Shaffer wrote:
>On Tue, Jul 30, 2024 at 3:40 PM <rsbecker@xxxxxxxxxxxxx> wrote:
>>
>> 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).
>
>I can understand the need for something that speaks the Git protocol and enables
>developers to develop. However, I guess I don't understand the need for that to be
>the latest version of Git, or even the C Git client to begin with. The protocol changes
>from time to time, but we're very careful - even compared to how careful we are
>about scripting compatibility on the C Git CLI - to provide backwards support for
>clients speaking older Git protocol. Why does it matter to NonStop, then, which
>client is being used or if it's sparkling brand new?
>
>Git is a central component to lots of things, you're right - at Google it's incredibly
>important, and our serving infrastructure is based around JGit, not C Git. It's
>integrated into lots of development tools like IDEs and notebooks and design
>software, and most of those use JGit or EGit or libgit2 or something.
>
>My point isn't "just fork Git" or "just use a different library", my point is "are you
>sure it's correct to worry about the Git client more than you worry about the Git
>protocol?"
>
>Anyway, I think we've gone pretty far afield. Let me resummarize my understanding
>of your thoughts on this patch so far:
>
>* Given the constraints that currently apply to NonStop, based on this doc, you are
>planning to run daily (or at least more frequent than
>weekly) tests against `next`, write detailed reports to the list as soon as you discover
>a problem (that is, before the problem series hits `master`, in most cases), and
>provide fixes yourself or work closely to test fixes others write in response to those
>reports.
>* Also given the constraints that currently apply to NonStop, a hard age limit on
>library dependencies would disqualify NonStop from explicit support assistance.
>
>v4 of this series drops the hard age limit on library dependencies. As written
>currently, is it still objectionable to you?
Staying on the latest git is not a requirement, although highly desirable. Any CVEs that impact
git would have to be addressed in whatever fork is done, if that becomes necessary,
which I assume we have to plan for. This is a bit of a regression, as we had a fork back
in 2016 when the NonStop code was not fully integrated into C git - changing that was my
primary contribution, with help from Jojo on our team. I would not be happy about
reverting to the old manual process of applying patches by hand - git merge was not
usually sufficient in those days - plus having to add separate tests that we had
difficulty certifying. We also then have to publish the changes as part of GPL v2.0,
which we did, and finally stopped having to do sharing the standard code base.
As far as JGit, it is much less functional and does not build or run on NonStop due to
dependencies that are also problematic (I may be wrong but I think it requires Java 17
for that, which is not yet available, nor will ever be on ia64). We used to recommend
using JGit while the C git code was not fully reconciled with our variances, but JGit stopped
working correctly around 2022 and I was unable to get any support to change that, at least
at that time. That and the user community really likes having "git help" - no such animal
is in JGit, and some of our base does not have direct Internet access where git is used
(high security environments). The reason we went with C git is because it actually builds
and tests correctly (with minor irrelevant exceptions in t9001 that no one on the boxes
care about). It is the only CLI client that works properly, so losing it permanently (as in
being stuck at an old version) would be undesirable. There is no GUI on NonStop, so
no options there.
To the actual question: I am actually fine (and happy) with dropping the age limit - to me
this is arbitrary without an official LTS designation and does not address the fundamental
compatibility issues that are unrelated to time. As above, the highest priority requirement
for me is being able to continue to apply CVE-related patches to whatever code is ported
and maintained. My own nightmare scenario is a git CVE (high) coming out that is only
fixed in a version of git that I cannot build/deploy. That would result in the community
having to drop git on a mandatory basis (serious concern). Compliance rules are typically
to apply High CVE patches within a fixed timeframe, typically 30 days.
--Randall
