thinking about git workflows again

the main reason maintainers prefer email workflow is its simpler to use for them than pr based system

but for contributors, what they want is a mostly painless experience, no looking arou'd what email provider to use, find out they cant be used with git send email, configure git send email, format patches, send

most of that could just be automated, what if there was some service that allows github like ease of use, but instead of user making email, the server does it, and user maybe annotate it. service just embeds a mail server so no asking where to sign up for email

then user would pretty much just need to make account, clone (fork) on service, clone locally, make cha'ges, push to service, and send, which is basically as painless as on github etc, could get more potential contributors interested in at least trying to send patches to email workflow based projects

@SRAZKVT I feel like PRs are easier for both sides but this sounds like a good idea for those who think otherwise

@lunareclipse well on some projects i maintain i sometimes would have preferred discussions were more tree based than just a list, for example when discussing an api we have two or more discussions overlapping so we use reply feature but its just a mess and have to shrink replies every so often

thats at least one advantahe over pr i see

but pr have advantage of "press one button u send, press one button u merge" which is definitely easier than doing the same with email imo

@SRAZKVT @lunareclipse

git-send-mail (after setup) is one command to send, merging requires you to download the patches, which some mail clients make it painless as well

and yeah, tree like conversations, less remotes to track (e.g. with github, to make a v2 of a pr, i need to have upstream and my fork as remotes, pull from upstream, rebase my fork, do my changes, push my fork)

with send-email, i clone the repo, commit changes, send the email, no fiddling with web uis, forks and extra remote repos, just my local copy. for a v2, rebase on origin, commit changes, send-email -v2

it's quite comfy and simple

and honestly, "forge federation" should be just that, make forges send-email to each other, but also let users do. the reason i don't do more email based patches is because github doesn't accept them, and gitlab repos, more often than not, has that option disabled

@navi @lunareclipse if anything the main reason i dislike email is that its a disgustingly bad protocol that no one respects, and is a massive pain to implement properly

but just hidden away behind a forge i would probably be just fine with using it

@SRAZKVT There are two wolves at the heart of this problem -- one is a quest to remain decentralized and resilient to single-points-of-failure, and another an effort to lower the barrier for entry. It is super difficult to get any sort of yin-yang balance here, unfortunately.

That said, have you looked at https://b4.docs.kernel.org/en/latest/contributor/overview.html ?

@monsieuricon i havent looked at it, at a quick glance it seems to kinda do things more like darcs does ?