111–120 of 265 posts
Earlier quoted context omitted.
“Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.
You don't need to subscribe. You are in CC when people want you to be notified, otherwise there are web interfaces you can browse. See https://lists.gnu.org/archive/html/guix-devel/ for example. On each message there is a button: "reply via email to [...]".
I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
There's a psychological basis for people taking pride in a difficult task learned and mastered, and many organizations take advantage of this by creating a culture that rewards this effort when put towards their own products with social status within the organization. It feels manipulative and unethical to me.
Earlier quoted context omitted.
> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" . You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
In what cases is it tricky? I find that most projects use some version of mailman (like QEMU - https://lists.nongnu.org/mailman/listinfo/qemu-trivial ) and then it's just a question of filling out the form and hitting "Subscribe". I cannot remember project I wanted to contribute to, I had to use git+email and it was difficult to subscribe to the mailing list they want me to use.
Earlier quoted context omitted.
This interface is awful. I wish GNU would make more of an effort to be easy to contribute to.
I usually know, when the interface is not too shiny, that the content might be good. It's the same with HN. And those interfaces are still very easy to understand and use. That being said, there is certainly room for improvement.
I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility.
It's not off the table that we may give it a try again, because the advantages of having concrete pull requests (and issues and...) rather than patch series is pretty significant. But if you're familiar with doing email-based review, I think it's still a far superior; and you're definitely giving something up when you move away from it.
Earlier quoted context omitted.
There’s another method that doesn’t use app specific passwords but I’m not entirely sure how it DOES work - it opens a connection and then gives you a web address to go to in your browser to authenticate with 2fa. And then somehow it magically works until it decides it doesn’t like you anymore.
I never studied the protocol of Gmail/Exchange/etc. 2FA, but I suppose the SMTP auth token expires after a while, and the client somehow hasn't implemented token refresh? Anyway, glad to know there is a way (?) to get git-send-email working with stricter 2FA.
I wish I could "preview" sending my patch to mailing lists. I've considered the idea of having a localhost mailing list for the sole purpose of sending it there just to make sure that i've got everything setup right, but haven't gotten around to doing it yet.
I love this. This is how it was done back in the days of usenet. People would email patches to the linux kernel. Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Their contribution. So cool! Maybe we should go back to this. Get rid of the whole github thing. Every group their own little mailing list. Laboring in private!
Did you contribute to open source in those days? I did a little (KDE patches to mailing lists before I got Subversion access) and: it was _awful_. You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse. GitHub has made some parts of open source worse (e.g. how easy it is to now open poor issues while ignoring required information compared to Bugzilla) but the…
Wait, are people doing this via the GitHub web UI these days? That sounds like a nightmare.
I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
Hard agree! I think the success of Github's PR system over Git + email workflows has proved itself quite well through sheer adoption numbers.
Earlier quoted context omitted.
> not the monsters that GitHub/Lab You mean cloning a repo and then simply pushing upstream? I can’t fathom how anyone would think that is more complicated than e-mail push workflows. It’s like someone telling you that IRC is “obviously” less complicated than setting up a Discord account.
There's complexity and then there's complexity. Your end user experience as a Discord user may be simpler on its face, but it's reliant on a lot of obfuscated complexity under the hood. You wouldn't be able to, say, send Discord messages using telnet, the way you can with IRC. Discord's simplicity in setting up an account, joining servers, having scrollback, etc comes at the cost of other types of simplicity. People…