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

Hi, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Hi all, > > On Sun, Sep 3, 2023 at 3:35 AM Ricardo Wurmus wrote: >> >> I won’t contribute to Mumi any more. Giving it up doesn’t hurt my >> feelings. I’d be glad to see it gone. > > For what it's

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

Attila Lendvai writes: > here's an approximate list of what's consuming/training my > frustration-tolerance with Guix: > > - debbugs and related tooling. i could live with an email based >workflow, but whatever is documented, or at least whatever i have >put together locally, is very

Re: CI job for lisp-team branch

Hi Guillaume, Guillaume Le Vaillant writes: > Hi. > I created a lisp-team branch to work one some updates for clisp and > sbcl. Could someone with admin access to the CI things add a job for it? > Thanks. I've also created a TLS client certificate and emailed it to you (encrypted) so that you

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

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 cover letter, rather than >> submitting

Re: native-search-path and guix profile

Hi Hartmut, Hartmut Goebel writes: > Good afternoon. > > I'm curious about how exactly native-search-path work. > > I packaged vagrant, which needs to find plugins, therefore I defined a > native-search-path, see > . > > This works fine when using

Pinned/fixed versions should be a requirement.

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-1`, where "1" refers to the semver "1.x" of the

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

Hi, Katherine Cox-Buday writes: [...] > Here's my understanding of the process to contribute a patch: > >   1. Check out main, and run `./bootstrap`, then `./configure > --localstatedir=/var --sysconfdir=/etc` >   2. Run `make` >   3. You need to determine whether the change can be targeted

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

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'm not convinced. I typically uses VM for

Re: questionable advice about Geiser load path setting

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 in the docs: (geiser)Customization and tips, > Init > files and load

Python Team: Keeping Branch Up To Date Question

Hi Lars, What is the git approach for keeping the Python branch up to date? 閭 Should I be rebasing off of master or something else? I'm trying to review this patch: https://issues.guix.gnu.org/64973 Any advice much appreciated. all best, jgart

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

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 cover letter, rather than > submitting the patches as attachments in the initial

CI job for lisp-team branch

Hi. I created a lisp-team branch to work one some updates for clisp and sbcl. Could someone with admin access to the CI things add a job for it? Thanks. signature.asc Description: PGP signature

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

> To second this, I'd like to note for the record that on fedi at least > 1-2 people told me that they chose Nix over Guix because they don't want > to deal with the email based workflow. At least one of these people is > a highly skilled programmer with decades of experience. FWIW, i'm 46,

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

"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. > This definitely should be automated. Why not generate a UUID locally and send > a

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

Hello jgart, Am Mon, Sep 04, 2023 at 05:48:05PM + schrieb jgart: > Old tickets are not kept around. > For example, A branch for ticket 51810* does not exist anymore. this is probably due to the fact that the git repo did not yet exist at the time. The oldest issue I see is 60286 from

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

>> Old tickets are not kept around. Hi, Oh ok, old tickets were never included instead of old tickets being deleted. I'm not familiar with this code yet. Thanks for the clarification.

Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

Hi Guixers, Andreas' detailed a nice workflow for reviewing patches in a previous thread*: ``` git clone https://git.guix-patches.cbaines.net/guix-patches/ git checkout issue-x git format-patch ... then in the development checkout of Guix: git am ...; make; ./pre-inst-env guix build ``` I

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

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 > >effort in 2023. whenever 'C'

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

Am Mon, Sep 04, 2023 at 10:23:45AM + schrieb Attila Lendvai: > - large backlog. contributions somtimes even fall through the cracks. My impression/hope is that the recent introduction of teams leads to improvements on this front. I am on the science and texlive teams and have been getting

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

"jgart" writes: > Hi Guixers, > > Andreas' detailed a nice workflow for reviewing patches in a previous thread*: > > ``` > git clone https://git.guix-patches.cbaines.net/guix-patches/ > git checkout issue-x > git format-patch ... > then in the development checkout of Guix: > git am ...;

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

>I really like Guix, I like what it promises, I love the community around it, and that's what keeps me here. But it's a >deeply frustrating experience to try to contribute to. I've been a contributor in various forms to a great many free >and open source software projects over the years, and Guix

Re: CI job for lisp-team branch

Guillaume Le Vaillant writes: > Hi. > I created a lisp-team branch to work one some updates for clisp and > sbcl. Could someone with admin access to the CI things add a job for it? > Thanks. Hello, Curiass CI job created. Thanks.

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

> I've got something like 6 patches waiting, all have been sitting around > for many months. They'll get some committer attention and then it drops > off and nothing happens. To me, that sounds like people lose track of > it, because debbugs doesn't allow people to stay easily on top of > patches

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

On Mon, Sep 04, 2023 at 10:56:39AM +0200, Ricardo Wurmus wrote: > > 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 cover

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

Hi all, I'm glad we're having this difficult but necessary conversation. I have been following the conversation with much interest. There seems to be a developing consensus that we should switch to sourcehut. I am all in favour of any decision the community comes to on this. But, meanwhile, I

Re: Current Issues with Patch Review Workflow Using git.guix-patches.cbaines.net

> I don't think automatically closing older issues is helpful, they still > need looking at. Or instead of closing them, put the patch into a state that is not open. Like an archived state or some other state that does not require action until someone takes ownership of the issue and resolves