I can sympathize with this take. Although I'm generally fine with either async or sync--whichever is most efficient--it seems that individuals don't usually know which is right for them.
I'll take this further: I think that bad commit messages breed resentment. It's highly context dependent, but needing to understand some code and its historical context is already a big challenge. git-blaming your way back through time only to encounter brain dump commit messages full of ambiguity and non-essential information is excruciating. Writing good commit messages--like any technical writing--is more art than procedure, and it's hard to do well without feedback and revision. I believe that commit messages should be subject to the same level of review as the code they are presumably documenting.
This is such an important feature that has a direct impact on code quality and time savings that I'm not sure why it isn't a priority feature. As a reviewer, having to choose between "review everything again" or "trust the submitter didn't introduce extra changes in the revised pr" is such a terrible choice to have to make.
Migrating away from a development model based on attaching patches to bugzilla tickets is sure to improve the development experience, especially for new contributes. Good move switching.
This sounds really similar to some of the work coming out of Vectorized on Redpanda [0]. They're building a Kafka API compatible system in C++ that's apparently achieving significant performance gains (throughput, tail latency) while maintaining operational simplicity.
Where do you see performance comparisons to Kafka? As far as I can tell, the product you linked doesn't exist outside of a blog, so this reads like a marketing post.
Great to hear. I couldn't get more details from them, but it was something about both rebalancing and data recovery. They picked SwiftStack, which is at least in part open source. Maybe by now you have figured who that company is.
My team is still very interested in Ceph and Rook, for the record.
If you are thinking about starting a Seastar project, definitely check out SMF [0]. It's a highly optimized RPC framework that uses Seastar, and makes it easy to build high-performance servers and clients. Seastar itself is RPC agnostic, and this project has a great implementation of functionality most developers will eventually need.
This seems to serve a purpose similar to Rook [0] for deploying distributed (or non-distributed) storage systems, including database. For example, Rook can deploy CockroachDB and also Ceph, which would have a lot of the same challenges as deploying some of the databases supported by KubeDB.
Rook stretching to databases looks like a random tangent trying to do everything at once. The project should focus on being a solid distributed storage provider first and let users run databases themselves on those volumes. It's especially strange since these databases already have their own storage replication and would be duplicating work.
[0]: https://makedist.com/projects/cruzdb/