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

[Giovanni Biscuolo <g@xelera.eu>]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

Hi all

Arun Isaac <arunisaac@systemreboot.net> 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", not the tool.

«All forges suck, _no one_ sucks less» :-D (it's a joke!)

Please forgive me if I insist and/or repeat myself (and others) but:

1. sourcehut is a suite of (alpha) applications: what set of
applications we should switch to?

2. given that all *.sr.ht applications are alpha [1], would the Guix
packages for applications listed in 1. be maintainable in the _near_
future?  Also we need to package them as Guix _services_ to be useful.

3. given current resources, where do we plan to host the new services?
Are current Guix sysadmins human resources enough to give _support_ to
the new services?  Please consider that «Currently, the only officially
supported method for installing sr.ht software is through packages on
Alpine Linux hosts. [...] the installation and deployment process can
become a bit more involving. In particular, many sr.ht services have
their own, unique requirements that necessitate extra installation
steps», unless we package them for Guix (point 2.)

4. git.sr.ht (the "forge"?) implements an email based patch workflow
management and _not_ a web based pull-request workflow, it's documented
here: https://man.sr.ht/git.sr.ht/#sending-patches-upstream; so
git.sr.ht will _not_ help Guix adding a web based PR workflow, for that
we need _other_ forges, for example GitLab, Gitea/Forgejo (other?)

5. what about "git request-pull" [2] to enable a PR workflow for Guix?
It seems completely ignored by all the "forges" or am I wrong?
Unfortunately AFAIU it runs only as CLI, there is no web or GUI
interface for that

6. in what aspect todo.sr.ht (the issue tracker) is better than Debbugs
(via multiple interfaces)?  AFAIU nothing in that application is so much
better than what Guix actually use; actually Debbugs or Mumi web
interfaces are read-only: you cannot open a bug report or comment it,
you have to send an email; this is a _feature_, not a bug since we don't
need a _complex_ web based authentication+authorization system for bug
reporters/commenters.  Please also consider that the emacs Debbugs
interface is very useful, I'd miss a similar interface for todo.sr.ht
(but there is a CLI for sourcehut web services)

7. last, but not least: a public-inbox instance (https://yhetil.org/)
helps a lot people who is not subscribed to a mailing list with email
replies (e.g https://yhetil.org/guix-bugs/87il8qrm53.fsf@gmail.com/#R)
**and** patch downloading; IMHO it should be officially provided by Guix

> I am all in favour of any decision the community comes to on this.

I just hope the decision comes after an analysis of each single problem,
otherwise there is a chance that different tools will not solve the
problems

[...]

> So, I thought it helpful to document it and put it into the manual. I
> have sent a patch to https://issues.guix.gnu.org/65746

Very good work, thanks Arun!

Happy hacking, Gio'


[1] https://man.sr.ht/packages.md

[2] https://www.git-scm.com/docs/git-request-pull

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]