Re: Teams: please add yourself to etc/teams.scm.in
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
Re: Teams: first draft list
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. signature.asc Description: PGP signature
Re: Teams: first draft list
Liliana Marie Prikler 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
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
Ludovic Courtès writes: > Ricardo Wurmus 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 teams.scm Description: Binary data
Re: Teams: first draft list
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, 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 אפרים פלשנר > 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
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 wrote: > Hi, > > Ricardo Wurmus 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
Hi, Ricardo Wurmus 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
Josselin Poiret schreef op wo 22-06-2022 om 14:30 [+0200]: > Hello, > > zimoun 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. signature.asc Description: This is a digitally signed message part
Re: Teams: first draft list
Hello, zimoun 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
Hi Ricardo, On Wed, 22 Jun 2022 at 09:59, Ricardo Wurmus 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
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
On Wed, Jun 22, 2022 at 12:21:15AM +0200, zimoun wrote: > On Tuesday, 21 June 2022, 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 אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Teams: first draft list
On Tuesday, 21 June 2022, 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 ;-)
Re: Teams: first draft list
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: how to write services (was: Re: Teams)
caton...@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 (was: Re: Teams)
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 # 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 record type (!= an instance of the record type ) 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. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
caton...@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)
Il giorno mer, 15/06/2022 alle 17.01 +, 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)
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 wrote: > Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > 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. >
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > 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. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > 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. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > 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 , 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. signature.asc Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
Blake Shaw schreef op wo 15-06-2022 om 17:01 [+]:
> 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.
signature.asc
Description: This is a digitally signed message part
Re: how to write services (was: Re: Teams)
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 wrote: > > caton...@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-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)
caton...@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-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
how to write services (was: Re: Teams)
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)
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: Teams
On Tue, 14 Jun 2022 08:47:37 -0400 guix-devel-requ...@gnu.org wrote: Hi Guixers, Count me in for any packaging on teams. I'd like to help out with python and/or rust. all best, jgart
Re: Teams
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 wrote: > On 2022-06-05 10:19, Josselin Poiret wrote: > > > Hello everyone, > > > > Ricardo Wurmus 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 >
Re: Teams
On 2022-06-05 10:19, Josselin Poiret wrote: > Hello everyone, > > Ricardo Wurmus 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 signature.asc Description: PGP signature
Re: Teams
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 + Blake Shaw 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 > 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
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 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
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
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 signature.asc Description: This is a digitally signed message part
Re: Teams
Hello, Ludovic Courtès writes: > Vagrant Cascadian 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
Vagrant Cascadian 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
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 signature.asc Description: PGP signature
Re: Teams
On Sun, Jun 05, 2022 at 11:51:20AM +0200, zimoun wrote: > Hi Ricardo, > > > > * R team > > Simon Tournier > > Ricardo Wurmus > > In addition, add me to: > > * Julia team I can do the Julia team too. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Teams
"pelzflorian (Florian Pelz)" writes: > On Sat, Jun 04, 2022 at 02:50:49PM +, 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
On Saturday, June 4th, 2022 at 12:07 PM, Ricardo Wurmus 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
Hi, Mathieu Othacehe 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
Hi! Josselin Poiret 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
Hi Ricardo, Ricardo Wurmus 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
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-patc...@gnu.org --cc guix-r-patc...@gnu.org --cc rek...@elephly.net --cc zimoun.touto...@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 tutors.scm Description: Binary data
Re: Teams
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-tea...@gnu.org”. People with questions about R in Guix could write an email to that alias. Mumi could also send email to guix-tea...@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
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 wrote: >Hi Ricardo, > >On Sat, 04 Jun 2022 at 14:07, 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: > >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
Hi Ricardo, On Sat, 04 Jun 2022 at 14:07, 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: 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
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
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
On Sat, Jun 04, 2022 at 02:50:49PM +, 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
Hello everyone, Ricardo Wurmus 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
On 4 June 2022 12:07:15 UTC, Ricardo Wurmus 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
Tobias Geerinckx-Rice schreef op za 04-06-2022 om 14:50 [+]: > 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. signature.asc Description: This is a digitally signed message part
Re: Teams
On 4 June 2022 12:07:15 UTC, Ricardo Wurmus 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
> 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-tea...@gnu.org”. People with questions about R in Guix could > write an email to that alias. > > Mumi could also send email to guix-tea...@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
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. signature.asc Description: This is a digitally signed message part
