Replacing Mumi+Debbugs?

Maxim Cournoyer writes: >> I’ll say that many of my gripes with (the GNU instance of) Debbugs are >> due to the fact that we can’t customize it to better suit our needs — it >> is a shared resource with a complicated maintenance story. So all >> changes went into Mumi as crude workarounds. I

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

Maxim Cournoyer writes: > Hi, > > Ricardo Wurmus writes: > >> "Danny Milosavljevic" writes: >> >>> I agree that automating the technical steps of contributing to Guix >>> would be nice. >> >> We could provide a VM. Guix can create systems well enough to make this >> feasible, I think. > > I'

Re: CI job for lisp-team branch

Maxim Cournoyer skribis: > Hi Guillaume, > > I've also created a TLS client certificate and emailed it to you > (encrypted) so that you can manage your branch yourself via the Cuirass > web interface, restart failing builds (which are sometimes spurious > failures due to not yet resolved CI/infra

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

Andreas Enge writes: > Am Mon, Sep 04, 2023 at 08:44:18AM -0400 schrieb brian via Development of GNU > Guix and the GNU System distribution.: >> Regarding the GNU changelog commits, I really dislike them. They're >> redundant busy-work as far as I'm concerned. And while I'd like to say >> they'

Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)

Hi all Arun Isaac writes: [...] > I have been following the conversation with much interest. There seems > to be a developing consensus that we should switch to sourcehut. I fear that the switch would _not_ solve many of the problems tagged as "cognitive overhead"; the problem is "the workflow

Re: Replacing Mumi+Debbugs?

FSF IT seems to have an instance of sourcehut running sourcehut.gnu.org or they are working on it. Maxim Cournoyer writes: > I'd be sad to loose at least two good things from Debbugs: > > 1. It's hosted by the GNU/FSF for us. It always work, and the rare > times it doesn't, the folks in #savan

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

Maxim Cournoyer writes: > Hi Ricardo, > > Ricardo Wurmus writes: > >> Vagrant Cascadian writes: >> >>> The only thing clunky about this particular aspect of the workflow >>> described is the fact that the guix community (maintainers?) have >>> decided on a one patch per mail policy with a cov

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

Andreas Enge writes: > Am Mon, Sep 04, 2023 at 08:44:18AM -0400 schrieb brian via Development of GNU > Guix and the GNU System distribution.: >> > - strict adherence to changelog style commit messages without a >> >clearly worded and documented argument about why it's worth the >> >ef

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

Hi Ricardo, all, On Sun, 03 Sep 2023 at 12:31, Ricardo Wurmus wrote: > As the original author of Mumi I want it to become obsolete as it > clearly has outlived its usefulness and better alternatives exist. The > way to get there is to add the replacement to Guix so we can host it. I am seeing

Debbugs CLI client (was Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)))

Hi, On Mon, 04 Sep 2023 at 23:06, Arun Isaac wrote: > But, meanwhile, I wish to remind everyone that we already have a mumi > CLI client that takes away some of the pain of dealing with Debbugs. It > operates fully on the command-line and does not require Emacs at > all. This CLI client has so f

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

Hi, On Tue, 29 Aug 2023 at 12:53, MSavoritias wrote: > Do you know if there are any plans to write a scheme bug/patching > system? Because looking a bit into it, it doesn't seem like its that > actively developed so maybe we would be better served by one in scheme. > Or Sourcehut of course as so

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

Hi Katherine, Thank you for your extensive analysis. I concur. On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday wrote: > 3. We should reify a way for Guix, the project, to measure, and track > progress, >    against long-term goals. Particularly when they're social and not > strictly >  

Re: Building from git

> guix shell -D guix --pure > > [...] > > Then if I run make authenticate as stated in the documentation it > fails with the error: guix: command not found. It appears you were still within the guix shell spawned with the first command when you tried to run `make authenticate`. Guix was not avai

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

pinoaffe writes: > Andreas Enge writes: >> So as far as I am concerned, they are tremendously useful. Well, that may >> be due to a lack of git knowledge, of course! But while in other projects >> I often find I need to look at the content of commits, in Guix it is often >> enough to just look a

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

Hi, brian via "Development of GNU Guix and the GNU System distribution." writes: > pinoaffe writes: > >> Andreas Enge writes: >>> So as far as I am concerned, they are tremendously useful. Well, that may >>> be due to a lack of git knowledge, of course! But while in other projects >>> I often

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

Hi, Csepp writes: [...] >>> Regarding the GNU changelog commits, I really dislike them. They're >>> redundant busy-work as far as I'm concerned. And while I'd like to say >>> they're no longer necessary, because we have better tooling >> >> As said before, I use them all the time through >>

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

Hi, On Tue, 29 Aug 2023 at 13:05, Giovanni Biscuolo wrote: > In other words: you can contribute to a SourceHut hosted project with > patches (or just with comments to patches) because everyone can send an > email to an email address provided by the project maintainer(s). Just to point that what

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

Hi, On Mon, 28 Aug 2023 at 23:00, Maxim Cournoyer wrote: >> If someone has use cases for the ChangeLog commits, I'd like to hear >> them. Maybe there is something that can't be achieved with git history >> without ChangeLogs, but I can't think of anything. Someone mentioned >> grepping the git l

Re: questionable advice about Geiser load path setting

On 2023-09-04 21:41:44 -0400, Maxim Cournoyer wrote: > Hello, > > wolf writes: > > [...] > > > Geiser seems to add the project root (I assume based on the git) into the > > load > > path automatically. geiser-repl-current-project-function seems to be set by > > default, and rest is described

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

On 9/5/23 10:01 AM, Simon Tournier wrote: Well, somehow, I consider the commit message format similarly as coding style. We can discuss which one is better than the other when at the end it only reflects some artificial preferences and for the sake of any project one needs to be arbitrarily pic

Re: Pinned/fixed versions should be a requirement.

On 2023-09-04 21:59:47 -0500, Distopico wrote: > > In my experience using Guix and attempting to make contributions, I've > noticed that the vast majority of times when a library breaks, it's > because one of its dependencies changed version. For instance, > referencing something like `rust-my-lib

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

On 9/4/23 7:32 PM, Maxim Cournoyer wrote:   13. Run `guix style` (this is still in the manual although I have since   learned this is not actually advisable). The intent is for it to be advisable -- when it's not, a bug should be/have been reported against it to track its resolution. T

Guix related things in Germany at the end of October/start of November

Hey, PackagingCon [1] is happening in Berlin on the 26th to the 28th of October, and the Reproducible Builds summit is happening in Hamburg on the 31st of October to the 2nd of November. 1: https://packaging-con.org/ 2: https://reproducible-builds.org/events/hamburg2023/ I've had a talk proposal

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

On 9/5/23 8:01 AM, Simon Tournier wrote: Hi Katherine, Thank you for your extensive analysis. I concur. On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday wrote: 3. We should reify a way for Guix, the project, to measure, and track progress,    against long-term goals. Particularly when t

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

On 9/3/23 1:36 AM, Ricardo Wurmus wrote: Why are we trying to compete with Sourcehut? What's the end goal? I can’t make myself even clearer about this, but I’ll repeat myself again: we are not. “Competition” is a foreign concept to me. Mumi exists only because I found the Debbugs web interf

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

Am Dienstag, dem 05.09.2023 um 11:01 -0600 schrieb Katherine Cox-Buday: > On 9/5/23 10:01 AM, Simon Tournier wrote: > > > Well, somehow, I consider the commit message format similarly as > > coding > > style.  We can discuss which one is better than the other when at > > the > > end it only reflec

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

Liliana Marie Prikler writes: > Uhm, we have snippets? Well, those are exclusive to Emacs :) And without regard to /that/ issue, I do think that there's a problem if the commit format is so complex that it's not trivial for anyone new to the project to write them out manually. -- (

Re: Guix pull speed

Hi Josselin, On Tue, 29 Aug 2023 at 13:58, Josselin Poiret wrote: > After looking a bit more into guix pull speed, or to be more precise the > "Computing Guix derivation..." step, which is not substitutable. I've > come to the conclusion that the thing that takes the majority of the > time is l

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

Maxim Cournoyer writes: > Hi, > > Csepp writes: > > [...] > Regarding the GNU changelog commits, I really dislike them. They're redundant busy-work as far as I'm concerned. And while I'd like to say they're no longer necessary, because we have better tooling >>> >>> As said befo

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

Thank you for your thoughtful comments, Giovanni! On 9/2/23 5:16 AM, Giovanni Biscuolo wrote: 1. We should use sourcehut or continue to improve mumi Please forgive me if I insist, but the one and _only_ benefit of using SourceHut is the web-UI /helper/ to prepare an email message to send, it'

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

Simon Tournier writes: > Hi, > > On Tue, 29 Aug 2023 at 13:05, Giovanni Biscuolo wrote: > >> In other words: you can contribute to a SourceHut hosted project with >> patches (or just with comments to patches) because everyone can send an >> email to an email address provided by the project mai

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

Csepp writes: > > Doesn't Magit have a generic forge integration? > There's forge.el[1] which is part of the magit project. It's not too generic though, as it only supports Gitlab (which applies to self-hosted instances/hosted instances such as e.g. salsa.debian.org) and Github[2]. Magit itself

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

Hi, Thanks for these pointers. Therefore I am asking more naive questions. :-) On Tue, 5 Sept 2023 at 21:19, Csepp wrote: > There are mbox downloads on lists.sr.ht. > Random example from my browser history: > https://lists.sr.ht/~lioploum/forevercomputer If I understand correctly, this

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

Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (: > Liliana Marie Prikler writes: > > Uhm, we have snippets? > > Well, those are exclusive to Emacs :)  And without regard to /that/ > issue, I do think that there's a problem if the commit format is so > complex that it's not trivial for anyone

Guix User Survey?

Hi Guix, Katherine Cox-Buday writes: > > I think the easiest way to start, and something that's actually pretty > effective, is to start doing annual surveys, e.g.: > > - https://discourse.nixos.org/t/2022-nix-survey-results/18983 > - https://survey.stackoverflow.co/2023/ > - https://tip.golang

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

On 2023-09-05 22:43:04 +0200, Liliana Marie Prikler wrote: > Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (: > > Liliana Marie Prikler writes: > > > Uhm, we have snippets? > > > > Well, those are exclusive to Emacs :)  And without regard to /that/ > > issue, I do think that there's a proble

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

On 2023-09-05 16:01:17 +0200, Simon Tournier wrote: > Hi Katherine, > > Thank you for your extensive analysis. I concur. > > On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday > wrote: > > > 3. We should reify a way for Guix, the project, to measure, and track > > progress, > >    against lo

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

Hi, On Tue, 05 Sep 2023 at 11:01, Katherine Cox-Buday wrote: >> Well, somehow, I consider the commit message format similarly as coding >> style. We can discuss which one is better than the other when at the >> end it only reflects some artificial preferences and for the sake of any >> project

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

"(" writes: > Liliana Marie Prikler writes: >> Uhm, we have snippets? > > Well, those are exclusive to Emacs :) And without regard to /that/ > issue, I do think that there's a problem if the commit format is so > complex that it's not trivial for anyone new to the project to write > them out ma

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

Hi, On Wed, 06 Sep 2023 at 00:11, wolf wrote: > But I guess this was supposed to be taken as "run make check' and make sure > nothing new is broken". Is there a command for that? Yes taken like that. :-) And nothing I am aware. I agree that the situation with “make check” is imperfect. Chee

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

Hi Katherine, I am fully aligned with the Survey proposal; at some past Guix Days I remember discussing a kind of survey á la Haskell or Emacs surveys. Well, such appears to me very informative to better know how to improve, from user to contributor. On Tue, 05 Sep 2023 at 12:00, Katherine Cox-Bu

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

On 9/5/23 4:57 PM, Simon Tournier wrote: Hi, On Tue, 05 Sep 2023 at 11:01, Katherine Cox-Buday wrote: Well, somehow, I consider the commit message format similarly as coding style. We can discuss which one is better than the other when at the end it only reflects some artificial preferences

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

Hi Katherine, Katherine Cox-Buday writes: > On 9/5/23 10:01 AM, Simon Tournier wrote: > >> Well, somehow, I consider the commit message format similarly as coding >> style. We can discuss which one is better than the other when at the >> end it only reflects some artificial preferences and for

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

On 9/5/23 5:55 PM, Simon Tournier wrote: Hi Katherine, I am fully aligned with the Survey proposal; at some past Guix Days I remember discussing a kind of survey á la Haskell or Emacs surveys. Well, such appears to me very informative to better know how to improve, from user to contributor. OK