Re: Current NEW review process saps developer motivation
Le vendredi 26 août 2022, 10:58:28 UTC Simon McVittie a écrit :
> 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
In this case the js team has solved the problem.
We use grouped source package, we have the same problem between javascript
package and typescript. Javascript is the main source and typescript is often
generated.
See here
https://wiki.debian.org/Javascript/GroupSourcesTutorial
In your case, you should group your rust source with the glib source and so no
bundle anymore.
You need only a little bit coordination with the glib maintenair and accept
funny version for glib like 1.0+~1.2
Bastien
>
> 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: