guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: MSavoritias
Subject: Re: How can we decrease the cognitive overhead for contributors?
Date: Mon, 18 Sep 2023 19:40:59 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0


On 9/14/23 11:24, Ricardo Wurmus wrote:
Fannys <email@fannys.me> writes:

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

It's not accessible and imposes a barrier in some people.
Yeah agreed. And we should be consious of that.
Ironically by mandating Emacs and Email we force people to use specific
tools while at the same time even though the same people will complain(!) 
against vendor lock-in
like github.
We don’t *mandate* the use of Emacs.  It’s just a common recommendation
because it works so well with text and is trivially extensible, so it’s
a common target for helper tools.  Surely we also wouldn’t call a
recommendation to use a shell script “vendor lock-in” just because it
needs Bash.

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

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

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

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

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


MSavoritias




reply via email to

[Prev in Thread] Current Thread [Next in Thread]