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 > >
