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…
Email and Git = <3
131–140 of 265 posts
Re: Email and Git = <3
#132Actually, if you want to cut out all the systems like github or git lab, why wouldn't the team just set up a VPS with standard ssh access and that would be the main repo people push to since git supports many protocols like ssh, and even file:// (which I use for my local projects which are backed up).
It's easy for the VPS admin to add new team members, just a standard Linux account. It might be possible to even set up a restricted account so the member ssh'ing in a commit using git only has access to the repo and can't get a login shell.
Re: Email and Git = <3
#133Earlier quoted context omitted.
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.
And then every so often mailman hits you up with "I'm receiving all these bounces from your email server!" because all the various garbage anti-spam techniques were not quite thought out with mailing lists in mind or people have lots of misconfigured servers and servers with different acceptance criteria, and it's all a big mess. Configuring git send-email is only half the battle, anyway - chances are you want to par…
This sounds like hyperbolic brought on by dislike, not a real indicator of time cost/effort. You've already spent more time complaining, than the work done to do these things!
Re: Email and Git = <3
#134Earlier 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…
Re: Email and Git = <3
#135Earlier quoted context omitted.
Damn, this is ugly and confusing, I mean, look at the threads XD! I'm glad I must not use this shit.
Shh now. A basic interface that took 5 minutes to make in 1995 is good enough for all eternity. No need to change it.
Re: Email and Git = <3
#136Earlier quoted context omitted.
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…
One thing I’ve noticed is that the people who “live in their email client” (and this applies to Outlook and to using emacs to read email) are very productive if everything is working right. I’ve seen people blow through a number of patches and discussions in their email client faster than I can even get GitHub to load the notifications. And then there’s a philosophical discussion if burning newbie’s time or discourag…
Re: Email and Git = <3
#137Earlier quoted context omitted.
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…
One thing I’ve noticed is that the people who “live in their email client” (and this applies to Outlook and to using emacs to read email) are very productive if everything is working right. I’ve seen people blow through a number of patches and discussions in their email client faster than I can even get GitHub to load the notifications. And then there’s a philosophical discussion if burning newbie’s time or discourag…
Argitrage?
Re: Email and Git = <3
#138Earlier quoted context omitted.
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…
“Obfuscated complexity” aka good UX that decreases friction and increases velocity.
Re: Email and Git = <3
#139Earlier quoted context omitted.
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…
your parens enclose the most unneeded addendum i have ever seen
Re: Email and Git = <3
#140Earlier quoted context omitted.
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.
How is that harder than signing up to Github?
I'm asking specifically what part of subscribing to mailing lists is the tricky part, as that's what parent mentioned. I'm not saying it's easier/harder than GitHub's workflow.