> > - Anticipated not to find serious bugs (e.g. old unchanged but poorly > tested features): Block GA
As an aside, I disagree about this blocking GA. We have a decade or so of debt and this is essentially a category without a ceiling. Under this umbrella we could feasibly delay 4.0 for another multiple years. On Fri, Dec 11, 2020 at 10:43 AM Joshua McKenzie <jmcken...@apache.org> wrote: > Reasonable categories. We haven't discussed what qualifies where for 4.0 > have we? (new lacking | changed modest | old lacking) > > On Fri, Dec 11, 2020 at 9:14 AM Benedict Elliott Smith < > bened...@apache.org> wrote: > >> In my opinion... >> >> - Expected to find serious bugs (e.g. new poorly tested features): Block >> beta >> - Anticipated to possibly find serious bugs (e.g. extensively changed >> features with modest testing): Block RC >> - Anticipated not to find serious bugs (e.g. old unchanged but poorly >> tested features): Block GA >> >> Which mostly accords with what you're saying re: today's state of play I >> think. >> >> >> On 11/12/2020, 13:03, "Benjamin Lerer" <benjamin.le...@datastax.com> >> wrote: >> >> It looks like my question raised more questions than I had in mind. >> >> 1. What is the meaning of the fix version? >> 2. When do we move from beta to RC? >> 3. Where does the Quality tickets fit in all that? >> >> >> *What is the meaning of the fix version?* >> >> It looks like we should just pick a definition and document it. >> >> My preference would be 'The version in which the item must be fixed' >> (e.g >> 4.0-beta if the ticket must be fixed in a beta release). >> >> >> *When do we move from beta to RC?* >> >> The 2 things that I can get from the Release Lifecycle page are: >> >> 1. *No flaky tests - All tests (Unit Tests and DTests) should pass >> consistently.* >> 2.* If there are no known bugs to be fixed before release, we promote >> to >> RC.* >> >> The first point is pretty clear, the second is a bit more vague. The >> main >> reason for that is probably that there is a choice to make here. >> There are >> some bugs that we cannot or chose to not fix in 4.0 (e.g. some LWT >> consistency issues during cluster changes). >> By consequence, I do not know if we can be more precise. We have to >> agree >> on which known bugs we want to fix on the release. Once they are >> fixed and >> we have the tests that pass constantly we should be able to cut an RC >> release. >> >> >> *Where does the Quality tickets fit in all that?* >> >> That is for me the tricky question because the `Quality tickets` are >> really >> about extending the test coverage and we probably did not think about >> that >> type of work when the Release Lifecycle page was written. >> >> We can decide to have (flaky tests + known bugs + increasing test >> coverage) >> in beta and fix the documentation tickets in RC while waiting for >> people to >> raise bugs or have (flaky tests + known bugs) in beta and (increasing >> test >> coverage + documentation tickets) in RC. >> >> I tend to prefer the (flaky tests + know bugs) in beta and >> (increasing test >> coverage + documentation tickets) in RC approach. It reduces the >> scope for >> the beta release and will increase our focus. Hopefully it might help >> us to >> move faster. >> I also hope that an RC release will push more people to test the >> release. >> Increasing our confidence in the stability of 4.0. >> >> What do you think? >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >>
