Re: Breath, let take a short break :-)

[MSavoritias]

On Sat, 22 Jun 2024 19:55:05 +0200
Simon Tournier  wrote:

Hey Simon,

I would suggest to take a step back as you said and consider whether what you 
are doing is in fact tone-policing here.
https://en.wikipedia.org/wiki/Tone_policing
> A tone argument (also called tone policing) is a type of ad hominem aimed at 
> the tone of an argument instead of its factual or logical content in order to 
> dismiss a person's argument. Ignoring the truth or falsity of a statement, a 
> tone argument instead focuses on the emotion with which it is expressed. This 
> is a logical fallacy because a person can be angry while still being 
> rational. Nonetheless, a tone argument may be useful when responding to a 
> statement that itself does not have rational content, such as an appeal to 
> emotion.
I will elaborate below.

> Hi MSavoritias,
> 
> This message is not to cut any discussion but maybe it could be helpful
> or a bit saner if you refrain to rehash again and again the same to all
> messages, replying the same (or almost) to each person expressing
> different opinions.

Its not really different tho is it? In the sense that since the beginning of 
this thread there has been 2 opinions.
The one for consent was supressed pretty fast with arguments appealing on 
"ethics" and "you just don't understand free software is all the rules we have" 
both of them bad faith arguments of course.

So if you look at the thread actually its the people that have already phrased 
their support have stopped replying, and I am the one replying to one opinion.
I invite you to think about 3 things:

1. Why did you felt to point it out to me instead of the same bad faith 
argument been written again and again?
2. What happened to the people that wanted consent but now don't reply anymore.
3. Does that a culture like this stop more voices from coming forward?

> No blame, and I also include myself: being very enthusiastic to defend
> ideas and values.  However, a storm of replies is maybe not the best
> mean to achieve such defense. :-)
> 
> I think people got your points and your opinion, quickly summarized as:
> 
>  1. SWH broke “implicit social rules”,
>  2. Because of that, Guix must make a clear public “pressure” against SWH.
> 
> 
> Let look how the thread looks like:
> 
> https://yhetil.org/guix/87a5jfjoey@gmail.com/T/#rc72a0743026006ee9d4758cfa794df42a9964a55
> (or this other one: https://yhetil.org/guix/87il1mupco.fsf@meson/#r)

Again see above.

> Then, for what my humble point of view is worth here, I think that your
> opinion is maybe not the consensus.  Obviously, the discussion is still
> open and your opinion is welcome – yeah obviously welcome! – but maybe
> not by replying to all, each time.

As mentioned above you probably missed the first few replies before this thread 
was taken over so please go read again the first few hours :)
As another point please dont gaslight me :) I know how many people have replied 
in support both in this thread and in xmpp.
So this thread being flooded by people who dont think CoC or consent or privacy 
matters doesn't really make me question if I am right. 
It makes me question that of course nobody else is going to reply to get storm 
of replies saying how "unethical" they are.
https://en.wikipedia.org/wiki/Gaslighting
> Gaslighting is a colloquialism, loosely defined as manipulating someone into 
> questioning their own perception of reality.

> You are advocating for a safe place, right?  From my eyes, when I see
> the structure of the thread, it does not generate a safe place where
> collaboration is encouraged.
> 
> My feeling, when I do a step back and look to the structure of the
> thread, is that some opinions are silent because it’s hard to have the
> space to express them.

Yes exactly. So lets see what opinions were expressed the first few hours of 
this thread. And what opinions have been expressed after mostly.
And lets see what kind of arguments were against these initial points. (hint: 
its not good faith arguments most of them :) )
I do agree that the mailing list is not a safe space for a host of reasons that 
I already knew going in (and believe me its not easy try to write and persist) 
but that is an argument for another time.

> Sometimes, a breath is helpful.  Somehow, FWIW, I suggest you to let the
> discussion aside, then some days later read again some messages, try to
> differently understand what other peers are trying to express, and
> comment to few on a fresh mindset.
> 
> All opinions are very welcome.  We are all here because we value Free
> Software, community, people, etc. and not necessary in that order.  And
> that’s very important to be able to express all the diversity.

If we value diversity then we need to ask:
Where are the different opinions really 

Re: About SWH, let avoid the wrong discussion

[MSavoritias]

On Fri, 21 Jun 2024 13:51:17 -0700
Vagrant Cascadian  wrote:


Hey,

I am really tempted to just write this off as a bad faith argument (which it 
mostly is) but either way i replied some things more down because I am trying 
to believe you are 
arguing in good faith.
If its not a bad faith argument, please consider the time and place and the 
context of things before arguing next time.

> On 2024-06-21, MSavoritias wrote:
> > On Fri, 21 Jun 2024 09:51:30 -0700
> > Vagrant Cascadian  wrote:
> >  
> >> On 2024-06-21, MSavoritias wrote:  
> >> > On Fri, 21 Jun 2024 11:46:56 +0200
> >> > Andreas Enge  wrote:
> >> >> Am Fri, Jun 21, 2024 at 12:12:13PM +0300 schrieb MSavoritias:
> >> >> > and as I mention in my first email I want to apply social pressure 
> >> >> > and make it clear to package authors what is happening so we can move 
> >> >> > to an opt-in model.  
> >> >> 
> >> >> Well, the opt-in model is in place: As soon as I put my code under a 
> >> >> free
> >> >> license on the Internet, I opt in for it to be harvested by SWH (and 
> >> >> anybody
> >> >> else, including non-friendly companies and state actors).
> >> >
> >> > That may be how you have understood it but that is not how most people 
> >> > understand it.
> >> > See for example mirroring videos that creators have made online, or more 
> >> > recently some activitypub software harvesting posts for a search engine. 
> >> >
> >> 
> >> I think the fundamental difference is that such videos or activitypub
> >> posts are not necessarily released under a license that *expressly*
> >> permits sharing.
> >> 
> >> In most cases, those posts and videos are often released without any
> >> license at all, and the person retains the legal, social, moral and
> >> ethical rights to decide how that content is shared if at all. (I am
> >> speaking with those terms in the "plain" english sense, although they
> >> may have specific legal meanings in some contexts)  
> >
> > Its not actually. License doesn't matter to fediverse communities (I am 
> > talking ones that are part of the BadSpace here)
> > It is a social issue and treat accordinly. As in defederate (dont 
> > assosiate) with people who dont respect your community rules.
> > Laws, and licenses have nothing to do with it.  
> 
> What is a license other than an explicit set of community rules
> pertaining to the community around which that license is relevent
> (e.g. a specific piece of software)?

A license is a state instrument that compels somebody to do something otherwise 
they may get taken to state courts and have violence used against them by police
> The simplest definition is "A license is a promise not to sue", because a 
> license usually either permits the licensed party to engage in an illegal 
> activity, and subject to prosecution, without the license
From https://en.wikipedia.org/wiki/License

You may equate license as social rules but outside of FSF and/or GNU nobody 
else really does. I havent seen it used anywhere like this.
Also nobody is using licenses as social rules (not Gnu, not Guix, not Debian) 
nobody really. And GPL would make a horrible community anyway because it doesnt 
say anything about racism or sexism for example.

> >> With something released under a Free Software license, calling someone
> >> an "asshole" simply for using the permissions granted by that license,
> >> by the very person who granted those permissions, starts to feel a bit
> >> like a baited trap and honestly, maybe outright duplicitous. Certainly
> >> rude, at the very least.
> >> 
> >> Again, that is different from some arbitrary post or video or cat
> >> picture on the internet, which more likely than not has no explicit
> >> permissions granted.  
> >
> > See about fediverse again. Its understood socially to be a bad thing not 
> > legally.
> > Because after all mostly nobody has the time and money for state laws to 
> > work.  
> 
> If I tell you "go ahead and do X with this cool thing I made, as long as
> you respect Y, forever, honest" and then you say "stop doing X now, I
> take it back because Z" ... that might come across as socially
> inappropriate weather there are laws involved or not; the law is
> irrelevent as far as I am concerned.

What somebody "tell you" is not only the license. You may try to make it 
simpler to make your life easier feel free.

Re: About SWH, let avoid the wrong discussion

[MSavoritias]

On Sat, 22 Jun 2024 09:06:20 -0400
Richard Sent  wrote:

> Hi MSavoritias,
> 
> MSavoritias  writes:
> 
> >> Well, the opt-in model is in place: As soon as I put my code under a free
> >> license on the Internet, I opt in for it to be harvested by SWH (and 
> >> anybody
> >> else, including non-friendly companies and state actors).  
> > That may be how you have understood it but that is not how most people
> > understand it. See for example mirroring videos that creators have
> > made online, or more recently some activitypub software harvesting
> > posts for a search engine.
> >
> > As I have been saying a lot in this thread (because there seem to be a
> > lot of people in the Guix community not familiar that legal are not
> > the same as social rules):  
> 
> I feel the need to jump in here because that first paragraph, to me,
> implies that the silent members of the community agree with you. I do
> not.
> 
> Mirroring/archiving code released under a free license is different then
> copying videos or posts that were not licensed. The two are so different
> that opposition to the latter can't be compared to opposition to the
> former. And yes, I do mean from a ethical perspective. These are wildly
> different issues.
> 
> > Saying that I can do whatever I want is a very reductionist point of
> > view that I doubt would be acceptable inside Guix and FSF even. Given
> > that GPL itself doesn't allow you to do whatever you want.  
> 
> Restrictions for the purpose of maximizing freedom are different then
> restrictions for the purpose of limiting freedom.

Thank you for proving my point :)
That what "limits freedom" is very subjective that is. You have your opinion 
other people have yours. 
GPL has been called bad for restricting freedom after all if you dont know.


> > Again as I wrote above legal has nothing to do with it really. Its
> > about our social rules and what we have as common understanding in
> > Guix.  
> 
> To some people (myself included), ensuring software is and remains free
> IS an ethical rule (along with the contents of Guix's Contributor
> Covenant of course). I do not believe any rules in said code of conduct
> are being violated here.

Does you ethics not include privacy and consent? Because mine do.
see -> https://www.consentfultech.io

> >>`-x archival` does it, but it is too easy to forget and once the cat is 
> >> out
> >> of the bag privacy is lost.  I really think this should be default 
> >> behaviour, 
> >> or
> >> at least there should be a flag in the package definition.  I would still 
> >> be
> >> uncomfortable with the last option, as everyone would be relying on the
> >> collective of Guix maintainers to not screw up and accidentally leak 
> >> private
> >> data.
> >>
> >> Dale  
> > Yeah very much agree this should be the default behavior. Archiving
> > should be opt-in to avoid any surprises for the person running it. I
> > am surprised it became default actually.  
> 
> It is not my responsibility to ensure publicly available code released
> under a FOSS license is not archived. It is the developers
> responsibility to not release it under a FOSS license. (Perhaps nonfree
> private channels would benefit from a change in the default behavior but
> Guix should not tailor its defaults around such a use case.)
> 
> I am opposed to any theoretical change in Guix's packaging policy that
> restricts software freedom. This would include a system that allows for
> marking individual packages as "do not upload to software heritage".
> 
> 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.

Now if you want to disagree that people should have privacy or expectations 
then I fear we are becoming the next Google.
Personally I do not want Guix to become the next google but I instead want to 
respect privacy, autonomy and consent.
If you do not believe in these then I fear we have a fundamental disagreement 
here.

Regards,
MSavoritias

Re: About SWH, let avoid the wrong discussion

[MSavoritias]

On Fri, 21 Jun 2024 09:51:30 -0700
Vagrant Cascadian  wrote:

> On 2024-06-21, MSavoritias wrote:
> > On Fri, 21 Jun 2024 11:46:56 +0200
> > Andreas Enge  wrote:  
> >> Am Fri, Jun 21, 2024 at 12:12:13PM +0300 schrieb MSavoritias:  
> >> > and as I mention in my first email I want to apply social pressure and 
> >> > make it clear to package authors what is happening so we can move to an 
> >> > opt-in model.
> >> 
> >> Well, the opt-in model is in place: As soon as I put my code under a free
> >> license on the Internet, I opt in for it to be harvested by SWH (and 
> >> anybody
> >> else, including non-friendly companies and state actors).  
> >
> > That may be how you have understood it but that is not how most people 
> > understand it.
> > See for example mirroring videos that creators have made online, or more 
> > recently some activitypub software harvesting posts for a search engine.  
> 
> I think the fundamental difference is that such videos or activitypub
> posts are not necessarily released under a license that *expressly*
> permits sharing.
> 
> In most cases, those posts and videos are often released without any
> license at all, and the person retains the legal, social, moral and
> ethical rights to decide how that content is shared if at all. (I am
> speaking with those terms in the "plain" english sense, although they
> may have specific legal meanings in some contexts)

Its not actually. License doesn't matter to fediverse communities (I am talking 
ones that are part of the BadSpace here)
It is a social issue and treat accordinly. As in defederate (dont assosiate) 
with people who dont respect your community rules.
Laws, and licenses have nothing to do with it.

Also bear in mind that the same communities opposed and blocked search engines 
that tried to make the posts searchable.
That is why it became opt-in in the end :D

> > As I have been saying a lot in this thread (because there seem to be a
> > lot of people in the Guix community not familiar that legal are not
> > the same as social rules):  
> 
> > -Just because you CAN do something doesn't mean you SHOULD. In the sense 
> > that yes somebody can probably harvest all my posts from activitypub and 
> > post them somewhere else, 
> > in practise they are an asshole tho and probably are going to be
> > deferated pretty fast for breaking the social rules of common human
> > decency :)  
> 
> With something released under a Free Software license, calling someone
> an "asshole" simply for using the permissions granted by that license,
> by the very person who granted those permissions, starts to feel a bit
> like a baited trap and honestly, maybe outright duplicitous. Certainly
> rude, at the very least.
> 
> Again, that is different from some arbitrary post or video or cat
> picture on the internet, which more likely than not has no explicit
> permissions granted.

See about fediverse again. Its understood socially to be a bad thing not 
legally.
Because after all mostly nobody has the time and money for state laws to work.

> > TBH it seems you are not the only one in this thread not knowing that laws 
> > (legal rules of states) ie. the FSF licenses and work and whatever, are not 
> > the same as social rules.
> > But given that Guix has a CoC and social rules on top of that I am hopeful 
> > :)  
> 
> Well... free software ... is a bunch of social rules. Licenses are
> social rules. Contracts are social rules. Laws are social
> rules. Admittedly, a lot of the mechanics involved in law creation and
> enforcement are dubious and suspect and weighted in the favor large,
> wealthy and/or otherwise powerful entities...
> 
> I am not sure arguing about social vs. legal vs. whatever is even really
> a useful direction... almost missing the point entirely.
> 
> I would rather ask... what is the intention of the Free Software
> movement?
> 
> The licenses are merely imperfect tools to achieve those aims, and a
> clever way to leverage some specific legal mechanisms, but the licenses
> are not an end unto themselves.
> 
> For me personally, it is about creating a shared commons that can be
> used to build healthy thriving local, regional, global and virtual
> communities that do useful or interesting things... I dare dream that
> some of those collaboration skills leak into other aspects of life too,
> not just software!

That is all well and good but sadly Free Software says nothing about social 
rules.
For example what is Guix supposed to do when racists come in the chat?
or what if there is a hostile fork with the same name and submits itself for 
Guix inclusio

Re: About SWH, let avoid the wrong discussion

[Msavoritias]

On Fri, 21 Jun 2024 16:33:40 +
Luis Felipe  wrote:

> El 21/06/24 a las 14:15, MSavoritias escribió:
> > On Fri, 21 Jun 2024 13:45:04 +
> > Luis Felipe  wrote:
> >  
> >> El 21/06/24 a las 10:44, MSavoritias escribió:  
> >>> On Fri, 21 Jun 2024 11:46:56 +0200
> >>> Andreas Enge  wrote:
> >>> 
> >>>> Am Fri, Jun 21, 2024 at 11:14:18AM +0300 schrieb MSavoritias:  
> >>>>> Aside from that even Guix uploading all code from the packages to
> >>>>> SWH that basically feeds it to a LLM model is indeed not honoring 
> >>>>> consent of the author of the package.  
> >>>> Guix does not upload code to SWH. It gives them a pointer to a public git
> >>>> repository that SWH then harvests or not according to their rules (see my
> >>>> reply to Dale yesterday). These are not the same things at all.  
> >>> This is bikeshedding and arguing on schemantics. Guix gives them a url to 
> >>> download the source code from, so ultimately we (the Guix project) is 
> >>> responsible for the code showing up in there.
> >>> Lets not argue over schemantics like this. It is even posted on their 
> >>> website in case you want to argue otherwise 
> >>> https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/
> >>>   
> >> I think the differentiation between sending code and sending a URL is
> >> necessary. Saying that Guix sends your code or your source files to SWH
> >> leads people to think that Guix *will* transmit those files from your
> >> local machine over the Internet to SWH machines when you run "guix lint
> >> YOUR_PRIVATE_PACKAGE". And that's not the case, is it?  
> > But I didnt say that tho did I? the context you are reading as from the 
> > quote is Guix uploading all code from its packages to SWH.
> > Not any private repos. So i have no idea what you are reffering to here 
> > tbh.  
> 
> No, you didn't.
> 
> What I'm trying to say is that I don't think specifying what Guix 
> sends/uploads to SWH is "bikeshedding". For example, when you say "Guix 
> uploading all code from its packages to SWH", it's ambiguous to me. I 
> don't understand whether you are referring to the package definitions or 
> to the source files those packages refer to. And, if I understand 
> correctly, Guix doesn't upload any of these to SWH.

From the `guix lint` documentation:

archival ¶

Checks whether the package’s source code is archived at Software Heritage.

When the source code that is not archived comes from a version-control 
system (VCS)—e.g., it’s obtained with git-fetch, send Software Heritage a 
“save” request so that it eventually archives it. This ensures that the source 
will remain available in the long term, and that Guix can fall back to Software 
Heritage should the source code disappear from its original host. The status of 
recent “save” requests can be viewed on-line.

When source code is a tarball obtained with url-fetch, simply print a 
message when it is not archived. As of this writing, Software Heritage does not 
allow requests to save arbitrary tarballs; we are working on ways to ensure 
that non-VCS source code is also archived.

Software Heritage limits the request rate per IP address. When the limit is 
reached, guix lint prints a message and the archival checker stops doing 
anything until that limit has been reset.

This is run for all packages in the Guix tree in case you didnt know. (and by 
default in guix lint)

MSavoritias

Re: About SWH, let avoid the wrong discussion

[MSavoritias]

On Fri, 21 Jun 2024 13:45:04 +
Luis Felipe  wrote:

> El 21/06/24 a las 10:44, MSavoritias escribió:
> > On Fri, 21 Jun 2024 11:46:56 +0200
> > Andreas Enge  wrote:
> >  
> >> Am Fri, Jun 21, 2024 at 11:14:18AM +0300 schrieb MSavoritias:  
> >>> Aside from that even Guix uploading all code from the packages to
> >>> SWH that basically feeds it to a LLM model is indeed not honoring consent 
> >>> of the author of the package.  
> >> Guix does not upload code to SWH. It gives them a pointer to a public git
> >> repository that SWH then harvests or not according to their rules (see my
> >> reply to Dale yesterday). These are not the same things at all.  
> > This is bikeshedding and arguing on schemantics. Guix gives them a url to 
> > download the source code from, so ultimately we (the Guix project) is 
> > responsible for the code showing up in there.
> > Lets not argue over schemantics like this. It is even posted on their 
> > website in case you want to argue otherwise 
> > https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/
> >   
> 
> I think the differentiation between sending code and sending a URL is 
> necessary. Saying that Guix sends your code or your source files to SWH 
> leads people to think that Guix *will* transmit those files from your 
> local machine over the Internet to SWH machines when you run "guix lint 
> YOUR_PRIVATE_PACKAGE". And that's not the case, is it?

But I didnt say that tho did I? the context you are reading as from the quote 
is Guix uploading all code from its packages to SWH.
Not any private repos. So i have no idea what you are reffering to here tbh.

MSavoritias

Re: About SWH, let avoid the wrong discussion

[MSavoritias]

On Fri, 21 Jun 2024 11:46:56 +0200
Andreas Enge  wrote:

> Am Fri, Jun 21, 2024 at 12:12:13PM +0300 schrieb MSavoritias:
> > and as I mention in my first email I want to apply social pressure and make 
> > it clear to package authors what is happening so we can move to an opt-in 
> > model.  
> 
> Well, the opt-in model is in place: As soon as I put my code under a free
> license on the Internet, I opt in for it to be harvested by SWH (and anybody
> else, including non-friendly companies and state actors).

That may be how you have understood it but that is not how most people 
understand it.
See for example mirroring videos that creators have made online, or more 
recently some activitypub software harvesting posts for a search engine.

As I have been saying a lot in this thread (because there seem to be a lot of 
people in the Guix community not familiar that legal are not the same as social 
rules):
-Just because you CAN do something doesn't mean you SHOULD. In the sense that 
yes somebody can probably harvest all my posts from activitypub and post them 
somewhere else, 
in practise they are an asshole tho and probably are going to be deferated 
pretty fast for breaking the social rules of common human decency :)
This is by design in activitypub btw the social rule of don't harvest stuff. 
Same way that it is in xmpp. Not that assholes don't exist of course, but 
nobody is exempt from common human decency and
a following the rules of a place. See also https://www.consentfultech.io/ for a 
good read. Hope it answers some questions.
- What you are saying even if it was true, is not indicated anywhere in the 
manual or the website. (which is part of what I want to do.) Add a warning for 
package authors and commiters and a proper procedure.
We are ultimately living in a society that we have some good faith by default 
that everybody acts respectfully (dont leak my messages that i sent to you in 
private for example). If they don't
we take measures to not include them anymore. I am not saying this for SWH mind 
you, its just an example.

Saying that I can do whatever I want is a very reductionist point of view that 
I doubt would be acceptable inside Guix and FSF even. Given that GPL itself 
doesn't allow you to do whatever you want.
TBH it seems you are not the only one in this thread not knowing that laws 
(legal rules of states) ie. the FSF licenses and work and whatever, are not the 
same as social rules.
But given that Guix has a CoC and social rules on top of that I am hopeful :)
 
> Now the code may not be found by SWH, and the moment someone makes a Guix
> package out of it and adds it to the Guix main channel, SWH will find and
> archive it; but the opt-in has happened before at the moment I put the code
> online with its license.
> 
> Maybe I misunderstood to what you want to apply the term "opt-in" (after
> reading your other message in which you use the term, this seems to be
> the case). If it is to source code of packages being used for AI training,
> there is actually no need to have a separate opt-in. Either it is legal
> under your license (and then you have effectively opted in), or it is
> illegal (in which case explicit opt-in already is a requirement).

Again as I wrote above legal has nothing to do with it really. Its about our 
social rules and what we have as common understanding in Guix.
if you just do something just because you can, then that makes you an asshole 
in my book. See hostile forks for example that have happened.

> Am Fri, Jun 21, 2024 at 11:14:18AM +0300 schrieb MSavoritias:
> > Aside from that even Guix uploading all code from the packages to
> > SWH that basically feeds it to a LLM model is indeed not honoring consent 
> > of the author of the package.  
> 
> Guix does not upload code to SWH. It gives them a pointer to a public git
> repository that SWH then harvests or not according to their rules (see my
> reply to Dale yesterday). These are not the same things at all.

This is bikeshedding and arguing on schemantics. Guix gives them a url to 
download the source code from, so ultimately we (the Guix project) is 
responsible for the code showing up in there.
Lets not argue over schemantics like this. It is even posted on their website 
in case you want to argue otherwise 
https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/

> Whether or not one agrees with the SWH policy on LLM training (and I have
> not looked at it well enough to form my opinion), I do not think there
> is anything we should change at the level of the Guix project. Maybe SWH
> should put into place an opt-in procedure for feeding LLM; but I do not
> think we in Guix should put into place an opt-in procedure for informing
> SWH of the source code we package. (Which would be 

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Fri, 21 Jun 2024 09:41:10 +0100
Dale Mellor  wrote:

> On Thu, 2024-06-20 at 22:59 +0200, Ekaitz Zarraga wrote:
> > Hi,
> > 
> > On 2024-06-20 22:54, Andreas Enge wrote:  
> > > Am Thu, Jun 20, 2024 at 07:42:44PM +0100 schrieb Dale Mellor:  
> > > > I'm sure guix lint tried to push my code out to them the last time I
> > > > tried.  
> > > 
> > > Ah indeed, there is this in guix/lint.scm:
> > > 
> > > So it does not push code, but a URL from which the code can be downloaded.
> > > Thus it requires the code to be available from the Internet; local code
> > > is "safe" from SWH.  
> 
>But this is still leaking information.
> 
> > > Now I do not know what will happen if you save your code as a git
> > > repository at a hidden URL. For instance, does SWH check the license?
> > > I would hope so.  
> 
>Hope is not really good enough, there needs to be certainty in this.
> 
> > 
> > For this specific case we could add some flag to the command line like 
> > `--do-not-archive` or something like that.  
> 
>`-x archival` does it, but it is too easy to forget and once the cat is out
> of the bag privacy is lost.  I really think this should be default behaviour, 
> or
> at least there should be a flag in the package definition.  I would still be
> uncomfortable with the last option, as everyone would be relying on the
> collective of Guix maintainers to not screw up and accidentally leak private
> data.
> 
> Dale

Yeah very much agree this should be the default behavior. Archiving should be 
opt-in to avoid any surprises for the person running it.
I am surprised it became default actually.

MSavoritias

Re: About SWH, let avoid the wrong discussion

[MSavoritias]

On Fri, 21 Jun 2024 10:39:50 +0200
Simon Tournier  wrote:


Hey,

Just wanted to send a quick reply that as I have mentioned elsewhere I do not 
wish to see SWH go. I think they are doing great work.
and as I mention in my first email I want to apply social pressure and make it 
clear to package authors what is happening so we can move to an opt-in model.

It was never my intent to make it seem like we need to burn all bridges with 
SWH. I do think they have done mistakes but that is not a reason to break apart.
We definetily need something like SWH and I do hope to see them come around to 
a consentual model.

MSavoritias

> Hi all,
> 
> For the record, the Software Heritage initiative is supportive of the
> Guix project since years.
> 
> It means that members of Guix community have or had interactions with
> Software Heritage (SWH) teams since years.  For example, the blog post
> “Connecting reproducible deployment to a long-term source code archive”
> [1] published in 2019.  And more recently, the scientific communication
> “Source Code Archiving to the Rescue of Reproducible Deployment” [2].
> 
> Almost 6 years of friendly interactions and shared values.
> 
> Could we avoid to express definitive opinions based on partial
> considerations about multi-dimensional topics?
> 
> Since years, several members of Guix community are helped in one way or
> the other by SWH team members in improving free software ecosystem.
> 
> Well, I speak for myself: I have been invited to several events
> organized by SWH and it’s up to you to trust me when I say: SWH team
> works very hard to embrace all the diversity of FOSS communities.  For
> example, I recently attended to a talk organized by SWH about Commons;
> that talk had been a very good food for thought and maybe it could feed
> our current discussion about governance/sociocracy via comments here or
> there I could commit, I do not know, maybe.
> 
> Well, I am very grateful for the opportunity to interact with SWH teams.
> 
> For the record, SWH provided various supports for the organization of 10
> Years of Guix, back in 2022.  Please remember that SWH team members were
> there and some stayed all the three days; probably because we are a nice
> community?  All the video stream and good videos of the 10 Years of Guix
> event you probably watched or maybe watch again is because the tireless
> work of multi-hats person (Debian Developer, Debian Video Team, … and
> working at SWH) helped by Guix community members.
> 
> Please check the Copyright header for the subcommand “guix locate”.
> Yes, it had been partly written by one SWH team member because, yes they
> run Guix.  Yes, their day-job is at SWH and they are also part of our
> Guix community by contributing to Guix source code.
> 
> Now, you take it as it is: I am sad by what people are concluding!
> 
> Yes I understand why people are angry.  Yes discussions must happen.
> 
> However, I was expecting more benefit of the doubt considering history
> and track record.  Hum, even, maybe, I am asking myself if Guix
> community is indeed nice or if this time the community is just harsh and
> unfair.
> 
> Do we forget the track record and the common history?
> 
> Then, for what my opinion is worth, fighting against SWH while thinking
> it’s fighting against LLM/AI is the wrong fight.  Because 1. we are all
> in the team.  And 2. because SWH could be a facilitator for helping in
> some regulations, maybe, I do not know.  Somehow, I agree with Ekaitz.
> 
> You take it as it is: I was expecting more humility by Guix community
> members.  Do you really think that a collective of people involved in
> various FOSS communities with different roles, dedicating their free
> time to free software or open source movements, do you think they are
> the bad actors here?
> 
> My humility tells me, as I expressed several times, nothing is ignored.
> 
> Yes I also got the point about the lack of transparency.  As I said
> above, FWIW, I am in touch with SWH team.  Well, I do not have special
> information from SWH and I trust them to have listened or are still
> listening various communities.  So my understanding is: work is in
> progress…  Somehow, wait and see.
> 
> Yes I know we cannot wait forever.  Again, do we forget the track record
> and the common history?  Do we consider that a multi-layers topic
> involving legal or ethics questions is straightforward to articulate?
> 
> My humility tells me to wait to have clear and better understanding
> about SWH motivations, their rationale, the measures and
> counter-measures they maybe have in mind.  Be patient and tolerant as I
> am with my friends.
> 
> Long enough email and thread.  That’s all from me! :-)
> 
> My last message.  N

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

thor that is packaged by Guix?
> 
> Again, I am not trying to avoid the discussion.  Instead, I would prefer
> to root the discussion on concrete examples.  Then it would appear to me
> easier to make progress.
> 
> As Greg or Ekaitz also wrote: opting out has implications on the meaning
> of freedom behind “free software“.

I mean it does if you think that:
1. Guix doesn't have any social rules on top of the FSF definition (it does) 
and that it doesn't respect consent
2. That its not about the context of something. For example GPL or our CoC 
restrict freedom so that people can be more free to express themselves :)

> IMHO, that’s not because we would like to opt-out that we could, would
> be able to or allowed to.  Therefore, instead of holding opinions on the
> abstract, let try to make progress and start on the concrete: which
> piece of source code are we speaking about?

The softwares here -> https://sr.ht/~msavoritias/
Which the minute I add them to guix the code is going to be in SWH.
Not that this is about only my software but as the example you wanted.

MSavoritias

> Cheers,
> simon
> 
>

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

 embrace them
> >> harder (one value, freedom, in our case).  
> > 
> > Definetily agree. The solution is not to embrace propietary software or
> > restrict software. Its to write down some common social rules that are
> > rooted in consent.
> >   
> >> If people is not happy with the Free Software movement because it
> >> puts the freedom first, I can only understand it as people being mad
> >> about Free Software because it's about software.
> >>
> >> For other values, we can start other initiatives I may or may not
> >> agree more with, but if the value is freedom (in software), I don't
> >> think there's any better way to push for it. But trying to disguise
> >> other things inside of the Free Software is kind of dishonest.  
> > 
> > Fair. I mean we already have CoC and channel descriptions. Idk if we
> > have event guidelines/CoC yet but we should.
> >   
> >> I don't know, maybe I'm just a little bit tired.  
> > 
> > No worries. I think it was very well said.
> > 
> > MSavoritias  
> 
> That was just for clarifying my point wasn't against this discussion but 
> to say that the decision Efraim took on dbxfs is not only correct but 
> the only possible decision, and that it should be.

I think our decisions should be a lot more based on context than dogma or some 
kind of immovable law. But that is just me and probably a discussion for 
another time.

> Now in Guix, I don't feel comfortable with the fact we are helping 
> people use AI that doesn't respect the licenses of our work to be 
> trained. I'm sick of it.
> 
> If they respected the licenses, I'd be ok with it. Since I accepted Free 
> Software's social contract I'm open for anyone to use my code with any 
> purpose (unless they don't respect people's freedom later).
> 
> Also, even if we don't do anything about it, Guix's codebase is public, 
> so they could do it anyway, regardless of SWH, so there's not much we 
> can do about that.

I mean sure. But the problem is that Guix actively gives them the source code 
which they use for the wrong purposes.
I wouldn't have a problem if it was on archiving. Just because somebody else is 
an asshole doesn't mean we have to be.

Also a lot of people don't see the Free Software social contract as GPL. They 
see it as a legal license.
Probably we could define some kind of Free Software contract on top but I am 
guessing that:
1. It would be against GPL, because GPL doesn't want anybody for any purpose to 
use your code. We would go public domain.
2. A lot of people probably couldn't accept it. See for example hostile forks 
even inside GNU that have happened.

> What we *can* do is raise our concerns to SWH, motivating them to be 
> more strict with their collaboration with companies or with the terms of 
> their collaboration. It's probably better that they are in our side in 
> this battle than if we are alone. I think they are sensible to this 
> issue so it shouldn't be hard to have a proper conversation with them 
> and see if we can understand better what they do, how, in which terms 
> and so on.

I agree. I don't want to burn any bridges. Which is why I made the proposal 
that I did. To put social pressure on them to actually respect consent.
 
> Maybe it's better that these AI companies reach our code through SWH 
> with a well-written contract than letting them steal it from the 
> internet without having them to sign anything.
> 
> I'm kind of just guessing there, but we are probably stronger that way.
> Also, if we could make other distros to take part on this it would be a 
> great way to be stronger.
> 
> In any case, I think SWH are more than sensible to this issue and I 
> think their connections might be helpful to not only restrict this 
> HugginFace from doing shady things but to start pushing for regulation 
> for every AI company that uses our sweat for their purposes.
> 
> So, to come back to my original point: It's not the free software that 
> needs to change. It's the regulation of AI companies that should, and 
> the responsibility we demand from them. Legally and morally, they should 
> be accountable of what they do, and that's the direction I'd like to 
> approach this. Maybe it's not easy to change the regulation of the whole 
> world, but we can try to push for it in Europe (we pioneered some 
> related regulations before) first.

Maybe. Then again this changes nothing to the current discussion.
That a system of code harvesting like SWH has needs to opt-in with consent.
Laws or not.

Then everybody can take the decision they think is based and give or not give 
their code to the LLM model :)

> In summary, I don't think this is just a SWH is bad/good or Free 
> Software is bad/good issue.
> 
> Best,
> Ekaitz
> 
> PS: If there's action I'm open and ready for it, but I won't like this 
> discussion to become an exercise of ethical bragging with no goals.

Please see my initial email for this thread for actional goals :)
That I plan to send a pr/mr/email for soonish.

MSavoritias

Re: Next Steps For the Software Heritage Problem (Dale Mellor)

[MSavoritias]

On Thu, 20 Jun 2024 14:43:30 -0700
Andy Tai  wrote:

> > Date: Wed, 19 Jun 2024 09:36:29 +0100
> > From: Dale Mellor 
> > I use Guix as a tool to develop my own projects, private and
> > personal for reasons I'm keeping to myself.  As part of that I write package
> > definitions for them, and use the Guix machinery to build and test.  I 
> > *cannot*
> > have Guix just giving my code away to anybody, that is just fundamentally 
> > wrong.
> >  
> If you release software as free software, you are giving away
> software, to anybody and everybody.

Legally yes. But I think Dale talks about the social rules that I have been 
repeating in these threads :)
 
> >   We need to ask what is Guix?  A free operating system, a framework for
> > developing free operating systems, or a more generic tool for software
> > development and deployment?  If the latter it *cannot* do nefarious things
> > without explicit consent.  
> 
> Guix is a free operating system _and_ a generic tool for software
> development and deployment.   It makes no sense to say it does nefarious 
> things
> without explicit consent.  Just like you cannot try to prohibit GNU
> Make from being  used to do nefarious things like building malware.
> You cannot place usage restriction on free software.

We already do tho! We restrict what one can do if they interact with GPL code. 
Aside from that even Guix uploading all code from the packages to
SWH that basically feeds it to a LLM model is indeed not honoring consent of 
the author of the package. What you can do legally doesn't matter if you are an 
asshole after all.
So in this context it absolutely makes sense. Because we have social rules 
around consent and Guix doesn't seem to be following them currently.

MSavoritias

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Wed, 19 Jun 2024 16:41:33 +0200
Simon Tournier  wrote:

> Hi MSavoritias, all,
> 
> Let me provide more context.
> 
> The concern started couple of months ago, to my knowledge.  And
> discussion is still on going.  So I think that’s incorrect to say “any
> result for over 6 months”.

Hey Simon,

I was talking about the perspective of a guix person that is not part
of maintainers or any mailing lists that these discussions are
happening. So from my side there hasn't been any updates from SWH or
from Guix either for the named issue or the LLM issue.

> Moreover, I feel you have a misunderstanding about HuggingFace and SWH
> partnership.  From the reading of public information, HuggingFace and
> BigCode trains on a subset of SWH source code archive.  I mean, it is
> a snapshot and to my knowledge, they provided the list of source code
> that had been used for training.
> 
> Not to avoid the question but from a pragmatic point of view, one
> might ask if the source code you write and do not want to be included
> in the training dataset, if this source code is concretely part of
> that training dataset.
> 
> HuggingFace is not training continuously with source code from SWH.
> 
> And technically, SWH is an archive i.e., the code is not stored hot.
> I do not know and I have not read all details by HuggingFace of their
> method; i.e., which kind of data they process – independent unique
> files, complete repository, etc.  What I know is that the piece when
> fetching from SWH is named SWH Vault; it requires to “cook” and
> prepare all the files that take times, from minutes to days.

Thats all fair and valid. Sadly tho SWH:
- Doesn't even mention on their website anything about what happens to
  my code and where. so there is provenance. (unless i start searching
  HuggingFace.
- The email from the director that was sent to me says explicitly that
  they don't see an issue with it being opt-out after the fact and
  embrase LLMs usage. So that seems to me that its already in there. 

> All that to say two key points:
> 
> 1. People behind SWH are well-aware about various sides of the
> concerns. As said, they are long-time free software supporters.  Be
> sure they have eared community concerns.  Some discussions are still
> pending because as explained, all sides of ethical questions needs to
> be cautious.
> 
> Please do not think it is ignored.
> 
> 
> 2. FWIW, I am in touch with SWH people – among other members from Guix
> community.  For instance, in order to feed the discussion, Roberto
> from SWH pointed to me this blog point by Bruce Perens:
> 
> https://perens.com/2019/10/12/invasion-of-the-ethical-licenses/
> 
> Well, I do not know if the outcome will be aligned with your current
> opinion, but be sure that your concerns as the others raised by Guix
> community members are taking into account.

Thank you for giving me an honest and detailed answer.

I wish I could say this was encouraging but as things currently stand I
would like much more transparency about what is actually happening from
Guix and SWH. Because currently:
- The director seemed completely oblivious to any issues with LLMs or
  code harvesting without consent.
- Efraim seemed to have suggested that there hasn't been any
  communication and its even offtopic.
- Nothing has been written from Guix or SWH publicly about it and there
  are no mechanisms in place in the short term even to mitigate some of
  these things. (Which my next steps try to fix when I make the patches
  in a few weeks)

Regards,
MSavoritias
 
> Cheers,
> simon

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Wed, 19 Jun 2024 17:46:08 +0200
Ekaitz Zarraga  wrote:

> On 2024-06-19 12:25, raingl...@riseup.net wrote:
> > On 2024-06-19 11:54, Efraim Flashner wrote:  
> >> On Wed, Jun 19, 2024 at 12:13:38PM +0300, MSavoritias wrote:
> >> ...
> >> One of our packages, dbxfs, left Github a while ago and continued
> >> development on a different forge. They adjusted their README to
> >> disallow hosting of their code on Github. Based on this
> >> restriction we have labeled later versions of the software as
> >> non-free and have not updated the package. IMO saying that source
> >> code cannot be uploaded to SWH would fall into the same category.  
> > 
> > No wonder more and more people are growing dissatisfied with the
> > free software movement.
> >   
> 
Hey Ekaitz,

Please remember two things in the context of all of this:
1. Guix is not a software entity but it is made of people that want a
safer, collaborative space to create things. These things may be code,
a blog post or anything else as part of guix. Even a social network
account. I am saying this because you only talked about Free Software
in your message and not about people or different contexts.
And we are talking about people here. Not code. Code is not alive.

2. You seem to imply that Free Software or code is apolitical. (in the
sense of social or state politics not) Which it is not. Nothing is.
For example Free Software is explicitly pro-capitalist and
pro-Google/big companies. I am not saying I disagree, but its good
to keep in mind that politics exist and do exist always. And in the case

> There are many valid reasons why someone might criticize the Free 
> Software movement and people behind it, but making free software only 
> has 4 simple rules. If you don't comply with them you are not free 
> software anymore. It's as simple as that, and that simple it should
> be.
> 
> Free Software gives me the FREEDOM to print the code, make a roll
> with it and shove it up my ass if I want to (and even distribute my
> modified copies for other people to do so). The same freedom I have
> to upload it to github. If you prevent me from doing one or the other
> you are restricting my freedom and that's defeating the purpose of
> free software and we cannot consider your code free software anymore.
> The line is clear, and trying to pretend to be free software while
> restricting people's freedoms (regardless of what they are) is absurd.

This is missing the context that GPL does indeed restrict people's
freedom to license code as the see fit. Because it was written to
further the political goals of FSF. It is on purpose. So we are already
restricting the freedom of people to do what they want on purpose.

And lets not forget 
"your freedom ends where the other persons freedom begins"
and consent of course in the issue at hand.

> 
> The Free Software movement can be labeled (and is often labeled) as a 
> political movement but I'd say it's more of an ethical movement. It's
> a way to share *values* and the value we share here is freedom. We
> might or might not share other values, politics, religion or
> anything, but as long as we put the freedom in the first place we
> should agree that free software is better than any other software
> model we have.
> 
> There are bad actors in the world (say thieves, killers or... GitHub
> and AI), and we can discuss about how we should deal with them but I
> don't think the answer is putting our *values* aside but embrace them
> harder (one value, freedom, in our case).

Definetily agree. The solution is not to embrace propietary software or
restrict software. Its to write down some common social rules that are
rooted in consent.

> If people is not happy with the Free Software movement because it
> puts the freedom first, I can only understand it as people being mad
> about Free Software because it's about software.
> 
> For other values, we can start other initiatives I may or may not
> agree more with, but if the value is freedom (in software), I don't
> think there's any better way to push for it. But trying to disguise
> other things inside of the Free Software is kind of dishonest.

Fair. I mean we already have CoC and channel descriptions. Idk if we
have event guidelines/CoC yet but we should.

> I don't know, maybe I'm just a little bit tired.

No worries. I think it was very well said.

MSavoritias

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Wed, 19 Jun 2024 19:56:26 -0700
Felix Lechner  wrote:

> Hi MSavoritias,
> 
> On Wed, Jun 19 2024, MSavoritias wrote:
> 
> > I am not interested what the states or licenses/copyrights allow or
> > don't allow in this case. What I care about is what we expect as a
> > community when we submit a package/code to guix and if that violates
> > our social rules and expectations.  
> 
> Just in case the sweeping mention of our social rules and expectations
> includes me, please know that licensing and copyright are a big part
> of why I am a part of this community.
> 
> Kind regards
> Felix

Sure we all are.
But remember that we also have a CoC and social rules because building
a community can't be done on top of legal rules ie. copyright.
Just like social rules shouldn't be used for legal matters all the
time, same way with copyright for social rules. Which is what I am
saying here.

MSavoritias

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Wed, 19 Jun 2024 12:54:30 +0300
Efraim Flashner  wrote:

> On Wed, Jun 19, 2024 at 12:13:38PM +0300, MSavoritias wrote:
> > On Wed, 19 Jun 2024 09:52:36 +0200
> > Simon Tournier  wrote:
> >   
> > > Hi Ian, all,
> > > 
> > > On Tue, 18 Jun 2024 at 10:57, Ian Eure  wrote:
>
> > > I think that LLM asks ethical and legal question that even FSF or
> > > EFF or SFC does not provide clear answers.  (And that probably
> > > the level where the discussion should happen.)  That’s not a
> > > light topic and we should not rush in one definitive conclusion.
> > > 
> > > Thank you for the rise of the concern some weeks ago.  It appears
> > > to me good that people had expressed their concerns.  And still
> > > does. Although I am reading there or overthere an aggressive
> > > tone; useless.
> > > 
> > > Again, people behind SWH are long-term free software activists
> > > and be sure that they do not take this concern lightly.  FYI,
> > > people of SWH are in touch with some people from Guix to speak
> > > about all that.  
> > 
> > That is a very good point actually and it is one I also raised in
> > the email I sent. That we have been told there are some discussions
> > but we haven't seen any results for over 6 months now. Hence me
> > asking for anybody that has approached SH in an official Guix
> > capacity to step forward. Otherwise as I said I can approach SH :)  
> 
> The relationship between SWH and Hugging Face is (IMO) off-topic for
> the Guix mailing lists.  I'm not surprised that the discussions are
> happening elsewhere.

Given that any code and package that is contributed to Guix goes to SWH
and Hugging Face I would disagree.

> > > 2. Ethical.
> > > 
> > > If we speak about ethical concerns, we need to be very cautious.
> > > We all share the same core of values about free software.  Then
> > > we all do not bound these values to the same point.  Some of us
> > > extend them to some topics, other restrict a bit.
> > > 
> > > Here the issue is that other values than the ones about free
> > > software are dragged in the picture to emit a position.  That’s
> > > where we need to be cautious because we need to embrace the
> > > diversity and do not morally judge what is outside our free
> > > software project.
> > > 
> > > About SWH, FWIW, here is my moral reasoning; as you see, it is
> > > far to be definitive.  
> > 
> > I agree that we probably won't find any definitive answer if LLMs
> > are bad or not. But that is also not the question posed here tho.
> > 
> > The question posed here was that *all* code that is sent from Guix
> > to SH is automatically transfered without consent to be used in an
> > LLM model. That is without said process being opt-in and without
> > said process being transparent.  
> 
> I am not a lawyer, nor do I play one on TV.
> 
> Transferring the code is (legally) fine, using the code is (legally)
> fine, distributing the result is (I think) legally questionable.
> 
> If your concern is the code being transferred to the LLM owners, IMO
> that's already covered by the license of the code itself. As for what
> the LLM owners do with the code, (again I am not a lawyer) it should
> not make a difference if SWH gives them the code, they download it
> from Guix's infrastructure or get it straight from upstream.
> Redistributing the source code is allowed.

Idk if you read the email that was sent to Greg in the other thread.
Given that you replied there too I assume you did.
So given this context I am repeating again that is not about legal and
let me copy-past my reply to the legal argument:

Quote:
You seem to be arguing on a different thread or a point I never made. I
didn't talk about licenses or legal/state rules before you mentioned
them. What I have mentioned is that SH breaks our social rules and
expectations by feeding all code into an algorithm that will endlessly
output the same as original.

I am not interested what the states or licenses/copyrights allow or
don't allow in this case. What I care about is what we expect as a
community when we submit a package/code to guix and if that violates
our social rules and expectations. And from what I have seen and talked
with people it does indeed.

> > The second one could be solved by adding the disclaimer and making
> > the changes to commit packages as a i said. It can also be done I
> > was told by just stopping guix from uploading any new code to SH
> > from any package. which I would also be in favor.
> > The first 

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Wed, 19 Jun 2024 09:52:36 +0200
Simon Tournier  wrote:

> Hi Ian, all,
> 
> On Tue, 18 Jun 2024 at 10:57, Ian Eure  wrote:
> 
> > Guix is continuing to partner with SWH in spite of their continued 
> > support of these violations.  
> 
> Quickly because I am in the middle of a busy day. :-)

Hey Simon,

> 
> I think that LLM asks ethical and legal question that even FSF or EFF
> or SFC does not provide clear answers.  (And that probably the level
> where the discussion should happen.)  That’s not a light topic and we
> should not rush in one definitive conclusion.
> 
> Thank you for the rise of the concern some weeks ago.  It appears to
> me good that people had expressed their concerns.  And still does.
> Although I am reading there or overthere an aggressive tone; useless.
> 
> Again, people behind SWH are long-term free software activists and be
> sure that they do not take this concern lightly.  FYI, people of SWH
> are in touch with some people from Guix to speak about all that.

That is a very good point actually and it is one I also raised in the
email I sent. That we have been told there are some discussions but we
haven't seen any results for over 6 months now. Hence me asking for
anybody that has approached SH in an official Guix capacity to step
forward. Otherwise as I said I can approach SH :)

> 
> 1. Legal.
> 
> These license violations are your interpretation of the law and to my
> knowledge nothing have been in Court, yet.
> 
> Today, it does not really matter if we (or I) share this opinion.
> Because for now, it’s just an opinion.
> 
> However, no one is a lawyer here and drawing a clear line is not
> simple.
> 
> Thus, FWIW, I would not jump in hard conclusions based on my own
> opinion because today I am not confidant enough to emit a definitive
> legal position.
> 

That is fair, I agree that copyright wise and legal/state wise the
answer is not clear at all. And I don't think anybody in this mailing
list can decidely answer that as you said.

> 2. Ethical.
> 
> If we speak about ethical concerns, we need to be very cautious.  We
> all share the same core of values about free software.  Then we all
> do not bound these values to the same point.  Some of us extend them
> to some topics, other restrict a bit.
> 
> Here the issue is that other values than the ones about free software
> are dragged in the picture to emit a position.  That’s where we need
> to be cautious because we need to embrace the diversity and do not
> morally judge what is outside our free software project.
> 
> About SWH, FWIW, here is my moral reasoning; as you see, it is far to
> be definitive.

I agree that we probably won't find any definitive answer if LLMs are
bad or not. But that is also not the question posed here tho.

The question posed here was that *all* code that is sent from Guix to
SH is automatically transfered without consent to be used in an LLM
model. That is without said process being opt-in and without said
process being transparent.

The second one could be solved by adding the disclaimer and making the
changes to commit packages as a i said. It can also be done I was told
by just stopping guix from uploading any new code to SH from any
package. which I would also be in favor.
The first one can be done with social pressure which is what the
blogpost and the talking and potentially the not including SH into Guix
go towards.

Whether LLMs are ethical or not has nothing to do with the question
posted above. Although personally I would push for not including LLMs
unless under strict criteria of environmental and ethical sourcing. but
that can come at a later time.

I would also like SH to see why opt-in should be the default at the
very least, and the process should be transparent to everybody putting
code into SH. Archiving source code is a good cause. This is why
I said to approach them in official Guix capacity :)

MSavoritias

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Tue, 18 Jun 2024 13:31:02 -0400
Greg Hogan  wrote:

> On Tue, Jun 18, 2024 at 12:33 PM MSavoritias 
> wrote:
> >
> > Ah it seems I wasn't clear enough.
> > I meant write something like:
> >
> > By packaging a software project for Guix you are exposing said
> > software to a code harvesting project (also known as LLMs or "AI")
> > run by Software Heritage and/or their partners. Make sure you have
> > gotten fully informed consent and that the author of this package
> > fully understands what the implications are.
> >
> > Something like that. To make it clear that the package that is
> > about to be added to Guix is going to be harvested for the LLM
> > models Software Heritage decided to share the code with.
> >
> > Hope this is more clear.  
> 
> Free software licenses do not require bespoke consent to "to run the
> program, to study and change the program in source code form, to
> redistribute exact copies, and to distribute modified versions" (and
> "Being free to do these things means (among other things) that you do
> not have to ask or pay for permission to do so.").
> 
> Your fear mongering against free software runs afoul of Guix project
> guidelines ("In addition, the GNU distribution follow [sic] the free
> software distribution guidelines. Among other things, these guidelines
> reject non-free firmware, recommendations of non-free software, and
> discuss ways to deal with trademarks and patents.").
> 
> If you feel that LLMs/AI are violating the terms of a license, then
> feel free to pursue that through the legal system (potentially very
> profitable given the monetary penalties for violations of copyright).
> Otherwise, we should be celebrating the users and use of free
> software. I'm old enough to remember "Only wimps use tape backup:
> _real_ men just upload their important stuff on ftp, and let the rest
> of the world mirror it ;)"
> [https://lkml.iu.edu/hypermail/linux/kernel/9607.2/0292.html].

Hey Greg,

You seem to be arguing on a different thread or a point I never made. I
didn't talk about licenses or legal/state rules before you mentioned
them. What I have mentioned is that SH breaks our social rules and
expectations by feeding all code into an algorithm that will endlessly
output the same as original.

I am not interested what the states or licenses/copyrights allow or
don't allow in this case. What I care about is what we expect as a
community when we submit a package/code to guix and if that violates
our social rules and expectations. And from what I have seen and talked
with people it does indeed.

PS. I am also not a man :P

Regards,
MSavoritias

Re: Next Steps For the Software Heritage Problem

[MSavoritias]

On Tue, 18 Jun 2024 12:21:33 -0400
Greg Hogan  wrote:

> On Tue, Jun 18, 2024 at 4:37 AM MSavoritias 
> wrote:
> >
> > 1. Add a clear disclaimer/requirment that any new package that is
> > added in Guix, the person has to give consent or get consent from
> > the person that the package is written in. This needs to be added
> > in the docs and in the email procedures.  
> 
> You will be happy to know that Guix has always had this requirement
> [1] by only packaging software licensed with the four essential
> freedoms [2]. It's the first item on the Guix homepage.
> 
> [1] https://guix.gnu.org/manual/en/html_node/Software-Freedom.html
> [2] https://www.gnu.org/philosophy/free-sw.en.html

Ah it seems I wasn't clear enough.
I meant write something like:

By packaging a software project for Guix you are exposing said software
to a code harvesting project (also known as LLMs or "AI") run by
Software Heritage and/or their partners. Make sure you have gotten
fully informed consent and that the author of this package fully
understands what the implications are.

Something like that. To make it clear that the package that is about to
be added to Guix is going to be harvested for the LLM models Software
Heritage decided to share the code with.

Hope this is more clear.

MSavoritias

Next Steps For the Software Heritage Problem

[MSavoritias]

Hello,

Context:

As you may already know there have discussions around Software Heritage
and the LLM model they are collaborating with for a bit now. The model
itself was announced at
https://www.softwareheritage.org/2023/10/19/swh-statement-on-llm-for-code/

As I have started writing some packages I became interested in how I
might actually stop my code from ever reaching Software Heritage or at
the very least said LLM model. Every single package in guix is added
there automatically.

I sent an email on Friday and I got an answer back that such consent
mechanism hasn't been implemented and I was shown the legal terms.
instead what I am supposed to do is:

After guix has my code, my code will be automatically in Software
Heritage and the LLM model. So I am supposed to opt out seperately with
both of them to ensure that my code wont be used for future versions.
This of course means that my code will stay forever in Software
Heritage and the LLM model (or some version of it at least).

The reasoning that was given was that code harvesting happens anyway
and we give an opt-out. I am guessing its opt-out and not opt-in
because they would have less code but this is speculation of course :)

This is against our desire to make it a welcoming space and also
against the spirit of our CoC. Specifically because authors do not know
this happens when they submit packages to Guix. So it is all done
without consent.

Next Steps:

So what can we do as a Guix community from here?
Communication/Writing wise:

1. Add a clear disclaimer/requirment that any new package that is added
in Guix, the person has to give consent or get consent from the person
that the package is written in. This needs to be added in the docs and
in the email procedures.
2. Make a blog post of our stance towards Software Heritage and the
code harvesting they are doing. This post will write in environmental
and ethical grounds why Guix is against this and mention specifically
Software Heritage. This is done to separate and mention that we do not
like what is happening in case anyone comes asking, and hopefully give
public pressure to Software Heritage.
3. Exclude all Software Heritage merch, stands, talks, people in
official capacity, logos, or anything else that participates in social
events of guix and write it in some rules we have. also write in
channel rules that Software Heritage is offtopic same way Non-Free
Software is offtopic.
4. There doesn't seem to be any movement on the side of Guix towards:
- Accountability in an official capacity of SH for the terrible
  handling of the trans name incident and a plan to make it easier in
  the future.
- The LLM problem that was mentioned in this email.
So with that said I urge anybody who has been in contact with them in
an official Guix capacity to come forward, otherwise I can volunteer to
be that. Idk if we have a community outreach thing I need to be in also
for that. (we should if not)

The above make two assumptions:
1. That the Guix community is against LLM/"AI". Which for environmental
and ethical grounds we should be.
2. That we are a consent culture.

Coding Wise this has been talked about before some potential options
are:
- Communicate with Software Heritage to be able to give a "sign" that
the code that is sent should go or not in the code harvesting project.
- Remove all Software Heritage integration since its too hard to be
  ethical about it and built a better solution.

Conclusion:

To summarize from the steps I wrote above, it seems Software Heritage
makes it harder and harder for us to actually be an inclusive,
welcoming space we want to be. Idk what that leaves us, as I said I am
not part of any "insider" discussions. But it seems to not move that
much and its time to start doing actionable things in another direction.

MSavoritias

Re: Idea for packaging rust apps

[MSavoritias]

On 5/22/24 05:04, Murilo wrote:


Hello, I hope this is the right place for this, apologies if it isn't.

I'm working with a friend on a cargo importer that lowers the entry barrier
and the maintainability costs for packaging rust apps in general, without
sacrificing Guix dependency tracking and reproducibility of rust packages.

When you get used to the tool, you can pretty much package rust apps with
all the dependency chain very easily (I just packaged [1] texlab for my
channel earlier this morning in less than 5 minutes, and i can easily
update apps to the latest version in less than a minute).

Progress is being tracked in [2] if anyone wants to check it out or
contribute to it. It is currently missing a lot of features, but we hope
to improve the user experience of the tool in the near future.

It is a very simple tool, it essentially parses the Cargo.lock file and
extracts all the relevant information for constructing the rust package
definitions of all the cargo-inputs and the package itself, and outputs
to stdio a guile module containing all the needed cargo-input chain as
guix packages, with all the cargo-inputs self-contained and versions all
sorted out for a working final package build.

This way a packager only needs to focus on the actual package they are
trying to build, instead of worrying about its cargo-inputs.

Due to how cargo-inputs are organized in gnu/packages/crates-*.scm, and
some current packaging guidelines for crates on Guix, we cannot simply
contribute these self-contained packages generated directly from the
Cargo.lock, thus requiring to use the guix crate importer and spending
a lot of time fixing dependencies and worrying about other packages
breaking in the process.

I would like to propose some discussion around a better way of organizing
the rust packages and its cargo-inputs in (gnu packages) for building
rust apps that only need sources as cargo-inputs:

1) Create a new directory at gnu/packages/rust/ in which a contributor
can commit self-contained rust apps scm modules.
2.1) Add a new module at gnu/packages/rust/my-rust-app-1.scm
2.2) Add a new module at gnu/packages/rust/my-rust-app-2.scm
3) All package definitions inside gnu/packages/rust/*.scm which are
source-only (#:skip-build? #t) should not be exported.
4.1) gnu/packages/crates-*.scm will not cease to exist, existing rust
apps packages that have a Cargo.lock could gradually be migrated to the
new organization
4.2) libs which need to be built can still live in
gnu/packages/crates-*.scm
5) A (define-public my-rust-app-1 (@@ (gnu packages rust my-rust-app-1)
my-rust-app-1)) or equivalent could be done in a (gnu packages category)
module to export the rust app in the desired category.
6) Unlike nix (which also parses the Cargo.lock in the build system),
we don't lose the ability to make snippets for sources this way.
7) For updating/maintaining a rust package defined this way, one would
be able to simply re-run the guix tool, and replace the
gnu/packages/rust/my-rust-app.scm file, only copying over the final
relevant package definition for the rust app with its tweaks for building,
and passing over the new cargo-inputs generated by the guix tool.

I believe that by only changing the way things are organized and having
a guix tool that generates self-contained package definitions from
Cargo.lock, it would be possible to greatly improve the time required
for contributing new rust apps packages and maintaining them on Guix.

Things don't need to be the way I described here, these are just my
initial thoughts after several failed attempts and wasted time trying
to contribute rust apps to Guix, I'd like to discuss workarounds and if
the benefits are greater than the disavantages for an approach like this.

The tool we made works really well for packaging for our personal channels,
I am very satisfied with how easy it is, and I think Guix could benefit a
lot by adopting a similar approach.

What am I missing here? Are there any disavantages to this approach?
Anything that would break from it if adopted on Guix?
Any questions or suggestions?

Murilo

[1] 
https://codeberg.org/look/saayix/commit/c7643943545d62baba80cccee1650ebf94362858
[2] https://git.sr.ht/~look/cargo2guix


Hey Murilo,


Thank you for taking the initiative to do something about the rust 
packaging situation in Guix. Which currently less than optimal.


I wanted to ask, are you also aware of the antioxidant effort? 
https://notabug.org/maximed/cargoless-rust-experiments


I was wondering of the differences since your build system seems to 
still be using cargo under the hood instead of rustc.



MSavoritias

Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)

[MSavoritias]

On 3/21/24 17:23, Hartmut Goebel wrote:


Am 21.03.24 um 07:12 schrieb MSavoritias:
Specifically the social rules that we support trans people and we 
want to include them. Any person really that want to change their 
name at some point for some reason. 


Interestingly you are asking the right to get the old name rewritten 
for trans people only.


To be frank: IMHO This is a quiet egocentric point of view.

In many cultures all over the world women are required to change their 
name when they merry. And you are not asking for women's right. But 
only for right for the small but loud minority of trans people.



What are you implying with the "loud" minority here?


MSavoritias

Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)

[MSavoritias]

On 3/21/24 17:08, Giovanni Biscuolo wrote:

Hello pinoaffe,

pinoaffe  writes:

[...]


I think we, as Guix,
- should examine if/how it is currently feasible to rewrite our git
history,

it's not, see also:
https://guix.gnu.org/en/blog/2020/securing-updates/


- should examine possible workarounds going forward,
- should move towards something like UUIDs and petnames in the long run.

(see https://spritelyproject.org/news/petname-systems.html).

I don't understand how using petnames, uuids or even a re:claimID
identity (see below) could solve the problem with "rewriting history" in
case a person wishes to change his or her previous _published_ name
(petname, uuid...) in an archived content-addressable storage system.


It doesnt solve the problem of rewriting history. It solves the bug of 
having names part of the git history.


see also https://gitlab.com/gitlab-org/gitlab/-/issues/20960 for Gitlab 
doing the same thing.



MSavoritias



As a side note, other than the "petname system" please also consider
re:claimID from GNUnet:
https://www.gnunet.org/en/reclaim/index.html
https://www.gnunet.org/en/reclaim/motivation.html

[...]

Regards, Giovanni.


[1] https://guix.gnu.org/en/blog/2020/securing-updates/

Re: the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive)

[MSavoritias]

On 3/20/24 19:22, Giovanni Biscuolo wrote:


Hello Ludovic and Guix devel community!

Disclaimer: I've still not read all the relevant threads [3] [4], so
please forgive me if I repeat some information already provided.

What rights are we talking about?


You are making the same misconception as some other people in the thread 
here.


We are talking about social rules that we have here in the Guix 
community not legal/state rules.



Specifically the social rules that we support trans people and we want 
to include them. Any person really that want to change their name at 
some point for some reason.


To that end we listen to their concerns/wishes and we accommodate them.



As a *free software* user do I have the right to redistribute /old/
copies of the source code and documentation I got in the past from the
copyright holder, in any form (e.g. print)?... or to use old sources or
documentation to develop derived work, with _attribution_, without
asking for consent from the original authors and/or contact the original
authors to ask them what is their current name?


Copyright is not consent. When we are talking about consent we are 
talking about it in social rules.


See also 
https://www.consentfultech.io/wp-content/uploads/2019/10/Building-Consentful-Tech.pdf 
as a nice paper for consent in tech.



If yes, I would like to exercise all my rights without being harassed.


Again this has nothing to do with rights granted by states. This is 
about including people and making them feel safe and respected.



MSavoritias



Also, SHW and other organizations (re)distributing free software have
their rights and should excercise them without being harassed.

Ludovic Courtès  writes:

[...]

Re: Guix role in a free society

[MSavoritias]

On 3/18/24 20:16, Tomas Volf wrote:

On 2024-03-18 18:48:27 +0100, Vivien Kraus wrote:

The guix users, I claim, would rather have a distribution of guix (and
the packages it provides) with accurate personal information, even if
it means to be annoyed for a moment with a security system.

Single data point: As a Guix user (and occasional contributor, albeit not a
committer), I would very much prefer a system that does not rewrite the history.
When someone wants to correct their name (for whatever reason), I would prefer
it to be done going forward, not retroactively.

I think making such broad statements without some empirical study is not great,
since it is, as you said yourself, just your claim not supported by anything (as
far as I can tell).

Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


It pretty easy to see who most people that use Guix agree with that 
actually. Check what the CoC says right here -> 
https://git.savannah.gnu.org/cgit/guix.git/tree/CODE-OF-CONDUCT


|We as members, contributors, and leaders pledge to make participation 
in our community a harassment-free experience for everyone, regardless 
of age, body size, visible or invisible disability, ethnicity, sex 
characteristics, gender identity and expression, level of experience, 
education, socio-economic status, nationality, personal appearance, 
race, caste, color, religion, or sexual identity and orientation. We 
pledge to act and interact in ways that contribute to an open, 
welcoming, diverse, inclusive, and healthy community. |


So since the Guix community have agreed to make it welcoming to 
everybody we have to take into account people that will want to change 
their names.


Social inclusion and people are above any tech ideals we may have.


We dont need to rewrite history at all also. There was a solution 
already by Gitlab which was also proposed in the other thread (for legal 
reasons) to do with UUIDs.



MSavoritias

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 17:14, Andreas Enge wrote:


Am Mon, Mar 18, 2024 at 04:33:49PM +0200 schrieb MSavoritias:

Actually gitlab already is facing something like that and they are doing
what was proposed elsewhere: mapping of UUIDs to display names
https://gitlab.com/gitlab-org/gitlab/-/issues/20960

Interesting, thanks! It is something that maybe could be implemented by
Savannah, but it would probably require a bit of thought. And yet again,
somehow the mapping uuid<->"real" names would have to be public (people
would "git clone" commits with uuids, and would need to locally replace
them by "real" names); so people can always keep copies of the mapping
over time.

Sure. But we can only say about Guix not everything else.

I am also not quite sure about the signing process for committers;
in principle keys are enough, but in GPG they are tied to email addresses,
and I do not know whether we use this in Guix.

I hope we don't because i use ssh to sign commits personally :D


In the end, my impression is this will not achieve much more than what we
already have with the .mailmap approach. In a sense, everyone would use
a pseudonym (their uuid), and then we would keep a mapping between these
pseudonyms and, well, "real" names or other pseudonyms chosen by the
contributors...

Hm, this could indeed be implemented exactly with .mailmap, no?
We would need to enforce that authors use a uuid of a specific format,
and potentially an empty or dummy email address, or another uuid.
Then we could keep a .mailmap file. The history of "real" identities
would still be visible in the git history, but as said above, anyway
we could not prevent people from storing the association information
over time.


Nicknames may change tho. UUIDs are not in any way meaningful to humans 
so i doubt we would need to change them.


I have changed nicknames once for example.


Right fair. As I have said before SWH does break Guix CoC effectively right
now.
So what Guix does from this point on will effectively dictate if the CoC is
valid or not.

Well, the CoC is valid on our communication channels; so what SWH does with
our software is outside its scope (that is governed by the license).

Andreas



My question was more like:


In the next Guix Days or any Guix conference, do we allow SWH to 
participate if this matter is still unresolved?


Because we would be basically inviting people that don't respect the CoC.


MSavoritias

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 16:19, Andreas Enge wrote:


Am Mon, Mar 18, 2024 at 04:03:20PM +0200 schrieb MSavoritias:

Rewriting history is the wrong question imo. I dont think a request to
change all of the history of Guix will be accepted anyway.
A much easier thing to do is to change the approach in the future. And let
all the past history untouched.

I was well thinking about the future history as well as the past one...
Everything we do now becomes unmutable history in the future; so the
question how we can rewrite an a priori unmutable history remains the same,
regardless of the date when person X wants to be known as person Y: Also in
the future, someone may wish to travel to a time before the change.
And the fundamental problem of history rewriting remains; I do not see
how we could simplify it. So I do not think that it is "a much easier
thing to do". Please feel free to prove me wrong by making a concrete
suggestion!


Actually gitlab already is facing something like that and they are doing 
what was proposed elsewhere: mapping of UUIDs to display names


https://gitlab.com/gitlab-org/gitlab/-/issues/20960


So no reason we couldn't do something like this.



Am Mon, Mar 18, 2024 at 04:00:38PM +0200 schrieb MSavoritias:

On 3/18/24 15:12, Simon Tournier wrote:

Again, this is an incorrect frame, IMHO.  Software Heritage (SWH) do the
things you granted them to do.  SWH respects the “ethical” definition of
“free software”.

You are bringing the legal argument again. The argument that you can do what
you want with Free Software is based around a licence which is a legal
construct of states.

I think there is a misunderstanding here, rooted in the use of "you" in
"you can do what you want". We need to be clear about whom we are speaking.
There is SWH, and what they can do is a result of the free license. The
other question is what we as the Guix community want to do (and can do);
I would suggest to concentrate in our discussion on the latter, which is
where we have agency.

Andreas


Right fair. As I have said before SWH does break Guix CoC effectively 
right now.


So what Guix does from this point on will effectively dictate if the CoC 
is valid or not.



MSavoritias

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 15:35, Andreas Enge wrote:


Hello all,

Am Mon, Mar 18, 2024 at 12:26:18PM +0100 schrieb Simon Tournier:

Therefore, it would be more constructive if you come with a
proof-of-concept allowing “history rewrite” and strong “software
identification” property

the one thing I can think of, and which would allow time travel to coexist
with history rewriting, is an additional layer of metainformation.

First of all, when rewriting history, all commits from the bifurcation
to an alternate universe must be signed again by the person doing the
"time split"; so there is a loss of information there.

Second, we need to create a table that associates every old, lost commit
hash to the corresponding new commit hash; this should also be signed by
the person rewriting history.

Of course this will have to be continued to the future: If Guix has n
commits and m history rewrites, then the m-th rewrite may have to create
a table of n entries that link commit hashes of the m-th rewrite to those
of the (m-1)-th rewrite. Total memory would become m*n entries.

When doing time travel to a commit hash, one would need to check whether
it is available in the current, m-th history rewrite; if not, one would
need to look for it in the (m-1)-th rewrite and map it to a commit hash
in the m-th rewrite; if not, one would have to look for it in the (m-2)-th
rewrite and map it to a hash in the (m-1)-th rewrite, and then check
whether or not it has been overwritten in the m-th rewrite. The total
time complexity would be m look-ups in tables of size n each.


It is a lot of effort; and probably for little gain, since we cannot
eradicate each and every fork of the Guix git repo. The old data will
still be available at SWH, and probably at random forks on lots of random
forges all over the world. As Simon, I think that history, fundamentally,
cannot be rewritten: What has happened in the past, has happened in the
past. If you have done some public activity as the person known as X, and
then change your name to Y, you cannot prevent your past activity to be
known under identity X. Also, the time split would have to be publicly
documented somehow; if we add as rationale for a history rewrite "person X
is now known as Y", not much is gained compared to just keeping the old
commits. Not documenting the rationales for history rewrites would not help
to instill trust in the codebase, and probably not solve the problem either,
since it is quite likely that the request by person X to now be addressed
as Y will have been made on the mailing list or some other public forum.

So my impression is that the .mailmap approach in the Guix project is a
good compromise between acknowledging the wish of people to be known under
identity Y, and what can reasonably be achieved to hide identity X.

Well, there are things people can do individually:
1) Use a pseudonym P from the start instead of X (which is admitted in
the Guix community, just look at a few of the names: there are pseudo-
nyms with clearly made-up first and last names, there are very obvious
one-word pseudonyms, and maybe some of the names that look like real
names are not from the persons' passports, who would know).
2) This does not help, of course, if you are already known as X and want
to be known as Y. Then either you can somehow make the change publicly,
and transfer your reputation and also the information that you used
to be known as X, or disappear as X and reappear as a new person Y
and lose X's reputation. Doing both is impossible, I would say.

Andreas

Rewriting history is the wrong question imo. I dont think a request to 
change all of the history of Guix will be accepted anyway.


A much easier thing to do is to change the approach in the future. And 
let all the past history untouched.



MSavoritias

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 15:12, Simon Tournier wrote:

Hi MSavoritias,

On lun., 18 mars 2024 at 13:47, MSavoritias  wrote:



As advice for the future when somebody says a concern or wish they have,
your first statement shouldn't be "but its legal" because that
completely dismisses any constructive discussion that could be done.

Again, I am not arguing about “legal” something.  Instead, I am pointing
that this wish does not match the principles of “free software”.

If you accept that the software you create is “free software” then you
cannot complain if this “free software” is used in some contexts that
you consider unethical.

That’s the double sword of “free software”.

Do I consider LLMs as something unethical?  I think yes: most AI appears
to me unethical but that’s another story (rooting my arguments in
arguments about energy [2,3,4]).

2: https://social.sciences.re/@zimoun/112082437445032973
3: https://social.sciences.re/@zimoun/112039562095800532
4: https://social.sciences.re/@zimoun/112038609631116527

Yes you are. The argument that you can do what you want with Free 
Software is based around a licence which is a legal construct of states.


I think you have misunderstood that here we are talking about the social 
rules of being a decent group of human beings and respect somebody 
else's wishes.



What is in question here is whether Software Heritage respects people
enough to do the right thing and respect their wishes without getting
lawyers/legal involved.

Again, this is an incorrect frame, IMHO.  Software Heritage (SWH) do the
things you granted them to do.  SWH respects the “ethical” definition of
“free software”.


You are bringing the legal argument again. The argument that you can do 
what you want with Free Software is based around a licence which is a 
legal construct of states.


I think you have misunderstood that here we are talking about the social 
rules of being a decent group of human beings and respect somebody 
else's wishes.


In this case somebody asks for something so if SFH is a good member of 
our community they should do that. Otherwise they are not a good member 
of our community.





Besides with the way you are framing Free Software as not respecting any
social rules then that makes Free Software not attractive which is the
opposite of what we are trying to do here :)

I do not know what are the “social rules” of “free software”.  At best,
I understand the social rules of a community working on free software.

And this community is far to be an homogeneous whole with clear social
rules.  These social rules vary and the only shared denominator is the
“free software” principles defined by four freedoms.


Guix has a CoC that's the common thing we have here. For social things 
that is. Plus some cultural things of course.



MSavoritias

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 11:28, Simon Tournier wrote:


Hi,

On sam., 16 mars 2024 at 08:52, Ian Eure  wrote:


They appear to be using the archive to build LLMs:
https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/

About LLM, Software Heritage made a clear statement:

 https://www.softwareheritage.org/2023/10/19/swh-statement-on-llm-for-code

Quoting:

 We feel that the question is no longer whether LLMs for code
 should be built. They are already being built, independently of
 what we do, and there is no turning back.  The real question is
 how they should be built and whom they should benefit.

Principles:

 1. Knowledge derived from the Software Heritage archive must be
 given back to humanity, rather than monopolized for private
 gain. The resulting machine learning models must be made available
 under a suitable open license, together with the documentation and
 toolings needed to use them.

 2. The initial training data extracted from the Software Heritage
 archive must be fully and precisely identified by, for example,
 publishing the corresponding SWHID identifiers (note that, in the
 context of Software Heritage, public availability of the initial
 training data is a given: anyone can obtain it from the
 archive). This will enable use cases such as: studying biases
 (fairness), verifying if a code of interest was present in the
 training data (transparency), and providing appropriate attribution
 when generated code bears resemblance to training data (credit),
 among others.

 3. Mechanisms should be established, where possible, for authors to
 exclude their archived code from the training inputs before model
 training begins.

I hope it clarifies your concerns to some extent.


Moreover, you wrote: « I want absolutely nothing to do with them. »

Maybe there is a misunderstanding on your side about what “free
software” and GPL means because once “free software”, you cannot prevent
people to use “your” free software for any purposes you dislike.

If you want to bound the use cases of the software you create, you need
to explicitly specify that in the license.  And if you do, your software
will not be considered as “free software”.

That’s the double sword of “free software”. :-)


Simon,


1.

You seem to be misunderstanding the statement here that was said.

What you can do legally and what you can do socially are not always the 
same thing.


As advice for the future when somebody says a concern or wish they have, 
your first statement shouldn't be "but its legal" because that 
completely dismisses any constructive discussion that could be done.


And you seem to be talking about legal a lot here so thats not a good look.


Yes, legally Ian probably can't get lawyers on you. But nobody is 
talking about legally here.


What is in question here is whether Software Heritage respects people 
enough to do the right thing and respect their wishes without getting 
lawyers/legal involved.



Besides with the way you are framing Free Software as not respecting any 
social rules then that makes Free Software not attractive which is the 
opposite of what we are trying to do here :)



2.

> Somehow, a Content-Addressed system is designed around immutable 
content. And if one know how to implement a Content-Addressed system 
relying on mutable content, I would be very interested to know more 
about it.



Please refrain from doing such remarks. Nobody here suggested anything 
that you mention here and you effectively devalue the discussion by 
arguing like this and frame other people as stupid.



3.

Its not on people that are not included to write the code. If Guix is to 
be an inclusive project, then Guix should do the work so that people 
feel included.


You may disagree with this sure, but shutting down the discussion 
because nobody wrote the code for you is very elitist of you.



4.

> This language is not acceptable on Guix channel of communication.

Calling out transphobia it is very much accepted here actually :)

Its transphobic speech that is not accepted.


I welcome Software Heritage to make an announcement about this or some 
kind of official communication saying their stance.


Although I still wouldn't use them due to the LLMs and AI stuff that 
they are using. Which I hope at some point realize their mistake.



MSavoritias

Re: rewriting history; Was: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/18/24 02:10, Attila Lendvai wrote:


I was also distressed to see how poorly they treated a developer
who wished to update their name:
https://cohost.org/arborelia/post/4968198-the-software-heritag
https://cohost.org/arborelia/post/5052044-the-software-heritag


let's put aside the trans aspect of this question for a moment, because this 
question has broad implications, much broader than the regrettable struggles of 
trans people.

the question here is whether person A has the right to demand that others 
change their memory of A's past actions (i.e. rewrite history, or else become a 
felon... or maybe just unwelcome in polite society?).

so, let's just assume that i have decided to prefer being called a new name 
(without disclosing my reasons).

is it reasonable for me to demand from somebody else to change their memory of 
my past actions? e.g. to demand that they rewrite their memory/instances of my 
books that i have published under my previous name in the past? or that they 
forget my old name, and when the change happened? or that they do not link the 
two names to the same individual?

if so, then where is the line? what's the principle here? and what are its 
implications?

do i have the right to demand the replacement of a page in each copy that 
exists out there? i.e. should it be criminal (or just a sin?) to own old 
copies? do i have the right to demand that certain libraries must sell/burn 
their copies of my books and never own them again?

what if i committed a fraud? e.g. i pushed a backdoor somewhere... do i have 
the right to memory-hole my old identity?

and who will enforce such a right? the government? i.e. those people who already keep an 
(extralegal) record of whenever i farted in the past decade? where can i even file my 
GDPR request for that? would that really be a "right to be forgotten", or 
merely a tool of even tighter monopolization of The Central Database?

what if i'm a joker and i demand a new change every week for the rest of my 
life? do i have the right to the resources of every library out there? to keep 
their staff and computers busy for the next couple of decades?

but let's put the technical aspects aside; wherever we draw the line... what 
are the implications of that for borader society? because i sure see some 
actors out there who can hardly wait to start erasing certain records at the 
barrel of the law, including rewriting books of significance... (and while we 
are at it, i suggest to start preserving your offline/local copies, because 
we're up to a wild ride!)

humanity has reached an enormous challenge with the complete marginalization of 
the costs of storing and transmitting information. it's a completely 
new/different playing field, and how we proceed from here has grave 
implications. this questions is nowhere near as obvious/trivial as presented in 
the cited blog post.

The right of a trans person to ask a project to not advertise their 
deadname was never in question.


Guix is a place that supports trans people and anybody else that wants 
to change their name.


We don't need "enforcers" here or put the "burden of proof" on people.


MSavoritias

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/17/24 18:20, Ian Eure wrote:



MSavoritias  writes:


On 3/17/24 11:39, Lars-Dominik Braun wrote:

Hey,


I have heard folks in the Guix maintenance sphere claim that we

never rewrite git history in Guix, as a matter of policy. I believe
we should revisit that policy (is it actually written anywhere?)
with an eye towards possible exceptions, and develop a mechanism for
securely maintaining continuity of Guix installations after history
has been rewritten so that we maintain this as a technical
possibility in the future, even if we should choose to use it
sparingly.
the fallout of rewriting Guix’ git history would be devastating. It
would break every single Guix installation, because

a) `guix pull` authenticates commits and we might lose our trust anchor
if we rewrite history earlier than the introduction of this feature,
b) `guix pull` outright rejects changes to the commit history to 
prevent

downgrade attacks.

Additionally it would break every single existing usage of the
time machine and thereby completely defeat the goal of providing
reproducible software environments since the commit hash is used to
identify the point in time to jump to.

I doubt developing “mechanisms” – whatever they look like – would
be worth the effort. Our contributors matter, but so do our users. 
Never
ever rewriting our git history is a tradeoff we should make for our 
users.


Lars



Thats a good point. in the sense that its a tradeoff here and I
absolutely agree.


But let me add some food for thought here:

1. Were the social aspects considered when the system came into place?

2. Is it more important for the system to stay as is than to welcome
new contributors?

3. You mention "its a tradeoff we should make for our users". How many
trans people where involved in that decision and how much did their
opinion matter in this?


I am saying this because giving power to people(what is called users)
is not only handling them code or make sure everything is free
software.

Its also the hard part of making sure the voices of people that can
not code is heard and is participating and taking in mind.



Just want to say that I appreciate and agree with your thoughtful words.

I’d also note that name changes aren’t a concern limited to trans 
people, and framing this as "we have to upend everything Because 
Transgender" is both wrong and feels pretty bad to me.  Anyone can 
change their name at any time for any reason, or no reason at all, and 
may wish to update historical references to their previous names.  
Having a mechanism to support this is, in my view, a matter of basic 
decency and respect for all humans.


Thanks,

 — Ian


You are right. I failed to see how it could be desirable for other 
people too.


I agree it should be done for everybody.


MSavoritias

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/17/24 13:53, paul wrote:

Hi all ,

thank you MSavoritias for bringing up points that many of us share. 
It's clearly a tradeoff what to do about the past. For the future, as 
Christpher already stated, we need a serious solution that we can 
uphold as a free software project that does not alienate users or 
contributors.


My opinion is that names are just wrong to be included, not only 
because of deadnames, but in general having a database with a column 
first_name and a column second_name is something only a 35 yrs old 
white cis boy could have thought was a good idea to model the spectrum 
of names humans use all over the world:


https://web.archive.org/web/20240317114846/https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ 



If we'd really need to identify contributors, and obviously Guix 
doesn't, we could use an UUID/machine readable identifier which can 
then be mapped to a displayed name. I believe git can already be 
configured to do so.



giacomo



The uuid sounds like a very interesting solution indeed.

I wonder how easy it could be to add it to git.


I agree that making some rules about names that are going to be wrong at 
some point or in some place is the wrong solution long term for sure.



MSavoritias

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/17/24 11:39, Lars-Dominik Braun wrote:

Hey,


I have heard folks in the Guix maintenance sphere claim that we never rewrite 
git history in Guix, as a matter of policy. I believe we should revisit that 
policy (is it actually written anywhere?) with an eye towards possible 
exceptions, and develop a mechanism for securely maintaining continuity of Guix 
installations after history has been rewritten so that we maintain this as a 
technical possibility in the future, even if we should choose to use it 
sparingly.

the fallout of rewriting Guix’ git history would be devastating. It
would break every single Guix installation, because

a) `guix pull` authenticates commits and we might lose our trust anchor
if we rewrite history earlier than the introduction of this feature,
b) `guix pull` outright rejects changes to the commit history to prevent
downgrade attacks.

Additionally it would break every single existing usage of the
time machine and thereby completely defeat the goal of providing
reproducible software environments since the commit hash is used to
identify the point in time to jump to.

I doubt developing “mechanisms” – whatever they look like – would
be worth the effort. Our contributors matter, but so do our users. Never
ever rewriting our git history is a tradeoff we should make for our users.

Lars


Thats a good point. in the sense that its a tradeoff here and I 
absolutely agree.



But let me add some food for thought here:

1. Were the social aspects considered when the system came into place?

2. Is it more important for the system to stay as is than to welcome new 
contributors?


3. You mention "its a tradeoff we should make for our users". How many 
trans people where involved in that decision and how much did their 
opinion matter in this?



I am saying this because giving power to people(what is called users) is 
not only handling them code or make sure everything is free software.


Its also the hard part of making sure the voices of people that can not 
code is heard and is participating and taking in mind.


I am not trying to say what we should do about commit history rewriting 
here. Personally the tradeoffs are probably worth it.


But I am trying to say what Guix should do as a culture over including 
people or excluding in the case of Software Heritage.



MSavoritias

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/16/24 21:45, Tomas Volf wrote:

On 2024-03-16 20:24:50 +0200, MSavoritias wrote:

I was also distressed to see how poorly they treated a developer who
wished to update their name:
https://cohost.org/arborelia/post/4968198-the-software-heritag
https://cohost.org/arborelia/post/5052044-the-software-heritag

This is probably worth thinking about as Guix is in a similar situation
regarding publishing source code, and people potentially wanting to
change historical source code both in things Guix packages and Guix
itself.

Like Software Heritage, there's cryptographical implications for
rewriting the Git history and modifying source tarballs or nars that
contain source code.

We have 17TiB of compressed source code and built software stored for
bordeaux.guix.gnu.org now and we should probably work out how to handle
people asking for things to be removed or changed (for any and all
reasons).

It's probably worth working out our position on this in advance of
someone asking.

I would go a step further actually. Software Heritage is effectively
breaking CoC of Guix now.

Im not proposing removing all code or something obviously that connects to
Software Heritage, but there should be some social action we can take.


For example until the matter is resolved and Software Heritage implements a
process that respects trans rights Software Heritage should not be welcome
in Guix Spaces.

I did skim the articles and I did not see any details on what the technical
solution should be.  SWH, among other things, archives the repositories and
allows fetching them by commit hash.  At least as far as I know.  Since that
commit hash does contain the author field, what is the proposed solution here to
change the author name without changing the commit hash?

While I am not a huge fan of the ability to map the "fake" author name over the
real one in the UI, what other solutions do you or the article author envision?
I am genuinely curious what you think can be done here.


I think you are arguing for something else than what I wrote? I didn't 
say about technical solutions and that's up to Software Heritage to 
figure it out.


I did say that there should be social consequences since Software 
Heritage is breaking CoC here.


And by breaking CoC I mean that Software Heritage seems to have a 
complete lack of empathy towards trans people.



Regarding what Guix could do personally the answer is clear: People are 
more important than machines and code.


So we should find a way that trans people feel safe in Guix.


MSavoritias


Have a nice day,
Tomas Volf

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/16/24 19:50, Christopher Baines wrote:

Ian Eure  writes:


Hi Guixy people,

I’d never heard of SWH before I started hacking on Guix last fall, and
it struck me as rather a good idea.  However, I’ve seen some things
lately which have soured me on them.

They appear to be using the archive to build LLMs:
https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/

I was also distressed to see how poorly they treated a developer who
wished to update their name:
https://cohost.org/arborelia/post/4968198-the-software-heritag
https://cohost.org/arborelia/post/5052044-the-software-heritag

GPL’d software I’ve created has been packaged for Guix, which I assume
means it’s been included in SWH.  While I’m dealing with their (IMO:
unethical) opt-out process, I likely also need to stop new copies from
being uploaded again in the future.

Is there a way to indicate, in a Guix package, that it should *never*
be included in SWH?

Not currently, and I don't really see the point in such a mechanism. If
you really never want them to store your code, then you need to license
it accordingly (and not make it free software).


You are talking about legal tho. Yes legally they can copy the code.

But what can Guix do socially to give people the choice? For reasons of 
consent that is.



I was also distressed to see how poorly they treated a developer who
wished to update their name:
https://cohost.org/arborelia/post/4968198-the-software-heritag
https://cohost.org/arborelia/post/5052044-the-software-heritag

This is probably worth thinking about as Guix is in a similar situation
regarding publishing source code, and people potentially wanting to
change historical source code both in things Guix packages and Guix
itself.

Like Software Heritage, there's cryptographical implications for
rewriting the Git history and modifying source tarballs or nars that
contain source code.

We have 17TiB of compressed source code and built software stored for
bordeaux.guix.gnu.org now and we should probably work out how to handle
people asking for things to be removed or changed (for any and all
reasons).

It's probably worth working out our position on this in advance of
someone asking.


I would go a step further actually. Software Heritage is effectively 
breaking CoC of Guix now.


Im not proposing removing all code or something obviously that connects 
to Software Heritage, but there should be some social action we can take.



For example until the matter is resolved and Software Heritage 
implements a process that respects trans rights Software Heritage should 
not be welcome in Guix Spaces.



MSavoritias

Re: Concerns/questions around Software Heritage Archive

[MSavoritias]

On 3/16/24 17:52, Ian Eure wrote:


Hi Guixy people,

I’d never heard of SWH before I started hacking on Guix last fall, and 
it struck me as rather a good idea.  However, I’ve seen some things 
lately which have soured me on them.


They appear to be using the archive to build LLMs: 
https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/


I was also distressed to see how poorly they treated a developer who 
wished to update their name: 
https://cohost.org/arborelia/post/4968198-the-software-heritag 
https://cohost.org/arborelia/post/5052044-the-software-heritag


GPL’d software I’ve created has been packaged for Guix, which I assume 
means it’s been included in SWH.  While I’m dealing with their (IMO: 
unethical) opt-out process, I likely also need to stop new copies from 
being uploaded again in the future.


Is there a way to indicate, in a Guix package, that it should *never* 
be included in SWH?


Is there a way to tell Guix to never download source from SWH?

I want absolutely nothing to do with them.

Thanks,

 — Ian



Oh no.

Apparently they have A.I. and blockchain besides being also transphobic.

Thanks for the heads up. That's all I needed to know to never touch 
whatever they are doing.



MSavoritias

Re: RFI: Guix XMPP service.

[MSavoritias]

On 12/10/23 17:56, Vivien Kraus wrote:

Le dimanche 10 décembre 2023 à 17:45 +0200, MSavoritias a écrit :

There is also a trust issue. For acceptance, we need bridging. For
bridging, we need policing. And for policing, we need people with
time.

That's a good question yeah. Whether we want bridging that is.
Personally I am leaning that we don't.

Because bridging can ruin the experience of people that use XMPP. But
I
can see it either way.

Maybe we could do something a little smarter, like having sneek deliver
messages in both IRC and XMPP.

Vivien


There are mirroring ways yeah. That would be a better solution.

Because there is biboumi but it basically just creates an IRC room in XMPP.


Also sneek should filter stuff probably. Because xmpp allows pictures 
and long messages and such.


So it shouldn't mirror everything as is. I don't know how possible it is 
though. Maybe some custom setup of something.



That said I do have my doubts whether this is more trouble than its 
worth personally.


Given that IRC and XMPP are two very different protocols that are 
probably gonna attract a different community.



MSavoritias

Re: RFI: Guix XMPP service.

[MSavoritias]

On 12/10/23 16:43, Felix Lechner wrote:

Hi MSavoritias,

On Sun, Dec 10 2023, MSavoritias wrote:


Do you think it would be ok to use a VPS? Or do we want a physical
server at somebody's home?

It's a community question. Everyone knows about IRC, and it works
well. I'm not sure there is a "we want" for XMPP, even though the
protocol is superior.


"We want" was in the context of what would be acceptable as hosting so 
that we can have the room under the same domain as guix.


The past few days has given me an indication that there is a good amount 
of people that want something else than IRC and email.




There is also a trust issue. For acceptance, we need bridging. For
bridging, we need policing. And for policing, we need people with
time.


That's a good question yeah. Whether we want bridging that is. 
Personally I am leaning that we don't.


Because bridging can ruin the experience of people that use XMPP. But I 
can see it either way.


Regarding moderation its not a problem to find moderators for the room. 
Add like 5-10 of them so that we always have somebody online. I have 
been running XMPP for the past two years like this.



Libera.chat has great volunteers that have a long track record in
maintaining a service that people rely upon. A group of people would
have to step up for XMPP here.


I agree. Hopefully this thread will encourage some people that there is 
a chance we have an XMPP instance :D


And we (the people doing/wanting the xmpp instance) can get some 
permission to set it up under a guix domain.


MSavoritias



Kind regards
Felix

Re: RFI: Guix XMPP service.

[MSavoritias]

On 12/10/23 05:53, Felix Lechner wrote:

Hi,

On Fri, Dec 08 2023, MSavoritias wrote:


2. We can self host our own prosody instance.

I host my own Prosody instance (mostly to talk to Soprani). [1][2] I
recommend the project host its own, as well.


Yeah the consensus so far seems to be to host our own. It is pretty easy 
as you said so it shouldn't be a problem for me to maintain it.


Do you think it would be ok to use a VPS? Or do we want a physical 
server at somebody's home?



The server is very lightweight. Unfortunately, my system's uptime
history is not suitable for a project instance.

For DNS, I'd be happy to offer help.juix.org, but an official address is
probably better.


Yeah under the guix domain would be best. We also have the guix.info of 
the foundation but idk how good it would be to be under that.



XMPP is great. Thanks for the initiative!

Yw ^^ Was missing an XMPP instance and since i can step up I did :)

Kind regards
Felix

[1] 
https://codeberg.org/lechner/system-config/src/commit/b566b08a982a12f896cd6ef7849dbac0ce2e/host/wallace-server/operating-system.scm#L1195-L1200
[2] Message retention in my setup may only be thirty days.


MSavoritias

Re: RFI: Guix XMPP service.

[MSavoritias]

On 12/8/23 20:43, Vivien Kraus wrote:

Hello Guix!

Le vendredi 08 décembre 2023 à 19:22 +0200, MSavoritias a écrit :

I propose to host an xmpp instance with a room/or some rooms under
the
guix domain. Something like xmpp.guix.gnu.org

Are there options for guests?

I don’t know how XMPP or Prosody or cheogram.com may handle this, but
the way I imagine it, we could have an array of guest accounts and
reserve one for anyone that would ask for it, for something like a
week. The guest accounts need not communicate with another server, so
we wouldn’t relay spam.

Maybe there’s something more convenient or more standard though. What
do you think?

Best regards,

Vivien



yes it does. from the page I linked it says:

Once configuration is complete, your chatroom will be accessible to 
anyone on the XMPP federation, as well as on the web via 
anonymous.cheogram.com <https://anonymous.cheogram.com/>.


You basically enter the address of the group chat you want and a 
nickname and you chat without an account. but only in the rooms in the 
guix server of course. same as IRC.



MSavoritias

RFI: Guix XMPP service.

[MSavoritias]

Hello o/


I would like to do a formal proposal to make an official Guix XMPP instance.


Background:

I asked a couple of days ago if it would be possible to have an XMPP 
room listed on the Guix site next to the IRC. I also asked in IRC and 
shared it on ActivityPub.


The response was very enthusiastic, thank you everyone for joining and 
spreading the message. ^^


It was said though that listing it on the website would make it 
official, plus some other concerns around log retention. Hence this 
proposal here. :)


For those that do not know XMPP is a protocol for many things, one of 
them being messaging. It has been active for more than 20 years now and 
is still being developed.



Who am I:

I have been around Guix for a bit in IRC and the email lists. I also do 
some small advocacy for Guix in ActivityPub federation (Mastodon, 
Peertube, etc.).


I am maintaining the infrastructure for https://joinjabber.org/ which is 
moving to Guix currently -> https://codeberg.org/joinjabber/Infra :) and 
I am a member of XSF.


I also do a lot of advocacy for xmpp in activitypub and handle the 
activitypub presence of joinjabber. -> @joinjabber@indieweb.social



What is being proposed:

I propose to host an xmpp instance with a room/or some rooms under the 
guix domain. Something like xmpp.guix.gnu.org


This can be done in one of two ways:

1. There is a service here -> https://cheogram.com/freedomware-muc/ 
hosted by https://soprani.ca/


 We can just setup our DNS to point to the service and sopranica will 
take care of the xmpp server.


I have talked with them and they do have unlimited retention of past 
messages plus they can also setup a log viewing thing just like IRC has.


Its a sustainable free software business and the hosting will be free. :)

2. We can self host our own prosody instance. It has minimal 
maintenance, and its very lightweight.


I can maintain the instance as it is done for joinjabber and we already 
have a guix service for prosody.



Why / What does Guix get from this:

Right now guix has email lists and IRC. What XMPP can give on top of 
that is:


1. XMPP is more approachable for people used to Matrix or Discord (for 
multiple reasons). While still being very lightweight and free software.


2. It is federated and easily self hosted. Which makes Guix more 
independent in case something like Freenode ever happens to Libera chat 
or in case people want to have their own server to connect to the guix 
rooms.



Personally I am in favor of option 1. We can host it in the cheogram 
service to test things out and if we need to we can self host it later. 
Since It will point to the same domain it shouldn't be a problem.


All we would need to do is change where our DNS points to and that's it.


MSavoritias

Re: Add xmpp room to the list of group chats.

[MSavoritias]

On 12/7/23 09:42, Ada Stevenson wrote:


Hi,

On 12/2/23 8:20 AM, MSavoritias wrote:
Hey, I thought this mailing list is the most fitting for the request 
feel free to point out if its better somewhere else.



Is the community open to have group chats listed in other networks 
than IRC assuming they are free software?


Having chat groups in different networks is going to greatly improve 
the accessibility of the project towards new contributors which I 
think we recently wanted to start working on as one of our areas of 
focus.


The group chat I am talking about is in xmpp/jabber and it is here -> 
g...@chat.disroot.org


It has already the CoC of the guix project and xmpp is free software 
from server to client.



Also disclaimer: I am not talking about starting to bridge them. That 
is an entirely separate thing with different tradeoffs and maintenance.


Just listing the group chat is easy though :)


Msavoritias


This sounds like a good idea to me! XMPP just works a lot nicer with 
stuff like attachments and message logging without needing peripheral 
tooling like znc to get around things like message 
logging/persistance. Whether we go with disroot.org to host the chat, 
or whether GNU can host something for us in the future I'm not sure, 
but I'm keen to see more usage of XMPP.


I think the channel should be listed once we have a strong consensus 
that we want to use XMPP as a main communication channel. Perhaps this 
is suitable for a RFI?


Why main communication channel? I mean sure we can have a discussion 
regarding that, but I think that brings far more questions than just 
listing the xmpp channel as an alternative.


Plus we don't even know how desirable it would be for it to be the main 
channel? (Although a lot of people have started to appear in the channel 
which is nice ^^)


The model I was looking at was similar to ->

General-purpose programming language and toolchain for maintaining 
robust, optimal, and reusable software. - ziglang/zig


github.com

Community <#>

General-purpose programming language and toolchain for maintaining 
robust, optimal, and reusable software. - Community · ziglang/zig Wiki


🔗 https://github.com/ziglang/zig/wiki/Community 
<https://github.com/ziglang/zig/wiki/Community>


However, I understand the desire to keep everything as central as 
possible, especially when it comes to communication. IRC works well 
enough in most cases, and by far has the most active users. This 
doesn't mean things can improve, though, and the niceties provided by 
a more modern protocol such as XMPP could be worth it, potentially. 
Anyway, there isn't much harm in maintaining our own XMPP channel for 
those who wish to use it.


What is being proposed here? hosting our own xmpp server or promoting 
this as an "official" channel? whatever that means.



MSavoritias


What do you think?

Thanks,

Ada (adanska)

Add xmpp room to the list of group chats.

[MSavoritias]

Hey, I thought this mailing list is the most fitting for the request 
feel free to point out if its better somewhere else.



Is the community open to have group chats listed in other networks than 
IRC assuming they are free software?


Having chat groups in different networks is going to greatly improve the 
accessibility of the project towards new contributors which I think we 
recently wanted to start working on as one of our areas of focus.


The group chat I am talking about is in xmpp/jabber and it is here -> 
g...@chat.disroot.org


It has already the CoC of the guix project and xmpp is free software 
from server to client.



Also disclaimer: I am not talking about starting to bridge them. That is 
an entirely separate thing with different tradeoffs and maintenance.


Just listing the group chat is easy though :)


Msavoritias

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/24/23 11:51, Liliana Marie Prikler wrote:

Am Sonntag, dem 24.09.2023 um 02:37 -0500 schrieb Nathan Dehnel:

I'm sorry if my tone was too harsh, I now realise this is still
triggering old pain.
Why is it still OK to for people to keep spreading negative
anecdotes about Emacs, and problematic to refute them or counter
them with positive anecdotes?

It was a mistake to say that. I felt the reflexive need to justify
why I don't use emacs, or else people would just tell me to use it
anyways as a result of talking about not knowing of a decent
(alternative) lisp editor.

I mean, you could try using it anyways, whether it's vanilla emacs,
customized emacs, guile studio, or the heavily popularized spacemacs,
doom, etc. variants.  On the Guix side, it doesn't really matter, our
configuration works with packages based on Emacs.

It's fine if you prefer another editor, but don't count on us to write
documentation for every editor out there, especially when it almost
always turns out to be invoking "guix edit" followed by "git commit …"
or perhaps using that editor's built-in VC integration to do so.  I'm
also not convinced you need to bring the big guns of lisp editing to
the table.  From personal experience, an editor that autocompletes the
closing bracket and has parentheses matching capabilities suffices.
The latter is even implemented by crude tools such as gnome-text-
editor.


How about we start with two editors then besides vanilla Emacs then?

Because we don't even have two now.


It's been me believing exactly such lies that scared me away from
starting with Emacs for years, lost years in a way; something I
deeply regret: this has to stop.

I want to clarify that I'm not just repeating rumors and I actually
have tried to use emacs.

There is a wide span of "tried emacs".  I personally wouldn't say I've
"tried" vi after hitting ESC :q once and being done or even that I've
tried using ed after vaguely figuring out how you can make it actually
change the contents of a file.

Now whether you want to qualify your experience further or not is up to
you, and even if you do, your personal choice of a suitable editor
remains personal.  However, I don't think that repeating the age old
jokes of "herp derp, me no likes defaults" as has happened in other
branches of this topic is helpful.  *The defaults in Emacs do not
matter.*  You don't need to be happy with the editor you get out of the
box.  You can change it into the editor you want and there's ample
documentation on how to do so.  Coming full circle, this is why we
reference Emacs in the manual, enough people collaborated to suggest a
workflow that works for them or at least goes in the right direction.
However, I think it's fair to say that most folks' setup will differ
ever so slightly from what is presented there.

Cheers



That's the thing you are missing.

The default of Emacs absolutely do matter.

Because

1. not everybody has time to learn elisp and configure Emacs so it 
doesn't break.


2. By how the defaults are you see how the community around a program is.

If the defaults are good and empower the person using the program that 
means that the community is open


to suggestions and changes at the very least. which is not what happens 
with Emacs.


This is from someone who uses Emacs.


MSavoritias

Re: The Giraffe; the Pelican et al (was Re: The e(macs)lephant in the room and the Guix Bang)

[MSavoritias]

On 9/23/23 15:59, indieterminacy wrote:
I would assume that people who dont use Emacs are entitled to document 
their experiences using their weapon(s) of choice within the Guix 
knowledge corpus.


Sure, consider and discuss governance and workflows... but people 
complaining that Emacs users have documented their techniques to a 
better standard than non Emacs users within an operating system's 
documentation is bordering on the ridiculous.


The discussion at least the last couple of weeks have been on lessening 
the difficulty to contribute.


So saying that the people who don't know guile or guix need to first 
contribute docs is pretty ridiculous.


MSavoritias


On 23-09-2023 10:58, paul wrote:

Dear Janneke,

On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:

Nathan Dehnel writes:


I don't use emacs either (because it's so impenetrable)

Emacs might be somewhat different from what you know, but this is utter
bollocks.


Thank you for your opinion but it's just that: a subjective judgement 
based on your own episodic experience. Which is definitely valid but 
unrealistically shared by so many to be able to define Nathan's 
experience "utter bollocks".


I think this attitude (in my experience typical of GNU maintainers) 
where their way of doing computation is more blessed or holier or 
better sometimes really ruins the social interactions happening 
around Guix (which is the safest community in the GNU project imho, 
probably also due to the distance they rightfully posed during the 
whole stallman drama).


It's especially problematic when people in power such as maintainers 
do not realize their role in the community. You have more power, 
probably due to your investment you have a clearer vision of where 
the project is going as well. You are supposed to be a role model for 
new users and contributors.



If he could learn, most anyone should be able to pick it
up.
People are still indenting their code manually today, etc... it's
ridiculous.
This behavior is not ok. Again, please, stop throwing your judgement 
on people. Potential users or contributors even.

Also, magit.


I use Emacs, love magit, I used to use it daily also at $day_job on 
Windows because it's just so good, but I can assure you most of Git 
users never heard of it and live their life pretty happily.


giacomo

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/23/23 13:00, Janneke Nieuwenhuizen wrote:

paul writes:

Dear Paul,


On 9/23/23 09:37, Janneke Nieuwenhuizen wrote:

Nathan Dehnel writes:


I don't use emacs either (because it's so impenetrable)

Emacs might be somewhat different from what you know, but this is utter
bollocks.

Thank you for your opinion but it's just that: a subjective judgement
based on your own episodic experience.

I'm sorry if my tone was too harsh, I now realise this is still
triggering old pain.

Why is it still OK to for people to keep spreading negative anecdotes
about Emacs, and problematic to refute them or counter them with
positive anecdotes?

It's been me believing exactly such lies that scared me away from
starting with Emacs for years, lost years in a way; something I deeply
regret: this has to stop.

Greetings,
Janneke


Depends what Emacs you mean.

The vanilla Emacs experience is traditionally horrible until you start 
tweaking it.


And it for years the maintainers of Emacs refuse to do anything to fix 
it. So I would say complaints are pretty valid


when its the same people that push Emacs as the "blessed" way to 
contribute (as in the guix manual) and then people see Emacs vanilla and 
cant use it.



The problematic is not that you say positive stuff about Emacs. I have a 
lot of positive stuff to say too :)


The problem part is the way you dismissed the persons experience as 
"bollocks". The knowledge that the Emacs community is pretty 
conservative in changing anything for decades in the default config also 
doesn't help.



MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/22/23 18:14, Imran Iqbal wrote:

On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote:

I use protonmail and they don't provide smtp access so I can't do git
send-mail as easy as other people do.

A mail provider not allowing SMTP is a git forge that does not allow git
push.

This is not Guix's fault, but it's a problem Guix doesn't help fix either.

This is not on guix to fix, this in you with your choice of mail
provider.


This doesn't mean I'm against the email based approach, in fact, I really
like it. The main problem I see is many people inside guix are not
sensible to people's problems and tastes.

The problem is people's tastes are "we need to use the web browser for
everything" which is what computers have become in a advertising and VC
funded world. We should not be forcing that on people.


Some people are forced to use tools for several reasons, too.

But text editing and email the two things which there are a plethora of
tools, and it's very hard to imagine a scenario where someone is forced
into using one.


This is what I mean when I say many times emacs is kind of mandatory, and
this thread is kind of a demonstration of what I meant because the main
discussion evolved to: you can use this or that in emacs to ease the dev
experience.

This is because emacs is a lisp machine that just happens to let you
edit text. If you are working in a lisp-y language, emacs provides the
best development experience. Emacs also lets you hand mail inside of
emacs (among many many other things). This does not mean you are forced
to use emacs. I use neovim and neomutt for my needs.


I don't think software we use is the main problem, but the fact that we
are not always sensible with other people's experience.

Imagine a different scenario, where instead of this being about email it
was around guile. Would it be fair to say that a Guix makes it hard
to contribute by choosing to be implemented in guile? And that Guix
should move towards using another language that more people are familiar
with like python or javascript?

Personally I don't think its fair to ask Guix to move away from emails
because folks are more familiar with using web browsers for everything.



I think a lot of this discussion is stuck on what is better web or 
email. Where it doesn't have to be.


What we instead need to do is acknowledge that some people like the web 
approach.


And accommodate them so we can have guix used by more people. Simple as 
that :D



Its free software and power to the person that using the software after all.


MSavoritias

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/20/23 17:03, Ricardo Wurmus wrote:

MSavoritias  writes:


On 9/20/23 11:45, Nguyễn Gia Phong via Development of GNU Guix and the
GNU System distribution. wrote:

On 2023-09-20 at 10:21+02:00, Csepp wrote:

It's better if we have at least one *well documented* developer setup,
than if we have a bunch of (sometimes conflicting) partial docs
for setting up certain subsystems.

Emacs can be pretty good, once you do (setq make-defaults-not-suck 1)
a bunch of times.

Or even more outrageous, an overriden Emacs package
with all the good stuff for Guix development.
We already have guix shell that spawns a shell
and guix edit that spawns an editor, why no guix boot
that spawns an OS^W^W Emacs with appropriate defaults?

Disclaimer: I use the devil editor that goes by the number
of VI VI VI, so take this suggestion with a grain of salt.


Can't the guile editor be that?

It kind of tries to be already. We just need to promote it and dogfood
it more.

Do you mean Guile Studio?[1]

It was really only intended to be a pre-configured editor for new
Guilers, which is why it includes the picture language and Geiser with
picture display.

But as I wrote there

There are many more things that can be done to make Emacs less
confusing for people who use it just as a Guile IDE. I would be happy
to hear your suggestions or apply patches to improve Guile Studio!

This is still true today.

[1]: https://elephly.net/guile-studio/

I did yeah. That's why i said we should promote it more to newcomers 
instead of plain Emacs.


I think guile and guix are close that it could easily be a guix-IDE too.


MSavoritias

Re: The e(macs)lephant in the room and the Guix Bang

[MSavoritias]

On 9/20/23 11:45, Nguyễn Gia Phong via Development of GNU Guix and the 
GNU System distribution. wrote:

On 2023-09-20 at 10:21+02:00, Csepp wrote:

It's better if we have at least one *well documented* developer setup,
than if we have a bunch of (sometimes conflicting) partial docs
for setting up certain subsystems.

Emacs can be pretty good, once you do (setq make-defaults-not-suck 1)
a bunch of times.

Or even more outrageous, an overriden Emacs package
with all the good stuff for Guix development.
We already have guix shell that spawns a shell
and guix edit that spawns an editor, why no guix boot
that spawns an OS^W^W Emacs with appropriate defaults?

Disclaimer: I use the devil editor that goes by the number
of VI VI VI, so take this suggestion with a grain of salt.



Can't the guile editor be that?

It kind of tries to be already. We just need to promote it and dogfood 
it more.



MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/18/23 20:13, Simon Tournier wrote:

On Mon, 18 Sept 2023 at 18:35, MSavoritias  wrote:


I was talking from my experience. If you don't share it that is fine.

Share what?  Your experience?  How can I?  Instead, I share facts
backed by numbers.

It is fine to share how you perceive, encouraged even!  It is not fine
to make bold claim based on nothing more than a very subjective view
point.


Please take a step back. You cannot dismiss my experience.

As I have said and other people in this thread, and as I said i also 
engage with people in social networks,


and I am talking from that experience.


As i said its okay if you don't understand it, or share it. What you can 
not do is dismiss my experience.


It is not attack on you personally what i have said it is meant as how I 
view things from my perspective that is all.



Consider this my last email in this thread.


MSavoritias.

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/14/23 11:24, Ricardo Wurmus wrote:

Fannys  writes:


But again, even if this is a great option for you, it might be a really bad
option for some other people. Everybody does not have the time to spend
learning emacs, or other specific tool. It's ok if the workflow suggests that
but it's not great if we have no other alternative.

It's not accessible and imposes a barrier in some people.

Yeah agreed. And we should be consious of that.
Ironically by mandating Emacs and Email we force people to use specific
tools while at the same time even though the same people will complain(!) 
against vendor lock-in
like github.

We don’t *mandate* the use of Emacs.  It’s just a common recommendation
because it works so well with text and is trivially extensible, so it’s
a common target for helper tools.  Surely we also wouldn’t call a
recommendation to use a shell script “vendor lock-in” just because it
needs Bash.

Emacs works well with text, and text is all that’s needed in a
patch-based workflow, which is in fact vendor agnostic.

Of course this doesn’t mean that it is as accessible as we’d want.

Well as it was pointed out when it is the only thing that is mentioned 
in the manual and all the tooling is based around it, it might as well 
be mandated.


If it works only in Bash it pretty much is "vendor lock-in" yes.

I have mentioned in other email so I won't repeat myself here, plain 
Emacs is not really accessible for a person that wants to start messing 
around with guix or guile.



MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/18/23 12:37, Simon Tournier wrote:

Hi,

On Sun, 17 Sep 2023 at 19:20, MSavoritias  wrote:


Including an committer. And the fact that guix doesn't get have many
committers and contributors are scarce, speaks for itself. If you don't
see it I suggest asking people in social networks/forums why they
*don't* get involved in guix.

--8<---cut here---start->8---
$ git shortlog -sn --all | wc -l
952

$ git log --format="%ce" | sort | uniq -c | wc -l
104
--8<---cut here---end--->8---

Please point one project where:

   + more than 900 people have contributed to the project,
   + more than 100 people had or have write access in the repository.

It is fine to discuss how to improve and what we could do better.  It is
incorrect to say “guix doesn't get have many committers and
contributors” and it is not fine to frame it negatively.

I was talking from my experience. If you don't share it that is fine.

For example Debian moved to Gitlab. Same for gnome and kde.

As I pointed in my very first reply [1] in this thread:

 For instance, Debian is based on Gitlab since their switch from Alioth
 to Salsa.  It would be interesting to know if this “new” web-based
 workflow using Merge Request is increasing the number of submissions
 and/or increasing the number of occasional contributors.

As far as I have read all this thread, no one provides numbers.  The
answer by Vagrant (Debian Developer and Guix contributor) appears to me
interesting [2].  Therefore, could we stop this useless and unproductive
flamewar?  Many Guix channels are hosted on Gitlab, Github or Sourcehut
and they are not receiving so much more contributions.  As Katherine
pointed [3],


Regarding the many contributions it has to do also with a lot of other 
stuff. Obviously a web interface wouldn't


solve everything. And i hope it never seemed I said otherwise.



 I know everyone is focusing on email vs. web-forge, but I am trying to
 draw attention to the root causes of the complexity, and enumerating
 possible solutions to these.

and I think that kind of mindset is very helpful; it is engaging.  Well,
to my approximate recollection, there is a talk at each DebConf about
reflecting on newcomers backed by some stats; e.g., [4].  In summary,
“email vs. web-forge” is a fake-problem, IMHO.  Last, the talk [5] by
Enrico Zini appears to me much more fruitful.  The question is about
sustain the community.  And this sustainability does not clearly depend
on any tool.


The thing is nobody talked about email vs web forge to my knowledge though.

What was pointed out was specifically cognitive overhead and how we can 
reduce that.


One of the solution offered was to have *also* a web interface. It was 
never suggested any comparison.


The comparison seemed to have stemmed from some people feeling they 
would be left behind (?) and wanting to


prove that email is better or something. Personally i don't care what is 
better.


What i care is that some people prefer web-based so we should 
accommodate them :) plain and simple.



MSavoritias


Cheers,
simon


1: Re: How can we decrease the cognitive overhead for contributors?
Simon Tournier 
Thu, 24 Aug 2023 20:53:14 +0200
id:871qfsuvad@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-08
https://yhetil.org/guix/871qfsuvad@gmail.com

2: Re: How can we decrease the cognitive overhead for contributors?
Vagrant Cascadian 
Sat, 02 Sep 2023 18:05:40 -0700
id:87wmx8m5gb.fsf@wireframe
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/87wmx8m5gb.fsf@wireframe

3: Re: How can we decrease the cognitive overhead for contributors?
Katherine Cox-Buday 
Tue, 05 Sep 2023 13:15:48 -0600
id:13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com

4: https://debconf23.debconf.org/talks/32-teams-newcomers-and-numbers/
5: https://debconf23.debconf.org/talks/2-adulting/

Re: Thank you for using Emacs

[MSavoritias]

On 9/18/23 16:10, Peter Polidoro wrote:


MSavoritias  writes:

I go to the manual to learn package management, 
https://guix.gnu.org/en/manual/devel/en/guix.html#Package-Management


Apparently i have to either use the terminal or something called 
emacs. If I follow the guide located here: 
https://emacs-guix.gitlab.io/website/manual/latest/emacs-guix.html#Installation


It says to install emacs-guix. Okay. So apparently it is an Emacs 
thing, whatever that means. And when you start Emacs after installing 
the package, you are going to end up with Emacs in its plain form. 
Unfamiliar keybindings, no autocomplete, etc. Well thats no to Emacs 
then. The other thing is the terminal apparently. Horrible, but at 
least it works.


You make a very good point, being exposed to Emacs for the very first 
time in this way would be a terrible experience and listing 
alternative options would be very beneficial.


However, I would just like to say "Thank you!" to everyone here for 
using Emacs in the manual.


For my entire career in hardware engineering, I have felt like an 
outcast for using Emacs and being passionate about free software. When 
everyone else on a team or in a company or organization uses 
proprietary software only, it is very isolating and career limiting to 
stay committed to the free software and hardware movements.


So while you may not win any popularity contests by using Emacs in the 
manual, just know that it is very much appreciated by some of us.


Its not Emacs per se. Its more like vanilla Emacs. I very much like 
Emacs. The idea of it at least.


What i meant more was:

- Offer an alternative to Emacs.

- Specify a distro like doom Emacs that comes with better defaults.

I would maybe lean towards the second one i here fyi. I agree it would 
be nice to introduce people to lisp modifiable editors :D


And for guile specifically to offer guile-studio instead of plain Emacs.


MSavoritias

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[MSavoritias]

Sounds like a great idea!

I agree that exclusivity and how we can improve contribution should be 
included.


Also communication channels of course. Maybe also what communication 
channels people would like to see?



Just thinking out loud for questions. I would also be glad to be of help 
with this.



MSavoritias

On 9/16/23 15:59, Wilko Meyer wrote:

Hi Guix,

I haven't had enough time to read up on every topic that has been
mentioned in the "How can we decrease the cognitive overhead for
contributors?" discussion as at some point it got quite a lot to
follow. At one point[0] there was a discussion on having a survey to get
a better picture on and quantify what potential blockers are to engage
with/contribute to Guix; which seems, if done right (as surveys have to
be carefully crafted), a good idea; especially with the prospect of
repeating it annually as a means to check if issues got
better/priorities in Guixes userbase change and so on. If there's a
consensus on doing this, I'd be happy to contribute some of my time to
get things going (would creating a issue on guixes bug tracker for this
topic be a good idea? how are these non-code contrib. topics handled?).

Before writing this mail, I had a look on how other projects handle
these kind of surveys, in particular:

- the emacs user survey[1]
- the nix community survey[2]
- the curl user survey[3]
- the fennel survey[4]

I identified a few key themes that could be useful for a guix user
survey as well. I plan on doing a more extensive summary on this later
this weekend if my time allows it, for now a loose collection of
ideas/list of what, in my subjective opinion, stood out and what most
surveys had in common should do to hopefully get a discussion on this
started:

- the emacs user survey specifically asked for elisp profiency; mapping
   out the Guile profiency of guixes community could be feasible.
- fennel as well as emacs had questions on which programming languages
   their community uses; in the regards on recent discussions on
   guix-devel on developer ecosystems[4] this could help to identify if
   there are any shortcomings in providing importers/packages for certain
   languages that may be used by guix users.
- the nix survey specifically asked for the environments and context nix
   is being used in; it'd be interesting to see where and for what
   purpose people are using Guix.
- most surveys had, some more some less extensive, demographic
   questions and questions mapping out how many years people have been
   programming.

Specifially in the lights of the original discussion/regarding
contributions:

- I think that the "Where do you discuss Fennel or interact with other
   Fennel developers" question of fennels survey should be asked for guix
   as well, to get a grasp on which platforms are being used to discuss
   all things guix.
- the curl user survey[6] did a pretty good job in mapping out what
   prevents users from contributing (p.20) as well as mapping out what
   areas of the project are regarding as good/which have room for
   improvements (p.24-26)
- fennel asked for "the biggest problems you have using Fennel", it had
   a "If you haven't hacked on Fennel itself, why not?" question as
   well. I personally think this could be good to assess potential pain
   points/blockers for Guix as well. Fennel also asked for "favorite
   features" which could be a nice way to map out which parts of Guix are
   popular.

Last, the nix user survey allowed free-form responses. Having a
qualitative research component to a survey could help getting better
results (especially when identifying problems in using guix/blockers in
contributing and so on); but evaluating these is pretty time extensive
and dependant on how much resources people have to compile a list of
findings/results from a prospective survey.

What could the next steps be to get this going?

[0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html
[1]: https://emacssurvey.org/
[2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983
[3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/
[4]: https://fennel-lang.org/survey/2022
[5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html
[6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/10/23 01:20, Liliana Marie Prikler wrote:

Am Samstag, dem 09.09.2023 um 21:40 +0200 schrieb Ricardo Wurmus:

Liliana Marie Prikler  writes:


Must we force a single workflow on everyone, even if our track
record in reviewing and merging doesn’t clearly show that our way
is superior?

Again, define superior.

No, I won’t.  I think it’s obvious that our review process isn’t
working *well*.  So the argument that our current workflow allows for
effective review is dubious.  Not saying that you made that claim,
just that it’s hard to convince others of adopting our ways when the
results just aren’t great.

What do you consider "the results" here?  The rate at which patches are
merged?  This is hardly an issue our project alone is fighting and I'm
not convinced that technology, more or less, will shift it in either
direction.


That's one thing yeah.

There are multiple people in the thread pointing out issues with 
contributing that create friction.


Including an committer. And the fact that guix doesn't get have many 
committers and contributors are scarce, speaks for itself. If you don't 
see it I suggest asking people in social networks/forums why they 
*don't* get involved in guix.



Let's take our importers as an example.  Bugs aside, they allow us to
bump any package to the newest released version.  Naturally, similar
tools have evolved over in the forge world as well.  The end result?
Bots are now writing merge request that end up ignored much like there
are bugs in Guix that receive little attention due to what might as
well be unfortunate timing.

I'm also not sure how we can tie back contribution throughput to
cognitive overhead.  In fact, there might well be a Jevons paradox
hiding somewhere in that less overhead per patch means that more
patches can be written, which results in the same overall cognitive
overhead in the long run.

Now, you are probably right in that our review process probably isn't
working well for some value of well that yet needs to be defined.
However, without any frame of reference it is also a statement that can
neither be verified nor falsified.  I could be sitting in a burning
house claiming "this is fine" or sitting in the finest restaurant
claiming "this place sucks" and since you can't see me, there's no way
for you to infer that I'm a cat.

Cheers

Frame of reference should be what other projects have done. Its not like 
this hasn't come up before in other projects.


For example Debian moved to Gitlab. Same for gnome and kde.

I'm not saying we should copy them but we should at least ask "Why?" and 
how did they come to those conclusions.


Then we should also do a survey of people outside of guix that may be 
interested in it. What stops you from doing so? (spoiler: its the email 
among other problems :) )



Personally free software means that there shouldn't even be a separation 
of Dev and user. But that's another topic.

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/8/23 21:50, Liliana Marie Prikler wrote:

Hi,

Am Freitag, dem 08.09.2023 um 16:44 +0200 schrieb Ricardo Wurmus:

I often have to review Github Pull Requests, and I don’t go commit by
commit by go through the diff and annotate the changes.  I *read* the
commits to get a sense for how the feature evolved and why changes
were made, but the fact that new commits are pushed on top of the
branch is not an obstacle in practice, because the commits don’t
matter.

(I know, it hurts me too, but I don’t make the rules, okay?)

Well, thanks to Guix inventing the time machine, individual commits do
matter to us.


And in these review interfaces we can mark individual comments as
resolved.  So the flat list of changes with annotations *does* in
fact provide a clearer organization than a tree of emails.

Note also that we don’t usually review commits by starting one new
thread for each issue we address, so we don’t benefit from automatic
branching of sub-discussions.

To be fair, the summarizing of changes followed by comments to
individual bits are a point that the forges at least get right.
However, unless you rework a single line multiple times – which
admittedly happens more often in the "push the change on top" model of
the forges than in the "condense your changes to logical units" model
we use – a branching discussion per commit still comes quite close in
practice.  Also, when there are multiple reviewers notice different
things, you also get the branching tree.


On Github, Pull Request branches are like our WIP branches.  They are
how we arrive at acceptable changes.  Picky people like me would then
go back and write new atomic commits for the effective diff, but in
my role as a reviewer I usually rebase, squash, and merge.

This workflow is more familiar to some and alienating to others, but
both of these workflows would work fine for Guix.  But today our
tools can only accommodate *one* workflow.

I'd imagine that rebase, squash and merge would exacerbate the workload
on the committer side and I think that most popular projects on those
forges already experience similar effects to us despite folks just
merging the requests as-is and in part even getting paid by big tech
for doing so.  (Perhaps I exaggerate at getting paid for processing
merge requests, I haven't worked for any of these companies, but
especially at the ones more oriented towards doing business, I'd
imagine that you can at least buy yourself a sandwich from the work you
do from time to time.)


It happens to be the one I’m used to, but let’s please not pretend
that it’s inherently *better* than the other.

I mean, when we say better, we would have to refer to some metric of
goodness.  And the metric I personally choose is somewhere in the
intersection of accessibility and interoperability, because that is
what matters to me.  With Github, Gitlab and whatever other forges you
have, you are more or less bound to their web interface.  If that works
for you, it works.  If it doesn't, it doesn't.  With the email-based
workflow, I can use whichever tools I am comfortable with, as long as
they work for sending mail (as a contributor) or eventually invoke `git
push' on a bunch of signed-off commits (as a committer).  This both
increases the chances of things working and gives me the tools to build
things that work for myself (and potentially others as well).

Cheers


That's the thing though, its not more accessible.

For multiple reasons including:

- knowledge accessibility

- accessibility for people with disabilities

- accessibility for people that don't have the time

and so on.


So the argument for accessibility is very much wrong. Now if you want to 
argue that its better for


some people because they can tweak their Emacs, sure I agree. I am one 
of those people.



But the web and html has orders of magnitude better accessibility than 
anything email. as a medium.


I mean we don't even have much accessibility to speak of in guix but 
that's another topic.



MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/12/23 17:51, Maxim Cournoyer wrote:

Hi,

Csepp  writes:


Giovanni Biscuolo  writes:


[[PGP Signed Part:Undecided]]
Hello Csepp,

Csepp  writes:

[...]


I don't think repeating that no forge sucks less advances the
conversation towards any solution other than keeping the status quo,
which can't really be called a solution.

Are we really talking about changing the official Guix forge:
https://savannah.gnu.org/projects/guix?

I definitely am.

The real place to put efforts toward that goal should be in the GNU
project; this way we can continue to maintain shared resource, knowledge
and tooling as a project.  I think packaging either sourcehut or gitea
and writing a Guix System service for it would provide opportunities to
experiment and perhaps one day move in that direction, so that's
something concrete that you can direct your efforts too.

Agreed. and speaking of that it seems its already something in the works 
as it was pointed elsewhere:


(as trial at least.)

sourcehut.gnu.org

sourcehut.gnu.org hub <#>

🔗 https://sourcehut.gnu.org/ 

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

he main guix platform. 
For better or worse. And we have excluded a portion of contributors. 
Same with email, debbugs. What can solve this is effort to actually 
include people.


Visual Code as you mentioned or any other editor, or mumi, these are all 
efforts to get contributors in the first place. The contributors will 
never come and create the infra and tooling they want by themselves. It 
takes some initial effort on our part to lower the barrier and 
"cognitive overhead" as in the title to actually encourage people to 
contribute. Same way that women or other minorities dont just "show up" 
to change the culture to make the welcome. they would rather go where 
they are already welcome.



Not to make this too long i strongly disagree that "Create your own 
toolbox" is a barrier we should have for new users. And recommendations 
carry weight because its what people see the community putting effort 
into and using.



Some proposals/good directions that we already have not to leave this 
with just complaining is:


- Improve guile studio and add it as a recommendation. With an improve 
UI and keybindings for it.


- Improve the docs of course.

- add more editors maybe(?) by ourselves.

This is for the starting to change guix/guile code that is. For people 
wanting to use code there is others. As there is for actually committing 
being discussed elsewhere for improvements.



Yes I want to help on all of them at some point :)


MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/7/23 23:38, Katherine Cox-Buday wrote:

On 9/5/23 2:43 PM, Liliana Marie Prikler wrote:

Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:

Liliana Marie Prikler  writes:

Uhm, we have snippets?


Well, those are exclusive to Emacs :)  And without regard to /that/
issue, I do think that there's a problem if the commit format is so
complex that it's not trivial for anyone new to the project to write
them out manually.

By definition, no amount of typing is non-trivial, safe for the empty
amount, which good luck trying to commit your changes by pure mouse
movements, I guess?

Now, if you excuse my French, I think the problem isn't really as much
that people struggle to type out the perfect ChangeLog on the first
try, which also makes it odd to request a linter.  Bear in mind that
committers will sign off anything that appears convincing enough, even
if there are smaller mistakes in the message.  Trust me, I've been
there and seen that; and also done it myself.

Instead, we have seen in this thread appeals to age, appeals to
perceived lack of personal benefit, and now appeals to typing effort,
none of which really make that great of an argument against the
ChangeLog style, especially when they come in combination with a
refusal to make use of already provided tools.  I think we're starting
to see the moving of the goal post as the actual game here.

Maybe it's time to take a step back and instead of asking “How can we
decrease the cognitive overhead for contributors?”, we should perhaps
ask “For which contributors do we want to/can we decrease the cognitive
overhead?”  We have drifted much from the original post that discussed
moms with full-time jobs, who struggle to do “difficult” tasks
(simplified wording; may change the meaning of the OP a little).  Now,
I personally struggle to see how your personal preference for
communication media, commit message style, and other things that were
discussed in any of the preceding threads actually correlate with being
a parent.  However, I do know that with its 150 million users, most
people of the world don't have a Github account.  Being one of the 4
billion email users out there is a comparably low barrier of entry
imho.  So, whose cognitive overhead do you want to reduce (besides the
obvious "my own", which everyone always tries)?


Liliana, many of your responses in this thread are not OK. They have 
been dismissive and have strayed into personal attacks. At times I'm 
not sure if you're intentionally misinterpreting the conversation to 
try and make a point.


If you disagree with something, or have a point to make, please do so 
directly, and without attacking anyone's character or making veiled 
innuendos about their motives or capabilities.


Speaking for myself, I think if you asked me questions instead of 
inferring narratives, you'd find that our values and preferences are 
probably more closely aligned than you realize.


We're all here to try and make Guix better, but we can't do that in a 
hostile environment.



Completely agree with this too. I wanted to say that Katherine is not 
alone in feeling that some comments


in the thread have been dismissive or even elitist in a lot of cases. 
and one of the main people posting these


have been Liliana.

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/6/23 23:10, Wojtek Kosior via Development of GNU Guix and the GNU 
System distribution. wrote:

Hello,

I wanted to add to this thread my 2 cents. As a person who has recently
(last months) made the first attempts at contributing.

To me, registrations and reliance on JS had always been an obstacle to
using web-based forges. This is one of the reasons I haven't been
contributing to existing projects in the past.

With Guix this issue is gone but there's also another thing that
incentivized me — that, since joining the Guix mailing lists, I am
seeing activity all the time, right at my fingertips (because I have my
email client opened most of the time).

So far I have sent patches 4 times. Once it was a simple update that got
accepted quickly, once I was addressing a problem that turned out to be
better solvable another way and 2 submissions are still waiting for
someone to review them.

Although I had to learn to use `git format-patch` and related tools, I
don't consider it a problem. Actually, I wanted to learn email-based
workflow anyway because it seems to be a more KISS way of software
development.

The amount of new stuff to learn can, however, be a bit overwhelming. I
did learn to use git to send emails but haven't yet started using any of
the templating packages for Emacs that were recommended in Guix
documentation. It would be just too much to process at once.

Do I think Guix has a problem with cognitive overhead? Not at all.
Rather, it seems to be addressing the problems really well.
1. It makes it easy to hack on itself without the need to clone the
repo first. That's what helped me get familiar with it before I
could even try to contribute anything.
2. It, by default, updates to the most up-to-date version.
3. It has some detailed documentation.
4. It eases the setting up of one's development environment.

I fact, I suspect the email-based workflow might be automatically
filtering out some bad submissions that would have been made otherwise.
The geeky nature of the project does put it in a kind of a niche where
only geeks dwell. But this is somewhat benefitial because geeks are
those who can build it.


Arguments that its a good thing its hard for people to contribute to the 
project don't really help.


Because among others it promotes gate-keeping and elitism. Im not saying 
you specifically are that person,


but that is how a person that wants to contribute will get the argument.


The part about email working for you, I am glad it does :)

We need to care for the people that may like a different style of 
contributing too though.


Because the more people guix can attract the better for the project.


MSavoritias



Lastly, sorry if something I wrote is a duplicate of other's opinions —
the thread got s long it'd be hard to read through 100% of it

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Tue, 05 Sep 2023 22:43:04 +0200 Liliana Marie Prikler 
 wrote:


Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:

Liliana Marie Prikler  writes:

Uhm, we have snippets?

Well, those are exclusive to Emacs :)  And without regard to /that/
issue, I do think that there's a problem if the commit format is so
complex that it's not trivial for anyone new to the project to write
them out manually.

By definition, no amount of typing is non-trivial, safe for the empty
amount, which good luck trying to commit your changes by pure mouse
movements, I guess?

Now, if you excuse my French, I think the problem isn't really as much
that people struggle to type out the perfect ChangeLog on the first
try, which also makes it odd to request a linter.  Bear in mind that
committers will sign off anything that appears convincing enough, even
if there are smaller mistakes in the message.  Trust me, I've been
there and seen that; and also done it myself.

Instead, we have seen in this thread appeals to age, appeals to
perceived lack of personal benefit, and now appeals to typing effort,
none of which really make that great of an argument against the
ChangeLog style, especially when they come in combination with a
refusal to make use of already provided tools.  I think we're starting
to see the moving of the goal post as the actual game here.

Maybe it's time to take a step back and instead of asking “How can we
decrease the cognitive overhead for contributors?”, we should perhaps
ask “For which contributors do we want to/can we decrease the cognitive
overhead?”  We have drifted much from the original post that discussed
moms with full-time jobs, who struggle to do “difficult” tasks
(simplif

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

s
> Lars-Dominik Braun 
> Wed, 02 Aug 2023 12:37:57 +0200
> id:cover.1690972374.git.l...@6xq.net
> https://issues.guix.gnu.org//65010
> https://issues.guix.gnu.org/msgid/cover.1690972374.git.l...@6xq.net
> https://yhetil.org/guix/cover.1690972374.git.l...@6xq.net
>
> then, one will do reply and probably comment one or more patches over
> the 8.  Then, it is harder for another person to follow.  For example, I
> would have to open the message in order to know that this series adds,
>
> guix: toml: Add TOML parser.
>
> which could be interesting for Julia.  And I would probably skip all the
> series because the subject is about Python build system improvements
> that I am necessary following.  However, if I see the subject,
>
> guix: toml: Add TOML parser.
>
> then I open the message and read it.
>
> Therefore, I do not see any “good” solution for this point #22.  One
> idea would be to have a kind of proxy.  We would send the whole series
> to an hypothetical guix-contributi...@gnu.org and then a bot would send
> to guix-patches for getting an ID and that bot would send the series to
> that ID, probably adding some X-Debbugs-CC for the submitter (and for
> teams).  Bah, too much “would”. :-)
>
>
> 1: https://yhetil.org/guix/87wmx8m5gb.fsf@wireframe
> Re: How can we decrease the cognitive overhead for contributors?
> Vagrant Cascadian 
> Sat, 02 Sep 2023 18:05:40 -0700
> id:87wmx8m5gb.fsf@wireframe
> https://lists.gnu.org/archive/html/guix-devel/2023-09
>
>
>> If I compare this workflow to the workflow of other contributions I make:
>>
>>    1-10 as usual
>>    11. Write a more commonly accepted commit message with no special 
>> formatting.
>
> This depends on the project and I am not convinced we can rule for #11.
>
> BTW, one strong advantage for this commit message format is that grep
> can be exploited.  For some reasons, I am often looking for some past
> versions, for example,
>
> $ git log --pretty="%h %s" | grep Update | grep vlc
> 8d342711dd gnu: vlc: Update to 3.0.17.4.
> 5a29cc9ade gnu: vlc: Update to 3.0.17.3.
> fb0e5874ec gnu: vlc: Update to 3.0.16.
> e2ad110f4c gnu: vlc: Update to 3.0.14.
> def314d810 gnu: vlc: Update to 3.0.12.
> 6ec120b1c7 gnu: vlc: Update to 3.0.11.1.
> 0bed485a39 gnu: vlc: Update to 3.0.11.
> 178f1d1f75 gnu: vlc: Update to 3.0.8.
> cf40f8e4d7 gnu: vlc: Update to 3.0.7.1.
> 94f7f9503a gnu: vlc: Update to 3.0.7.
> dba326def1 gnu: vlc: Update to 3.0.6.
> ea593fe298 gnu: vlc: Update to 3.0.5.
> d0e23e3940 gnu: vlc: Update to 3.0.3, and add more inputs.
> 7627705293 gnu: vlc: Update to 3.0.3, and add more inputs.
> f137f84923 gnu: vlc: Update to 2.2.8 [fixes CVE-2017-9300, CVE-2017-10699].
> dd13aa90d6 gnu: vlc: Update to 2.2.6.
> 3bc45ad460 gnu: vlc: Update to 2.2.5.1.
> a134cc8e93 gnu: vlc: Update to 2.2.4 [fixes CVE-2016-5108].
> c6c86cd7a5 gnu: vlc: Update input Qt to version 5.
> 9c55bae607 gnu: vlc: Update to 2.2.1.
> 1a189da0e7 gnu: vlc: Update to 2.2.0.
> b9156ccc08 Revert "gnu: vlc: Update to 2.2.0"
> ad036bda89 gnu: vlc: Update to 2.2.0
> 23466647a8 gnu: vlc: Update to 2.1.5.
>
>
> And because there is some variation with the commit message format,
> these are not all the updates of VLC,
>
> $ git log --pretty="%h %s" | grep Update | grep VLC
> af74211d98 gnu: VLC: Update to 3.0.18.
> 5af110868c gnu: VLC: Update to 3.0.10.
> 091ef8c97e gnu: VLC: Update to 3.0.4.
> 324c049ff6 gnu: VLC: Update to 3.0.3-1 [fixes CVE-2018-11529].
>
> Then “guix time-machine --commit=fb0e5874ec -- shell vlc” and hop I get
> 3.0.16.  If the commit message format would not be so strict, this would
> be impossible and we would need another external tool.
>
>
>>    12. Run `git push` (subsequent changes are still just `git push`).
>>    13. Go to forge website, click button to open a pull-request.
>>    14. Wait for CI to tell you if anything is wrong.
>
> To be fair, here you forget one important blocker: having an account to
> the forge website.
>
> I do not speak about freedom issues.  Just about the fact to open an
> account to the forge website.  For example, let consider this project:
>
> https://framagit.org/upt/upt
>
> And if I want to contribute with a Merge-Request, I need to open an
> account to the Gitlab instance of FramaGit and push my code to this
> instance, even if I already have my fork living on my own Git
> repository and I have no plan to use this FramaGit forge.
>

Bear in mind that Sourcehut accepts patches without an account and there
is forgefed https://forgefed.org/ for forges federation. which forgejo
has support https://forgejo.org/

MSavoritias

>> If you're so inclined, for a bit of fun, and as a crude way of simulating
>> compromised executive functioning, imagine that between each of the 
>> steps above,
>> a year passes. And reflect on what it would be like to gather the energy to
>> start the process of starting a contribution of some kind, let alone 
>> follow it
>> through to completion.
>
> I like this way of thinking because it helps to spot some blockers.
>
> Please note that it is not truly about the complexity of the steps but
> about how many steps one is able to complete between two interruptions.
> Well, it is a well-known issue about task switching [1]. :-)
>
> 1: https://en.wikipedia.org/wiki/Task_switching_(psychology)
>
> Cheers,
> simon

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

I dont think we need to compare things here. Of course we should be able
to make lives easier for reviewers and contributors. There is no need
here to compare them. Remember that making lives easier for contributors
will make lives easier for reviewers too after all :) Because more
correct pathces and more people wanting to be involved.
Hence me saying its not a comparison or focusing on one or the
other. But more of the same thing.

As I mentioned in another point in the thread we already have
"non-standard" stuff so that argument doesn't really hold water
here. Non standard stuff being emacs, mumi and a bunch of other stuff
that make submissions tolerable. Or emacs-debbugs.

Also yes "visual" flow helps some people. Nothing wrong with that and we
should encourage that. (Encrourage that by fully supporting it). I mean i am 
trying to use the cli as less as
possible since its a horrible interface.

And yes the gnu commit messages could be improved. Its not like they are
set in stone anyway.

MSavoritias

Giovanni Biscuolo  writes:

> [[PGP Signed Part:Undecided]]
> Hello Katherine,
>
> thank you for having summarized (part of) this thread in a list of
> actionable tasks
>
> now Someone™ have the chance to decrease the cognitive overhead for
> contributors by _increasing_ her cognitive overhead to sort out and
> complete each task
>
> as a general comment, it seems to me that you put very much attention to
> the process of contributing v1 of a patch but you underestimate the
> cognitive overhead of the collective patch reviewing process and
> committing to Guix proper process
>
> AFAIU, observing what is happening in Guix since 2019, what is actually
> critical for Guix is _not_ the cognitive overhead needed to send a patch
> to guix-devel, but what comes after and _around_.
>
> last but not least, to be fair we should see at what other distribution
> (not single software projects) are doing for their contributing process:
> I know a little about Debian and in my experience it's far easier to
> contribute to Guix than to Debian (but I know little, I emphasize)
>
> Katherine Cox-Buday  writes:
>
>> Summary of my conclusions:
>>
>> 1. We should use sourcehut or continue to improve mumi
>
> Please forgive me if I insist, but the one and _only_ benefit of using
> SourceHut is the web-UI /helper/ to prepare an email message to send,
> it's "just" a web-UI version of the "git format-patch" CLI; the rest of
> the "patch management workflow" is email **and** CLI (git am) based;
> it's documented.
>
> Furthermore, users that are comfortable with the SourceHut web UI are
> free to use that as their personal working repo, there is no need for
> Guix to use a SourceHut remote as the official one.
>
>>     - QA status should be visable from a patch's page
>
> On mumi web interface, in each issue page related to a patch, there is a
> "badge" linking to the QA status for that patch, right below the issue
> title; i.e.:
>
> https://issues.guix.gnu.org/65694
>
> have a link to https://qa.guix.gnu.org/issue/65694
>
> QA (and relates services, like data.qa) is a great project that could
> greatly improve current situation when completed!
>
>>     - It should be possible to interact with the issue through the
>>  page
>
> I don't exactly understand: what do you mean with "interact"?
>
> ...and what page?  https://issues.guix.gnu.org/ or
> https://qa.guix.gnu.org/issue/65694 (or any other issue)
>
>> 2. We should create scripts/sub-commands to lift contribution activities 
>> into
>>     higher-order concepts:
>>     - Prepare a new submission
>>     - Run pre-checks on a submission
>>     - Submit a patch
>>     - Status of patch
>
> AFAIU you already use some of this "lifting" scripts od commands: can
> you please send patches so thay could possibly be included in Guix
> proper or in some section of the Cookbook?
>
> [...]
>
>> On 8/28/23 4:17 AM, Simon Tournier wrote:
>
> [...]
>
>>  > In order to be pragmatical and list actionable items, could you
>>  > specifically list what you consider as a toil or cognitive overhead?
>>  > Maybe you could share your script helping you.
>>
>> Yes, great point! Let's try to distill all this conversation down into the
>> salient points and see if we can't agree on some actionable items.
>>
>> Here's my understanding of the process to contribute a patch:
>>
>>    1. Check out main, and run `./bootstrap`, then `./configure 
>> --localstatedir=/var --sysconfdir=/etc`
>>    2. Run `make`
>>    3. You need 

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

Simon Tournier  writes:

> Hi,
>
> On Tue, 29 Aug 2023 at 12:53, MSavoritias  wrote:
>
>> Do you know if there are any plans to write a scheme bug/patching
>> system? Because looking a bit into it, it doesn't seem like its that
>> actively developed so maybe we would be better served by one in scheme.
>> Or Sourcehut of course as somebody wrote in another email.
>> Since not much would change with sr.ht anyways.
>
> The only work I know is named tissue by Arun Isaac.  Arun also
> contributes to Mumi (one web front-end of the venerable Debbugs instance
> of the GNU project).
>
> https://tissue.systemreboot.net/
> https://archive.fosdem.org/2023/schedule/event/tissue/
>
> Well, I am not convinced by the argument « we would be better served by
> one in scheme ».  For instance, Cuirass or Build Coordinator or even
> Mumi, all are implemented in Scheme and they are receiving very few
> contributions.
>
> https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git
> https://git.savannah.gnu.org/cgit/guix/build-coordinator.git/
> https://git.savannah.gnu.org/cgit/guix/mumi.git/
>
>
> Cheers,
> simon

Its more about:
If debbugs has issues and we dont fully control it and can make those
improvements, why not something in scheme instead of sr.ht?
But i could go either way.

MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

Ekaitz Zarraga  writes:

>> > This is what I mean when I say many times emacs is kind of mandatory,
>> > and
>> > this thread is kind of a demonstration of what I meant because the main
>> > discussion evolved to: you can use this or that in emacs to ease the
>> > dev
>> > experience.
>> 
>> 
>> One of the benefits of my being able to attend Guix Days was seeing
>> peoples' workflows and stacks in person.
>> 
>> As such, one of my conclusions having (already) committed to Guix was
>> that I needed to master Emacs prior to Guile
>> (Im highly flow orientated).
>
> But again, even if this is a great option for you, it might be a really bad
> option for some other people. Everybody does not have the time to spend
> learning emacs, or other specific tool. It's ok if the workflow suggests that
> but it's not great if we have no other alternative.
>
> It's not accessible and imposes a barrier in some people.

Yeah agreed. And we should be consious of that.
Ironically by mandating Emacs and Email we force people to use specific
tools while at the same time even though the same people will complain(!) 
against vendor lock-in
like github.

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

Yep completely agree with all of this.
Personally I dont think its necessery to move to sourcehut but from the
discussions I saw debbugs does seem to become a burden the more time
passes on.

One of the weirdest things for me in guix is how its based on scheme
which is designed to be hacked in place and instead we have so many
complicated steps to do it.

A much more logical thing as bare minimmum is like you said: Have it as
a subcommand in guix. The first thing i tried to do to contribute
personally was to just do a 'guix edit' and edit the package but turns
out not only i cant do it as easy as that but I also need to clone a
repo and run multiple scripts inside a container(?). We should work on
moving as close to a 'guix edit' and 'mumi push' contribution as
possible.

MSavoritias

Katherine Cox-Buday  writes:

> Summary of my conclusions:
>
> 1. We should use sourcehut or continue to improve mumi
>    - QA status should be visable from a patch's page 
>    - It should be possible to interact with the issue through the page
>
> 2. We should create scripts/sub-commands to lift contribution
> activities into
>    higher-order concepts:
>    - Prepare a new submission
>    - Run pre-checks on a submission
>    - Submit a patch
>    - Status of patch
>
> 3. We should reify a way for Guix, the project, to measure, and track
> progress,
>    against long-term goals. Particularly when they're social and not
> strictly
>    technical.
>
> On 8/28/23 4:17 AM, Simon Tournier wrote:
>> Hi Katherine,
>>
>> On Fri, 25 Aug 2023 at 19:02, Katherine Cox-Buday
>wrote:
>>
>>> I think there's utility in distinguishing between familiarity and
>>> eliminating toil. I think it was incorrect of me to suggest forming
>>> habits in my original message. I think it's better to focus on
>>> eliminating toil so that whatever workflow remains can more easily be
>>> habituated.
>>
>> Since I am French, I am good as moaner and I would like to avoid the
>> ramblings of some grumble party. :-)
>>
>> I agree with you that it is important to reflect ourselves about our
>> practises and we need to be critical about what does not suit us.
>>
>> In order to be pragmatical and list actionable items, could you
>> specifically list what you consider as a toil or cognitive overhead?
>> Maybe you could share your script helping you.
>
> Yes, great point! Let's try to distill all this conversation down into the
> salient points and see if we can't agree on some actionable items.
>
> Here's my understanding of the process to contribute a patch:
>
>   1. Check out main, and run `./bootstrap`, then `./configure
> --localstatedir=/var --sysconfdir=/etc`
>   2. Run `make`
>   3. You need to determine whether the change can be targeted against
> main or
>  needs to target a feature branch, so you go read about that.
>
> [I'm usually starting here]
>
>   4. Run `./pre-inst-env guix refresh --list-dependent `
>   5. Create a git worktree for your patch
>   6. Run `./bootstrap`, then `./configure --localstatedir=/var
> --sysconfdir=/etc`
>   7. Run `make`
>   8. Make your changes
>   9. Build to ensure your changes are workable.
>   10. Try and determine how your changes should be factored into individual
>   commits (sometimes it's not always so clear when changing two
> things might
>   need to be done atomically).
>   11. Try and get each commit message close to correct and commit.
>   12. Run `guix lint`
>   13. Run `guix style` (this is still in the manual although I have since
>   learned this is not actually advisable).
>   14. Review the changes these tools have made, and fix things.
>   15. Run `guix build --rounds=2 ` to check for idempotency.
>   16. Run `make` to ensure you didn't break anything elsewhere in Guix.
>   17. Run `guix size` to ensure the closure isn't becoming bloated.
>   18. Build all the packages that depend on this package.
>   19. Run `guix pull --url=/path/to/your/checkout
> --profile=/tmp/guix.master` to
>   ensure you didn't break Guix in a different way.
>   20. Run `git format-patch -1 --cover-letter [--reroll-count]`
>   21. Run `./pre-inst-env ./etc/teams.scm cc-members ` to get
> the CC flags for Git
>   22. Remember that if you're sending multiple patches, an email first
> has to be
>   sent to `guix-patc...@gnu.org` to get an ID, and then...
>   23. Run `git send-email --to guix-patches  `
>
> I view steps 1-10 as pretty standard "development" steps common to most
> projects, although 11 compounds the effort in 10.
>
> In other projects I&

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

Liliana Marie Prikler  writes:

> Hi,
>
> Am Sonntag, dem 27.08.2023 um 16:57 +0300 schrieb Saku Laesvuori:
>> > > 
>> > not sure how most people consume their emails nowadays, but for me
>> > it's one flat list per thread, in a browser (i.e. it's not a tree).
>> 
>> The point is that the emails contain the information on how to
>> construct a tree out of them. It's just that most web clients (which
>> most people are unfortunately using nowadays) are so bad that they
>> render the tree as a flat list.
> Not sure about "most", but Guix folk are definitely biased towards
> dedicated mail clients (terminal, graphical, Emacs…), so perhaps my own
> perception was a little off in that people will always benefit from
> having the tree.  Then again, you can share your email between multiple
> clients, which isn't that easy to do with code repositories sadly.  
>
> Of course, you can mirror the repo, but your bug trackers aren't that
> easily mirrored.
>
>> 
>> > and all i'm trying to achieve here is to move the discussion away
>> > from email-is-superior-period, to look at what requiremenets we
>> > have and what tools satisfy them, if any.
>> 
>> I think that is a good discussion to have, but I think it would be
>> better to describe some of the requirements you think we should
>> consider instead of just saying email isn't superior. It might not
>> be, but it might also be. We should consider what we need and
>> evaluate the available tools based on that, and if the result is that
>> email is the best then it is.
> Not needing to register yet another account for one-off contributions
> is an argument that kills all the forges, sadly :)
>
With Sourcehut you can contribute without an account.
There is also https://forgefed.org/ which is for federated forges using
activitypub. So you can have one account for all forges that
federate. :D

MSavoritias
>> > > at the ChatGPT-related stuff that has been submitted). There
>> > > sadly is no pleasing everyone here and unless these tools are
>> > > incredibly simple to maintain, the utilitarian approach of least
>> > > misery leads you to plain email.
>> > 
>> > but is a least-misery model appropriate here? how do you even
>> > account for the contributions that could have happened in a
>> > different environment, but did not happen?
>> > 
>> > similarly, e.g. demanding a dated ChangeLog format for commit
>> > messages has a filtering effect on who will contribute, and then
>> > who will stick around. most engineers have a hard time jumping
>> > through hoops that they find pointless (git automatically encodes
>> > that information), and i'd suggest considering what the effect are
>> > of such rules on Guix asan emergent order.
>> 
>> I agree on the ChangeLogs being a weird thing to require in commit
>> messages. I think of commit messages as the place where you record
>> the reasons behind the change in the commit. The ChangeLog seems to
>> just record the changes which the diff of the commit already
>> automatically records more accurately.
> First things first, I disagree with the framing here.  Engineers do
> pointless things all the time and both code style and commit message
> style have near endless potential for bikeshedding (which we are
> currently engaged in btw).  There are like thirteen competing standards
> on how to format C code and similar debates in other languages.  In
> fact, I'd go so far as to argue that a language ecosystem that has no
> such debate is potentially lacking in diversity.
>
> A proper ChangeLog doesn't simply "record the changes the diff already
> records more accurately".  It adds semantics.  For instance, when
> bumping a package, we write the same line twice; once for the header,
> once for the ChangeLog.  What we don't write is that we also adjusted
> the hash along with the version.  Doing so would give us no new
> information, but the diff includes it anyway, because diffs are stupid.
> Humans writing (and reading) ChangeLogs aren't stupid and can rely on
> contextual meta-information – however, the ChangeLog should still be
> self-contained in the sense that it doesn't rely on other parts of the
> message to infer the actual changes made.
>
>> If someone has use cases for the ChangeLog commits, I'd like to hear
>> them. Maybe there is something that can't be achieved with git
>> history without ChangeLogs, but I can't think of anything. Someone
>> mentioned grepping the git log with them, 

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

Simon Tournier  writes:

> Hi,
>
> On Fri, 25 Aug 2023 at 18:39, Katherine Cox-Buday  
> wrote:
>
>> 2. Remember the email address (it might seem silly unless you have forms 
>> of dyslexia. is it guix-patches? or patches-guix? Wait, what was I doing?)
>> 3. And then the whole deal with what to do with follow ups.
>
> For what it is worth, I am using Emacs-Notmuch for reading emails and it
> provides the key “c G” for stashing the email address.  For instance,
> applying to your message:
>
> --to="Katherine Cox-Buday " 
> --to="guix-devel@gnu.org" --cc="guix-devel@gnu.org" 
> --in-reply-to="547c097a-d805-9a55-11d9-b0434327f...@gmail.com"
>
> Then, I am able to paste as argument for git-send-email or else.  Well,
> it reduces the opportunity for a typo.
>
> That’s said…
>
>> I wrote some elisp to one-key apply patches from GNUS, but I guess my 
>> point is: not everyone can do that. How are we to expect more 
>> contributors if that, or something similar, is the barrier to entry?
>
> …I agree that Debbugs is not the best system for managing patches.  Many
> of us are ending with some custom helpers for working around the
> annoyances.  And that seems an indicator that Debbugs is not the best
> fit.
>

Do you know if there are any plans to write a scheme bug/patching
system? Because looking a bit into it, it doesn't seem like its that
actively developed so maybe we would be better served by one in scheme.
Or Sourcehut of course as somebody wrote in another email.
Since not much would change with sr.ht anyways.

MSavoritias

> Cheers,
> simon

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

Just some remarks here,

Liliana Marie Prikler  writes:

> Am Freitag, dem 25.08.2023 um 08:07 + schrieb Attila Lendvai:
>> i couldn't even find out which tools are used by those who are
>> comfortable with the email based workflow. i looked around once, even
>> in the manual, but maybe i should look again.
> Users who have tried curlbash also looked at
>   wget https://issues.guix.gnu.org/issue/N/patch-set/M | git am -3
>
>> i'm pretty sure most maintainers have a setup where the emailed
>> patches can be applied to a new branch with a single press of a
>> button, otherwise it'd be hell of a time-waster.
> Well, it's several keys, actually, but as others have already pointed
> out, keyboard > mouse.
>
That is a subjective thing and its posed as something that is not. We
should all be open to being wrong.

>> one fundamental issue with the email based workflow is that its
>> underlying data model simply does not formally encode enough
>> information to be able to implement a slick workflow and frontend.
>> e.g. with a PR based model the obsolete versions of a PR is hidden
>> until needed (rarely). the email based model is just a flat list of
>> messages that includes all the past mistakes, and the by now
>> irrelevant versions.
> What the?  If anything, emails are like a tree and discussions in most
> forges are a single long list that's rarely well organized.  Virtually
> every mail client supports threads, whereas a certain one of the more
> popular forges still refuses to do so.  Hiding obsolete versions of a
> pull request is in practice implemented either by pushing more commits
> on top of the existing one, often with dubious commit messages or by
> force-pushing a branch, neither of which is an acceptable solution for
> Guix.
>
Using Emacs with mu4e its also bad to deal with lots of patches here too
:) Now having worked with Gitlab for example the UI is not as chaotic.
Aside from the "Gitlab is proprietary" argument which is NOT the
point. The point is how do we make it as easy as that for the people
that dont want to customize their email clients for optimal "threading"
capabilities?

>> > But someone would have to write and maintain them...
>> 
>> 
>> there are some that have already been written. here's an ad-hoc list
>> of references:
>> 
>> #github #gitlab #alternative
>> https://codeberg.org/
>> https://notabug.org/
>> https://sourcehut.org/
>> https://sr.ht/projects
>> https://builds.sr.ht/
>> https://git.lepiller.eu/gitile
>> codeberg.org is gitea and sr.ht is sourcehut
> Gitile is (as far as I'm aware) not yet a full forge.  It also hasn't
> loaded for me in ages, but I digress.
>
> It doesn't suffice if you just integrate any of those forges into the
> pre-existing workflow somehow.  You must also make it a pleasant
> experience for everyone involved.  This is similar to the issue that
> already bugs our Matrix<->IRC bridge.  
>
> Other implicit assumptions include that people will be happy to switch
> for the particular fork you've chosen (they won't) and will not demand
> $new_hot_thing within the next five years (they likely will, just look
> at the ChatGPT-related stuff that has been submitted).  There sadly is
> no pleasing everyone here and unless these tools are incredibly simple
> to maintain, the utilitarian approach of least misery leads you to
> plain email.
>
Also this is sounds like you think the other person just follows fashion
and you are the one that follows the "enlightened" way because you use
email. This is not the discussion we are having and we don't treat
people as less if they dont use terminal, emails or emacs or whatever
else you find amazing or whatever.

MSavoritias
> Cheers

Re: Relaxing the restrictions for store item names

[MSavoritias]

Julien Lepiller  writes:

> Le 24 août 2023 10:41:23 GMT+02:00, Msavoritias  a 
> écrit :
>>
>>What I am saying here is that:
>>Its easy to see from our very US centric tech culture why everybody
>>should just use ASCII because "This is how it is". But there is very
>>little reasons why we shouldn't strive to be more inclusive of all
>>cultures.
>>Especially since nowadays where we have tools like Unicode that make our
>>lives easier compared to US or nothing of 30-40 years ago.
>>Just imagine how many good programmers we are missing because they don't
>>want/can't learn English or don't have an ASCII keyboard.
>>
>>MSavoritias
>>
>>MSavoritias  writes:
>>
>>> Nguyễn Gia Phong  writes:
>>>
>>>> [[PGP Signed Part:Undecided]]
>>>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>>>>> Nguyễn Gia Phong  writes:
>>>>> > I think the distinction must be made here between Guix and GuixSD.
>>>>> >
>>>>> > The packaging software should support full localization,
>>>>> > but the distro should target the least common denominator.
>>>>>
>>>>> Depends what do we mean the "distro" here.
>>>>> If I can pick arabic or chinese in the installation as a display
>>>>> language and also I am able to use an arabic/chinese keyboard sounds
>>>>> good to me.
>>>>
>>>> I meant GuixSD.  I agree a distribution based on Guix Systems
>>>> shouldn't meet any obstacle declaring packages with non-ASCII names.
>>>> That you can type arabic and chinese and I can type hangul
>>>> and most latin characters doesn't mean names having all of the above
>>>> will be accessible to either of us or a third person.
>>>>
>>>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>>>>> Regarding the initial question it was about package names to my
>>>>> understanding. Specifically package names in the store to use unicode
>>>>> characters. Which makes perfect sense there because some packages dont
>>>>> use ascii names.
>>>>
>>>> It does, but as said before, whether this is desireable depends
>>>> on the target audience.  The purpose of API is to be used,
>>>> i.e. it would be useless if even just one user can't type it.
>>>>
>>> Well we already have that don't we? What I mean is that ASCII names cant
>>> be typed by all keyboards layouts easily. So what you are saying already
>>> happens. Thats why I always have an ASCII layout available as a
>>> secondary, next to my non ASCII. I bet every person that uses packages
>>> with names other than english can add a seperate layout.
>>>
>>>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>>>>> Regarding the broken install example, most (all?) base
>>>>> packages use ASCII due to unix historical baggage.
>>>>> So you shouldn't need to type anything non ASCII
>>>>> to fix an install with only basic packages.
>>>>
>>>> Due to historical baggage, most (all?) keyboard layouts can fall
>>>> back to ASCII alphanumerics.  A broken install was given
>>>> as the worst case; there's no reason any other packages
>>>> should be less accessible based on the users' culture.
>>>>
>>>
>>> But they are already aren't they? Because if I want to add a package
>>> with the Greek alphabet or the Japanese one I have to transliterate it
>>> into ASCII which is always going to be worse and people won't be able to
>>> find the package. Because they won't know we changed the name. Plus they
>>> will have to change the layout. Same as an ASCII user would have to do.
>>>
>>>> I suggest, in an international context such as GuixSD,
>>>> for every package to have a ASCII name.  It'd of course
>>>> be better if a correctly written name is also available.
>>>>
>>>
>>> So you propose two names? Sure if that can be done I don't see why not. 
>>> Either way not
>>> having unicode names is a bug. Also to note: Most of the world speaks
>>> Unicode. So its more for compatibility purposes i guess (?) rather than
>>> to be "international".
>>>
>>> MSavoritias
>>
>>
>
> There are two things discussed here:
>
> 1. A restriction in the daemon prevents using unicode in store item names.
>
> I think this is an issue worth fixing, as it would allow users to define 
> their own store items more easily. For instance, I might want to make a file 
> with non-ascii name a file-like item, eg.
>
> (local-file "fond d'écran.jpg")
>
> 2. Naming policy for packages in the Guix channel
>
> I don't think we should distribute packages that have non-ascii
> characters in their names. Of course I don't know all keyboards that
> exist out there, but I don't think you can find a programmer that
> can't type an ascii character, or a guix user that can't at least type
> "guix" in their terminal.
>
> For discoverability, we could add the real non-ascii name in the package 
> description.

Seems like a good solution for both cases.
I agree that it would help with searching especially to have the
non-ascii name in the description. or maybe as alternative translation
in the name (?). Probably description is the easiest one though.

MSavoritias

Re: Relaxing the restrictions for store item names

[Msavoritias]

What I am saying here is that:
Its easy to see from our very US centric tech culture why everybody
should just use ASCII because "This is how it is". But there is very
little reasons why we shouldn't strive to be more inclusive of all
cultures.
Especially since nowadays where we have tools like Unicode that make our
lives easier compared to US or nothing of 30-40 years ago.
Just imagine how many good programmers we are missing because they don't
want/can't learn English or don't have an ASCII keyboard.

MSavoritias

MSavoritias  writes:

> Nguyễn Gia Phong  writes:
>
>> [[PGP Signed Part:Undecided]]
>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>>> Nguyễn Gia Phong  writes:
>>> > I think the distinction must be made here between Guix and GuixSD.
>>> >
>>> > The packaging software should support full localization,
>>> > but the distro should target the least common denominator.
>>>
>>> Depends what do we mean the "distro" here.
>>> If I can pick arabic or chinese in the installation as a display
>>> language and also I am able to use an arabic/chinese keyboard sounds
>>> good to me.
>>
>> I meant GuixSD.  I agree a distribution based on Guix Systems
>> shouldn't meet any obstacle declaring packages with non-ASCII names.
>> That you can type arabic and chinese and I can type hangul
>> and most latin characters doesn't mean names having all of the above
>> will be accessible to either of us or a third person.
>>
>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>>> Regarding the initial question it was about package names to my
>>> understanding. Specifically package names in the store to use unicode
>>> characters. Which makes perfect sense there because some packages dont
>>> use ascii names.
>>
>> It does, but as said before, whether this is desireable depends
>> on the target audience.  The purpose of API is to be used,
>> i.e. it would be useless if even just one user can't type it.
>>
> Well we already have that don't we? What I mean is that ASCII names cant
> be typed by all keyboards layouts easily. So what you are saying already
> happens. Thats why I always have an ASCII layout available as a
> secondary, next to my non ASCII. I bet every person that uses packages
> with names other than english can add a seperate layout.
>
>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>>> Regarding the broken install example, most (all?) base
>>> packages use ASCII due to unix historical baggage.
>>> So you shouldn't need to type anything non ASCII
>>> to fix an install with only basic packages.
>>
>> Due to historical baggage, most (all?) keyboard layouts can fall
>> back to ASCII alphanumerics.  A broken install was given
>> as the worst case; there's no reason any other packages
>> should be less accessible based on the users' culture.
>>
>
> But they are already aren't they? Because if I want to add a package
> with the Greek alphabet or the Japanese one I have to transliterate it
> into ASCII which is always going to be worse and people won't be able to
> find the package. Because they won't know we changed the name. Plus they
> will have to change the layout. Same as an ASCII user would have to do.
>
>> I suggest, in an international context such as GuixSD,
>> for every package to have a ASCII name.  It'd of course
>> be better if a correctly written name is also available.
>>
>
> So you propose two names? Sure if that can be done I don't see why not. 
> Either way not
> having unicode names is a bug. Also to note: Most of the world speaks
> Unicode. So its more for compatibility purposes i guess (?) rather than
> to be "international".
>
> MSavoritias

Re: Relaxing the restrictions for store item names

[MSavoritias]

Nguyễn Gia Phong  writes:

> [[PGP Signed Part:Undecided]]
> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>> Nguyễn Gia Phong  writes:
>> > I think the distinction must be made here between Guix and GuixSD.
>> >
>> > The packaging software should support full localization,
>> > but the distro should target the least common denominator.
>>
>> Depends what do we mean the "distro" here.
>> If I can pick arabic or chinese in the installation as a display
>> language and also I am able to use an arabic/chinese keyboard sounds
>> good to me.
>
> I meant GuixSD.  I agree a distribution based on Guix Systems
> shouldn't meet any obstacle declaring packages with non-ASCII names.
> That you can type arabic and chinese and I can type hangul
> and most latin characters doesn't mean names having all of the above
> will be accessible to either of us or a third person.
>
> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>> Regarding the initial question it was about package names to my
>> understanding. Specifically package names in the store to use unicode
>> characters. Which makes perfect sense there because some packages dont
>> use ascii names.
>
> It does, but as said before, whether this is desireable depends
> on the target audience.  The purpose of API is to be used,
> i.e. it would be useless if even just one user can't type it.
>
Well we already have that don't we? What I mean is that ASCII names cant
be typed by all keyboards layouts easily. So what you are saying already
happens. Thats why I always have an ASCII layout available as a
secondary, next to my non ASCII. I bet every person that uses packages
with names other than english can add a seperate layout.

> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>> Regarding the broken install example, most (all?) base
>> packages use ASCII due to unix historical baggage.
>> So you shouldn't need to type anything non ASCII
>> to fix an install with only basic packages.
>
> Due to historical baggage, most (all?) keyboard layouts can fall
> back to ASCII alphanumerics.  A broken install was given
> as the worst case; there's no reason any other packages
> should be less accessible based on the users' culture.
>

But they are already aren't they? Because if I want to add a package
with the Greek alphabet or the Japanese one I have to transliterate it
into ASCII which is always going to be worse and people won't be able to
find the package. Because they won't know we changed the name. Plus they
will have to change the layout. Same as an ASCII user would have to do.

> I suggest, in an international context such as GuixSD,
> for every package to have a ASCII name.  It'd of course
> be better if a correctly written name is also available.
>

So you propose two names? Sure if that can be done I don't see why not. Either 
way not
having unicode names is a bug. Also to note: Most of the world speaks
Unicode. So its more for compatibility purposes i guess (?) rather than
to be "international".

MSavoritias

Re: Relaxing the restrictions for store item names

[MSavoritias]

Nguyễn Gia Phong  writes:

> On 2023-08-24 at 10:16+03:00, MSavoritias wrote:
>> "("  writes:
>> > Eidvilas Markevičius  writes:
>> > > with a name that contains non-Latin characters in it
>> > > (e.g., "Naršytuvas" by Raštija [2]).
>> >
>> > I think we should stick to ASCII characters in package names,
>> > since it's a bit difficult to type `guix install naršytuvas`
>> > for those who don't have keyboards with the 'š' character.
>>
>> And some people don't have an english keyboard so its harder to type
>> english characters. Thats not a reason to exclude people in either
>> direction :)
>
> I think the distinction must be made here between Guix and GuixSD.
>
> On 2023-08-24 at 10:16+03:00, MSavoritias wrote:
>> I was not aware that its not possible to have Unicode characters
>> in store names but that is a bug to me at the very least
>> (and exclusionary of course). We should open a bug report
>> and work on fixing the bug.
>
> The packaging software should support full localization,
> but the distro should target the least common denominator.
> AFAIK most keyboard layouts cover ASCII alphanumerics
> but the reverse is not true.
>
> Inclusion goes both ways.  Imagine trying to type my name
> to fix a broken install that only boots to run level 3.

Depends what do we mean the "distro" here.
If I can pick arabic or chinese in the installation as a display
language and also I am able to use an arabic/chinese keyboard sounds
good to me.

Regarding the initial question it was about package names to my
understanding. Specifically package names in the store to use unicode
characters. Which makes perfect sense there because some packages dont
use ascii names. Regarding the broken install example, most (all?) base
packages use ASCII due to unix historical baggage. So you shouldn't need
to type anything non ASCII to fix an install with only basic packages.

Not that I would care if that changed personally. Non Ascii people have
been accomodating for a long time already. Some balance would be nice :)

MSavoritias

Re: Relaxing the restrictions for store item names

[MSavoritias]

And some people don't have an english keyboard so its harder to type
english characters. Thats not a reason to exclude people in either
direction :)

I was not aware that its not possible to have Unicode characters in
store names but that is a bug to me at the very least (and exclusionary
of course). We should open a bug report and work on fixing the bug.

MSavoritias

"("  writes:

> Eidvilas Markevičius  writes:
>> with a name that contains non-Latin characters in it (e.g.,
>> "Naršytuvas" by Raštija [2]). 
>
> I think we should stick to ASCII characters in package names, since it's
> a bit difficult to type `guix install naršytuvas` for those who don't
> have keyboards with the 'š' character.  You can do it in emacs with
> insert-char or Evil digraphs, but not everyone uses the terminal in
> emacs :)
>
> (In fact, controversial studies show that some people may not even use
> Emacs at all. This observation may well overturn the entirety of known
> physics if proven.)
>
>   -- (

Re: A Forum for Guix Users

[MSavoritias]

Attila Lendvai  writes:

>> Regarding the forum I dont think any forum would have much traction.
>> I agree that either matrix or xmpp could be considered instead for that
>> purpose.
>> As a more approachable chat mechanism compared to IRC.
>
>
> it's an essential role of a forum that latecomers find the earlier
> questions/discussions, typically through a websearch. a forum's
> primary user-story is very much not that of a chat, i.e. a real-time,
> ephemeral, linear flow of text, sometimes with multiple overlapping
> discussions, and as such not very well processed by the search engine
> crawlers...
>
> i think it all boils down to this:
>
> mailing list archives (and IRC logs) are stuck in time. their underlying data 
> model is inadequate for efficient indexing/searching, and often lack 
> structure even to conveniently present the archive to the user.

Good point.
My thinking is that next we miss too things for that:

1. Easy search and indexing of our docs. Which already exists for the
most part. Searching for occurunces of words like grep or a full blown
wiki like gentoo or arch would be an interesting future approach.
2. We need something easier than gnu info to contribute docs. As I have
read a lot in irc for it to be a barrier. And personally its one of the
main reasons i havent contributed yet. That I need time to learn
it. That and I can't easily change or add Docs. I have to do pull
requests and such.

Thats why I was also aggreeing with Sourcehut in the other email. (Which
already has guix ci support.) Guix would benefit from less NIH imo. At
least in places where there already better solutions.

Msavoritias

> -- 
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39

Re: A Forum for Guix Users

[Msavoritias]

Csepp  writes:

> Robby Zambito  writes:
>
>> Hi Sarthak,
>>
>>> As of now, it's a bit difficult for beginners to find answers to their 
>>> problems in the mailing list or in IRC logs as they aren't very
>>> easy to navigate compared to forum threads.
>>
>> I personally think that it would be wiser to improve the documentation
>> relating to the mailing lists and IRC logs, rather than fragmenting the
>> places that someone should look for answers. Maybe a new / additional
>> frontend that is more approachable for new users would also be good.
>
> Sourcehut has full-time employees working on making these accessible, so
> it really boggles my mind why we aren't using that instead of Savannah
> and Debbugs.
> We could also bridge IRC to Matrix (even though the company behind it
> has some people who... let's say like the taste of leather too much).
> Pine64 has a great chat setup actually, their channels are bridged to a
> whole bunch of services.  Not saying we must also bridge with Discord,
> but at least the libre options should be considered.
>

Hey,

Very much agreed with Sourcehut as a much better frontend for guix.
Plus its AGPL3 licensed all of it afaik.

Regarding the forum I dont think any forum would have much traction.
I agree that either matrix or xmpp could be considered instead for that
purpose.
As a more approachable chat mechanism compared to IRC.

MSavoritias

>> I have never found myself participating in distro-specific forums; I
>> have always used them as read-only sources of information. Yet here I am
>> participating in the Guix mailing lists :). I bet I am not alone in this
>> experience.
>>
>> Also FWIW, Guix was basically my introduction to participating in
>> mailing lists. So I wouldn't say I am biased in my old ways of doing
>> things - I just genuinely think it's a good way to handle communication.
>>
>> Robby
>
> Guix is also the first project I contributed to in a major way over
> mailing lists and my experience is that if you don't keep up to date
> with the list, the lackluster search and linking will be a major pain in
> the buttocks.  It is usable for experts, but is absolutely not
> beginner-friendly.
> But even experts would benefit from a better workflow.

Re: Maybe a way to get a few more developpers to work on Guix ?

[MSavoritias]

pinoaffe  writes:

> Nicolas Graves via "Development of GNU Guix and the GNU System distribution." 
>  writes:
>> ... code generation through LLMs. This could itself help Guix generate
>> (and fix) package definitions.
>
> I really don't think that that'd be a good match for Guix.  Writing
> package definitions is easy, can be assisted with a snippet (such as
> provided in /path/to/guix/etc/snippets/yas/scheme-mode/guix-package) and
> writing a package definition takes hardly more work than verifying that
> an LLM-provided package definition is reasonable.
>
> In other words, I don't think a LLM could make it easier/faster to write
> package definitions.
>
> Kind regards,
> pinoaffe

Yeah Agreed.

It seems to just shift the problem from "We need developers" to "We need
people that verify the output of the LLM." So we are basically stuck
with the same problem.

Regards,
MSavoritias