unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: MSavoritias <email@msavoritias.me>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: Richard Sent <richard@freakingpenguin.com>,
	Andreas Enge <andreas@enge.fr>,
	guix-devel@gnu.org
Subject: Re: About SWH, let avoid the wrong discussion
Date: Mon, 24 Jun 2024 10:55:56 +0300	[thread overview]
Message-ID: <20240624105556.7e92bc20@fannys.me> (raw)
In-Reply-To: <87cyo8zrd4.fsf@elephly.net>

On Sat, 22 Jun 2024 21:53:27 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> MSavoritias <email@msavoritias.me> writes:
> 
> >> To clarify. I am specifically opposed to a change in official Guix
> >> packages that allows for this statement:
> >> 
> >> "Do not upload automatically to software heritage, and no one else can
> >> either."  
> >
> > Let me put this more clear Richard, the statement above that archiving should be off by default means:
> >
> > - Guix respects the consent of the person using guix lint and their expectations. (that lint actually lints)
> > - Respects their privacy
> > - Respects their autonomy.  
> 
> User autonomy is not curtailed by informing an aligned service's crawler
> that an update has occurred.  You have a first class option to disable
> whatever checks you don't want to run.  That's autonomy.

It is in the sense that you haven't gotten the consent of the person running the linter on something that happens outside the context of "linting code".
I have posted this elsewhere but see https://www.consentfultech.io/
Its about not assuming things on behalf of the person running the tool. Specifically for stuff that are more "sensitive" like operations that don't involve linting code.

> Since time immemorial "guix lint" has done more than strictly checking
> that code is formatted correctly.  "guix lint" is a contributor's tool.
> Its features encode values that "we" want to preserve as new packages
> are added.  The intended purpose of "guix lint" is to encourage "high
> quality" packages.  We arrived at this meaning of "high quality" (as
> approximated by the workings of "guix lint") through years of collective
> work on packages.  Since we've seen source code disappear, which negates
> Guix reproducibility guarantees by robbing users of Guix of their
> practical freedoms to the software, the modules of "guix lint" include
> discouraging the use of volatile URLs (like generated tarballs),
> suggesting the use of mirrors, and relatedly notifies SWH that the Guix
> software collection is about to change to increase your chances of
> getting identical source code years from now.  All that because software
> freedom is void without source code. 

Maybe then the tool needs to be renamed? Or more ideally a new subcommand `guix lint contribute` should be added.
Because from the places I asked in xmpp and here it seems everybody that is not reading the docs or knee deep in guix project, assumes it just lints and is surprised it does more things.

> Here is a list of other checks that talk to the internet:
> 
> --8<---------------cut here---------------start------------->8---
> - home-page: Validate home-page URLs
> - source: Validate source URLs
> ...
> - cve: Check the Common Vulnerabilities and Exposures (CVE) database
> - refresh: Check the package for new upstream releases
> - archival: Ensure source code archival on Software Heritage
> --8<---------------cut here---------------end--------------->8---
> 
> Are these all privacy leaks?  Are they in opposition of the goals of
> "guix lint"?  In opposition to the goals of those who use "guix lint"?
> If so: why?

This has actually been mentioned yeah. In the xmpp room I have there were a lot of people surprised that a linter was added and would like to see it being opt-in.
Lets be honest here irc is a tech place exclusively these days so you will rarely find new arguments. Maybe putting a poll in activitypub/masto would help :)

> > Now if you want to disagree that people should have privacy or
> > expectations then I fear we are becoming the next Google.  
> 
> This is jumping the shark, and I think it is a statement that is
> (unintentionally?) rather insulting to those of us who have been
> contributing to Guix for a long time and have spent many excess calories
> wringing their brains to make sure Guix is not your average tech bro
> project.
> 
> It is disappointing to see the levity with which statements of this
> severity are dropped here.  The Guix community that I choose to remember
> was less prone to making inflammatory statements when disagreements
> became apparent.
> 

You are right I did assume things about your opinions when I shouldn't. I apologize.
I am glad that you and others have been trying to make this into a welcoming project, its one of the reasons I joined after all :D

Of course that doesn't mean we can't do better, and this thread has made that pretty apparent. In a whole set of different terms that is.
I would say also that as the Guix community becomes larger its going to be necesserily less homogenous. Especially if we (the Guix Project) are doing our it right.

As a counterpoint I know a lot of people who choose not to join the mailing lists specifically due the culture so to speak.

Seeing how this thread has devolved I am wondering what the next steps would be to address this. Seeing as diversity and a welcoming environment wasn't kept.
Open to suggestions of course :)

MSavoritias


  reply	other threads:[~2024-06-24  7:57 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18  8:37 Next Steps For the Software Heritage Problem MSavoritias
2024-06-18 14:19 ` Ian Eure
2024-06-19  8:36   ` Dale Mellor
2024-06-20 17:00     ` Andreas Enge
2024-06-20 18:42       ` Dale Mellor
2024-06-20 20:54         ` Andreas Enge
2024-06-20 20:59           ` Ekaitz Zarraga
2024-06-20 21:12             ` Andreas Enge
2024-06-21  8:41             ` Dale Mellor
2024-06-21  9:19               ` MSavoritias
2024-06-21 13:33                 ` Luis Felipe
2024-06-21 17:51               ` Exclude checker with package properties [draft PATCH] Simon Tournier
2024-06-21 18:37                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-21 18:44                   ` Simon Tournier
2024-06-21 18:42                 ` Simon Tournier
2024-06-22 15:54                 ` Draft: dry-run + Exclude checker with package properties Simon Tournier
2024-06-20 21:27         ` Next Steps For the Software Heritage Problem Simon Tournier
2024-06-18 16:21 ` Greg Hogan
2024-06-18 16:33   ` MSavoritias
2024-06-18 17:31     ` Greg Hogan
2024-06-18 17:57       ` Ian Eure
2024-06-19  7:01       ` MSavoritias
2024-06-19  9:57         ` Efraim Flashner
2024-06-20  2:56         ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-20  5:18           ` MSavoritias
2024-06-19 10:10 ` Efraim Flashner
2024-06-21  8:39 ` About SWH, let avoid the wrong discussion Simon Tournier
2024-06-21  9:12   ` MSavoritias
2024-06-21  9:46     ` Andreas Enge
2024-06-21 10:44       ` MSavoritias
2024-06-21 13:45         ` Luis Felipe
2024-06-21 14:15           ` MSavoritias
2024-06-21 16:33             ` Luis Felipe
2024-06-21 17:04               ` Msavoritias
2024-06-21 16:34             ` Liliana Marie Prikler
2024-06-21 16:51         ` Vagrant Cascadian
2024-06-21 17:22           ` MSavoritias
2024-06-21 20:51             ` Vagrant Cascadian
2024-06-22 15:46               ` MSavoritias
2024-06-22 17:55                 ` Breath, let take a short break :-) Simon Tournier
2024-06-24  7:30                   ` MSavoritias
2024-06-24 10:23                     ` Tomas Volf
2024-06-24 11:56                     ` Lets cut this off Efraim Flashner
2024-06-21 17:25           ` About SWH, let avoid the wrong discussion Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-22 13:06         ` Richard Sent
2024-06-22 14:42           ` MSavoritias
2024-06-22 19:53             ` Ricardo Wurmus
2024-06-24  7:55               ` MSavoritias [this message]
2024-06-24  9:13                 ` Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240624105556.7e92bc20@fannys.me \
    --to=email@msavoritias.me \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    --cc=richard@freakingpenguin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).