> When we have failing tests people do not spend the time to figure out if > their logic caused a regression and merge, making things more unstable… so > when we merge failing tests that leads to people merging even more failing > tests... What's the counter position to this Jacek / Berenguer?
Mick and Ekaterina (and everyone really) - any thoughts on what test coverage, if any, we should commit to for this new configuration? Acknowledging that we already have *a lot* of CI that we run. On Wed, Feb 14, 2024, at 5:11 AM, Berenguer Blasi wrote: > +1 to not doing, imo, the ostrich lol > > On 14/2/24 10:58, Jacek Lewandowski wrote: >> We should not block merging configuration changes given it is a valid >> configuration - which I understand as it is correct, passes all config >> validations, it matches documented rules, etc. And this provided latest >> config matches those requirements I assume. >> >> The failures should block release or we should not advertise we have those >> features at all, and the configuration should be named "experimental" rather >> than "latest". >> >> The config changes are not responsible for broken features and we should not >> bury our heads in the sand pretending that everything is ok. >> >> Thanks, >> >> śr., 14 lut 2024, 10:47 użytkownik Štefan Miklošovič >> <stefan.mikloso...@gmail.com> napisał: >>> Wording looks good to me. I would also put that into NEWS.txt but I am not >>> sure what section. New features, Upgrading nor Deprecation does not seem to >>> be a good category. >>> >>> On Tue, Feb 13, 2024 at 5:42 PM Branimir Lambov <blam...@apache.org> wrote: >>>> Hi All, >>>> >>>> CASSANDRA-18753 introduces a second set of defaults (in a separate >>>> "cassandra_latest.yaml") that enable new features of Cassandra. The >>>> objective is two-fold: to be able to test the database in this >>>> configuration, and to point potential users that are evaluating the >>>> technology to an optimized set of defaults that give a clearer picture of >>>> the expected performance of the database for a new user. The objective is >>>> to get this configuration into 5.0 to have the extra bit of confidence >>>> that we are not releasing (and recommending) options that have not gone >>>> through thorough CI. >>>> >>>> The implementation has already gone through review, but I'd like to get >>>> people's opinion on two things: >>>> - There are currently a number of test failures when the new options are >>>> selected, some of which appear to be genuine problems. Is the community >>>> okay with committing the patch before all of these are addressed? This >>>> should prevent the introduction of new failures and make sure we don't >>>> release before clearing the existing ones. >>>> - I'd like to get an opinion on what's suitable wording and documentation >>>> for the new defaults set. Currently, the patch proposes adding the >>>> following text to the yaml (see >>>> https://github.com/apache/cassandra/pull/2896/files): >>>> # NOTE: >>>> # This file is provided in two versions: >>>> # - cassandra.yaml: Contains configuration defaults for a "compatible" >>>> # configuration that operates using settings that are >>>> backwards-compatible >>>> # and interoperable with machines running older versions of >>>> Cassandra. >>>> # This version is provided to facilitate pain-free upgrades for >>>> existing >>>> # users of Cassandra running in production who want to gradually and >>>> # carefully introduce new features. >>>> # - cassandra_latest.yaml: Contains configuration defaults that enable >>>> # the latest features of Cassandra, including improved functionality >>>> as >>>> # well as higher performance. This version is provided for new users >>>> of >>>> # Cassandra who want to get the most out of their cluster, and for >>>> users >>>> # evaluating the technology. >>>> # To use this version, simply copy this file over cassandra.yaml, or >>>> specify >>>> # it using the -Dcassandra.config system property, e.g. by running >>>> # cassandra >>>> -Dcassandra.config=file:/$CASSANDRA_HOME/conf/cassandra_latest.yaml >>>> # /NOTE >>>> Does this sound sensible? Should we add a pointer to this defaults set >>>> elsewhere in the documentation? >>>> >>>> Regards, >>>> Branimir
