+1 > On Dec 14, 2020, at 10:03 AM, Benjamin Lerer <benjamin.le...@datastax.com> > wrote: > > 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 >> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
