|
|
Subscribe / Log in / New account

Email-based workflow does not seems to be much in demand nowadays

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 5:12 UTC (Tue) by pabs (subscriber, #43278)
In reply to: Email-based workflow does not seems to be much in demand nowadays by grothesque
Parent article: Emacs discusses web-based development workflows

For me GitLab's email integration is fairly good, you can even file issues (and ISTR patches) via email. The messages have correct subjects, Reply-To, correct threading and various GitLab metadata in X-GitLab-* headers. The main difference to a mailing list that I can see is the author's email isn't used in From, but that could be due to DKIM/DMARC/etc or people's mails not being public.


to post comments

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 10:31 UTC (Tue) by grothesque (guest, #130832) [Link] (4 responses)

Indeed, since the above issue has been opened, the threading of discussions has been corrected!

The subjects could be still more useful... For example instead of simply using the same subject for all messages in the thread (e.g. "Backport blabla fixes from master (!395)"), the action that triggers the notification could be included, e.g. "merged: Backport blabla fixes from master (!395)".

Same for the use of To/Cc (see the issue).

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 11:38 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

Alas, we are now stuck with braindead email clients that ignore In-Reply-To and instead try to do "smart threading" purely based on the email subject. While I have little sympathy for such laziness (though it seems way harder to me, but whatever), GMail and Outlook are, unfortunately, quite common.

Granted, there may be ways to make these clients behave sensibly, but it's not the default AFAIK.

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 22:07 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

And I miss Turnpike which, while it DID thread on in-reply-to, it also allowed the user to "break thread" so if somebody (as they often do on mailing lists) clicked "reply" then wiped everything and started a new topic, I could tell it to break on that email and make a new thread.

Or, in the not uncommon case that a change of subject in a long-running discussion really did herald a shift in what was being discussed, I could break so that the new subject was visible at the top level and thus easier to find.

Oh for intelligent clients that follow the rules BY DEFAULT, but allow you to break them where appropriate.

Cheers,
Wol

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 15, 2021 17:05 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> And I miss Turnpike which, while it DID thread on in-reply-to, it also allowed the user to "break thread" so if somebody (as they often do on mailing lists) clicked "reply" then wiped everything and started a new topic, I could tell it to break on that email and make a new thread.

Mutt allows this too (I just delete `In-Reply-To` in the message editor). I think there's a "break thread" command as well, but I almost never use it. I can even stitch together broken threads (though it seems that offlineimap doesn't sync that around, so it is fixed per client).

Email-based workflow does not seems to be much in demand nowadays

Posted Sep 14, 2021 11:56 UTC (Tue) by pabs (subscriber, #43278) [Link]

I see correct threading as far back as May 2020, when was the issue closed?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds