Hi!
Is there still interest in moving over to Sourcehut for emacs
development? If so, what blockers are left for emacs development? I
just had a small chat on irc with Drew DeVault, the developer of
Sourcehut, and got some directions for at least one important issue:
sending patches as attachments for them to be rendered in the web view.
Should we assemble a general list of what is missing in etc/TODO?
For the attachment issue, the one implementing this needs to build
'lists' and 'meta' subsystems of sourcehut. To build sourcehut, there
are directions on some blogs: [1] and [2].
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.
Theo
[1]: https://emersion.fr/blog/2021/setting-up-sr.ht-for-local-development/
[2]: https://man.sr.ht/installation.md
Theodor Thornhill <theo@thornhill.no> writes:
> 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.
> 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.
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.
In all steps of the way, I would try to involve emacs-devel for further
input and feedback.
>> 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
Hello Theodor,
On Tue 21 Dec 2021 at 07:30PM +01, Theodor Thornhill wrote:
> 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.
How about just setting up meta, lists and builds, leaving debbugs and
savannah doing bug tracking and git hosting, and then add 'todo' and
'git' later? Might make the migration easier.
--
Sean Whitton
Hi, Sean!
>> 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.>> How about just setting up meta, lists and builds, leaving debbugs and> savannah doing bug tracking and git hosting, and then add 'todo' and> 'git' later? Might make the migration easier.>
I think an even easier way to start using srht would be to make an
official mirror on sr.ht.
Theo
>> I think an even easier way to start using srht would be to make an> official mirror on sr.ht.>> Theo
As a followup to this I actually 'own' the user 'emacs' on sr.ht, and
would gladly donate it to Lars, Eli or some other interested person. If
so, the address would be https://git.sr.ht/~emacs/emacs
Theo
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.
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