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