Thank you for the feedback. I propose to: - update the documentation to clarify the meaning of the fix version as 'The version in which the item must be fixed' (e.g 4.0-beta if the ticket must be fixed in a beta release) - create a 4.0-GA fix version and use it for the Quality testing tickets - Start a discussion beginning of January to discuss the scope of those tickets
If you disagree on any of the points do not hesitate to raise your concerns On Sat, Dec 12, 2020 at 12:23 AM Benedict Elliott Smith <bened...@apache.org> wrote: > Yes, I meant of those tickets we agreed at ApacheCon a year ago, blocking > at most GA seems reasonable - roughly in accordance with what Benjamin was > saying. Not that the entire codebase should be brought up to our preferred > standards before any new releases are cut. I'm also not opposed to some > modification of scope of those tasks, if we anticipate release dragging on > too much longer. > > > On 11/12/2020, 17:07, "Benjamin Lerer" <benjamin.le...@datastax.com> > wrote: > > > > > 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 > > >> > > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
