181–190 of 265 posts
Earlier quoted context omitted.
I have absolutely no desire to send all of my companies intellectual property to a mail server. It could be the best workflow in the world, but if one email address gets breached, you're leaking everything and that's really unacceptable.
Isn't this also the case for centralized git servers? Even moreover if you run a monorepo.
And that having been said, I really GitHub/GitLab/etc. could move on from the pull request model and into a more change-oriented model like Gerrit or Phabricator. These are clearly better models in my opinion, and for most uses it's not even dramatically different.
Earlier quoted context omitted.
This is like saying that pyramids were constructed without modern cranes and bulldozers so obviously it's the right way to build stuff today. It's clearly not true but there are many power-wielding individuals in these projects who prefer to browse the web with lynx or develop in emacs and will impose this on anyone that would like to participate. This is wrong.
No one is forcing you to contribute to, or even use, software that uses an email-based workflow. I’d also put money on the fact that the majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow.
This is exactly the problematic attitude. I'm an OpenJDK author but not linux kernel contributor for mainly this reason. There are many people like me.
> majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow
This reminds me the many absurd conversations I had from my time in Goldman Sachs, few years ago. People with 15+ year tenures claiming Slang is the best answer to any- and everything. They just didn't know any better and stubbornly stuck to tooling and mindset straight out of 1995.
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…
A GitHub PR is way more steps than e-mailing a patch to a mailing list, and far less accessible. Have you never done the "sign the contributor license agreement and get the GitHub bot to approve it" polka? I've done it a dozen times now, it's painful and way more gatekeepery than just emailing a patch.
> but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement
Who hurt you?
Earlier quoted context omitted.
There is usually no need to subscribe.
This. You just To: the mailing-list and depending on the project CC: the maintainers. No subscribing needed. Standard policy on all mailing lists is to reply-to-all so you'll get always CC'ed on replies. This also makes it very easy to pull in more people into a discussion, even across different projects.
Many mailing lists today reject posts from non-subscribers.
Of those that allow posts from non-subscribers, you will find that many are configured such that you will not get a reply, due to "reply-to munging". Your message will go to the list, but with a Reply-to: header designating that list, instead of (or in addition to) setting the more modern mailing-list-related headers.
Reply-to-all isn't a list policy; it's a behavior of the individuals. Some people don't reply to all. They think they are, but only the post author gets their reply. That is one of the motivations behind the Reply-to.
https://marc.merlins.org/netrants/reply-to-still-harmful.htm...
Earlier quoted context omitted.
Sadly you’re right. Microsoft has brainwashed many IT departments into forcing oauth on everything, no app specific passwords, no regular passwords, nothing else. Thankfully they do support this on imap and smtp, but you have to have something that can handle it. I use a modified version of isync with the sasl plugin to fetch mail, and a python smtp sender that supports the oauth flow along with a set of scripts for…
Multiple enterprise customers use my software ( https://emailengine.app ) because it can proxy OAuth2-enabled IMAP/SMTP connections as regular password-based sessions. Turns out there are a lot of legacy, like all kinds of cron scripts, that want to connect to some IMAP account to check and do something. It all breaks down once the organisation enforces OAuth for their email. So, personally, I don't like it at all, b…
Earlier quoted context omitted.
Isn't this also the case for centralized git servers? Even moreover if you run a monorepo.
No clue, I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals.
Like a mail server?
Earlier quoted context omitted.
Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
“needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with c…
You cannot possibly claim that the other side needs to cite their sources and then throw numbers like that out without any backing.