On Fri, Aug 16, 2024 at 5:38 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > On 2024-08-16 at 11:39:24, Patrick Steinhardt wrote: > > That to me raises an important question: who is the one fixing breakage? > > Hypothetically speaking, if I continue with my refactoring spree to drop > > `the_repository`, do I also have to fix the Rust bindings that I break > > as a consequence? I share Patrick's concern, and it's one of the reasons I posed the question in the first place about why these Rust bindings are being proposed for Git's "contrib/" rather than as a standalone project. > If we're testing it in CI, then you are responsible for not breaking it, > even if you don't use it, just as I am responsible for not breaking > Windows, even though I don't use that platform. That's typically been > the policy here and elsewhere. This is an apples-and-oranges comparison, isn't it? Although the majority of Git developers may be Unix folk, Git itself has a reasonably large Windows user population, so breaking it on Windows carries some potentially real consequences (i.e. hurting the immediate user community). On the other hand, the Rust bindings under discussion are (1) as yet effectively hypothetical, (2) will almost certainly be relied upon by a tiny number of other projects, and (3) impact only developers, not users, of Git-related tooling. As such, it seems far too early to be placing the onus on *all* Git developers to have to worry about the Rust bindings. If, at some point in the future, the Rust bindings gain significance or become indispensable to the Git project itself, then the onus might well be warranted, but at this early stage, it seems unreasonable. A more friendly approach to the overall Git developer community would be for those interested in the Rust bindings to maintain them. (The case with the CMake project files is similar. In the end, the people interested in utilizing them took on the responsibility of maintaining them.)
