Apache Software Foundation joins GitHub open source community

You ignore the most important part of the workflow, the patch review and the iterations that you'll probably have to do on it. If you just send your patches to random mailing lists and never bother to follow up on them then yeah, that's pretty easy.

I like "old tech". I use emacs, my mailer is mutt, I don't like HTML email, I like IRC, I like using a terminal, I don't like how the web is eating everything.

Still, my experience using mailing lists is just garbage.

Random anecdotes from working with project using mailing lists for patch reviews:

- I find a patchset that seems interesting, but I wasn't subscribed to the ML back when it was posted. Now I need to dig up the mails on some archive out there. I want to see if there were important comments/revisions on these patches? Well here goes 30 minutes of clicking on "next by thread" to sift through the entire discussion, hoping not to miss anything.

- Every project has slightly different guidelines for contributing. Should I put somebody in copy? Run some script on the patch beforehand? Is there a special procedure for contributing patches? Here comes 15 minutes sifting through the "contributing" doc to figure out the modus operandi. I still get it wrong from time to time on projects I don't frequently contribute to (mainly because I get confused between different projects and forget the idiosyncrasies). And of course you need to figure out the exact mailing list to use, whether you need to subscribe to post on it etc...

- You get some feedback on your patch and need to create a new revision? Oh boy, that's where the fun begins. Don't forget to set the "--in-reply-to=" to your git command line if you want your patches to thread correctly! Also some projects prefer that you add a revision number to your patch set, but I actually forgot how to do that and a quick browse through git format-patch's man page didn't help me. Boy, this sure is easy and straightforward! To think of those losers on GH who just have to push their updated commits on their branches and the PR is automatically updated.

- Okay now you've amended your patchset and integrated your modifications. But the patchset is large and the modifications are mainly small coding style issues. Do I send the patch right now, at the risk of getting comments on two separate threads, one outdated, and also risking spamming the mailing list if I do other modifications in a row? Wouldn't it be better buffering the changes and pushing a big new patchset later once I get more feedback? But then the other reviewers will work with outdated code... Wow, it sure does feel like the proper tool to work with! I'm so glad I'm not using github's PR system right now.

I can't justify this. I'll defend IRC over Slack/Discord to the bitter end, mutt over gmail, Emacs over VS Code but I just can't comprehend how mailing lists are still a thing, much less patch mailing lists. I actually have some modifications to software that I use that I didn't bother upstreaming because I can't be arsed to figure out where those patches need to be sent and how. On the other hand I have already submitted PRs for small, non-important one line changes on github because it's so simple and frictionless.

I want mailing lists to die. I want patch mailing lists to die a painful death.

Personally, my only gripe (even though it's not a huge deal) is I'd have preferred it if they used hosting that actaully was open source (like gitlab)

Does apple really make any software that is that complicated?

http://www.usionly.xyz/27/04/2019/repixel-ad-network-review-...

I agree with some of what you say—one caveat is that you're still on the hook, for example, for finding out which GitHub URL/repo maps to the project you want to contribute to. In practice, this is roughly on par with the difficulty of finding the link to the self-hosted Bugzilla instance. It's a shame that decentralized single sign-on is still such a disaster, since that's essentially the one thing that GitHub has as a leg up over other options—assuming you've contributed to some other GitHub project before.

To stray outside the lines with some meta-commentary: it's nice to get a well thought out response instead of the sort of kneejerk rooting-for-my-home team that's on display in the wasteland of intellectual dishonesty in the comments below.

This has been my observation as well - projects flourish under the Apache umbrella. Parquet and Arrow are also widely used and will probably continue gaining importance. A Rust big data engine, similar to Apache Spark, was just donated to the Apache Arrow project (it's called DataFusion: https://github.com/andygrove/datafusion). From what I can tell, Apache already has a lot of important projects and is adding new ones that will continue to grow.