Re: Current NEW review process saps developer motivation
On Fri, 26 Aug 2022 at 09:09:25 +0200, Jonas Smedegaard wrote:
> The way I see it, the process is clear: provide *source* to build from.
>
> If there is "source" built from another source, then that other source
> is the true source.
I hope you agree that we are doing this in order to get some desirable
properties of building from source, rather than because the rules are
the rules and we follow them without any critical thinking?
I feel strongly that if our policies are not meeting their goals of
advancing Free Software and providing benefit to our users, then we
should reconsider whether they are the right policies.
I don't think building from the least-derived form is always the right
thing to do. 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. It contains a description of the GLib library's
API/ABI, basically the Rust equivalent of a C header file. It could
have been written by hand, but that would be tedious and error-prone,
so instead its upstream maintainers chose to machine-generate the API/ABI
description from GLib. The thing that would be closest to "true source"
would presumably be to redo that machine-generation process, from first
principles, at build-time.
However, if we did that by using the version of GLib in the archive,
then the API of the Rust bindings would not be entirely determined
by the content of the rust-glib-sys package as tracked by its version
number, which seems really bad for library stability: you could take
the same version number, build it twice in different environments, and
get two different APIs! rust-glib-sys could have a minimum supported
GLib version, but then would unpredictably have or not have additional
APIs beyond the ones present in that version, depending on the version
of GLib that happened to be installed at build-time.
If the generation process is not always 100% backwards-compatible, which
I suspect it is not, then that just makes it worse: now you can't even
rely on a rebuilt version of rust-glib-sys being compatible with the
version from before it was rebuilt! If the API description is curated by
the upstream maintainers, then they have an opportunity to detect
incompatible changes and release them with a suitably changed version
number, or even as a separate parallel-installable version, so that
dependent projects can migrate at their own pace; but that can't happen
if the API description is generated at build time.
Or, the other way to generate rust-glib-sys from "true source" would be
to bundle a complete copy of GLib source code in it, and generate the
API description from that (which, as an implementation detail of the way
it was done, requires compiling GLib and then introspecting the binary,
and cannot be done while cross-compiling). This is not great from either
a technical or social point of view. From a technical point of view,
rust-glib-sys' build system would have to be taught to compile GLib,
which uses a totally different build system (Meson rather then Cargo)
and is quite a large library, resulting in a much slower and less
reliable build. From a social point of view, again, GLib is not small,
and I don't think either the rust-glib-sys maintainer or the ftp team
would welcome the requirement to review another complete copy of GLib,
transcribe all its potential copyright holders into debian/copyright
and check that it has been done, and so on.
Generating the API description in a way that does not arbitrarily vary
based on installed software might also require bundling and building a
complete copy of GObject-Introspection, which, again, is not small.
All of this is for a functional interface description, analogous to a C
header file without comments. In other contexts elsewhere in the project,
we rely on the functional parts of an interface description as not being
strongly protected by copyright (after all, the whole GNU system started
as a compatible implementation of the interfaces provided by 1980s Unix,
and we have code in Debian that is a compatible reimplementation of
Windows interfaces), and we strongly limit the modifications that we
are prepared to make to interface descriptions (because Free Software
is important to us, we require the technical and legal ability to make
modifications, but because API/ABI compatibility is also important to us,
we treat many of those modifications as something that we will refuse
to do unless there is a really compelling reason).
More generally, I don't think it's always useful to talk about "the"
source or "the" preferred form for modification, as though there is only
one. I think it would be more appropriate to consider whether the form
in which some software is provided is suitable for exercising your Free
Software rights (as described in the FSF's "four essential freedoms",
for example) within the scope of whatever package we're talking about at
the time, or whether it's unsuitable for that use. If it's suitable, then
it's source, or close enough; if it's unsuitable, then that needs fixing.
If we insist on a particularly puritanical view of what is source and
what is the preferred form for modification, then I think there is a
significant risk of producing a distribution which is unquestionably Free
Software, but either is missing useful Free software because it would be
too hard to get that software into a form that meets our self-imposed
policies, or can only contain that software as a result of individual
developers putting a heroic amount of effort into meeting those policies -
particularly if we always go back to the "true source" and generate from
there every time (which I will note that the ftp team specifically do not
insist on unless there is a technical reason to do so, they merely require
source to be *available*).
If we require contributors to do a considerable amount of work that
does not advance the project's goals, at best that's a waste of our most
limited resource (developers' time and motivation), and at worst it's a
recipe for burned-out contributors, which we absolutely should not want,
both because we're a community that cares about the well-being of our
contributors (or at least I hope we are!) and because even from a purely
amoral/utilitarian point of view, contributors giving up on the project
harm our ability to achieve our goals.
smcv
Reply to: