On 2024.09.04 11:33, Junio C Hamano wrote: > Calvin Wan <calvinwan@xxxxxxxxxx> writes: > > > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> ... > >> Debian stable is the version that most projects who have defined > >> lifespans track, so it's also what we should track. According to my > >> recommended approach, that would be 1.63. > > > > ... I also don't think reinventing the wheel with > > our own implementation makes sense in this case, > > I do agree that we would want to avoid that. > > > and even if Debian were > > to upgrade stable to a higher version today, we would still need to > > support oldstable for another year. > > I doubt that part, though. As long as the rust binding stays an > optional code, as long as we are supported by the "current" system, > we would still have enough audience to matter. > > What's the primary objective of this effort, by the way? > > Is it "we need to access the guts of Git implementation from Rust"? > Or does it merely serve as an example application to have Rust > bindings, a good goal to have to give us an incentive to clean up > the subsystem interactions in our code? For us at $DAYJOB, it's "we need to access the guts of Git from Rust". > If it is the former, we cannot reasonably achieve that goal until > some form of standardized foreign function interface becomes > available to wide audience. If it is the latter, on the other hand, > it does not have to be Rust---if the version of Rust that is > distirbuted to the mainstream users is not yet ready to be used in > such a way, we could pick another goal (like, "Can we clean-up the > interface cgit uses to call into us, so that the parts used by them > look more like a proper library?"). > > Thanks. I think brian already addressed your point about having a standard FFI, but if there's anything that still needs clarification please let me know.
