Hacker News Reader

Comment by IshKebab | Hacker News Reader

> Sometimes people just can’t work out how to send me patches at all.

Yeah indeed. I have written but not submitted patches to a project (OpenSBI) because it made the submission process super complicated, requiring signing up to a mailing list, learning how to set up git send-email.

I don't see how he can think creating a GitHub account (which almost everyone already has) is a big barrier when he freely admits his process is incomprehensible.

I don't buy the GitHub locks you in either. It's pretty easy to copy issues and releases elsewhere if it really comes to it. Or use Gitlab or Codeberg if you must.

https://docs.codeberg.org/advanced/migrating-repos/

Any of those are far better than random mailing lists, bugzilla, and emailed patch files.

Putty is great but please don't listen to this.

View on HN

Back when i checked out sr.ht, i really liked the idea of git-send-email precisely because it doesn't require making an account for everything. there's a nice tutorial for how to set it up: https://git-send-email.io/#step-1

worked easily enough for me, i could see myself using it for small patches here and there.

I did end up installing forgejo in my homelab after all, but back then it sounded like federation was much closer than it actually was. i did kind of expect that though, federation gets pretty complex quick.

every time i log into forgejo, i do see that juicy "proceed with OpenID" button though, and i've looked into running my own openid provider a few times - sadly not seeing anything that would work for me yet. honestly i can't believe we went from "facebook sign in" to "google sign in" and are now going to "github sign in" without a single open standard that's gotten some adoption.

Pragmatically, how about fediverse sign in? Tweet this nonce to a bot account to log in.

> there's a nice tutorial for how to set it up

A simple 12 step process...

> requiring signing up to a mailing list

A traditionally configured mailing list allows posts from non-subscribers.

All the mailing lists I operate are like this.

If you have good anti-spam-fu, you can get away with it. Plus, it's possible to have posts from non-members be held for moderation, and you can whitelist non-members who write legitimate posts.

Projects which require people to sign up to their mailing lists to participate are erecting a barrier that costs them users; it's a stupid thing to do, and unnecessary.

Whenever I have to interact with some mailing list, I begin by just sending my query to the list address. If it bounces due to nonmembership, I usually move on, unless it's some important matter.

By the way, some modern lists allow posts from non-members but then rewrite the headers in such a way that the nonmember does not receive replies! This happens in more than one way, I think. One of them is Reply-To Munging: the list robot sets the Reply-To: header redirecting replies to be directed to the list address. The Reply-To throws away the content of the original To and Cc fields.

When this happens to me, I usually refrain from further interaction with the list. I check for replies in their archive. If I'm satisfied with what they said, that's the end of it.

>when he freely admits his process is incomprehensible.

Which one of the 4 preferred processes, not including the maligned git send-email, and infinite other accepted processes?

I submitted at least one patch to putty some time ago and it was such a nothingburger I don't even remember what it took. Somehow it neither baffled nor infuriated nor even annoyed me a little.

All these complaints and critiques sound like so much baby crying over nothing to me.

Same with the account creation on normal git websites. You fill out three fields and click a link in your email, it's no more complex than git send-email.

I'm sure I can figure out the archaic git email system, how hard can it possibly be? Same with the git bundle thing, this is the first time I've read about it but it seems usable. I don't expect anyone I'll ever directly work with to know what the hell a bundle file is but if a project wants their git commits in that format, it shouldn't be that much of a problem. The biggest hurdle will probably be spam filters, but that's an email problem and not necessarily a git problem.

Or course the downside to all this funky command line stuff is that you're applying a filter on the people who will ever contribute code. Plenty of people don't want to figure out the git's many weird command line flows and communication options. Plenty of developers don't care enough to actually learn about git beyond push/pull/rebase/merge. If you're only interested in the turbo nerds who enjoy using the many tricks git has to offer, you'll probably filter out most contributors, but realistically how many contributors does hobby project on a personal git server ever attract in the first place.

These deep thoughts would almost be slightly interesting except for a kind of big elephant that you somehow missed:

He's not writing about how you should run your project for his convenience.

> He's not writing about how you should run your project for his convenience.

No, but we can discuss and criticize policies all the same, regardless of how the original creator feels about such discourse.

That filter may be the advantage, but Mr. Tatham is just too polite to say that aloud.

Reply on news.ycombinator.com