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
