Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Theodor Thornhill <theo@thornhill.no> writes:

> Actually, I think that running Sourcehut as a local instance wouldn't
> really be necessary for the evaluation, because it is the same code that
> is running on sr.ht.  Apart from the fiddly bits with self hosting, the
> workflow should be the same.
[snip]
> Of course.  However, I think that getting some sense of what _needs_ to
> be supported before even considering sourcehut would be smart.  The self
> hosting can come later, IMO.

I might be wrong, but I suspect that we are much closer than we think.

Mainly, it needs someone to drive the work; whatever that might mean.
I gave the suggestion for where I would start, but any work in this
direction is of course very welcome.

My thinking is that it would be good to provide something that people
can easily look at and experiment with to convince themselves that this
is a good move.  Self-hosting makes it easier for people to just jump
right into it, and makes it more likely to happen.  But if someone could
set up an Emacs mirror on sr.ht and allow people to easily experiment
there, then I guess that works too.

The important thing here is to pick up one of the loose threads and
start making concrete progress.

> For example, its author suggests that emacs-devel adopts the `git
> send-email` workflow rather than using attachments anyway, but I believe
> that was a hard no.

On August 28, Lars wrote:

> Well, we really don't care as long as the patches reach us unscathed.
>
> In my experience, it's more likely that a patch won't be mangled if it's
> in an attachment (which is why CONTRIBUTE says that), but if you have a
> setup that allows you to send patches safely otherwise (i.e., you're not
> using Gmail :-)), then we don't care.

https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg01436.html

I don't see this as a "hard no"; it is just something we need to
properly look into and understand the implications of.

To add to what Lars said, if you support a web based workflow the people
using a bad MUA that would mangle your patches could just use the web
based workflow instead.  Or at least that's my understanding.

Personally, I tend to much agree with Lars that we don't (or shouldn't)
care too much if we are dealing with attached patches or "git
send-email" or whatever.  The end result will be mostly the same with
perhaps some small or trivial differences details such as which exact
command to run.