[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How can we decrease the cognitive overhead for contributors?
From: |
Andreas Enge |
Subject: |
Re: How can we decrease the cognitive overhead for contributors? |
Date: |
Fri, 25 Aug 2023 11:16:57 +0200 |
Hello,
just a quick reply with what I do personally as one irrelevant data point :)
Am Fri, Aug 25, 2023 at 08:07:53AM +0000 schrieb Attila Lendvai:
> i couldn't even find out which tools are used by those who are comfortable
> with the email based workflow. i looked around once, even in the manual, but
> maybe i should look again.
No tools at all, I would say, which indeed may be a bit inefficient...
Or: terminal, mutt, vim, git
A bit of web for browsing the manuals (of Guix and Guile)
and issues.guix.gnu.org
But then I type much faster than I click.
> i'm pretty sure most maintainers have a setup where the emailed patches can
> be applied to a new branch with a single press of a button, otherwise it'd be
> hell of a time-waster.
mutt
save message to /tmp/x
git am /tmp/x
or something like this
or:
git clone https://git.guix-patches.cbaines.net/guix-patches/
git checkout issue-xxxxx
git format-patch ...
then in the development checkout of Guix:
git am ...; make; ./pre-inst-env guix build
> one fundamental issue with the email based workflow is that its underlying
> data model simply does not formally encode enough information to be able to
> implement a slick workflow and frontend. e.g. with a PR based model the
> obsolete versions of a PR is hidden until needed (rarely). the email based
> model is just a flat list of messages that includes all the past mistakes,
> and the by now irrelevant versions.
For this, I either go to issues.guix.gnu.org to download the newest patches,
in case the message is not in my inbox.
Otherwise I do not get your point: I keep untreated messages with the latest
patch version in my Guix inbox, and file away the others in a separate mbox.
So things are not flat, but have two levels: "to be treated" or "done".
Nothing to be documented, really, and I do not know whether these are just
personal habits or whether others work similarly. These might be the ways
of an aging non-emacs hacker...
> https://sourcehut.org/
This comes up a lot in the discussion and looks like an interesting
solution. It would be nice to be able to accomodate diverse styles
of working on Guix beyond (but including) emacs and vim.
Andreas
- How can we decrease the cognitive overhead for contributors?, Katherine Cox-Buday, 2023/08/23
- Re: How can we decrease the cognitive overhead for contributors?, Felix Lechner, 2023/08/23
- Re: How can we decrease the cognitive overhead for contributors?, Wilko Meyer, 2023/08/25
- Re: How can we decrease the cognitive overhead for contributors?, Liliana Marie Prikler, 2023/08/26
- Re: How can we decrease the cognitive overhead for contributors?, Attila Lendvai, 2023/08/27
- Re: How can we decrease the cognitive overhead for contributors?, Saku Laesvuori, 2023/08/27
- Re: How can we decrease the cognitive overhead for contributors?, Liliana Marie Prikler, 2023/08/27
- Re: How can we decrease the cognitive overhead for contributors?, MSavoritias, 2023/08/29
- Re: How can we decrease the cognitive overhead for contributors?, Giovanni Biscuolo, 2023/08/29
- Re: How can we decrease the cognitive overhead for contributors?, Maxim Cournoyer, 2023/08/28