Teams

Teams

[Ricardo Wurmus]

Hi Guix,

this is not a new idea[1]: let’s add a page to the website that lists teams
and a mail alias for each of the teams.

For example, the “R team” consists of people familiar with how R
packaging works in Guix, e.g. Simon and myself.  There would be an alias
“guix-team-r@gnu.org”.  People with questions about R in Guix could
write an email to that alias.

Mumi could also send email to guix-team-r@gnu.org to remind them about
patches relating to R / Bioconductor / CRAN, etc.

Maintainers could write to these teams before releases to ask if there
are any obstacles to a release.

As a first step I’d suggest collecting teams, setting up the email
aliases, and updating the website to show the existing teams.  Here’s
a draft of three teams:

* R team
Simon Tournier
Ricardo Wurmus

* Java team
Julien Lepiller

* Rust team
Efraim Flashner
Aleksandr Vityazev
Arun Isaac
John Soo
Maxim Cournoyer
Nicolas Goaziou
Tobias Geerinckx-Rice

What do you think?


-- 
Ricardo

[1]: https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00224.html

Re: Teams

[Maxime Devos]

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

Ricardo Wurmus schreef op za 04-06-2022 om 14:07 [+0200]:
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:
> 
> [...]

You can add me to the Rust team and to a new Minetest team.
Maybe Vivien Kraus would be interested in joining the Minetest team.

Greetings,
Maxime.

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

Re: Teams

[Ekaitz Zarraga]

> Hi Guix,
>
> this is not a new idea[1]: let’s add a page to the website that lists teams
> and a mail alias for each of the teams.
>
> For example, the “R team” consists of people familiar with how R
> packaging works in Guix, e.g. Simon and myself. There would be an alias
> “guix-team-r@gnu.org”. People with questions about R in Guix could
> write an email to that alias.
>
> Mumi could also send email to guix-team-r@gnu.org to remind them about
> patches relating to R / Bioconductor / CRAN, etc.
>
> Maintainers could write to these teams before releases to ask if there
> are any obstacles to a release.
>
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams. Here’s
> a draft of three teams:
>
> * R team
> Simon Tournier
> Ricardo Wurmus
>
> * Java team
> Julien Lepiller
>
> * Rust team
> Efraim Flashner
> Aleksandr Vityazev
> Arun Isaac
> John Soo
> Maxim Cournoyer
> Nicolas Goaziou
> Tobias Geerinckx-Rice
>
> What do you think?
>
>
> --
> Ricardo
>
> [1]: https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00224.html


If you want to add a Bootstrapping team, feel free to add me there.

Thanks for this effort. It's really interesting.

Cheers,
Ekaitz

Re: Teams

[Tobias Geerinckx-Rice]

On 4 June 2022 12:07:15 UTC, Ricardo Wurmus <rekado@elephly.net> wrote:
>* Rust team
[...]
>Tobias Geerinckx-Rice

OK what the hell.

I'll also join Leo on a kernel/module/initrd team if they're interested.

I think we should also have (natural) language 'teams' who can be pinged when, e.g., a news item lands, through a single guix-translators@ meta-alias, and who can co-ordinate before releases.

I'll take -nl.  Maxime?

Ricardo,

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: Teams

[Maxime Devos]

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

Tobias Geerinckx-Rice schreef op za 04-06-2022 om 14:50 [+0000]:
> I think we should also have (natural) language 'teams' who can be pinged when, e.g., a news item lands, through a single guix-translators@ meta-alias, and who can co-ordinate before releases.
> 
> I'll take -nl.  Maxime?

Ok sure.

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

Re: Teams

[david larsson]

> On 4 June 2022 12:07:15 UTC, Ricardo Wurmus <rekado@elephly.net> wrote:
>> * Rust team
> [...]
>> Tobias Geerinckx-Rice
> 
> OK what the hell.
> 

Would you wanna create and be the Bash team person as well? :)

Best regards,
David

Re: Teams

[Josselin Poiret]

Hello everyone,

Ricardo Wurmus <rekado@elephly.net> writes:

> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.

I think an installer team would be good too (which I would gladly join).
WDYT of the following teams:
* Installer (which I'd gladly join);
* System;
* Home;
* Internals?

Maybe that would add too many teams, but I think the first three could
be pretty useful.

How do we automatically make Mumi understand which team a patch should
notify?  I've just started using public-inbox/lei and the `dfn:` search
term is pretty useful, it lets you select only patches that change
specific files.  For example, `dfn:gnu/installer*` would match all
patches that touch the installer.

Best,
-- 
Josselin Poiret

Re: Teams

[pelzflorian (Florian Pelz)]

On Sat, Jun 04, 2022 at 02:50:49PM +0000, Tobias Geerinckx-Rice wrote:
> I think we should also have (natural) language 'teams' who can be
> pinged when, e.g., a news item lands, through a single
> guix-translators@ meta-alias, and who can co-ordinate before
> releases.

If we do so, please add me too for -de.

Regards,
Florian

Re: Teams

[Lars-Dominik Braun]

Hi Ricardo,

> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:

* Python Team
Lars-Dominik Braun

* Haskell Team
Lars-Dominik Braun

Anyone interested to join these with me?

Cheers,
Lars

Re: Teams

[zimoun]

Hi Ricardo,

On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus <rekado@elephly.net> wrote:

> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:

Well, a team per build system would fit more or less the needs, I
guess.  It is not a big deal if there are some overlaps.

For what is it is worth, I would suggest that people with commit access
appear at least once in one team, if possible.


> * R team
> Simon Tournier
> Ricardo Wurmus

In addition, add me to:

* Julia team


Cheers,
simon

Re: Teams

[Andreas Enge]

Hello,

Am Sat, Jun 04, 2022 at 02:07:15PM +0200 schrieb Ricardo Wurmus:
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:

if something like this makes sense, I would be interested in joining a team
around algebra.scm and maths.scm. Or maybe a C team :)

Andreas

Re: Teams

[Julien Lepiller]

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

If we make a team per build system, I'd be in ant, maven, ocaml and dune :)

I think there was also interest in formal methods, it could be a team.

On June 5, 2022 11:51:20 AM GMT+02:00, zimoun <zimon.toutoune@gmail.com> wrote:
>Hi Ricardo,
>
>On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> As a first step I’d suggest collecting teams, setting up the email
>> aliases, and updating the website to show the existing teams.  Here’s
>> a draft of three teams:
>
>Well, a team per build system would fit more or less the needs, I
>guess.  It is not a big deal if there are some overlaps.
>
>For what is it is worth, I would suggest that people with commit access
>appear at least once in one team, if possible.
>
>
>> * R team
>> Simon Tournier
>> Ricardo Wurmus
>
>In addition, add me to:
>
>* Julia team
>
>
>Cheers,
>simon
>

[-- Attachment #2: Type: text/html, Size: 1439 bytes --]

Re: Teams

[indieterminacy]

FWIW,

I just want to commend whoever is packaging TexLive.

My last update covered March of this year - no mean feat given that it 
is a 3.4GB package aggregate.

(sorry I cant do more direct contributions for Guix atm, looking forward 
to such an honour eventually)

On 04-06-2022 14:07, Ricardo Wurmus wrote:
> Hi Guix,
> 
> this is not a new idea[1]: let’s add a page to the website that lists 
> teams
> and a mail alias for each of the teams.
> 
> For example, the “R team” consists of people familiar with how R
> packaging works in Guix, e.g. Simon and myself.  There would be an 
> alias
> “guix-team-r@gnu.org”.  People with questions about R in Guix could
> write an email to that alias.
> 
> Mumi could also send email to guix-team-r@gnu.org to remind them about
> patches relating to R / Bioconductor / CRAN, etc.
> 
> Maintainers could write to these teams before releases to ask if there
> are any obstacles to a release.
> 
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:
> 
> * R team
> Simon Tournier
> Ricardo Wurmus
> 
> * Java team
> Julien Lepiller
> 
> * Rust team
> Efraim Flashner
> Aleksandr Vityazev
> Arun Isaac
> John Soo
> Maxim Cournoyer
> Nicolas Goaziou
> Tobias Geerinckx-Rice
> 
> What do you think?

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: Teams

[Mathieu Othacehe]

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


Hello Ricardo,

I would suggest to extend a bit the scope of this idea. What about
creating an etc/tutors.scm file as the one attached.

This way people would run something like:

--8<---------------cut here---------------start------------->8---
git send-email $(get-tutors.scm HEAD^^) *.patches
--8<---------------cut here---------------end--------------->8---

The get-tutors.scm command would take a git reference as argument. From
this git reference the list of edited files would be extracted. Once
matched with the modules field of tutors.scm, the ML & tutors that
should be CC'ed would be returned.

For the previous example, if the patches are modifying (gnu packages
bioconductor), the command would be:

--8<---------------cut here---------------start------------->8---
git send-email --to guix-patches@gnu.org --cc guix-r-patches@gnu.org
--cc rekado@elephly.net --cc zimoun.toutoune@gmail.com *.patches
--8<---------------cut here---------------end--------------->8---

People could subscribe to the relevant ML if they want to follow
specific subjects. If someone wants to become a tutor, a patch could be
sent against the tutors.scm file.

Being listed in the tutors.scm file would imply some duties, such as
trying to review part of the traffic for the tutored parts.

We could then turn this tutors.scm file into a website page,
transforming the tutors SEXP into an HTML table.

WDYT?

Thanks,

Mathieu

[-- Attachment #2: tutors.scm --]
[-- Type: application/octet-stream, Size: 1769 bytes --]

;;; Copyright © 2022 Mathieu Othacehe <othacehe@gnu.org>

(tutors
 (version 0)

 (entry (name "R tutors")
        (members
         "R patches <guix-r-patches@gnu.org>"
         "Ricardo Wurmus <rekado@elephly.net>"
         "Simon Tournier <zimon.toutoune@gmail.com>")
        (modules
         "gnu/packages/bioconductor.scm"
         "gnu/packages/bioinformatics.scm"
         "gnu/packages/cran.scm"
         "guix/build/r-build-system.scm"
         "guix/build-system/r.scm"))

 (entry (name "Java tutors")
        (members
         "Java patches <guix-java-patches@gnu.org>"
         "Julien Lepiller <julien@lepiller.eu>")
        (modules
         "gnu/packages/java.scm"
         "gnu/packages/java-*.scm"
         "gnu/packages/maven*.scm"
         "guix/build/maven-build-system.scm"
         "guix/build/maven/*"
         "guix/build-system/maven.scm"))

 (entry (name "Rust tutors")
        (members
         "Rust patches <guix-rust-patches@gnu.org>"
         "Efraim Flashner <efraim@flashner.co.il>"
         "Aleksandr Vityazev <avityazev@posteo.org>"
         "Arun Isaac <arunisaac@systemreboot.net>"
         "John Soo <jsoo1@asu.edu>"
         "Maxim Cournoyer <maxim.cournoyer@gmail.com>"
         "Maxime Devos <maximedevos@telenet.be>"
         "Nicolas Goaziou <mail@nicolasgoaziou.fr>"
         "Tobias Geerinckx-Rice <me@tobias.gr>")
        (modules
         "gnu/packages/rust*.scm"
         "guix/build/cargo*.scm"
         "guix/build-system/cargo.scm"))

 (entry (name "Installer tutors")
        (members
         "Installer patches <guix-installer-patches@gnu.org>"
         "Josselin Poiret <dev@jpoiret.xyz>"
         "Mathieu Othacehe <othacehe@gnu.org>")
        (modules
         "gnu/installer.scm"
         "gnu/installer/")))

Re: Teams

[Maxim Cournoyer]

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

[...]

> * Rust team
[...]
> Maxim Cournoyer
[...]

I don't think I'm specially fit for Rust packaging (I have little
experience/interest in packaging *apps/libraries* with it -- I've only
looked into shortening the Rust bootstrap out of necessity :-)).

I'd be happy to be on a Python/Emacs packaging team though.

Thanks for the initiative!

Maxim

Re: Teams

[Ludovic Courtès]

Hi!

Josselin Poiret <dev@jpoiret.xyz> skribis:

> WDYT of the following teams:
> * Installer (which I'd gladly join);
> * System;
> * Home;
> * Internals?

I think these are good ideas.

Count me on the System, Home, and Internals/Core teams!

Ludo’.

Re: Teams

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

> I would suggest to extend a bit the scope of this idea. What about
> creating an etc/tutors.scm file as the one attached.
>
> This way people would run something like:
>
> git send-email $(get-tutors.scm HEAD^^) *.patches

Nice idea, I like that!

To get the ball rolling though, I’d suggest starting with a dumb
structured web page like Ricardo proposes (I’m happy to give a hand if
needed).

From there we can enhance it by making the tutors file you propose the
canonical source of info, and providing a script to read it.

Ludo’.

Re: Teams

[Ryan Prior]

On Saturday, June 4th, 2022 at 12:07 PM, Ricardo Wurmus <rekado@elephly.net> wrote:

> let’s add a page to the website that lists teams
> and a mail alias for each of the teams

That sounds great. What do you think about encouraging each team to write a dedicated intro to Guix from the perspective of that team as well? For example, I assume people who are on the Home or System teams use different workflows than I typically do, and I'd love to learn them.

Teams I could contribute to:
- python, ruby, golang
- DevOps/Docker

Cheers,
Ryan

Re: Teams

[Thiago Jung Bauermann]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> On Sat, Jun 04, 2022 at 02:50:49PM +0000, Tobias Geerinckx-Rice wrote:
>> I think we should also have (natural) language 'teams' who can be
>> pinged when, e.g., a news item lands, through a single
>> guix-translators@ meta-alias, and who can co-ordinate before
>> releases.
>
> If we do so, please add me too for -de.

I'd be happy to be in a -pt team.

-- 
Thanks
Thiago

Re: Teams

[Efraim Flashner]

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

On Sun, Jun 05, 2022 at 11:51:20AM +0200, zimoun wrote:
> Hi Ricardo,
> 
<snip>
> 
> > * R team
> > Simon Tournier
> > Ricardo Wurmus
> 
> In addition, add me to:
> 
> * Julia team

I can do the Julia team too.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: Teams

[Vagrant Cascadian]

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

On 2022-06-04, Ricardo Wurmus wrote:
> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:

I'm almost afraid to volunteer... but maybe architecture specific teams?

If I were to put my very highly optimistic hat on, I might be up for
aarch64, riscv64 and armhf...

live well,
  vagrant

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

Re: Teams

[Ludovic Courtès]

Vagrant Cascadian <vagrant@debian.org> skribis:

> On 2022-06-04, Ricardo Wurmus wrote:
>> As a first step I’d suggest collecting teams, setting up the email
>> aliases, and updating the website to show the existing teams.  Here’s
>> a draft of three teams:
>
> I'm almost afraid to volunteer... but maybe architecture specific teams?

There could also be an “embedded” team for people who take care of
packages like U-Boot, cross-compilation to ARM, platform definitions,
and all these things you’re familiar with.

> If I were to put my very highly optimistic hat on, I might be up for
> aarch64, riscv64 and armhf...

That too!

Ludo’.

Re: Teams

[Thiago Jung Bauermann]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Vagrant Cascadian <vagrant@debian.org> skribis:
>
>> On 2022-06-04, Ricardo Wurmus wrote:
>>> As a first step I’d suggest collecting teams, setting up the email
>>> aliases, and updating the website to show the existing teams.  Here’s
>>> a draft of three teams:
>>
>> I'm almost afraid to volunteer... but maybe architecture specific teams?
>
> There could also be an “embedded” team for people who take care of
> packages like U-Boot, cross-compilation to ARM, platform definitions,
> and all these things you’re familiar with.

I'm assuming the teams are for committers, so because of that and
also — or even especially — because of my time availability I would
be interested in being a lurker/occasional helper on an embedded team,
if it would be possible to have such a thing.

>> If I were to put my very highly optimistic hat on, I might be up for
>> aarch64, riscv64 and armhf...
>
> That too!

Ditto for ppc64le and even aarch64 teams.

-- 
Thanks
Thiago

Re: Teams

[Eric Bavier]

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

Hi,

On Sun, 2022-06-05 at 11:51 +0200, Andreas Enge wrote:
> Hello,
> 
> Am Sat, Jun 04, 2022 at 02:07:15PM +0200 schrieb Ricardo Wurmus:
> > As a first step I’d suggest collecting teams, setting up the email
> > aliases, and updating the website to show the existing teams. 
> > Here’s
> > a draft of three teams:
> 
> if something like this makes sense, I would be interested in joining
> a team
> around algebra.scm and maths.scm. Or maybe a C team :)

I like the Teams idea.  It might help me focus and add just enough
accountability.

I'd add myself to an algebra.scm and maths.scm team.

`~Eric

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

Re: Teams

[Arun Isaac]

Hi Guix,

I like the idea of teams. And, it's nice to see so many volunteers raise
their hands!

> * Rust team
> Efraim Flashner
> Aleksandr Vityazev
> Arun Isaac
> John Soo
> Maxim Cournoyer
> Nicolas Goaziou
> Tobias Geerinckx-Rice

However, I know very little about Rust, and I'm not a good fit for this
team. I could easily be a part of the python, emacs lisp, common lisp,
scheme teams, etc if necessary.

But, what I'd really like is to be part of a mumi+tooling team. Maybe we
should have such a team?

Also, since we have so many ideas for teams, can we have some structured
way to suggest teams, and add or remove them as needs change?

Regards,
Arun

Re: Teams

[Blake Shaw]

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

Hi folks,

I'm just getting back to the list after finishing a gig, but want to raise
my hand to join both the scheme team and perhaps something like an A/V team
if folks think that would be a desirable team to put together. I think an
A/V team would look after:

#+begin_example scheme
 (gnu packages gstreamer)
 (gnu packages gl) ;; Maybe games could handle this?
 (gnu packages video)
 (gnu packages graphics)
 (gnu packages music)
#+end_example

Which is quite a lot! So maybe some of this should be split up with the
"games" team.

On another note, I'll be getting back to the Guile Docs soon, and before
that I plan on taking a stab at refactoring the patch submission criteria,
which I think could use some work. As it is currently, it personally
becomes a hurdle of a checklist when I want to quickly submit a patch,
which has lead me to running a hotfix branch so that I can quickly fix an
issue and move on, therefore contributing what I should be. I think it
could express all the same requirements in less rules, making it easier to
ensure what you're handing in is in order. But I still need to take a stab
at it and see.

Best,

On Fri, Jun 10, 2022, 03:29 Arun Isaac <arunisaac@systemreboot.net> wrote:

>
> Hi Guix,
>
> I like the idea of teams. And, it's nice to see so many volunteers raise
> their hands!
>
> > * Rust team
> > Efraim Flashner
> > Aleksandr Vityazev
> > Arun Isaac
> > John Soo
> > Maxim Cournoyer
> > Nicolas Goaziou
> > Tobias Geerinckx-Rice
>
> However, I know very little about Rust, and I'm not a good fit for this
> team. I could easily be a part of the python, emacs lisp, common lisp,
> scheme teams, etc if necessary.
>
> But, what I'd really like is to be part of a mumi+tooling team. Maybe we
> should have such a team?
>
> Also, since we have so many ideas for teams, can we have some structured
> way to suggest teams, and add or remove them as needs change?
>
> Regards,
> Arun
>
>

[-- Attachment #2: Type: text/html, Size: 2635 bytes --]

Re: Teams

[raingloom]

I'd definitely love to see an A/V or graphics production team, making
Guix more suitable for artists has been on my TODO list for a while,
even made some tentative steps towards packaging Blender addons.
Personally, I'd love to help out with testing and/or developing Blender
stuff.

On Mon, 13 Jun 2022 13:38:16 +0000
Blake Shaw <blake@sweatshoppe.org> wrote:

> Hi folks,
> 
> I'm just getting back to the list after finishing a gig, but want to
> raise my hand to join both the scheme team and perhaps something like
> an A/V team if folks think that would be a desirable team to put
> together. I think an A/V team would look after:
> 
> #+begin_example scheme
>  (gnu packages gstreamer)
>  (gnu packages gl) ;; Maybe games could handle this?
>  (gnu packages video)
>  (gnu packages graphics)
>  (gnu packages music)
> #+end_example
> 
> Which is quite a lot! So maybe some of this should be split up with
> the "games" team.
> 
> On another note, I'll be getting back to the Guile Docs soon, and
> before that I plan on taking a stab at refactoring the patch
> submission criteria, which I think could use some work. As it is
> currently, it personally becomes a hurdle of a checklist when I want
> to quickly submit a patch, which has lead me to running a hotfix
> branch so that I can quickly fix an issue and move on, therefore
> contributing what I should be. I think it could express all the same
> requirements in less rules, making it easier to ensure what you're
> handing in is in order. But I still need to take a stab at it and see.
> 
> Best,
> 
> On Fri, Jun 10, 2022, 03:29 Arun Isaac <arunisaac@systemreboot.net>
> wrote:
> 
> >
> > Hi Guix,
> >
> > I like the idea of teams. And, it's nice to see so many volunteers
> > raise their hands!
> >  
> > > * Rust team
> > > Efraim Flashner
> > > Aleksandr Vityazev
> > > Arun Isaac
> > > John Soo
> > > Maxim Cournoyer
> > > Nicolas Goaziou
> > > Tobias Geerinckx-Rice  
> >
> > However, I know very little about Rust, and I'm not a good fit for
> > this team. I could easily be a part of the python, emacs lisp,
> > common lisp, scheme teams, etc if necessary.
> >
> > But, what I'd really like is to be part of a mumi+tooling team.
> > Maybe we should have such a team?
> >
> > Also, since we have so many ideas for teams, can we have some
> > structured way to suggest teams, and add or remove them as needs
> > change?
> >
> > Regards,
> > Arun
> >
> >  

Re: Teams

[Andrew Tropin]

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

On 2022-06-05 10:19, Josselin Poiret wrote:

> Hello everyone,
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> As a first step I’d suggest collecting teams, setting up the email
>> aliases, and updating the website to show the existing teams.
>
> I think an installer team would be good too (which I would gladly join).
> WDYT of the following teams:
> * Installer (which I'd gladly join);
> * System;
> * Home;
> * Internals?
>
> Maybe that would add too many teams, but I think the first three could
> be pretty useful.
>
> How do we automatically make Mumi understand which team a patch should
> notify?  I've just started using public-inbox/lei and the `dfn:` search
> term is pretty useful, it lets you select only patches that change
> specific files.  For example, `dfn:gnu/installer*` would match all
> patches that touch the installer.
>
> Best,

I'm not in a guix-maintainers yet, but I would like to join Home team.

-- 
Best regards,
Andrew Tropin

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

Re: Teams

[Blake Shaw]

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

I think I could join the Home team as well, at least for now, as I started
using it a month ago and have been having a blast. I also have some
home-services to upstream after a bit of polish (Guile EDSL for
Herbstluftwm configuration if anyone is interested), and some plans to work
on the documentation.

I found the documentation to be a bit confusing (understandably, as its
new), but once the workflow snapped together its been amazing to see how
easy it is to create new services. And I now I have my entire desktop
environment contained in a single text file! Being able to ftp a text file
to a fresh Debian linode and get to work with all my tools ready within 10
minutes has been magic.

It also demonstrates a lot of Guile's strengths in one place: you can
easily wrap interfaces in Guile, and the expressive power it adds (at least
in the case of a window manager) is immediately evident.

Very excited about it, great work :)

On Tue, Jun 14, 2022, 18:31 Andrew Tropin <andrew@trop.in> wrote:

> On 2022-06-05 10:19, Josselin Poiret wrote:
>
> > Hello everyone,
> >
> > Ricardo Wurmus <rekado@elephly.net> writes:
> >
> >> As a first step I’d suggest collecting teams, setting up the email
> >> aliases, and updating the website to show the existing teams.
> >
> > I think an installer team would be good too (which I would gladly join).
> > WDYT of the following teams:
> > * Installer (which I'd gladly join);
> > * System;
> > * Home;
> > * Internals?
> >
> > Maybe that would add too many teams, but I think the first three could
> > be pretty useful.
> >
> > How do we automatically make Mumi understand which team a patch should
> > notify?  I've just started using public-inbox/lei and the `dfn:` search
> > term is pretty useful, it lets you select only patches that change
> > specific files.  For example, `dfn:gnu/installer*` would match all
> > patches that touch the installer.
> >
> > Best,
>
> I'm not in a guix-maintainers yet, but I would like to join Home team.
>
> --
> Best regards,
> Andrew Tropin
>

[-- Attachment #2: Type: text/html, Size: 2701 bytes --]

how to write services (was: Re: Teams)

[catonano]

Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
> 
> I found the documentation to be a bit confusing (understandably, as
> its new), but once the workflow snapped together its been amazing to
> see how easy it is to create new services. 

This is something I'm specifically interested in

In fact, I wrote this toot that got several boosts and likes but NO
answer
https://floss.social/web/@abbienormal/108378060174601402

How to write a service (was: Re: Teams)

[catonano]

Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
> 
> I found the documentation to be a bit confusing (understandably, as
> its new), but once the workflow snapped together its been amazing to
> see how easy it is to create new services. 

I'm specifically interested in this issue

In fact, I posted a toot about this, that received several booosts and
likes but NO answer
https://floss.social/@abbienormal/108378060174601402

Maybe writing a Home service is easier (meaning the process is less
articulated) ?

And then once it's reasonably stable it can be moved to be a system
service ?



> > 

Re: how to write services (was: Re: Teams)

[Ricardo Wurmus]

catonano@gmail.com writes:

> Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
>> 
>> I found the documentation to be a bit confusing (understandably, as
>> its new), but once the workflow snapped together its been amazing to
>> see how easy it is to create new services. 
>
> This is something I'm specifically interested in
>
> In fact, I wrote this toot that got several boosts and likes but NO
> answer
> https://floss.social/web/@abbienormal/108378060174601402

I don’t know Odoo, but the general process is this:

- look up the relevant documentation of your application to figure out
  what commands must be executed.  Take note of any way to pass a
  configuration file.

- copy an existing shepherd service.  Maybe start with
  gnu/services/audio.scm, because it’s pretty simple while not completely
  trivial.

- adjust the commands and names.

In gnu/services/audio.scm you see the definition of mpd-service-type,
which is a *system* service that 1) adds a user account, 2) does some
one-shot preparation work, and 3) registers the mpd-shepherd-service.

mpd-shepherd-service is a procedure returning a shepherd service.  The
service has a start and stop command.  Adjust this for your service.

mpd-shepherd-service refers to its argument “config”, which is supposed
to be a Scheme configuration value.  It’s just a record defined higher
up as <mpd-configuration>.  mpd-config->file turns that Scheme value
into a string that can live in a file as the mpd configuration file.

This is pretty much all there is to it.  Some services are simpler and
don’t need any one-shot setup, nor do they need system user accounts, so
they would just boil down to a shepherd service definition.

-- 
Ricardo

Re: how to write services (was: Re: Teams)

[Blake Shaw]

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

Ricardo:
Thats very good advice and will be a useful guide in refactoring the parts
of the system services documentation. I think in general, we need to find a
nice middle ground between the extremely general and the immediately
sensible, as I remember when I first got into guix 1.5 years ago, arriving
at services left me very confused. While as a recent PhD candidate in
philosophy of mathematics I'm a fellow appreciator of the power of
generality (the extreme genericity of scheme and guix is why I'm here!), I
also think if it doesn't obey strict linguistic rules it can antithetical
to its original purpose. For example, I remember being very confused about
"file-like objects", for the simple reason that it wasn't "a file or
file-like object". While this might come from a GNU terminological lineage
i'm unaware of, my immediate reaction to trying to understand file-likeness
is the simple rule that a semblance is strictly not what it resembles, and
likeness qualifies semblance. It would be improper to place phones in a
category of "phone-like objects", because the likeness assumes a
distinction from the thing itself. Perhaps it could be justified if we dive
into the minutiae of paraconsistent logic, but I think then we are going to
far (also, isn't 'everything a file' a motto of Unix, even if gnu is
strictly not?). But I've digressed; I think your straightforward
description above communicates many of the ideas better than the docs, but
I think this is a situation where we can have our cake and eat it too, so
to speak; usually, an appendage such as "file AND file-like objects" will
accomplish much of the work for us.

Catonano:
I think writing a home-service is much easier given that you don't need to
do produce an entire system generation before you find out what you did
wrong; it just depends on if you need your service initialized at startup
(system-services, globally defined and available prior to login) rather
than at login (home-services, per-user/locally defined).

I'm not on Mastodon but feel free to send your service my way for some
help, I'm still a beginner but a second pair of eyes is always nice to have.

ez,
b


---
Blake Shaw
Director, SWEATSHOPPE
sweatshoppe.org
---


On Wed, Jun 15, 2022 at 2:04 PM Ricardo Wurmus <rekado@elephly.net> wrote:

>
> catonano@gmail.com writes:
>
> > Il giorno mer, 15/06/2022 alle 01.52 +0700, Blake Shaw ha scritto:
> >>
> >> I found the documentation to be a bit confusing (understandably, as
> >> its new), but once the workflow snapped together its been amazing to
> >> see how easy it is to create new services.
> >
> > This is something I'm specifically interested in
> >
> > In fact, I wrote this toot that got several boosts and likes but NO
> > answer
> > https://floss.social/web/@abbienormal/108378060174601402
>
> I don’t know Odoo, but the general process is this:
>
> - look up the relevant documentation of your application to figure out
>   what commands must be executed.  Take note of any way to pass a
>   configuration file.
>
> - copy an existing shepherd service.  Maybe start with
>   gnu/services/audio.scm, because it’s pretty simple while not completely
>   trivial.
>
> - adjust the commands and names.
>
> In gnu/services/audio.scm you see the definition of mpd-service-type,
> which is a *system* service that 1) adds a user account, 2) does some
> one-shot preparation work, and 3) registers the mpd-shepherd-service.
>
> mpd-shepherd-service is a procedure returning a shepherd service.  The
> service has a start and stop command.  Adjust this for your service.
>
> mpd-shepherd-service refers to its argument “config”, which is supposed
> to be a Scheme configuration value.  It’s just a record defined higher
> up as <mpd-configuration>.  mpd-config->file turns that Scheme value
> into a string that can live in a file as the mpd configuration file.
>
> This is pretty much all there is to it.  Some services are simpler and
> don’t need any one-shot setup, nor do they need system user accounts, so
> they would just boil down to a shepherd service definition.
>
> --
> Ricardo
>

[-- Attachment #2: Type: text/html, Size: 5153 bytes --]

Re: how to write services (was: Re: Teams)

[Maxime Devos]

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

Blake Shaw schreef op wo 15-06-2022 om 17:01 [+0000]:
> Thats very good advice and will be a useful guide in refactoring the
> parts of the system services documentation. I think in general, we
> need to find a nice middle ground between the extremely general and
> the immediately sensible, as I remember when I first got into guix
> 1.5 years ago, arriving at services left me very confused. 

I don't doubt your confusal, though personally I'm confused on the
confusal and I think I would have been confused by ‘file AND file-like
object’.  Even more so since we both come from a mathematical
background, where AFAICT this kind of terminology and Guix'
interpretation is standard.

> mathematics I'm a fellow appreciator of the power of generality (the
> extreme genericity of scheme and guix is why I'm here!), I also think
> if it doesn't obey strict linguistic rules it can antithetical to its
> original purpose.

I don't see what linguistic rule the term ‘file-like object’ does not
follow.  

> For example, I remember being very confused about
> "file-like objects", for the simple reason that it wasn't "a file or
> file-like object". While this might come from a GNU terminological
> lineage i'm unaware of,

AFAIK no relation to GNU.

>  my immediate reaction to trying to understand
> file-likeness is the simple rule that a semblance is strictly not
> what it resembles, and likeness qualifies semblance. It would be
> improper to place phones in a category of "phone-like objects",
> because the likeness assumes a distinction from the thing itself.

An object being ‘X-like’ merely means that it is like an X.  This does
not imply it _isn't_ an X, only suggests that in some cases it might be
a non-X.

More concretely, to me phones resemble phones and are objects, so
phones are phone-like objects.

Summarised, to me semblance/similar/likeness is reflexive, I don't see
where the non-reflexivity would come from?

Something I dislike about the ‘file AND file-like objects’ construction
is that it suggests that files and file-like objects are separate and
are handled separately, whereas files (as in, 'local-file' or
'computed-file') are just another case of file-like objects to Guix
(next to 'file-append', 'package', 'git-checkout', ...).  Furthermore,
usually file-like objects aren't files but more often they are
packages.

For a comparison, suppose we have a hierarchy of concepts, e.g.

  {0}⊊ℕ⊊ℤ⊊ℚ⊊ℝ⊊ℂ

Whole numbers can (informally speaking) be considered to be natural-
like numbers. Yet, that doesn't make natural numbers non-whole. 
Compare:

File-like objects are objects that are like a file.  Yet, that doesn't
make files non-file-like.

Greetings,
Maxime.

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

Re: how to write services (was: Re: Teams)

[Maxime Devos]

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

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+0000]:
> > Something I dislike about the ‘file AND file-like objects’
> > construction
> > is that it suggests that files and file-like objects are separate
> > and
> > are handled separately, whereas files (as in, 'local-file' or
> > 'computed-file') are just another case of file-like objects to Guix
> > (next to 'file-append', 'package', 'git-checkout', ...). 
> > Furthermore,
> > usually file-like objects aren't files but more often they are
> > packages.
> 
> Going off the packages example, are they not often handled 
> differently? While I may want to (load "gnu/packages/base.scm"),
> a file,

Files can be loaded by Guile, yes.

>  a that I can work with <package coreutils>,

That's not a file, it's a package record.  You ca

>  as a record I 
> will get an error if I've included (gnu packages base) in my module
> and then try to invoke (load coreutils), although its defined.
> 
> But I think i'm missing your point here.


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

Re: how to write services (was: Re: Teams)

[Maxime Devos]

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

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+0000]:
> > AFAIK no relation to GNU.
> 
> I thought recalled hearing it used in relation to GNU/Linux. A quick
> search
> brings up this stackexchange discussion[1], which quotes the book
> "Linux
> Philosophy" with the following:
> 
> #+begin_example
> Whenever possible, Linux makes its components available via files or
> objects
> that look like files. Processes, devices, and network sockets are all
> represented 
> by file-like objects, and can often be worked with using the same
> utilities used
>  for regular files.
> #+end_example
> 
> So the contents of /proc are file-like objects, but AFAIK they
> strictly aren't files
> per-se, but representations of processes that take the shape of a
> file at a 
> particular instance in time.
> 
> [1]
> https://unix.stackexchange.com/questions/416778/what-is-file-like-objects-in-linux

From Guix and Guile's perspective, things in /proc are just (OS) files
that happen to be dynamically generated.  Devices are weird files that
need a special I/O API, but still files).  Some information on
processes is available in files, but the process itself isn't a file.

I would say that sockets (except for unix domain sockets) aren't files
and are rather unlike files (you cannot copy, hardlink, mv, symlink or
stat them, they don't have file names, they don't have an
owner/group/...) -- the only similarity seems to be the basis on file
descriptors and the possibility of read/write.

However, you cannot save sockets in the store, so from Guix perspective
even Unix domain sockets aren't file-like.

Though good point about the potential confusing with Linux' notion of
file-like objects!

Greetings
Maxime.

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

Re: how to write services (was: Re: Teams)

[Maxime Devos]

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

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+0000]:
> On the contrary, lets say I'm writing an intro book on CT. If I'm
> demonstrating something trivial, say the initial object, I'm not
> going to refer to it as "an initial-like object" for the sake of
> generality.

Neither does Guix?  If you're in a context where only the basic object
(in this case, your demonstration the initial object) is used, just
talk about the basic object.  But in a later section where you
generalize things to ‘initial-like objects’ (whatever that would be in
CT, I don't know any CT), you talk about ‘initial-like objects’, not
‘initial object and initial-like objects’.

For an example from another domain, consider groups in algebra.
In group theory, we have e.g. the fundamental theorem on homomorphisms.
Wikipedia formulates this as:

Given two groups G and H and a group homomorphism f : G → H, let K be a
normal subgroup in G and φ the natural surjective homomorphism G → G/K
(where G/K is the quotient group of G by K). If K is a subset of ker(f)
then there exists a unique homomorphism h: G/K → H such that f = h∘φ.

An equivalent statement could be made by replacing ‘given a group’ by
‘given an Abelian group or a group’:

Given two Abelian groups or groups G and H and a group homomorphism f :
G → H, let K be an Abelian normal subgroup or normal subgroup in G and
φ the natural surjective homomorphism G → G/K (where G/K is the
quotient group of G by K). If K is a subset of ker(f) then there exists
a unique homomorphism h: G/K → H such that f = h∘φ.’

But why do such a pointless thing, wouldn't just talking about groups
instead of ‘Abelian groups or groups’ be much simpler?

TBC: here ‘file-like object’ ≃ ‘group’ and ‘file’ = ‘Abelian group’.

Greetings,
Maxime.

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

Re: how to write services (was: Re: Teams)

[Blake Shaw]

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

Thanks for the feedback, abelian groups are a good example because so many
groups are abelian (fields etc).

But, perhaps it's just getting late and the matters are now & the details
are slipping my mind, but im starting to realize im unsure of many examples
of file-like objects that aren't a file? The email where you responded re:
packages was cut short, but it seemed to be that you were saying that
record-types *aren't* file-like, when I had thought they are; I thought
anything with simple means of serialization could be considered file-like,
and that pseudofiles (/devs, /procs, etc) were also in the file-like
category (which is apparently a misnomer on my part).

Would anyone care to share an explanation of what is/is not a file-like
object in Guix? Are fluids not considered file-like? I had thought that
would be a use case where this geneticity becomes important.

I remember when I first encountered gexps I thought, as FLOs didn't seem to
be files, they were either records or fluids. It took me a good while to
realize a file-like object is usually just a file, haha

On Thu, Jun 16, 2022, 05:28 Maxime Devos <maximedevos@telenet.be> wrote:

> Blake Shaw schreef op wo 15-06-2022 om 21:40 [+0000]:
> > On the contrary, lets say I'm writing an intro book on CT. If I'm
> > demonstrating something trivial, say the initial object, I'm not
> > going to refer to it as "an initial-like object" for the sake of
> > generality.
>
> Neither does Guix?  If you're in a context where only the basic object
> (in this case, your demonstration the initial object) is used, just
> talk about the basic object.  But in a later section where you
> generalize things to ‘initial-like objects’ (whatever that would be in
> CT, I don't know any CT), you talk about ‘initial-like objects’, not
> ‘initial object and initial-like objects’.
>
> For an example from another domain, consider groups in algebra.
> In group theory, we have e.g. the fundamental theorem on homomorphisms.
> Wikipedia formulates this as:
>
> Given two groups G and H and a group homomorphism f : G → H, let K be a
> normal subgroup in G and φ the natural surjective homomorphism G → G/K
> (where G/K is the quotient group of G by K). If K is a subset of ker(f)
> then there exists a unique homomorphism h: G/K → H such that f = h∘φ.
>
> An equivalent statement could be made by replacing ‘given a group’ by
> ‘given an Abelian group or a group’:
>
> Given two Abelian groups or groups G and H and a group homomorphism f :
> G → H, let K be an Abelian normal subgroup or normal subgroup in G and
> φ the natural surjective homomorphism G → G/K (where G/K is the
> quotient group of G by K). If K is a subset of ker(f) then there exists
> a unique homomorphism h: G/K → H such that f = h∘φ.’
>
> But why do such a pointless thing, wouldn't just talking about groups
> instead of ‘Abelian groups or groups’ be much simpler?
>
> TBC: here ‘file-like object’ ≃ ‘group’ and ‘file’ = ‘Abelian group’.
>
> Greetings,
> Maxime.
>

[-- Attachment #2: Type: text/html, Size: 3651 bytes --]

Re: how to write services (was: Re: Teams)

[catonano]

Il giorno mer, 15/06/2022 alle 17.01 +0000, Blake Shaw ha scritto:
> 
> Catonano:
> I think writing a home-service is much easier given that you don't
> need to do produce an entire system generation before you find out
> what you did wrong; 

I suspected something like this

This is why I hypotized that a gradual passage with a Home service
could be convenient

Ricardo, the general map of the concepts involved in conceiving a
service is useful

But in my toot I asked for something different

I asked for indications about the process (what magic to use in the
REPL)

if you prefer, I asked for something more menial

Which buttons do I have to push (metaforically) ?

As for the semantics involved in thinking a service, I feel I can work
them out myself (to some extent)

This should be covered in the cookbook

I see there's a package for Tryton (that's a relative of Odoo) and the
package definition for Tryton is quite sought after

In fact Tryton modules are not python modules and there's a patch
modifying how Tryton retrieves its modules in Guix

Yet there's no service for Tryton

I asked Hartmut (I remembered they were involved in this) and they
declared their surrender in writing services
(Here https://nerdculture.de/@kirschwipfel/108477739857485544 )

Maybe there's some cognitive friction about how to produce services ?

This reminds me of an argument about Haskell I read

Some "expert" haskellers are deeply involved in "plug ins" to the
compiler that actually change the language and many haskellers with a
lower level of proficiency are confused by this

And this hampers the Haskell field as a whole

Too bad I can't provide a pointer to this

My point being that I think this is a case of curse of knowledge
(mentioned here https://www.hillelwayne.com/post/learning-a-language/ )

I think the friction on how to write a service is not in the semantics
involved

It's more menial

As an blueprint for what I mean, you can think of Smalltalk, the
programming language

There a famous implementation of Smalltalk called Squeak

I played with Squeak myself, many years ago

That's how I learned object orientation ,really

The experience Squeak offers is NOT Posix based (thank God)

A GNU implementation of Smalltalk also exists and it's totally Posix
based (because of the unfortunate "GNU System" delusion)

Do you think the GNU Smalltalk would have been as effective in teaching
me object orientation ?

I honestly doubt it

yet the language is exactly the same

because the problem is not the language, that is something people CAN
work out themselves (roughly)

The problem is the experience

As I'm writing this, I noticed someone replied to my toot
(here
https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 )

as you can see, they also noticed a difference in the experience
between creating home services and system services

While you somewhat downplayed that

Now I want to be clear, here

In the past I have misunderstood some of your contributions about
macros in Guile (that I had asked about)

I came to terms with the fact that you're doing your best and in total
good faith, so I hope it's clear that's not what's happening today

But I also hope you can see why I could get a bit frustrated with your
reply

Guix is being successful, these days but that's an exception in the
free software world and more so in the GNU world

Guile is less exceptional in that it's suffering from its marginality
and it has been doing so for several years now

and I believe these cultural issues are part of why and they are
threatening the whole user freedom movement

Sorry if I went off on a tangent, I just feel a bit about this

> it just depends on if you need your service initialized at startup
> (system-services, globally defined and available prior to login)
> rather than at login (home-services, per-user/locally defined).
> 
> I'm not on Mastodon but feel free to send your service my way for
> some help, I'm still a beginner but a second pair of eyes is always
> nice to have.

That's very kind of you, thank you

I don't know if I'll ever attempt to write a service for Odoo

Or for Tryton

I have a job now (and it has to do with Odoo), I also train in a gym, I
like to spend the free time I have on the beach (as it's evident from
my presence on the fediverse)  so I don't know it's not like I have any
slots to assign to attempt this

It's just that if the _process_ to write a service (home or system) was
made explicit, I could have played with it in the few moments of grace

Re: how to write services (was: Re: Teams)

[Ricardo Wurmus]

catonano@gmail.com writes:

> Ricardo, the general map of the concepts involved in conceiving a
> service is useful
>
> But in my toot I asked for something different
>
> I asked for indications about the process (what magic to use in the
> REPL)

There is no REPL magic.  I write the service in chunks that I *could*
run separately (like the start command).  The rest I just write, and
then build a system with “guix system build” until it works.

Your assumption that there’s some guarded secret knowledge is wrong.

> as you can see, they also noticed a difference in the experience
> between creating home services and system services
>
> While you somewhat downplayed that
>
> Now I want to be clear, here
>
> In the past I have misunderstood some of your contributions about
> macros in Guile (that I had asked about)
>
> I came to terms with the fact that you're doing your best and in total
> good faith, so I hope it's clear that's not what's happening today
>
> But I also hope you can see why I could get a bit frustrated with your
> reply

No, I don’t.  I answered a vague question with what I hoped would be
helpful.  My bad.  I won’t do it again.

This is not the first time that my attempt to answer your question is
just met with a barrage of criticism, so I won’t expose myself to this
situation again.

-- 
Ricardo

Re: how to write services (was: Re: Teams)

[Maxime Devos]

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

Blake Shaw schreef op do 16-06-2022 om 06:20 [+0700]:
> But, perhaps it's just getting late and the matters are now & the
> details are slipping my mind, but im starting to realize im unsure of
> many examples of file-like objects that aren't a file? The email
> where you responded re: packages was cut short, but it seemed to be
> that you were saying that record-types *aren't* file-like,

I wrote that a package record #<package [the hello package]> is not a
file (as it lacks a lot of operations and properties that would be
expected of a package, such as 'stat', 'read', 'write', and a file
name’.

Likewise, the <package> record type (!= an instance of the record type
<package>) is not a file, but that's going rather meta.

However, packages (not the package _type_, but packages) are definitely
file-like, because when used in a G-exp with #$ or #+, Guix is able to
automatically ‘lower’ it in the store (resulting in a /gnu/store/.../
file name).

>  when I had thought they are; I thought anything with simple means of
> serialization could be considered file-like,
> [...]

It depends on the serialisation.  Not any serialisable object can do,
it must be an object that _Guix_ considers to be serialisable -- in
Guix terminology, this is called a ‘lowerable’ (low-level terminology)
or ‘file-like’ (high-level terminology, equivalent to ‘lowerable’
AFAICT) object.

> Would anyone care to share an explanation of what is/is not a
> file-like object in Guix? 
> Are fluids not considered file-like?

They aren't, as they do not implement lowering. (Technically: they
don't have a ‘define-gexp-ompiler’).

> I had thought that would be a use case where this geneticity becomes
> important.

Why would one put a fluid in a G-exp?  I suppose we could define what
lowering is for fluids (probably: get the value of what's inside and
lower that value), implement it in the Guix code and document it, and
hence consider fluids to be file-like.

I suppose that's all technically possible, though shouldn't it then be
extended to SRFI-111 boxes, parameter objects, variable objects,
promises and thunks as well?  Where would we stop?  And is this
behaviour actually useful?


> I remember when I first encountered gexps I thought, as FLOs didn't
> seem to be files, they were either records or fluids.

There is only a single mention of fluids in the manual (concerning
%guile-for-build).  The related concept of parameters is never used in
(guix)G-expressions, (except for 'with-parameters’).  So I fail to see
where this could have come from.

Greetings,
Maxime.

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

Re: how to write services (was: Re: Teams)

[Brian Cully via Development of GNU Guix and the GNU System distribution.]

catonano@gmail.com writes:

> I asked for indications about the process (what magic to use in 
> the
> REPL)

My experience with Guix, in general, is that the REPL isn't 
particularly useful for any task beyond very simple testing (eg, 
what are the contents of ‘%base-services’). It's a shame, but I 
suspect it's like this because it's hard to make it more 
functional, and there are more important problems to work on. Even 
though I would much prefer to do almost all work with a REPL, I 
have not invested the effort into figuring it out because I don't 
have the time or expertise, currently. I can't fault anyone else 
for making similar choices.

> This should be covered in the cookbook

I agree. The cookbook could use a lot of work. Guix's 
documentation suffers in the middle ranges. There's a lot of very 
high level overview, and all the low level bits are reasonably 
documented, but there's very little on how to integrate them.

If we were building a house, it'd be like having instructions that 
say: our house is made out of rooms. Then being given a bill of 
materials for all the different types of nails, boards, etc that 
can be used to build a house. There's no (or almost no) 
instructions for how to use those parts to build the shepherd 
service room, or how to connect the activation plumbing, 
etc. Unfortunately, those are the instructions that are most 
important, I think.

I have been keeping notes on my process of learning Guix in the 
hopes of starting something along these lines, but I'm not sure 
I'll ever have the time to get around to it; and I'm not much of a 
writer, besides.

> In fact Tryton modules are not python modules and there's a 
> patch
> modifying how Tryton retrieves its modules in Guix
>
> Yet there's no service for Tryton

This is the case for many packages. The good news(?) is that you 
can create your services your operating system config, and if you 
can get them working acceptably, send a patch.

> I think the friction on how to write a service is not in the 
> semantics
> involved
>
> It's more menial

See above: there's no documentation for assembly. Everything I've 
learned was from studying the source.

> As I'm writing this, I noticed someone replied to my toot
> (here
> https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 
> )
>
> as you can see, they also noticed a difference in the experience
> between creating home services and system services

I wasn't following this thread at the time, and didn't know 
whether you were talking about shepherd services or not. In terms 
of shepherd services, yes, there's quite a difference (maybe it 
would be a good idea to define a generic service type, akin to 
‘home-shepherd-service-type’ that only extends the 
‘shepherd-root-service-type’ with a shepherd service?). As I said 
there, if you have questions, feel free to ask! I may not be able 
to write the cookbook/how-to that I want to, but I can try to 
answer questions and share what little knowledge I do have with a 
fellow neophyte.

However, for the types of services you'd add to the ‘services’ 
slot of the home/operating-system config, I don't think there is 
much of a difference; or maybe none at all.

> Guix is being successful, these days but that's an exception in 
> the
> free software world and more so in the GNU world

I'm happy that Guix is growing, and more people are using it and 
adding to it (I'm a recent adopter, too!). But I think it's still 
a niche distribution, and it shows in things like the 
documentation, the builds breaking, old or broken packages, etc.

I want to be very clear on this point, though: I don't blame 
anyone for this, and I don't mean to downplay anyone's work 
because of these problems. Creating and maintaining a 
distribution, especially one as different as Guix, is a tremendous 
amount of work, and it's frankly incredible how well Guix does on 
such a small core crew. It's simply impossible to have the same 
level of polish as a bigger, more established distribution, with 
an order of magnitude (or more) contributors.

> I have a job now (and it has to do with Odoo), I also train in a 
> gym, I
> like to spend the free time I have on the beach (as it's evident 
> from
> my presence on the fediverse)  so I don't know it's not like I 
> have any
> slots to assign to attempt this

We're, all of us, in a similar situation, and we're few in number 
(relatively), with a lot of work to do. I think this explains the 
state of Guix more than anything else.

-bjc

Re: how to write services

[indieterminacy]

Hello Brian,

On 16-06-2022 15:09, Brian Cully via "Development of GNU Guix and the 
GNU System distribution." wrote:
> catonano@gmail.com writes:
> 
>> I asked for indications about the process (what magic to use in the
>> REPL)
> 
> My experience with Guix, in general, is that the REPL isn't
> particularly useful for any task beyond very simple testing (eg, what
> are the contents of ‘%base-services’). It's a shame, but I suspect
> it's like this because it's hard to make it more functional, and there
> are more important problems to work on. Even though I would much
> prefer to do almost all work with a REPL, I have not invested the
> effort into figuring it out because I don't have the time or
> expertise, currently. I can't fault anyone else for making similar
> choices.
> 
>> This should be covered in the cookbook
> 
> I agree. The cookbook could use a lot of work. Guix's documentation
> suffers in the middle ranges. There's a lot of very high level
> overview, and all the low level bits are reasonably documented, but
> there's very little on how to integrate them.
> 
Personally, Im somebody who requires examples to hack off.
As many as possible, to compare and contrast concepts and feed my 
imagination.

I wish I could reach for any API to explore and extrapolate with the 
same ease as I do with a dictionary.
Probably a cognitive failing from me getting into coding so late in 
life.

As with many things, I rely on conversational models to wash over me, so 
MLs have been useful as filling gaps - though I have to be patient 
waiting for solutions and ideals to reveal themselves over time.

The Guix mailing lists are hugely important to serve as the bridge 
between higher and lower level concepts.
This method may not be optimal to or known by some hoping to users 
hoping to utilise Guix further however.

Similarly, Im sure IRC/Matrix is useful, though I find the volume of the 
official (Matrix?) room to be like a firehose with its volume and too 
much to passively observe.

> If we were building a house, it'd be like having instructions that
> say: our house is made out of rooms. Then being given a bill of
> materials for all the different types of nails, boards, etc that can
> be used to build a house. There's no (or almost no) instructions for
> how to use those parts to build the shepherd service room, or how to
> connect the activation plumbing, etc. Unfortunately, those are the
> instructions that are most important, I think.
> 
I like the analogy.

I feel that there is an information-governance issue in terms of 
competencies, knowledge and requirements not fully intersecting.

Its not only because of the scale of the Guix community and as you 
mention the weaker middle layer but problems of time and perspective 
making it hard for specific solutions to find troubled users with 
minimal costs.

In many respects its not only a problem of documenting and publishing - 
there needs to be something in place to help orchestrate connections in 
a way akin to pollination.

Like the moribund efficacy of forums such as GitHub Issues, I do feel 
that the 'classic' model of SEO based search does not serve our 
individual or collective requirements.

I have been nudged into considering RDF more proactively, it would be 
super if Guix related knowledge could be represented in a semantic form, 
as it could be that triples can serve to provide 'knowledge-corridors', 
which connect up aspects of the ecosystem in ways unintended by 
contributors.

> I have been keeping notes on my process of learning Guix in the hopes
> of starting something along these lines, but I'm not sure I'll ever
> have the time to get around to it; and I'm not much of a writer,
> besides.
> 
You are a cogent and thoughtful writer so please write more and tell 
people when you make progress!

My own research project, Icebreaker, has focused on trying to utilise 
GemText and augment it with minimal syntaxes to support domains such as 
knowledge-management and kanban boards.

GemText's minimal syntax could allow you to write your thoughts down 
unimpeded and can be interpreted with ease.

See Genenetwork's own approach to such concepts to see how such habits 
can build out over time:
https://github.com/genenetwork/gn-gemtext-threads

Midway through my NLNet grant (once a move past a hospice related 
issue), Ill be integrating two interpreters covering formats (GemText 
and Koutliner) and my own annotation system (Qiuy).
https://git.sr.ht/~indieterminacy/1q20hqh_kq_parsing_gemtext
https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_glean

For me, this has put me in a situation whereby I can annotate anywhere 
and soon I shall have a graph of resources to inspect and extrapolate.

To aid others comprehension and interoperability I shall be trying to 
map my opaque seeming annotation syntax into RDF, hopefully something 
positive can come from that phase.

Additionally, based upon a decent demonstration on LMDB, I realised that 
my annotation system makes it more feasible to adapt documents into LDIF 
database-like-files (is that the correct terminology Maxime?) - 
potentially turning each document into an LDAP ready database.

Should both things turn out to be actionable then Guix 
knowledge-management could become a question of the governance of 
chaining concepts to fit usecases. Fingers crossed.

>> In fact Tryton modules are not python modules and there's a patch
>> modifying how Tryton retrieves its modules in Guix
>> 
>> Yet there's no service for Tryton
> 
> This is the case for many packages. The good news(?) is that you can
> create your services your operating system config, and if you can get
> them working acceptably, send a patch.
> 
>> I think the friction on how to write a service is not in the semantics
>> involved
>> 
>> It's more menial
> 
> See above: there's no documentation for assembly. Everything I've
> learned was from studying the source.
> 
>> As I'm writing this, I noticed someone replied to my toot
>> (here
>> https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 )
>> 
>> as you can see, they also noticed a difference in the experience
>> between creating home services and system services
> 
> I wasn't following this thread at the time, and didn't know whether
> you were talking about shepherd services or not. In terms of shepherd
> services, yes, there's quite a difference (maybe it would be a good
> idea to define a generic service type, akin to
> ‘home-shepherd-service-type’ that only extends the
> ‘shepherd-root-service-type’ with a shepherd service?). As I said
> there, if you have questions, feel free to ask! I may not be able to
> write the cookbook/how-to that I want to, but I can try to answer
> questions and share what little knowledge I do have with a fellow
> neophyte.
> 
> However, for the types of services you'd add to the ‘services’ slot of
> the home/operating-system config, I don't think there is much of a
> difference; or maybe none at all.
> 
>> Guix is being successful, these days but that's an exception in the
>> free software world and more so in the GNU world
> 
> I'm happy that Guix is growing, and more people are using it and
> adding to it (I'm a recent adopter, too!). But I think it's still a
> niche distribution, and it shows in things like the documentation, the
> builds breaking, old or broken packages, etc.
> 
> I want to be very clear on this point, though: I don't blame anyone
> for this, and I don't mean to downplay anyone's work because of these
> problems. Creating and maintaining a distribution, especially one as
> different as Guix, is a tremendous amount of work, and it's frankly
> incredible how well Guix does on such a small core crew. It's simply
> impossible to have the same level of polish as a bigger, more
> established distribution, with an order of magnitude (or more)
> contributors.
> 
>> I have a job now (and it has to do with Odoo), I also train in a gym, 
>> I
>> like to spend the free time I have on the beach (as it's evident from
>> my presence on the fediverse)  so I don't know it's not like I have 
>> any
>> slots to assign to attempt this
> 
> We're, all of us, in a similar situation, and we're few in number
> (relatively), with a lot of work to do. I think this explains the
> state of Guix more than anything else.
> 
> -bjc

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: how to write services

[Maxime Devos]

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

indieterminacy schreef op za 18-06-2022 om 13:53 [+0200]:
> Additionally, based upon a decent demonstration on LMDB, I realised that 
> my annotation system makes it more feasible to adapt documents into LDIF 
> database-like-files (is that the correct terminology Maxime?) - 
> potentially turning each document into an LDAP ready database.

If your asking me, I don't know.  What's LDAP doing here?  Isn't LDAP
about authenticating users, which doesn't seem relevant to the
documentation effort?  If this is about databases: is the exact
database format relevant, or would any do -- e.g., Guix uses SQLite in
some places, will SQLite do?

And the text above seems about databases and RDF, but there appear to
be missing some things:

  * what's the RDF and database for?  As I understand it, it's for
    something about documentation and terminology, but currently it's
    super vague.

  * what stuff goes in the RDF and database, and what documents are you
    speaking of?  The Guix manual?  All the package definitions, to use
    them as examples?  The mails in the ML?  Manually written things?
    Likewise, how is this database written or generated?

  * How will this RDF be used?  I mean, RDF can be flexible (see e.g.
    Wikidata), but someone has to actually write some applications that
    make use of the information, otherwise the fancy RDF is useless.

  * How is the RDF an improvement on the TeXinfo documentation?
    I guess I'm missing something important here, but I prefer reading
    TeXinfo documentation over RDF.

Greetings,
Maxime.

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

Re: how to write services

[indieterminacy]

Hi Maxime,

On 18-06-2022 14:23, Maxime Devos wrote:
> indieterminacy schreef op za 18-06-2022 om 13:53 [+0200]:
>> Additionally, based upon a decent demonstration on LMDB, I realised 
>> that
>> my annotation system makes it more feasible to adapt documents into 
>> LDIF
>> database-like-files (is that the correct terminology Maxime?) -
>> potentially turning each document into an LDAP ready database.
> 
> If your asking me, I don't know.  What's LDAP doing here?  Isn't LDAP
> about authenticating users, which doesn't seem relevant to the
> documentation effort?  If this is about databases: is the exact
> database format relevant, or would any do -- e.g., Guix uses SQLite in
> some places, will SQLite do?
> 

The prod was a little tongue in cheek, more of a nod to the thread 
discussing file-like aspects of computing.

I have no focus on LDAP nor authentification per se (though my own 
annotations would be able to map some of the parameters.

My understanding is that LDIF can hold keys and values and as such is 
capable of representing concepts (or at least pointing to them).
As such I fancy a good 'ol hack.

In any case I shall be experimenting and breaking things and I should be 
treated at this point as speculating.

I have no desire for substituting existing Guix databases - though I 
would contend that knowledge-management has different requirements and 
needs than system-maangement or coding. As such different toiling and 
tooling is advisable.

> And the text above seems about databases and RDF, but there appear to
> be missing some things:
> 
>   * what's the RDF and database for?  As I understand it, it's for
>     something about documentation and terminology, but currently it's
>     super vague.
> 
>   * what stuff goes in the RDF and database, and what documents are you
>     speaking of?  The Guix manual?  All the package definitions, to use
>     them as examples?  The mails in the ML?  Manually written things?
>     Likewise, how is this database written or generated?
> 
>   * How will this RDF be used?  I mean, RDF can be flexible (see e.g.
>     Wikidata), but someone has to actually write some applications that
>     make use of the information, otherwise the fancy RDF is useless.
> 
>   * How is the RDF an improvement on the TeXinfo documentation?
>     I guess I'm missing something important here, but I prefer reading
>     TeXinfo documentation over RDF.
> 
> Greetings,
> Maxime.

The RDF is something experimental based upon feedback from my own 
project.

Suppose we return to Brian's (apt) analogy concerning buildings and 
building materials:

I would hazard that there would exist chains across triples which would 
permeate from the concept stages of a building down to the point whereby 
nails are contextualised (including with regards to safety; purchasing; 
type; context; implementation).

Guix users should be able to build and resolve without the expertise of 
all layers and abstractions pertinent to Guile and our community.


At my end, Ive spent a considerable time creating loose annotations - 
which I inject everywhere.

Here is an example of task orientated annotations operating within my 
Emacs config:
https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/init.el#L138

and for policy positions:
https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/init.el#L155

These annotations recurse through my entire system, for instance 
operating as directory prefixes for specific concerns:
https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/rqr_organise
https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs/tree/master/item/iq_policy

My own bundle of knowledge repos can be found just from searching for 
'3q' references within my system.
Some can be found here (I will upload some Guix repos eventually)
https://git.sr.ht/~indieterminacy/?search=3q

Feel free to root around for approaches I have been taking to document 
and plan in modern ways.

Similarly, these annotations can operate literate-programming style 
within comments.

The fact that I can operate within Emacs-Hyperbole's Koutliner (block 
orientated) filetype to provide hierarchy and hyperlinking keeps me in a 
very terse and tactile state everywhere.

Currently I am able to grok my system with ease.
Ive been advised that outputting the interpretation of these files into 
RDF would be advantageous to make use of the graph orientated and 
folksonomic qualities of Icebreaker's approach.

FYI, I did a Fosdem talk. About 21 mins in some of the concepts coalesce 
into an area more pertinent with regards to RDF themes
https://fosdem.org/2022/schedule/event/minimalsyntaxes/

Im hoping that RDF can mitigate some of the chaos from users personal 
behaviours. My work operates more akin to body-language and philology as 
opposed to more classical approaches to computer-programming and 
computer-science.

I personally use my annotation system everywhere and adapt it for my own 
needs. I think of it like in terms of ants, whereby the colony 
increasingly grows smarter and more capable as the number of ants grows.

An ideal world would be one with which an RDF can provide a subset of a 
document AND that a user who prefers to use other formats would then use 
parameters to have this occur.

Emacs Hyperbole's use of contexts and Action-Buttons for PIM is a good 
example of encouraging reflexive behaviours which can be configured for 
individual usecases.


Sorry if this probably still comes across as vague (and certainly 
straying off the realms of Guix in our current respective states).
However, its a big topic which will still take a lot of time to unpack 
(expecially why I am still experimenting and testing the limitations of 
things).

Feel free to ask me more (though please can you switch the subject 
title) or even engage me privately (I have a matrix room, xq_icebreaker 
too).

Kind regards,


-- 
Jonathan McHugh
indieterminacy@libre.brussels

Teams: first draft list

[zimoun]

Hi,

On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus <rekado@elephly.net> wrote:

> As a first step I’d suggest collecting teams, setting up the email
> aliases, and updating the website to show the existing teams.  Here’s
> a draft of three teams:

Here below a collection of answers.  The teams are more or less.  Maybe,
we could join some for having another structure.  WDYT?


Cheers,
simon



* Python

 + Arun Isaac
 + Lars-Dominik Braun
 + Maxim Cournoyer
 + Ryan Prior

* Haskell

 + Lars-Dominik Braun
 + Simon Tournier

* R

 + Ricardo Wurmus
 + Simon Tournier

* Julia

 + Efraim Flashner
 + Simon Tournier

* OCaml / Dune

 + Julien Lepiller
 + Simon Tournier

* Java / Maven

 + Julien Lepiller

* Algebra / Maths

 + Andreas Enge
 + Eric Bavier

* Emacs

 + Arun Isaac
 + Maxim Cournoyer
 + Nicolas Goaziou

* Lisp

 + Arun Isaac
 + Guillaume Le Vaillant

* Ruby

+ Ryan Prior

* Go

+ Ryan Prior

* Embedded / Bootstrap

 + Ekaitz Zarraga
 + Ludovic Courtes
 + Thiago Jung Bauermann
 + Vagrant Cascadian

* Rust

 + Aleksandr Vityazev
 + Arun Isaac
 + Efraim Flashner
 + John Soo
 + Maxim Cournoyer
 + Maxime Devos
 + Nicolas Goaziou
 + Tobias Geerinckx-Rice

* Kernel

 + Tobias Geerinckx-Rice

* Core / Tools / Internals

 + Arun Isaac
 + Josselin Poiret
 + Ludovic Courtès
 + Ricardo Wurmus

* Games / Videos
 
 + Blake Shaw
 + Maxime Devos
 + raingloom

* Traductions

 + Florian Pelz
 + Julien Lepiller
 + Maxime Devos
 + Thiago Jung Bauermann
 + Tobias Geerinckx-Rice

* Installer

 + Josselin Poiret
 + Mathieu Othacehe

* Home

 + Andrew Tropin
 + Blake Shaw
 + Josselin Poiret
 + Ludovic Courtès
 

Re: Teams: first draft list

[bokr]

On +2022-06-21 17:21:11 +0200, zimoun wrote:
> 
> Here below a collection of answers.  The teams are more or less.  Maybe,
> we could join some for having another structure.  WDYT?

Where is the RISC/MES team? :)

Re: Teams: first draft list

[zimoun]

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

On Tuesday, 21 June 2022, <bokr@bokr.com> wrote:

> On +2022-06-21 17:21:11 +0200, zimoun wrote:
> >
> > Here below a collection of answers.  The teams are more or less.  Maybe,
> > we could join some for having another structure.  WDYT?
>
> Where is the RISC/MES team? :)
>

Embeded / Bootstrap ;-)

[-- Attachment #2: Type: text/html, Size: 536 bytes --]

Re: Teams: first draft list

[Efraim Flashner]

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

On Wed, Jun 22, 2022 at 12:21:15AM +0200, zimoun wrote:
> On Tuesday, 21 June 2022, <bokr@bokr.com> wrote:
> 
> > On +2022-06-21 17:21:11 +0200, zimoun wrote:
> > >
> > > Here below a collection of answers.  The teams are more or less.  Maybe,
> > > we could join some for having another structure.  WDYT?
> >
> > Where is the RISC/MES team? :)
> >
> 
> Embeded / Bootstrap ;-)

I would suggest adding "Ports" to that list, or "Odd Architectures". We
just had a discussion on IRC about changing some mesa flags and it's
definitely a case where pinging someone who has had to deal with
underused architectures would help since 'auto' doesn't work for all the
architectures. Plus in my mind there often seems to be a bunch of
overlap between bootstrap level things and odd architectures, in terms
of getting into the weeds of common tools.

Seeing I managed to not get myself added to all the teams I can join the
embedded/bootstrap team, with or without the 'odd architectures' bit.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: Teams: first draft list

[Ricardo Wurmus]

Hi simon,

> Here below a collection of answers.  The teams are more or less.  Maybe,
> we could join some for having another structure.  WDYT?

Thank you for the initiative!  I had been meaning to go through the
whole thread and collect and organize all submissions, but you’ve done
all the work already.  Thanks!

Now the question is merely how to represent and present this.  It’s not
a bad idea to have the team associations in the repository so that we
can present the data on the website and also use it with our tools to
notify the right people.  It wouldn’t help with keeping mailing aliases
on fencepost up to date, though.

I also wonder about how / if we should notify teams about relevant
patches.  Will contributors Cc the relevant teams or will we have team
predicates, e.g. a procedure that spits out the appropriate teams when
given a patch?

-- 
Ricardo

Re: Teams: first draft list

[zimoun]

Hi Ricardo,

On Wed, 22 Jun 2022 at 09:59, Ricardo Wurmus <rekado@elephly.net> wrote:

> I also wonder about how / if we should notify teams about relevant
> patches.  Will contributors Cc the relevant teams or will we have team
> predicates, e.g. a procedure that spits out the appropriate teams when
> given a patch?

We discussed about tools to achieve that.  IMHO, the first step is to
expose such list; on the website? in the repo?  and update the node
«Submitting Patches» to point on the website or repo or else.

Then maybe, we could hook Mumi and add regexps based on commit messages
for notifying a specific team.  Well, it is a rough approximation with
many false-positive but hey the aim is to deal with patches so these
false-positive do not matter, IMHO.

We have not discussed how we maintain the list of team; we can discuss
later.

Cheers,
simon

Re: Teams: first draft list

[Josselin Poiret]

Hello,

zimoun <zimon.toutoune@gmail.com> writes:
> Then maybe, we could hook Mumi and add regexps based on commit messages
> for notifying a specific team.  Well, it is a rough approximation with
> many false-positive but hey the aim is to deal with patches so these
> false-positive do not matter, IMHO.

Maybe we could attribute files to teams?  It seems like the simplest and
more robust way, since it easily grants 99% coverage (excluding new
files, that is), and the structure of the Guix files seem well-amenable
to such classification.

WDYT?

-- 
Josselin Poiret

Re: Teams: first draft list

[Maxime Devos]

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

Josselin Poiret schreef op wo 22-06-2022 om 14:30 [+0200]:
> Hello,
> 
> zimoun <zimon.toutoune@gmail.com> writes:
> > Then maybe, we could hook Mumi and add regexps based on commit messages
> > for notifying a specific team.  Well, it is a rough approximation with
> > many false-positive but hey the aim is to deal with patches so these
> > false-positive do not matter, IMHO.
> 
> Maybe we could attribute files to teams?  It seems like the simplest and
> more robust way, since it easily grants 99% coverage (excluding new
> files, that is), and the structure of the Guix files seem well-amenable
> to such classification.

FWIW, I'm in the Rust team for the build system, not the individual
rust packages.

Greetings,
Maxime.

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

Re: Teams: first draft list

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Now the question is merely how to represent and present this.  It’s not
> a bad idea to have the team associations in the repository so that we
> can present the data on the website and also use it with our tools to
> notify the right people.

Mathieu suggested that we have a team file in guix.git, which would
allow us to eventually write tools like ‘get-tutors.scm’ as Mathieu
calls it.

The web site could fetch that file and present one tile per team on a
page.

> It wouldn’t help with keeping mailing aliases on fencepost up to date,
> though.

Argh, yes.  Maybe this can be addressed later?  Having a list of teams a
name would already help, even if there are no email aliases.

Then perhaps we could automate alias creation with @guix.gnu.org
addresses?  Not sure what it would take…

> I also wonder about how / if we should notify teams about relevant
> patches.  Will contributors Cc the relevant teams or will we have team
> predicates, e.g. a procedure that spits out the appropriate teams when
> given a patch?

I think we can start small and build up automation incrementally.

Thanks,
Ludo’.

Re: Teams: first draft list

[Blake Shaw]

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

Hi y'all,

This looks great, thanks for putting in the work!

Im getting back into the Guile + Guix documentation, and realize its a
subject the @whereiseveryone and others are also working on, and thus it
could probably use a concentrated team of its own. What do others think?


Best,
Blake

On Wed, Jun 22, 2022, 20:51 Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
> > Now the question is merely how to represent and present this.  It’s not
> > a bad idea to have the team associations in the repository so that we
> > can present the data on the website and also use it with our tools to
> > notify the right people.
>
> Mathieu suggested that we have a team file in guix.git, which would
> allow us to eventually write tools like ‘get-tutors.scm’ as Mathieu
> calls it.
>
> The web site could fetch that file and present one tile per team on a
> page.
>
> > It wouldn’t help with keeping mailing aliases on fencepost up to date,
> > though.
>
> Argh, yes.  Maybe this can be addressed later?  Having a list of teams a
> name would already help, even if there are no email aliases.
>
> Then perhaps we could automate alias creation with @guix.gnu.org
> addresses?  Not sure what it would take…
>
> > I also wonder about how / if we should notify teams about relevant
> > patches.  Will contributors Cc the relevant teams or will we have team
> > predicates, e.g. a procedure that spits out the appropriate teams when
> > given a patch?
>
> I think we can start small and build up automation incrementally.
>
> Thanks,
> Ludo’.
>
>

[-- Attachment #2: Type: text/html, Size: 2346 bytes --]

Re: Teams: first draft list

[bokr]

On +2022-06-22 09:56:14 +0300, Efraim Flashner wrote:
> On Wed, Jun 22, 2022 at 12:21:15AM +0200, zimoun wrote:
> > On Tuesday, 21 June 2022, <bokr@bokr.com> wrote:
> > 
> > > On +2022-06-21 17:21:11 +0200, zimoun wrote:
> > > >
> > > > Here below a collection of answers.  The teams are more or less.  Maybe,
> > > > we could join some for having another structure.  WDYT?
> > >
> > > Where is the RISC/MES team? :)
> > >
> > 
> > Embeded / Bootstrap ;-)
> 
> I would suggest adding "Ports" to that list, or "Odd Architectures". We
> just had a discussion on IRC about changing some mesa flags and it's
> definitely a case where pinging someone who has had to deal with
> underused architectures would help since 'auto' doesn't work for all the
> architectures. Plus in my mind there often seems to be a bunch of
> overlap between bootstrap level things and odd architectures, in terms
> of getting into the weeds of common tools.
> 
> Seeing I managed to not get myself added to all the teams I can join the
> embedded/bootstrap team, with or without the 'odd architectures' bit.
>

IMHO "RISC" should be somewhere in the team title,
so that a flag/clue/cue for those interested in RISC
will be advertised in any quoted reference to the team
that may be archived in mailing lists or blogs or news etc.

This would tell the RISC-interested that
they might find friends by checking further :)

> -- 
> Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
--
Regards,
Bengt Richter

Re: Teams: first draft list

[Ricardo Wurmus]

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


Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Now the question is merely how to represent and present this.  It’s not
>> a bad idea to have the team associations in the repository so that we
>> can present the data on the website and also use it with our tools to
>> notify the right people.
>
> Mathieu suggested that we have a team file in guix.git, which would
> allow us to eventually write tools like ‘get-tutors.scm’ as Mathieu
> calls it.

Attached is a draft etc/teams.scm, which defines teams, their members,
and procedures to fetch a relevant subset of the information.

An example:

   ./pre-inst-env guile --no-auto-compile -l etc/teams.scm -c '(cc r core)'

This prints “git send-email” arguments to Cc members of the R and Core
teams when a patch is received by Debbugs.

Another example:

   ./pre-inst-env guile --no-auto-compile \
     -l etc/teams.scm -c '(list-teams)' | recsel -p name,members

I haven’t defined any other members yet, because I think it’s better for
people to do this by themselves to avoid adding people who don’t
actually want to be a member of any team.

-- 
Ricardo


[-- Attachment #2: teams.scm --]
[-- Type: application/octet-stream, Size: 5795 bytes --]

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2022 Ricardo Wurmus <rekado@elephly.net>
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; This code defines development teams and team members.

;;; Code:

(use-modules (srfi srfi-1)
             (srfi srfi-9)
             (ice-9 format)
             (guix ui))

(define-record-type <team>
  (make-team id name description members)
  team?
  (id          team-id)
  (name        team-name)
  (description team-description)
  (members     team-members set-team-members!))

(define-record-type <person>
  (make-person name email)
  person?
  (name    person-name)
  (email   person-email))

(define* (person name #:optional email)
  (make-person name email))

(define* (team id #:key name description (members '()))
  (make-team id
             (or name (symbol->string id))
             description
             members))

(define %teams
  (make-hash-table))

(define-syntax define-team
  (lambda (x)
    (syntax-case x ()
      ((_ id value)
       #`(begin
           (define-public id value)
           (hash-set! %teams 'id id))))))

(define-syntax-rule (define-member person teams ...)
  (let ((p person))
    (for-each (lambda (team-id)
                (let ((team
                       (hash-ref %teams team-id
                                 (lambda ()
                                   (error (format #false
                                                  "Unknown team ~a for ~a~%"
                                                  team-id p))))))
                  (set-team-members!
                   team (cons p (team-members team)))))
              (quote (teams ...)))))

(define (cc . teams)
  "Return arguments for `git send-email' to notify the members of the given
TEAMS when a patch is received by Debbugs."
  (format #true
          "~{--add-header=\"X-Debbugs-Cc: ~a\"~^ ~}"
          (map person-email
               (delete-duplicates (append-map team-members teams) equal?))))

(define (list-teams)
  "Print all teams and their members."
  (define port* (current-output-port))
  (define width* (%text-width))
  (hash-for-each
   (lambda (key team)
     (format port*
             "\
id: ~a
name: ~a
description: ~a
members:
"
             (team-id team)
             (team-name team)
             (or (and=> (team-description team)
                        (lambda (text)
                          (string->recutils
                           (fill-paragraph text width*
                                           (string-length "description: ")))))
                 "<none>"))
     (for-each
      (lambda (member)
        (format port*
                "+ ~a <~a>~%"
                (person-name member)
                (person-email member)))
      (team-members team))
     (newline))
   %teams))

\f
(define-team python
  (team 'python
        #:name "Python team"
        #:description
        "Python, Python packages, the \"pypi\" importer, and the python-build-system."))

(define-team haskell
  (team 'haskell
        #:name "Haskell team"
        #:description
        "GHC, Hugs, Haskell packages, the \"hackage\" and \"stackage\" importers, and
the haskell-build-system."))

(define-team r
  (team 'r
        #:name "R team"
        #:description
        "The R language, CRAN and Bioconductor repositories, the \"cran\" importer,
and the r-build-system."))

(define-team julia
  (team 'julia
        #:name "Julia team"
        #:description
        "The Julia language, Julia packages, and the julia-build-system."))

(define-team ocaml
  (team 'ocaml
        #:name "OCaml and Dune team"
        #:description
        "The OCaml language, the Dune build system, OCaml packages, the \"opam\"
importer, and the ocaml-build-system."))

(define-team java
  (team 'java
        #:name "Java and Maven team"
        #:description
        "The JDK and JRE, the Maven build system, Java packages, the ant-build-system,
and the maven-build-system."))

(define-team maths
  (team 'maths
        #:name "Algebra and Maths team"))

(define-team emacs
  (team 'emacs
        #:name "Emacs team"))

(define-team lisp
  (team 'lisp
        #:name "Lisp team"))

(define-team ruby
  (team 'ruby
        #:name "Ruby team"))

(define-team go
  (team 'go
        #:name "Go team"))

(define-team embedded-bootstrap
  (team 'embedded-bootstrap
        #:name "Embedded / Bootstrap"))

(define-team rust
  (team 'rust
        #:name "Rust"))

(define-team kernel
  (team 'kernel
        #:name "Linux-libre kernel team"))

(define-team core
  (team 'core
        #:name "Core / Tools / Internals"))

(define-team games
  (team 'games
        #:name "Games and Videos"))

(define-team translations
  (team 'translations
        #:name "Translations"))

(define-team installer
  (team 'installer
        #:name "Installer script and system installer"))

(define-team home
  (team 'home
        #:name "Team for \"guix home\""))

\f
(define-member (person "Ricardo Wurmus"
                       "rekado@elephly.net")
  r core)

(define-member (person "Ludovic Courtès"
                       "ludo@gnu.org")
  core home embedded-bootstrap)

Re: Teams: first draft list

[Liliana Marie Prikler]

Am Freitag, dem 01.07.2022 um 12:28 +0200 schrieb Ricardo Wurmus:
> [...]
> An example:
> 
>    ./pre-inst-env guile --no-auto-compile -l etc/teams.scm -c '(cc r
> core)'
> 
> This prints “git send-email” arguments to Cc members of the R and
> Core
> teams when a patch is received by Debbugs.
> 
> Another example:
> 
>    ./pre-inst-env guile --no-auto-compile \
>      -l etc/teams.scm -c '(list-teams)' | recsel -p name,members

Could we perhaps make that script itself executable, so that we can
write 
$ ./etc/teams.scm list-teams | recsel -p name,members
$ ./etc/teams.scm cc r core

After some pondering, I think I might want to join the emacs and games
teams, especially the former given that I'm often explaining to people
on IRC that they can load subdirs.el :)

Re: Teams: first draft list

[Ricardo Wurmus]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Freitag, dem 01.07.2022 um 12:28 +0200 schrieb Ricardo Wurmus:
>> [...]
>> An example:
>> 
>>    ./pre-inst-env guile --no-auto-compile -l etc/teams.scm -c '(cc r
>> core)'
>> 
>> This prints “git send-email” arguments to Cc members of the R and
>> Core
>> teams when a patch is received by Debbugs.
>> 
>> Another example:
>> 
>>    ./pre-inst-env guile --no-auto-compile \
>>      -l etc/teams.scm -c '(list-teams)' | recsel -p name,members
>
> Could we perhaps make that script itself executable, so that we can
> write 
> $ ./etc/teams.scm list-teams | recsel -p name,members
> $ ./etc/teams.scm cc r core

Yes, we can.  Just like etc/committer.scm it would need to have a .in
template to let us plug in the right guile shebang.

> After some pondering, I think I might want to join the emacs and games
> teams, especially the former given that I'm often explaining to people
> on IRC that they can load subdirs.el :)

Good good.  Feel free to add yourself to etc/teams.scm.in once it hits
the repo.

-- 
Ricardo

Re: Teams: first draft list

[Leo Famulari]

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

On Tue, Jun 21, 2022 at 05:21:11PM +0200, zimoun wrote:
> * Kernel
> 
>  + Tobias Geerinckx-Rice

Feel free to add my name to the kernel team.

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

Teams: please add yourself to etc/teams.scm.in

[Ricardo Wurmus]

Ricardo Wurmus <rekado@elephly.net> writes:

> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
>> Am Freitag, dem 01.07.2022 um 12:28 +0200 schrieb Ricardo Wurmus:
>>> [...]
>>> An example:
>>> 
>>>    ./pre-inst-env guile --no-auto-compile -l etc/teams.scm -c '(cc r
>>> core)'
>>> 
>>> This prints “git send-email” arguments to Cc members of the R and
>>> Core
>>> teams when a patch is received by Debbugs.
>>> 
>>> Another example:
>>> 
>>>    ./pre-inst-env guile --no-auto-compile \
>>>      -l etc/teams.scm -c '(list-teams)' | recsel -p name,members
>>
>> Could we perhaps make that script itself executable, so that we can
>> write 
>> $ ./etc/teams.scm list-teams | recsel -p name,members
>> $ ./etc/teams.scm cc r core
>
> Yes, we can.  Just like etc/committer.scm it would need to have a .in
> template to let us plug in the right guile shebang.

etc/teams.scm.in is now part of the repository.  The configure script
generates the executable etc/teams.scm.

Please feel free to add yourself to teams in that file by adding a
definition like this:

  (define-member (person "Ricardo Wurmus"
                         "rekado@elephly.net")
    r core mentors)

Thanks!

-- 
Ricardo

Re: Teams: please add yourself to etc/teams.scm.in

[Andreas Enge]

Hello,

Am Sun, Jul 03, 2022 at 03:04:36PM +0200 schrieb Ricardo Wurmus:
> etc/teams.scm.in is now part of the repository.  The configure script
> generates the executable etc/teams.scm.
> Please feel free to add yourself to teams in that file by adding a
> definition like this:

thanks for pushing the teams idea forward!

I took the liberty to rename "maths and algebra" to "science", which is a
bit less narrow. Then it probably contains all of R and bio*, so maybe
this is too large? I am more thinking of "classical" science packages
written in C... So please feel free to rename back or to something else
if you think I have broadened the scope too much.

Andreas