Conversation

Notices

1. Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 15-Feb-2023 07:53:40 JST Adrian Cochrane

   Question: What exactly are the objections to emailing opensource patches? Has SourceHut addressed them sufficiently?

   I want to explore federating codeforges in a way that isn't specific to codeforges.
   For now email (which I actually like the UX of...) is my tactic, but I may explore adding #Haphaestus-specific features once its up & running!

   :boost_love:

   • Jason Bowen (jbowen@mast.hpc.social)'s status on Wednesday, 15-Feb-2023 08:02:07 JST Jason Bowen

     in reply to

     @alcinnz Here was a thread today on the topic: https://social.treehouse.systems/@marcan/109863991681394714

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 15-Feb-2023 08:02:07 JST Adrian Cochrane

     in reply to

     • Jason Bowen

     @jbowen Yeah I saw that, kind of prompted this question. I don't see many specifically complaints though there are these toots: https://social.pixie.town/@joepie91/109864083801124159

     I'd say that SourceHut Todo has addressed those complaints by essentially using email as an authenticated comment box.

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 15-Feb-2023 08:23:21 JST Adrian Cochrane

     in reply to

     • wizzwizz4

     @wizzwizz4 I'm offering email to collaborators who don't want their existing one to be public.

     But yeah, I'm hearing that it will be valuable to offer an alternative! I'll enjoy exploring that once Haphaestus's basics are working!

   • wizzwizz4 (wizzwizz4@fosstodon.org)'s status on Wednesday, 15-Feb-2023 08:23:22 JST wizzwizz4

     in reply to

     @alcinnz Problems I have experienced:

     • I haven't always had access to an email address. (I'm not yet cool enough to self-host.) Email-address-based workflows are a barrier for baby-young programmers, in a way that not even GitHub is.
     • I never know whether it's going to publish my email address publicly (something I would rather not happen) or, worse, edit my commits to *insert* my email address (when I explicitly did not provide that in the patch).
     • Many email clients are bad.

   • jan Anja :toki: (cybertailor@deadinsi.de)'s status on Wednesday, 15-Feb-2023 12:38:46 JST jan Anja :toki:

     in reply to

     @alcinnz at Gentoo, both workflows are supported. There are GitHub mirrors where you can open a PR. Developers apply them as patches using the "pram" utility.

   • Silmathoron (silmathoron@floss.social)'s status on Wednesday, 15-Feb-2023 16:38:58 JST Silmathoron

     in reply to

     @alcinnz
     I can sum up the main ones I've seen:

     - the first is people not knowing how it works and thinking it will take more time, while it's actually just a glorified commit/push with git-send-email
     - second is people not wanting to show their address, which I find weird when contributing to FLOSS
     - third, which is fair, is that review is less convenient than on interactive forges with GUI; sourcehut is definitely lacking there

     See also: https://gitlab.com/postmarketOS/postmarketos/-/issues/49

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 15-Feb-2023 17:21:55 JST Adrian Cochrane

     in reply to

     • Silmathoron

     @silmathoron Yeah, I've seen the unfamiliarity issue before... Difficult to address an unwillingness to try something new...

     Hmmm, I'm curious whether I'll be bump against those review inconveniences? I guess I'm willing to explore fixes if/when I feel I need them!

     I can certainly understand for a degree of anonymity, or to avoid spam. I've got short-term & long-term plans to address that need...

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 15-Feb-2023 17:23:44 JST Adrian Cochrane

     in reply to

     • Silmathoron

     @silmathoron Oh, and thanks!

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 15-Feb-2023 17:26:20 JST Adrian Cochrane

     in reply to

     • raboof

     @raboof Depends on whether you use Todo or Lists to accept patches. I'm using Todo, treating pull requests like bugs. Todo provides these features.

   • raboof (raboof@merveilles.town)'s status on Wednesday, 15-Feb-2023 17:26:21 JST raboof

     in reply to

     @alcinnz what I miss in most 'email patches' workflows is that a contribution doesn't have a URL you can point to that gives a clear overview of the current state: is it rejected or still open, is there an updated patchset that is intended to replace it, are we waiting for the contributor or the project to take the next steps? Also other metadata like tags, assigning people etc.

     I didn't see SourceHut address those, though I closed my account there long ago for different reasons.

   • nawordar@mstdn.social's status on Thursday, 16-Feb-2023 05:17:37 JST nawordar

     in reply to

     @alcinnz no code highlighting or any other formatting to make text easier to read (let's forget about HTML…). Git send-mail may be difficult to set up, depending on e-mail hosting

   • Vertigo #$FF (vertigo@hackers.town)'s status on Thursday, 16-Feb-2023 05:39:18 JST Vertigo #$FF

     in reply to

     @alcinnz The entire user experience is a travesty.

     1. Number one, and in my opinion, the single most important detractor: No side-by-side comparison of patches. Hate to say this, but the line-oriented diffs are not ideal for making before-and-after comparisons of the code. In my experiments with SourceHut, it does not adequately address this concern.

     2. No (topical) in-line feedback is possible without completely marring the content and legibility of the email. One could argue this is a good thing, as it strongly rewards making lots of microscopically-sized patches that are easier to review. However, I counter that with, in my day-to-day, I find tiny patches are a once- or twice-in-a-year phenomenon. My work typically results in large-scale changes that cuts across multiple layers in the technology stack, leading to large, wide-sweeping patches that must be applied all at once for things to work (e.g., drivers, kernel, language bindings, and the app proper). Use of email for patches just isn't useful for my current line of work.

     3. Interfacing with e-mail clients assumes you run a mail client locally, and do not make use of web-mail or "integrated" mail clients like MS Outlook. Unfortunately, at work, we use Outlook and webmail interfaces depending upon need. My personal mail needs is also covered by webmail. Importing and exporting messages for use with Git is possible, but it is an additional burden which, bluntly, is remarkably error-prone if you don't pay attention to what you're doing.

     I'm not going to say that it's superior or inferior to alternative methods; but for my current work-flows, e-mail patch management is just not a good fit. I'm sure it's great for those who have good supporting tooling surrounding their workflows, and for those who have teams who buy in to having tons of really, really tiny patches instead of a few rather larger patches.

     At the end of the day, it all depends on the preferences of your team mates and the needs of the project.

   • Adrian Cochrane (alcinnz@floss.social)'s status on Thursday, 16-Feb-2023 05:54:12 JST Adrian Cochrane

     in reply to

     • Vertigo #$FF

     @vertigo Thanks! This feedback is useful!

     From a lot of this feedback I get the impression that I'm largely bypassing the most hated bits by using SourceHut todo. I may not have the most optimal tooling on my side, but I'm willing to improve them as I hit their inconveniences.

     Here's my conclusions from the feedback: https://floss.social/@alcinnz/109870608563040270

     I'm finding the UX very seamless with native mail clients, but I'll ensure it works well with webmail.