On Tue, Oct 15, 2024 at 02:13:45AM -0400, Eric Sunshine wrote:
> On Fri, Oct 11, 2024 at 4:01 PM brian m. carlson
> <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On 2024-10-11 at 18:09:14, Eric Sunshine wrote:
> > > I may be in the minority here, but I'm fairly negative on this entire
> > > patch series. As you say, supporting these old versions is effectively
> > > zero-cost, so how does this project benefit from these changes which
> > > potentially "break" Git for users on older platforms? I see no upside
> > > here. The cover letter provides no strong justification for
> > > (potentially) inconveniencing people; the argument about being able to
> > > utilize more modern Perl features is weak[1] at best and is not
> > > convincing.
> >
> > It is not effectively zero cost. When I want to write a patch, I must
> > make sure that it works on all the platforms we support, or my patch
> > will get reverted or not picked up. That means I have to expend
> > additional effort when adding features to look through the supported
> > versions of our dependencies and either conditionally check them or skip
> > the feature. Sometimes I have to rewrite that feature in a different
> > way, or ship a compatibility stub for a system that doesn't support it.
> >
> > I have actually spent a decent amount of work getting things to work
> > across older versions of software, both in Git and elsewhere. The more
> > we honour the policy we have already made and agreed upon, the less work
> > Git developers have to do to support adding and maintaining these
> > features.
>
> This attitude feels backward to me. It says that simplifying life for
> Git developers ("the few") is of paramount importance and that Git
> developers shouldn't care about inflicting pain/difficulty upon Git
> users ("the many"). This is especially disturbing considering the size
> of the Git user base.
>
> Instead, for every proposed change to Git, we should be asking
> ourselves what possible positive and negative impacts the change will
> have on *users*, and if the negatives outweigh the positives, then the
> change should be considered with a very wary eye indeed.
I agree with Eric that we should first and foremost consider the
user-impact of any changes we make to Git.
I think in reality there must be a balance between the two. We should
make reasonable decisions when presented a trade-off between supporting
users and making the lives of Git developers easier. For instance, if
there is some change we could make which would involve a manageable
amount of additional effort, but would somehow benefit the lives of many
users (e.g., supporting more versions of a dependency, improving
performance, fixing a widespread bug, etc.), then we should do that
thing.
On the other hand, if we are bending over backwards as developers to
support a small portion of the user-base (e.g., by maintaining some
ancient version of a dependency that is no longer reasonable because we
can assume that 99.99% of users have a newer version), then we should
consider our options and investigate. What are the ongoing costs to
maintain that minimum version? What features are we missing? How many
users would be affected by dropping support for that version, etc.?
I am not entirely sure whether the jump that brian is proposing is
reasonable or not. The current minimum version of Perl, for example, is
from 2003, but the proposed new minimum is from 2017. While the new
version is certainly not new, I am not sure how many users would be
affected by dragging the minimum version forward by some 14 years.
> > Certainly we cannot force people to upgrade, but we also don't have to
> > support those people. Git is an open-source project, and people are
> > welcome to make changes that they want to it without our approval, as
> > long as they comply with the license.
>
> Ditto what I said above about this attitude feeling backward.
>
> Moreover, as mentioned previously, it is not *this* project's
> responsibility to be forcing people to upgrade their insecure systems.
I do not think it is our responsibility to force people to upgrade their
systems. But OTOH we should not bend over backwards here either to
support ancient versions of dependencies when there are compelling
reasons *not* to use those versions.
I agree with your earlier comment that there is a balance between
thinking about this abstractly and applying it to the real world. But at
some point we have to throw our hands up and stop spending effort
supporting ancient/insecure versions of dependencies.
> > There's also discussion about adding Rust to Git. Assuming we do that,
> > we're going to have to work with Rust's requirements for OSes, which
> > usually follow major supported distros (for Linux) or upstream's policy
> > (for the BSDs). So we're going to have the same problem in that people
> > are actually going to have to upgrade to a supported OS, except it's
> > really not going to be optional because the code simply won't compile.
> > We might as well get used to doing that now.
>
> "Assuming we do that" is the key phrase.
Indeed. Let's not worry about it for now.
Thanks,
Taylor
