+1 On Mon, 14 Dec 2020 at 13:43, David Capwell <dcapw...@apple.com.invalid> wrote:
> +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 > >
