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 <dcapw...@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 <m...@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-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
