Re: Current NEW review process saps developer motivation
Paul Wise <pabs@debian.org> writes:
> On Fri, 2022-08-26 at 11:58 +0100, Simon McVittie wrote:
>> For instance, take rust-glib-sys, a package of Rust bindings for the
>> GLib library, which is one of the libraries whose handling prompted
>> this thread.
> I feel like the right way to organise this upstream is for GLib itself
> to be building the bindings for itself (as Bastian Roucariès suggests).
Speaking as an upstream maintainer who historically has maintained
language bindings for a package together with that package (remctl), I can
tell you that this is a bad idea, I would tell my past self to never go
down this path, and that maintaining each language binding as a separate
upstream release is a superior technical solution.
This is unintuitive! I believed the opposite for many years! But it
turns out that maintaining language bindings as part of a single combined
source package is an incredibly difficult thing to attempt to do in the
upstream build system, and it is getting more difficult by the day. Each
language ecosystem has its own build system, and many of them are
undergoing rapid development. Each language now also has its own archive
to which build artifacts should be uploaded, often including pre-built
binary artifacts for major platforms, and doing this with a combined build
system from a single source package is quite difficult. All of the tools
are oriented around a single package building for a single language, with
all of the build system configuration for that language at the top level
of the package.
It's *possible* to do this. I have for years supported bindings for four
languages plus the C source in remctl. But it's hard; I have personally
spent multiple hours keeping this working, hours that were not spent on
the software itself or even on the build system but just on integration
problems between the various build systems mushed together into the same
release. There's very little payoff for this work and it's contributed to
not integrating some language bindings or other implementations, such as
Java. I haven't yet had the time to do this, but I plan on separating
remctl into five separate upstream releases for different languages.
This will also, ironically, help in Debian, since it will mean that the
remctl source package doesn't tie together language transitions for four
different languages.
remctl doesn't have the specific problem that Simon is pointing out with
the definition of what source code is, so it's unaffected by the point of
this thread. But I think it's important to note that upstreams do things
like this for good reasons, and undoing them may mean that someone spends
a bunch of time and effort, on an ongoing basis, working around problems
that upstream has wisely avoided and doesn't think should need to exist.
It's very hard to find motivation or volunteers for that kind of work!
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: