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

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

[Ricardo Wurmus]

> Date: Fri, 10 Jun 2022 14:27:44 +0200
> From: Giovanni Biscuolo <g@xelera.eu>
> To: Arun Isaac <arunisaac@systemreboot.net>, Guix Devel
> 	<guix-devel@gnu.org>
> Cc: GNU Guix maintainers <guix-maintainers@gnu.org>
> Subject: Re: On commit access, patch review, and remaining healthy
> Message-ID: <87o7z0itz3.fsf@xelera.eu>
> Content-Type: text/plain; charset="utf-8"
>
>> - 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, or
have packages with bundled dependencies (e.g. vendored jars).

-- 
Ricardo

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

Giovanni Biscuolo schreef op zo 12-06-2022 om 11:42 [+0200]:
> > 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?

FWIW, sometimes the bundled ‘source’ dependencies contain bundled
binaries of their own.  So while AFAICT not strictly necessary for
reproducible builds, unbundling ‘source dependencies’ makes ensuring
reproducibility(*) much more convenient.

(*) i.e., the non-trivial kind of reproducibility, where things are
actually built from source instead of copying binaries.

> 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?

It's ‘reproducible’ in the trivial sense that you can ‘reproduce’ a
scientific paper by putting it a photocopier.  That way, you can
reproduce the results, but you cannot confirm whether these results
were correct.

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

Hi Maxime and all,

I'm so sorry this discussion is shifting to the actual meaning of
reproducible... especially since Maxime and many of us know it very well

I'm sure 95% of people I know would not understand me if I tell them
that their software should be reproducible, they should study a little
bit (effort) what software is to really understand what I mean... or
Just Trust Us™

Maxime Devos <maximedevos@telenet.be> writes:

[...]

> It's ‘reproducible’ in the trivial sense that you can ‘reproduce’ a
> scientific paper by putting it a photocopier.

Maxime I have a question for you please: do you really think that in the
NixOS community (or any other project mentioned in
https://reproducible-builds.org/who/projects/) the term reproducible is
interpreted in that way?

That's not reproducible in this context [1] (I mean software
reproducibility), or to be unambiguous we should always use "build
reproducible" instead of "reproducible" so we amost recall some context
[2]?

IMVHO if we continue using the term reproducible in that trivial way [3]
when talking about software (this include each and every scientific
paper [4]), we will never get to any point; reproducible is what
reproducible means: https://reproducible-builds.org/docs/definition/

I was just hoping that nowadays "reproducible" is perceived as "build
reproducible" (as defined in the definition above) by all software
developers and many users (including scientists)

... the same holds for "bootstrappable" (in this context)


Happy Hacking!  Gio'

P.S.: or you Maxime are just playng the devil's advocate? :-D



[1] context is what defines the meaning of symbols ;-)

[2] build what?

[3] scan and print (aka copy) and distribute the compiled binary
artifact

[4] is it software even if not always expressed in a programming
language? (my guess is yes)

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
> Maxime I have a question for you please: do you really think that in
> the NixOS community

Going by the Java example, yes, at least for some of the NixOS
community.  I've also seen this interpretation of reproducibility in
Clojure (there was some question on building things from source and
reproducibility, and the response was something along the line ‘using
upstream binaries is 100% reproducible’).

>  (or any other project mentioned in
> https://reproducible-builds.org/who/projects/) the term reproducible
> is
> interpreted in that way?

I don't know about all of them, but for Guix and Debian: no.

> IMVHO if we continue using the term reproducible in that trivial way
> [3]
> when talking about software (this include each and every scientific
> paper [4]), we will never get to any point; reproducible is what
> reproducible means: https://reproducible-builds.org/docs/definition/

Exactly, trivial interpretations aren't really the point, because
trivial.

> [...]
> I was just hoping that nowadays "reproducible" is perceived as "build
> reproducible" (as defined in the definition above) by all software
> developers and many users (including scientists)

I'd hope so, yes.

> P.S.: or you Maxime are just playng the devil's advocate? :-D

No, I'm not advocating that trivial reproducibility is useful or the
goal or such.  My response was some speculation on an answer to the
following question:

> but it's impossible to me to understand how a packaged upstream jar
> can be considered reproducible (and bootstrappable);

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Hi Maxime

Maxime Devos <maximedevos@telenet.be> writes:

> Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
>> Maxime I have a question for you please: do you really think that in
>> the NixOS community
>
> Going by the Java example, yes, at least for some of the NixOS
> community.  I've also seen this interpretation of reproducibility in
> Clojure (there was some question on building things from source and
> reproducibility, and the response was something along the line ‘using
> upstream binaries is 100% reproducible’).

Ouch!  It hurts so much ;-(

[...]

>> P.S.: or you Maxime are just playng the devil's advocate? :-D
>
> No, I'm not advocating that trivial reproducibility is useful or the
> goal or such.  My response was some speculation on an answer to the
> following question:
>
>> but it's impossible to me to understand how a packaged upstream jar
>> can be considered reproducible (and bootstrappable);

OK OK, now I understand, I did not imagine there's still this kind of
interpretation about reproducible builds in some groups of
developers/maintainers


Thanks!  Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

«Reproducibility vs. Replicability: A Brief History of a Confused Terminology»

[zimoun]

Hi,

On Sun, 12 Jun 2022 at 15:10, Maxime Devos <maximedevos@telenet.be> wrote:

> It's ‘reproducible’ in the trivial sense that you can ‘reproduce’ a
> scientific paper by putting it a photocopier.  That way, you can
> reproduce the results, but you cannot confirm whether these results
> were correct.

More details for the interested reader here [1].

1: <https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5778115/>


Cheers,
simon

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

[Ricardo Wurmus]

>> - We have strict conventions for commit messages. Our commit message
>>   Changelog is a strange dated practice from the time before good
>>   version control systems. I can live with it, but not everyone likes
>>   it. Let's just say I've heard complaints about it offlist.
>
> AFAIU this is a requirement Guix inherits from GNU (being it a GNU
> project)
>
> I don't remember the ratio for this requirement but AFAIU it made sense
> to me when I read that.
>
> I just hope this requirement is refraining people to contribute and to
> review patches.
>
> Maybe we could help users not using Emacs with other editor-related
> snippets in [~/src/guix/]etc/snippets? (I don't know other editors
> templating systems)

We have an editor-agnostic tool in ./etc/committer.scm.

-- 
Ricardo