> > 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.
I do not think that anybody wants to delay 4.0 more than needed. Now, nothing prevents us from having another discussion about the scope of what is reasonable to tackle in 4.0. I can start that discussion beginning of January if people feel the need for it. On Fri, Dec 11, 2020 at 5:05 PM Joshua McKenzie <jmcken...@apache.org> wrote: > > > > - 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 > >> > >> >
