Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

Stefan Kangas <stefankangas@gmail.com> writes:

> 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.
>

I don't think you are wrong at all.

> 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.
>

Your suggestions are welcome, and were in line with what I was thinking
as well :)

> 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.
>
IMO this will be the easiest option, at least until some of the more
senior emacs contributors/maintainers wants to take over the reigns.

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

I can at least donate the ~emacs user, but not sure if I have time to
maintain a mirror with no delay.  

>> 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.

What I meant was a hard no was to enforce the send-email workflow.  It
seems emacs wants to be a little more forgiving, which I agree with.

Theo