~emacs/emacs#1: 
Migration to sourcehut

What is missing for us to migrate to this forge?

Status
RESOLVED FIXED
Submitter
~emacs
Assigned to
No-one
Submitted
3 years ago
Updated
3 years ago
Labels
srht migration

~johnmuhl 3 years ago

i guess it depends on what you mean by migrate. sourcehut is a set of services so there is no need for an all-at-once migration of everything. we could start with the simpler services. maybe just git and builds (and maybe lists) at first. then we can work on the others longer term.

i've been searching around unsuccessfully for a way to get a dump of emacs debbugs to play around with converting to todos. do you know where i could get that or should i ask on emacs-devel?

~skangas 3 years ago

Regarding downloading debbugs data, you could try https://lars.ingebrigtsen.no/2016/05/03/emacs-bug-trends/ or see what the debbugs package (on GNU ELPA) is doing.

~johnmuhl 3 years ago

On Wed, 2021-12-22 at 05:42 +0000, ~skangas wrote:

Regarding downloading debbugs data, you could try https://lars.ingebrigtsen.no/2016/05/03/emacs-bug-trends/ or see what the debbugs package (on GNU ELPA) is doing.

thanks for the pointer. that looks promising.

~emacs 3 years ago

I've added you both as users with all controls on the services, should you be interested. I don't have much time on my hands the next days, but feel free to hack on it if you'd like!

~larsi (edited) 3 years ago*

I'm just testing; never mind me...

EDIT (skangas): Just testing what it looks like if I edit someone else's message.

~larsi 3 years ago

Hey, seems to work!

~larsi 3 years ago

Another test, just to see what this looks like via email.

diff --git a/INSTALL b/INSTALL index 21298422af..307599cda0 100644 --- a/INSTALL +++ b/INSTALL @@ -1,4 +1,4 @@ -GNU Emacs Installation Guide +GNU Emacs Installation Guide, yes Copyright (C) 1992, 1994, 1996-1997, 2000-2021 Free Software Foundation, Inc. See the end of the file for license conditions.

~larsi 3 years ago

Well, that's not... pretty...

How about an attachment?

~larsi 3 years ago

And the attachment totally went missing. (As well as the text after the attachment.)

~skangas 3 years ago

Regarding attachments, see https://todo.sr.ht/~sircmpwn/lists.sr.ht/156

It is marked as "beta" but maybe we could ask Drew DeVault to bump the priority.

~skangas 3 years ago

~larsi outgoing@sr.ht writes:

Another test, just to see what this looks like via email.

diff --git a/INSTALL b/INSTALL index 21298422af..307599cda0 100644 --- a/INSTALL

+++ b/INSTALL @@ -1,4 +1,4 @@ -GNU Emacs Installation Guide +GNU Emacs Installation Guide, yes Copyright (C) 1992, 1994, 1996-1997, 2000-2021 Free Software Foundation, Inc. See the end of the file for license conditions.

I'm testing replying to this here. However this is rendered on the web, the good news is that the formatting survived over email, so us old-school, email regulars will not be impacted by this.

I'd personally mark this down as a "minor" bug rather than a blocker for that reason.

~iyefrat 3 years ago

I propose having problems/desired features in individual issues, it would probably be an easier way to keep track of the things that emacs needs/wants for sourcehut migration. It could also be used to jot down observations from the mailing list as well, so they don't get lost.

~emacs 3 years ago*

diff --git a/slime.el b/slime.el
index 8436b332..216b6ad0 100644
--- a/slime.el
+++ b/slime.el
@@ -60,7 +60,6 @@
 ;;;; Dependencies and setup
 (eval-and-compile
   (require 'cl-lib nil t)
-  ;; For emacs 23, look for bundled version
   (require 'cl-lib "lib/cl-lib"))
 
 (eval-and-compile

FWIW, if you use the markdown code block with backticks it looks like this. (from the webpage)

~theo 3 years ago

~lyefrat that might be smart

~larsi 3 years ago

I don't think we can expect people to do Markdown just to appease the bug tracker.

It's not like it's difficult to auto-detect diffs in a mail, so it's a bit odd that they haven't implemented that for a forge.

~theo 3 years ago

~larsi outgoing@sr.ht writes:

I don't think we can expect people to do Markdown just to appease the bug tracker.

It's not like it's difficult to auto-detect diffs in a mail, so it's a bit odd that they haven't implemented that for a forge.

not so sure, people are used to it from github etc. But that could be an issue as well. I'll ask them.

diff --git a/slime.el b/slime.el
index 8436b332..216b6ad0 100644
--- a/slime.el
+++ b/slime.el
@@ -60,7 +60,6 @@
 ;;;; Dependencies and setup
 (eval-and-compile
   (require 'cl-lib nil t)
-  ;; For emacs 23, look for bundled version
   (require 'cl-lib "lib/cl-lib"))
 
 (eval-and-compile

-- View on the web: https://todo.sr.ht/~emacs/emacs/1#event-109230

~theo 3 years ago

~larsi outgoing@sr.ht writes:

I don't think we can expect people to do Markdown just to appease the bug tracker.

It's not like it's difficult to auto-detect diffs in a mail, so it's a bit odd that they haven't implemented that for a forge.

-- View on the web: https://todo.sr.ht/~emacs/emacs/1#event-109230

<ddevault> todo is markdown first, email second
<ddevault> this might change at some point but for now that's how it's
           designed

~larsi 3 years ago

The emails I'm getting in response to this thread also look extraordinarily ugly: https://quimby.gnus.org/s/hut.jpg

It looks like the HTML has been rendered into text/plain with a very odd folding algorithm (when just sending them out as HTML might have been better).

~theo 3 years ago

~larsi outgoing@sr.ht writes:

The emails I'm getting in response to this thread also look extraordinarily ugly: https://quimby.gnus.org/s/hut.jpg

It looks like the HTML has been rendered into text/plain with a very odd folding algorithm (when just sending them out as HTML might have been better).

That is strange. For me it looks exactly the same as emacs-devel. This could be a config issue on my end, though I use a pretty vanilla message-mode buffer initiated from notmuch. Do messages sent from me to emacs-devel look better?

~larsi 3 years ago

Wasn't the message I was looking at in the URL sent from/via Sourcehut? The Received header seems to say so?

Your messages on emacs-devel look fine, but they haven't been via Sourcehut.

~theo 3 years ago

Wasn't the message I was looking at in the URL sent from/via Sourcehut? The Received header seems to say so?

Your messages on emacs-devel look fine, but they haven't been via Sourcehut.

No, The only messages I've sent from the web forms are the ones from the ~emacs user. Strange. But to me it looks mostly like a line-wrapping thing? Or is it something else you are thinking of?

~larsi 3 years ago

The mail is from the sr.ht server:

Received: from mail-b.sr.ht ([173.195.146.151]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from outgoing@sr.ht) id 1n08MH-0003SA-0e for larsi@gnus.org; Wed, 22 Dec 2021 21:37:11 +0100

So you've sent the mail to sr.ht, and it has apparently mangled it before sending it on to me?

~theo 3 years ago

On 22 December 2021 21:41:08 CET, ~larsi outgoing@sr.ht wrote:

The mail is from the sr.ht server:

Received: from mail-b.sr.ht ([173.195.146.151]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from outgoing@sr.ht) id 1n08MH-0003SA-0e for larsi@gnus.org; Wed, 22 Dec 2021 21:37:11 +0100

So you've sent the mail to sr.ht, and it has apparently mangled it before sending it on to me?

Apparently. In notmuch, I press R, then type, then C-c C-c. (this one is sent from K9 on android)

What specifically is mangled, so that I know we are talking about the same things? Also would help me pass it on to the devs.

~larsi 3 years ago

~theo outgoing@sr.ht writes:

What specifically is mangled, so that I know we are talking about the same things? Also would help me pass it on to the devs.

The lines are folded improperly, as you can see when comparing that JPG with how it looks in the web interface.

~larsi 3 years ago

And another oddity -- the messages have a From header of

From: ~theo outgoing@sr.ht

and a Reply-to that's the real address. But when doing a "wide" reply (which is common on mailing lists), the response goes to both From and Reply-to, and the former bounces:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

outgoing@sr.ht host mail-b.sr.ht [173.195.146.151] SMTP error from remote mail server after RCPT TO:outgoing@sr.ht: 550 5.1.1 outgoing@sr.ht: Recipient address rejected: User unknown in local recipient table

Having something unusable in From will annoy a lot of people.

~theo 3 years ago

Yeah! I've seen that as well!

~sircmpwn 3 years ago

Hiya, SourceHut maintainer here.

todo.sr.ht is not a mailing list, and does not behave like one. It's markdown first, and email second. It does not behave like Debbugs, and treating it like that is going to raise a lot of problems -- as you've already discovered :)

This is, in my opinion, a defect in the design of todo.sr.ht, and I have thought about improving on it before, to make it actually work like a mailing list and to be more email-oriented, which would be more in line with the design goals of SourceHut. However, it won't be easy, and this work has not been prioritized, and is unlikely to be prioritized soon. If any emacs volunteers want to get on top of the necessary changes, start a thread on sr.ht-discuss and I'll see if I can weigh in with my thoughts (though I might be slow to answer during the holidays).

The alternative is to adapt your workflow to work within the constraints of todo.sr.ht's present-day design. Up to you.

~skangas 3 years ago

Lars Ingebrigtsen writes:

After futzing around with the bug tracker, I think that it's going to be
pretty annoying to work with in its current state.  See:

  https://todo.sr.ht/~emacs/emacs/1

The main problem is that the email integration is lacking.  The mails it
sends out are unreadable, and when you send mails to it, they'll usually
end up being unreadable on the web interface.

It sounds like fixing this on the er todo list, but is not a priority.
So I don't think moving to it is an option at this time.

But working on importing debbugs into it would be useful anyway (if they
ever fix the mail stuff).

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02304.html

~emacs REPORTED FIXED 3 years ago

Closing this since it seems we reached some consensus here: revisit at a later time.

Register here or Log in to comment, or comment via email.