Re: On commit access, patch review, and remaining healthy

[Giovanni Biscuolo]

Hi Ricardo and all,

following this discussion, it came to my mind a great presentation made
by Prot:

https://protesilaos.com/codelog/2021-12-21-emacsconf2021-freedom/
«How Emacs made me appreciate software freedom»

especially the "You can't be an Emacs tourist" part; I think that
similar arguments can be adapted to a "(Guix?) Software developer can't
be a repro+bootstrapping tourist" (to fully unserstand my analogy please
read or listen to Prot presentation)

concerning this discussion, this is probably the most interesting part:

--8<---------------cut here---------------start------------->8---

Now you may wonder why do I mention those things?  Shouldn't we make
Emacs easier for everyone?  Yes, we should make everything as simple as
possible.  Though that still does not refashion Emacs into something
entirely different.  We continue to have a potent tool at our disposal
that we must treat with the requisite respect.  Take, for instance, the
various frameworks that set up Emacs in an opinionated way so that
newcomers get everything set up for them out-of-the-box.  There is
nothing wrong with those frameworks.  In fact, a large part of the
community uses them to great effect.  However, the point stands: even
after every package has been set up for you, you still have to put in
the work in making use of your newfound computing freedom.

--8<---------------cut here---------------end--------------->8---

Ricardo Wurmus <rekado@elephly.net> writes:

[...]

>>> - We build strictly from source.
>>
>> This is also a requirement now adopted by many other distributions, at
>> least all the ones in https://reproducible-builds.org/who/projects/
>
> NixOS is on the list, but they don’t have this requirement.  That’s why
> they have Java packages that are little more than the upstream jars,

good point Ricardo, the very moment I started replying I had it in my
mind but forgot to write it

I guess that all experienced packagers or maintainers well understands
what's needed in order to get a reproducible AND bootstrappable package:
almost all of the "constraints" Guix "impose" to packagers and
contributors depends from this... let's call them "golden rules of
software security"?

I just feel sometimes it's hard for newcomers to understand this,
especially considering that unfortunately both some projects in that
list (https://reproducible-builds.org/who/projects/) and some (some?)
upstream developers do not care much about them

the "tag line" of https://reproducible-builds.org/ is

--8<---------------cut here---------------start------------->8---

Reproducible builds are a set of software development practices that
create an independently-verifiable path from source to binary code.

--8<---------------cut here---------------end--------------->8---

honestly I did not study all the reproducible-builds.org documentation,
but it's impossible to me to understand how a packaged upstream jar can
be considered reproducible (and bootstrappable); maybe distros like
NixOS are still slowly transitioning to a full reproducible build
workflow?

IMHO the simple fact that (some, one?) projects listed on
reproducible-builds.org are still bundling binaries in their packages
it's too confusing for newcomers

> or have packages with bundled dependencies (e.g. vendored jars).

bundling binaries it's (is it?) for sure against the definition of a
reproducible build, but what about bundling (source) dependencies?

AFAIU not to bundle (source) dependencies is an additional Guix
requirement (and it is a Good Thing™): do I miss something?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature