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

[Giovanni Biscuolo]

[I sent this message incomplete by mistake, sorry!]

Ciao Giacomo,

I never used nor installed/administered SourceHut services, I've some
comments from what I learned reading documentation and articles.

Executive summary: it's "just" and **interface** problem; contributors
who like the SourceHut web UI to format and send patchsets via email are
very wellcome to subscribe and use the SourceHut services to send
patches (also) to Guix [1].  There is no reason for Guix to be
(self)hosted on SourceHut.

Also, like there are manu TUI for Git, there are also many Git GUIs
around https://git-scm.com/downloads/guis, maybe some of them also have
a "patch preparation UI" like the Git SourceHut web service.

paul <goodoldpaul@autistici.org> writes:

> From reading this discussion it appears sourcehut supporting both the
> web and email workflow and being free software is really the best
> solution.

SourceHut is a suite including this tools providing different services
(some of them already covered by specialized tools in Guix, e.g. CI):

- builds.sr.ht
- git.sr.ht
- hg.sr.ht
- hub.sr.ht
- lists.sr.ht
- man.sr.ht
- meta.sr.ht
- pages.sr.ht
- paste.sr.ht
- todo.sr.ht

git.sr.ht have a tool for "web-based patch preparation UI", it's
documented [1]: that tool is "just" a web interface to prepare a
patchset to be sent upstream via email; please read all the section and
you'll see that it describes an email based patch management workflow.

Also, in the "Tutorials" page I find the section "Contributing to
projects on SourceHut" [1] and the "Read more" link point to
https://git-send-email.io/

Finally, yesterday I sent a message (id:87il8z9yw8.fsf@xelera.eu) with
some pointers to related articles, two were from Drew DeVault, SourceHut
founder

Given what I found above, I'd say that the workflow model used by
SourceHut hosted projects is email based, not web based, and that the
service "git.sr.ht" provides SourceHut users "just" a web UI helping
them to format and send a patchset via email in the same way "git
format-patch" and "git send-email" do.

...it's "just" an _interface_ question, not an email vs web patch
management question :-)

That said, I understand that some (many?) users are not comfortable with
CLI interfaces and prefers a GUI interface (web UI is the same), but
there is no reason to increase the reviewers cognitive overhead by
introducing an inefficient web based patch management workflow just to
address a "simple" and unrelated interface problem.

> It appears to have no downsides (besides for the work required for
> packaging and provisioning the service)

First, let's start with packaging each SourceHut service in Guix: AFAIU
packaging in other distros is not in good shape, i.e.

- Debian
  
https://packages.debian.org/search?keywords=sourcehut&searchon=names&suite=all&section=all
  https://wiki.debian.org/Teams/pkg-sourcehut

- Arch Linux
  https://archlinux.org/packages/?sort=&q=sourcehut&maintainer=&flagged=

- Fedora
  https://packages.fedoraproject.org/search?query=sourcehut

Sure, they have https://man.sr.ht/packages.md for Alpine Linux, Arch
Linux and Debian, but:

--8<---------------cut here---------------start------------->8---

Warning: SourceHut is still in alpha, and has no stable releases. As such, we 
do not recommend packaging SourceHut for your upstream distribution 
repositories until we have shipped stable versions of our software.

--8<---------------cut here---------------end--------------->8---
(from https://man.sr.ht/packages.md)

So we have to wait for SourceHut to exit its alpha status to start
packaging it, no?

> and everything else either does not support email workflow or does not
> support web workflow.

I insist: SourceHut does _not_ support a "web workflow" (fork, PR and
merge all done via a web UI)

> What are the blockers in Guix's policies for moving in this direction?

Guix is a GNU project, GNU have an infrastructure, a set of services and
a policy for their projects.  Maybe one day GNU will provide a self
hosted SourceHut service, now GNU have https://savannah.gnu.org/ and
https://debbugs.gnu.org/

...and please remember: "all forges and all issue trackers suck, some
just sucks less" (stolen from mutt motto)

> Should a team with a defined roadmap be created to address Katherine's 
> and all other people's point, either way the consensus will fall?

First it would be useful to separate each /different/ question raised in
dedicated threads that are actionable, possibly leading to a patch or at
least to a consensus... or to some sort of clarification at least.

I hope I helped to clarify the "email vs web patch management" question
with this message.

Ciao! Gio'


[1] https://man.sr.ht/git.sr.ht/#sending-patches-upstream

[2] https://man.sr.ht/tutorials/#contributing-to-srht-projects

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

signature.asc
Description: PGP signature