Re: Which fix version should be used for the Quality Testing tickets
> 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
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 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 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-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: Which fix version should be used for the Quality Testing tickets
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 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-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Which fix version should be used for the Quality Testing tickets
> 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
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=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: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x
> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti > wrote: > > +1 to moving v5-beta changes in trunk to new protocol v6. > > Regarding 3.11 and v5, I suppose we could say, v5 could never get matured > beyond beta, but not sure if it would be confusing to see v6 while v5 is > still in beta (curious on others' thoughts as well) > > On Tue, Dec 8, 2020 at 12:33 PM Mick Semb Wever wrote: > >>> …move to v6 for the new protocol to avoid this issue >> >> >> +1, feels more the "grown-up thing to do". >> >> Perhaps we should skip v5… >>> We could finalise v5 as it was prior to the new framing format, then >> create v6-beta in trunk only with the 15299 changes. >> >> >> Would v5 come out of beta then in 3.11?, or would it stay as beta forever, >> with the focus on maturing v6 in 4.0+? >> Technically, it *could* come out of beta in 4.0, but stay as it is in 3.11. That is, the v5 protocol itself would be identical in both C* versions, but there would be some considerations on the client side. Namely, if connecting to a cluster with any 3.11 nodes, clients would need to set the beta flag in CQL frame (meaning a frame in v5 terms). Any 4.0 nodes in the cluster would simply ignore the flag, as it wouldn't be required for v5 connections. So the most straightforward path would be probably to promote v5 out of beta in the next 3.11 and 4.0-beta releases. Clients would just need to ensure that they stay on a *current* driver (i.e. one which sets that flag for v5) until after upgrading clusters to either the latest 3.11 or 4.0-beta releases. I have patches for C*, java and python drivers ready, so I'll file a JIRA and open some PRs. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
