On 07/12/2018 07:38 PM, Stefan Podkowinski wrote:
Deferring huge amount of commits gives rebase/redo hell. That's the
biggest impact and the order in which these deferred commits are then
actually committed can make it more painful or less painful depending on
the commit. And that in turn will have to then wait for each contributor
to rebase/redo their commit and those timings might make more rebase
issues. If those committers will want to rebase something after n-months
or have time at that point.

That's a problem for all Cassandra patches that take huge time to commit
and if this block takes a lot of time, then that will for sure be even
more painful. I know products such as Kubernetes does the same (I guess
that's where this idea might have come from) "trunk patches only", but
their block is quite short.

My wish is that this freeze does not last too long to kill enthusiasm
towards committing to Cassandra. There are (I assume) many hobbyist who
do this as a side-project instead of their daily work and might not have
the capabilities to test 4.0 in a way that will trigger bugs (easy bugs
are fixed quite quickly I hope). And if they feel like it's not worth
the time at this point to invest time to Cassandra (because nothing they
do will get merged) - they might move to another project. And there's no
guarantee they will return. Getting stuff to the product is part of the
satisfaction and without satisfaction there's no interest in continuing.

   - Micke

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB