Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

>> Is there still interest in moving over to Sourcehut for emacs
>> development?
>
> My understanding is that the answer is yes.  AFAIK, no final decision
> has yet been taken, but it seems like the consensus is more or less that
> sourcehut is the most likely candidate to have what we need within some
> reasonable time-frame.
>

Good to hear.  I think it would be stupid to decide this without trying
it properly first anyway.

>> I'm planning to look into this myself a little during the holidays, but
>> not sure how much time I realistically can spend on this, so therefore
>> this mail.  Possibly it may be useful if someone other than me wishes to
>> tackle this over the holidays?  In general they are pretty responsive
>> over at #sr.ht, so they might be willing to help out a little.
>
> I would personally start with setting up a sourcehut instance with a
> mirror of the Emacs source code.  This would allow you to start
> experimenting with it to see how it works and what is missing.  In this
> work, I would specifically compare the sourcehot workflow to what we
> have now.  If you could make the instance publicly accessible, other
> interested parties could help with this work more easily.
>

Workflow-wise I believe it already is established that sourcehut
supports most if not all aspects of the emacs development workflow,
modulo the patch-rendering issue when patches are sent as attachments.
One of the biggest improvements would be to set up builds on patch
submission, running tests etc.  All of this works properly in Sourcehut.

> Preferably any gotchas when installing should be noted down somewhere
> (e.g. sent to emacs-devel).
>
> Next, I would start looking into those things that are still missing.
> For starters, they would need to be listed and it should be ensured that
> there are good feature requests on the sourcehut issue tracker.  If the
> sourcehut developers are willing to implement those things then great,
> otherwise it would be obviously be very useful if someone would
> volunteer to start working on those things.
>

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.  I'd encourage people on this list getting
their own user there and trying it out, as I think many already have.
Specifically, emacs-devel would want to use the `meta`, `lists`, `git`,
`todo` and `builds` subprojects, that is all apart from the `hg` one.

> In all steps of the way, I would try to involve emacs-devel for further
> input and feedback.

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.

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.

I'll start the list of hard requirements:

- [ ] patches as attachments


Theo