You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Benjamin Lerer <be...@datastax.com> on 2020/12/09 12:10:46 UTC
Which fix version should be used for the Quality Testing tickets
Hi everybody,
Looking at the Dashboard, it seems that the *Quality Testing* tickets are
spread between the Beta and RC releases.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&quickFilter=1661
I assumed that those tickets were part of the Beta release but I might have
misunderstood things.
Do we want them fixed before we release 4.0-RC or are they part of the
testing of the RC release?
Re: Which fix version should be used for the Quality Testing tickets
Posted by Michael Semb Wever <mc...@apache.org>.
Done. Thanks!
On 2020/12/17 10:57:35, Benjamin Lerer <be...@datastax.com> wrote:
> Thanks Mick for raising that problem. Effectively, I got confused along the
> way.
>
> +1
>
> On Thu, Dec 17, 2020 at 11:56 AM Sam Tunnicliffe <sa...@beobal.com> wrote:
>
> >
> >
> > > On 17 Dec 2020, at 10:54, Michael Semb Wever <mc...@apache.org> wrote:
> > >
> > >
> > >> 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
> > >
> > >
> > > Even though we have gone ahead and created the `4.0-GA` label, and have
> > already moved the Quality testing tickets to it, I do think we have made a
> > small mistake here…
> > >
> > > What would the difference between `4.0-rc` and `4.0-GA` be?
> > >
> > > If `4.0-beta` is a "Placeholder for blockers to 4.0-rc1",
> > > then `4.0-rc` would be a "Placeholder for blockers to 4.0.0",
> > > so then what is `4.0-GA` ?
> > >
> > > This was half-documented in the fixVersion descriptions here
> > >
> > https://issues.apache.org/jira/projects/CASSANDRA?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> > > (`4.0-rc` did fail to have any useful description).
> > >
> > > Can I suggest we move all `4.0-GA` to `4.0-rc`, and delete `4.0-GA` ?
> > >
> >
> > +1
> >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
Posted by Benjamin Lerer <be...@datastax.com>.
Thanks Mick for raising that problem. Effectively, I got confused along the
way.
+1
On Thu, Dec 17, 2020 at 11:56 AM Sam Tunnicliffe <sa...@beobal.com> wrote:
>
>
> > On 17 Dec 2020, at 10:54, Michael Semb Wever <mc...@apache.org> wrote:
> >
> >
> >> 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
> >
> >
> > Even though we have gone ahead and created the `4.0-GA` label, and have
> already moved the Quality testing tickets to it, I do think we have made a
> small mistake here…
> >
> > What would the difference between `4.0-rc` and `4.0-GA` be?
> >
> > If `4.0-beta` is a "Placeholder for blockers to 4.0-rc1",
> > then `4.0-rc` would be a "Placeholder for blockers to 4.0.0",
> > so then what is `4.0-GA` ?
> >
> > This was half-documented in the fixVersion descriptions here
> >
> https://issues.apache.org/jira/projects/CASSANDRA?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> > (`4.0-rc` did fail to have any useful description).
> >
> > Can I suggest we move all `4.0-GA` to `4.0-rc`, and delete `4.0-GA` ?
> >
>
> +1
>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Which fix version should be used for the Quality Testing tickets
Posted by Sam Tunnicliffe <sa...@beobal.com>.
> On 17 Dec 2020, at 10:54, Michael Semb Wever <mc...@apache.org> wrote:
>
>
>> 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
>
>
> Even though we have gone ahead and created the `4.0-GA` label, and have already moved the Quality testing tickets to it, I do think we have made a small mistake here…
>
> What would the difference between `4.0-rc` and `4.0-GA` be?
>
> If `4.0-beta` is a "Placeholder for blockers to 4.0-rc1",
> then `4.0-rc` would be a "Placeholder for blockers to 4.0.0",
> so then what is `4.0-GA` ?
>
> This was half-documented in the fixVersion descriptions here
> https://issues.apache.org/jira/projects/CASSANDRA?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> (`4.0-rc` did fail to have any useful description).
>
> Can I suggest we move all `4.0-GA` to `4.0-rc`, and delete `4.0-GA` ?
>
+1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
Posted by Michael Semb Wever <mc...@apache.org>.
> 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
Even though we have gone ahead and created the `4.0-GA` label, and have already moved the Quality testing tickets to it, I do think we have made a small mistake here…
What would the difference between `4.0-rc` and `4.0-GA` be?
If `4.0-beta` is a "Placeholder for blockers to 4.0-rc1",
then `4.0-rc` would be a "Placeholder for blockers to 4.0.0",
so then what is `4.0-GA` ?
This was half-documented in the fixVersion descriptions here
https://issues.apache.org/jira/projects/CASSANDRA?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
(`4.0-rc` did fail to have any useful description).
Can I suggest we move all `4.0-GA` to `4.0-rc`, and delete `4.0-GA` ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
Posted by Ekaterina Dimitrova <e....@gmail.com>.
+1
On Mon, 14 Dec 2020 at 13:43, David Capwell <dc...@apple.com.invalid>
wrote:
> +1
>
> > On Dec 14, 2020, at 10:03 AM, Benjamin Lerer <
> benjamin.lerer@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 <
> benedict@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" <be...@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 <
> jmckenzie@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 <
> >> jmckenzie@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 <
> >>>> benedict@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.lerer@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-unsubscribe@cassandra.apache.org
> >>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Which fix version should be used for the Quality Testing tickets
Posted by David Capwell <dc...@apple.com.INVALID>.
+1
> On Dec 14, 2020, at 10:03 AM, Benjamin Lerer <be...@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 <be...@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" <be...@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 <jm...@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 <
>> jmckenzie@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 <
>>>> benedict@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.lerer@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-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
Posted by Benjamin Lerer <be...@datastax.com>.
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 <be...@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" <be...@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 <jm...@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 <
> jmckenzie@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 <
> > > benedict@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.lerer@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-unsubscribe@cassandra.apache.org
> > >> For additional commands, e-mail: dev-help@cassandra.apache.org
> > >>
> > >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Which fix version should be used for the Quality Testing tickets
Posted by Benedict Elliott Smith <be...@apache.org>.
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" <be...@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 <jm...@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 <jm...@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 <
> > benedict@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" <be...@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-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
Posted by Benjamin Lerer <be...@datastax.com>.
>
> 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 <jm...@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 <jm...@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 <
> > benedict@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" <be...@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-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
>
Re: Which fix version should be used for the Quality Testing tickets
Posted by Joshua McKenzie <jm...@apache.org>.
>
> - 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 <jm...@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 <
> benedict@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" <be...@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-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
Re: Which fix version should be used for the Quality Testing tickets
Posted by Joshua McKenzie <jm...@apache.org>.
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 <be...@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" <be...@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Which fix version should be used for the Quality Testing tickets
Posted by Benedict Elliott Smith <be...@apache.org>.
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" <be...@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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Which fix version should be used for the Quality Testing tickets
Posted by Benjamin Lerer <be...@datastax.com>.
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?
Re: Which fix version should be used for the Quality Testing tickets
Posted by Mick Semb Wever <mc...@apache.org>.
> I have thought that the fix version is the version which the item will be…
fixed in… Others want the fix version to be the version which must not
start until the ticket is closed…
David, my understanding of it doesn't quite fit into this…
Issues with a fixVersion of 4.0-beta indicate they are a blocker to the
first RC release.
Issues with a fixVersion of 4.0-rc indicate they are a blocker to the GA
release.
Issues with a fixVersion of 4.0.x indicate they are not blocking GA, but
should be fixed in some subsequent patch version.
At the same time, of course no one is preventing 4.0-rc and 4.0.x issues
from going into a 4.0-betaX release.
https://lists.apache.org/thread.html/r734c071b9f921f9e07455d4fe2262703c8f4daeddd9065a28a4cc4ed%40%3Cdev.cassandra.apache.org%3E
> If there are no known bugs to be fixed before release, we promote to RC.
It would be really helpful to elaborate on this, because there are always
known bugs in every system. And if we are then to say "blocking bugs" what
do we then mean by that? There are plenty of bugs that can be assigned
fixVersion 4.0.x
And this thinking extends to the testing epics too. There's this fuzzy line
of knowing when those epics have done enough to discover those blocking
bugs, or shall we continue with the testing epics forever to find the
non-blocking bugs…
Re: Which fix version should be used for the Quality Testing tickets
Posted by Joshua McKenzie <jm...@apache.org>.
I read the release lifecycle a little differently when it comes to the
quality tickets; I don't think it really speaks to those (areas without
known defects but with known skepticism about their stability). If we find
the text to be unclear or not address them we should definitely revise.
Here's what I take away from it (relevant excerpts):
Beta:
- During this phase:
-- If there are no known bugs to be fixed before release, we promote to RC.
RC:
- Definition / Expectations:
-- A release candidate build is legitimately a release candidate. The final
release will be built from the same SHA as the final release candidate.
- During this phase:
-- If no release-blocking issues are identified within a brief incubation
period, release is promoted to GA.
-- The intent of this period is to allow for the user community to fully
exercise the release and flag potential release-blocking issues.
-- If bugs are found, fixes are made and above step is repeated.
It seems our options, specifically w/regards to the "we believe we need to
test system X more" style tickets, are:
1. We should agree to block rc 1 on them being done and update the rel
lifecycle text
2. We let things go to RC but block GA on them and update the rel lifecycle
text
3. We put them in a special ongoing "best effort" bucket of "things we're
working on and will continue to work on during beta, rc, and after GA"
Not sure the right way to proceed. The testing is certainly turning up
things that need fixing, but it's also a different category afaict of
"areas we expect to find defects if we take the time to look closer".
On Wed, Dec 9, 2020 at 2:27 PM David Capwell <dc...@gmail.com> wrote:
> Thanks for bringing this up, this is a major form of confusion right now.
>
> I have thought that the fix version is the version which the item will be…
> fixed in… Others want the fix version to be the version which must not
> start until the ticket is closed… Both of these opinions are not documented
> and rely on 1-to-1 conversations… Let's fix this!
>
> Now, for the quality tickets, my understanding is we can not cut a RC
> release until they are complete, so I “feel” they should be marked beta
> (which is called out in
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle as
> Beta is the version under test [1][2]), though I know others feel they
> should be RC (as we can not cut a RC release until it is complete); which
> ever stance we take, I hope we document it!
>
> 1 - Beta calls out "This release is recommended for test", and the quality
> tickets are to write and test
> 2 - RC calls out "If no release-blocking issues are identified within a
> brief incubation period, release is promoted to GA", so if a quality ticket
> takes (lets say) 1 month to work on and finds a correctness issue, this may
> be too late as this could be interpreted as larger than the "brief
> incubation period", so RC may have been promoted to GA already.
>
> On Wed, Dec 9, 2020 at 7:48 AM Michael Semb Wever <mc...@apache.org> wrote:
>
> >
> > > Do we want them fixed before we release 4.0-RC or are they part of the
> > > testing of the RC release?
> >
> >
> > We are so unbearably close, it would be nice to see the beta tickets
> > narrowed (again) to just the most critical issues.
> >
> > Tickets about creating new tests, and bugs edge-case, or not severe or
> > have an easy-enough workaround, don't need to block a RC release IMHO.
> Just
> > like they don't block a patch release when there's other stuff that's
> > important to roll out. The testing epics tickets too i would think can
> > continue to roll on during RC.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: Which fix version should be used for the Quality Testing tickets
Posted by David Capwell <dc...@gmail.com>.
Thanks for bringing this up, this is a major form of confusion right now.
I have thought that the fix version is the version which the item will be…
fixed in… Others want the fix version to be the version which must not
start until the ticket is closed… Both of these opinions are not documented
and rely on 1-to-1 conversations… Let's fix this!
Now, for the quality tickets, my understanding is we can not cut a RC
release until they are complete, so I “feel” they should be marked beta
(which is called out in
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle as
Beta is the version under test [1][2]), though I know others feel they
should be RC (as we can not cut a RC release until it is complete); which
ever stance we take, I hope we document it!
1 - Beta calls out "This release is recommended for test", and the quality
tickets are to write and test
2 - RC calls out "If no release-blocking issues are identified within a
brief incubation period, release is promoted to GA", so if a quality ticket
takes (lets say) 1 month to work on and finds a correctness issue, this may
be too late as this could be interpreted as larger than the "brief
incubation period", so RC may have been promoted to GA already.
On Wed, Dec 9, 2020 at 7:48 AM Michael Semb Wever <mc...@apache.org> wrote:
>
> > Do we want them fixed before we release 4.0-RC or are they part of the
> > testing of the RC release?
>
>
> We are so unbearably close, it would be nice to see the beta tickets
> narrowed (again) to just the most critical issues.
>
> Tickets about creating new tests, and bugs edge-case, or not severe or
> have an easy-enough workaround, don't need to block a RC release IMHO. Just
> like they don't block a patch release when there's other stuff that's
> important to roll out. The testing epics tickets too i would think can
> continue to roll on during RC.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Which fix version should be used for the Quality Testing tickets
Posted by Michael Semb Wever <mc...@apache.org>.
> Do we want them fixed before we release 4.0-RC or are they part of the
> testing of the RC release?
We are so unbearably close, it would be nice to see the beta tickets narrowed (again) to just the most critical issues.
Tickets about creating new tests, and bugs edge-case, or not severe or have an easy-enough workaround, don't need to block a RC release IMHO. Just like they don't block a patch release when there's other stuff that's important to roll out. The testing epics tickets too i would think can continue to roll on during RC.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org