What sort of commitment is there to the follow-up tickets? Are the follow-ups "make this faster" or are there specific tasks we know will help? I'm concerned by the increase in testing run times on circle but don't think that should prevent a good/decided upon default from merging.
Jordan On Wed, Aug 19, 2020 at 9:49 AM Mick Semb Wever <m...@apache.org> wrote: > It was agreed¹ that 4.0 should have the new configuration defaults of > num_tokens: 16 > allocate_tokens_for_local_replication_factor: 3 > > 13701's patches: against cassandra, cassandra-builds, cassandra-dtest, ccm; > are reviewed, tested, and ready to commit. But the ccm and dtest patches > required ccm having to now start nodes sequentially, and adding some longer > timeout values in the dtests. > > The consequence of this is CI runs now take longer. ci-cassandra.a.o's > dtests take ~30% longer, and circleci's dtests (with vnodes) have gone from > ~22 to ~43 minutes. The general opinion (on slack²) is to commit, and work > on improving ccm and dtest startup times in a subsequent ticket. > > 13701 was intended to be committed before the first beta release because of > its user-facing changes. But these numbers are significant enough it makes > sense to touch base with dev@ > > Does anyone (strongly) object to the "commit + follow up ticket" approach? > > regards, > Mick > > > ¹ – > > https://lists.apache.org/thread.html/ra829084fcf344e9e96fa5c61cb31e909c8629091993471594b65ea89%40%3Cdev.cassandra.apache.org%3E > ² – https://the-asf.slack.com/archives/CK23JSY2K/p1597747395032600 and > > https://the-asf.slack.com/archives/CK23JSY2K/p1597849774078200?thread_ts=1597762085.048300&cid=CK23JSY2K >
