On Wed, May 27, 2020 at 1:23 PM Joshua McKenzie <jmcken...@apache.org> wrote:
> Maybe. Do we just time box, say we're going to cut an RC and give it 4 > weeks, if nothing awful surfaces we GA? > I've seen that work well in the past on other projects. I agree with the notion that RCs are real candidates for release if no one finds issues with them. Ideally we would have as little RCs as possible and have more alphas/betas. > > On Wed, May 27, 2020 at 4:12 PM Brandon Williams <dri...@gmail.com> wrote: > > > Absolutely my understanding. > > > > On Wed, May 27, 2020, 2:49 PM Jeremiah D Jordan < > jeremiah.jor...@gmail.com > > > > > wrote: > > > > > > A clear point to cut RC's doesn't surface from the above for me. > > > Releasing > > > > an RC before broad verification seems wrong, and cutting an RC after > > the > > > 4 > > > > points above may as well be GA because it's all known scope. > > > > > > Isn’t the whole point of an RC is that it could be the GA? It is a > > > “release candidate”, meaning if no one finds any issues with it, that > can > > > them become the release? So that seems like exactly the right time to > > make > > > RC releases? > > > > > > > On May 27, 2020, at 2:45 PM, Joshua McKenzie <jmcken...@apache.org> > > > wrote: > > > > > > > > I think we're all on the same page here; I was focusing more on the > > > release > > > > lifecycles and sequencing than the entire version cycle. Good to > > broaden > > > > scope I think. > > > > > > > > One thing we're not considering is the separation of API changes from > > > major > > > > changes and how that intersects with release milestones. > > > > > > > > Meaning: > > > > 1. alpha phase > > > > 2. Milestone: API freeze (all API changes pushed to next major) > > > > 3. beta phase > > > > 4. Verification phase (all major disruptive pushed to next major) > > > > > > > > A clear point to cut RC's doesn't surface from the above for me. > > > Releasing > > > > an RC before broad verification seems wrong, and cutting an RC after > > the > > > 4 > > > > points above may as well be GA because it's all known scope. > > > > > > > > Thoughts? > > > > > > > > On Wed, May 27, 2020 at 3:28 PM Scott Andreas <sc...@paradoxica.net> > > > wrote: > > > > > > > >> That makes sense to me, yep. > > > >> > > > >> My hope and expectation is that the time required for "verification > > > work" > > > >> will shrink dramatically in the not too distant future - ideally to > a > > > >> period of less than a month. In this world, the cost of missing one > > > train > > > >> is reduced to catching the next one. > > > >> > > > >> One of the main goals in shifting focus from "testing" and "test > > plans" > > > to > > > >> "test engineering" is automating as many aspects of release > > > qualification > > > >> as possible, with an asymptotic ideal as a function of compute > > capacity > > > and > > > >> time. While such automation will never be complete (it's likely that > > > >> development of new features will/must include qualification infra > > > changes > > > >> to exercise them), if we're able to apply the same rigor to major > > > releases > > > >> as we are to patchlevel builds with little incremental effort, I'd > be > > > >> thrilled. > > > >> > > > >> This is mostly a way of saying: > > > >> – I like the cadence/sequencing Benedict proposes below. > > > >> – I think improvements in test engineering can reduce/eliminate > > > >> invalidation and may increase the scope of what can be a candidate > for > > > >> merge on a given branch > > > >> – And if not, the cost of missing the train is lower because we'll > be > > > able > > > >> to deliver major releases more often. > > > >> > > > >> Scott > > > >> > > > >> ________________________________________ > > > >> From: Jeremiah D Jordan <jeremiah.jor...@gmail.com> > > > >> Sent: Wednesday, May 27, 2020 11:54 AM > > > >> To: Cassandra DEV > > > >> Subject: Re: [DISCUSS] CASSANDRA-13994 > > > >> > > > >> +1 strongly agree. If we aren’t going to let something go into > 4.0.0 > > > >> because it would "invalidate testing” then we can not let such a > thing > > > go > > > >> into 4.0.1 unless we plan to re-do said testing for the patch > release. > > > >> > > > >>> On May 27, 2020, at 1:31 PM, Benedict Elliott Smith < > > > bened...@apache.org> > > > >> wrote: > > > >>> > > > >>> I'm being told this still isn't clear, so let me try in a > > bullet-point > > > >> timeline: > > > >>> > > > >>> * 4.0 Beta > > > >>> * 4.0 Verification Work > > > >>> * [Merge Window] > > > >>> * 4.0 GA > > > >>> * 4.0 Minor Releases > > > >>> * ... > > > >>> * 5.0 Dev > > > >>> * ... > > > >>> * 5.0 Verification Work > > > >>> * GA 5.0 > > > >>> > > > >>> I think that anything that is prohibited from "[Merge Window]" > > because > > > >> it invalidates "4.0 Verification Work" must also be prohibited until > > > "5.0 > > > >> Dev" because the next equivalent work that can now validate it > occurs > > > only > > > >> at "5.0 Verification Work" > > > >>> > > > >>> On 27/05/2020, 19:05, "Benedict Elliott Smith" < > bened...@apache.org > > > > > > >> wrote: > > > >>> > > > >>> I'm not sure if I communicated my point very well. I mean to say > > > >> that if the reason we are prohibiting a patch to land post-beta is > > > because > > > >> it invalidates work we only perform pre-ga, then it probably should > > not > > > be > > > >> permitted to land post-ga either, since it must also invalidate the > > same > > > >> work? > > > >>> > > > >>> That is to say, if we're comfortable with work landing post-ga > > > >> because we believe it to be safe to release without our > > > pre-major-release > > > >> verification, we should be comfortable with it landing at any time > > > pre-ga > > > >> too. Anything else seems inconsistent to me, and we should examine > > what > > > >> assumptions we're making that permit this inconsistency to arise. > > > >>> > > > >>> > > > >>> On 27/05/2020, 18:49, "Joshua McKenzie" <jmcken...@apache.org> > > > >> wrote: > > > >>> > > > >>>> > > > >>>> because it invalidates our pre-release verification, then it > should > > > not > > > >>>> land > > > >>> > > > >>> until we next perform pre-release verification > > > >>> > > > >>> At least for me there's a little softness around our > collective > > > >> alignment > > > >>> on when pre-release verification takes place. If it's between > > > >> alpha-1 and > > > >>> ga we don't want changes that would invalidate those changes > to > > > >> land during > > > >>> that time frame. Different for beta-1 to ga. We also risk > > > >> invalidating > > > >>> testing if we do any of that testing before wherever that > > cutoff > > > >> is, and a > > > >>> lack of clarity on that cutoff further muddies those waters. > > > >>> > > > >>> My very loosely held perspective is that beta-1 to ga is the > > > >> window in > > > >>> which we apply the "don't do things that will invalidate > > > >> verification", and > > > >>> we plan to do that verification during the beta phase. I > > *think* > > > >> this is > > > >>> consistent w/the current framing of the lifecycle doc. That > > being > > > >> said, I > > > >>> don't have strong religion on this so if we collectively want > > to > > > >> call it > > > >>> "don't majorly disrupt from alpha-1 to ga", we can formalize > > that > > > >> in the > > > >>> docs and go ahead and triage current open scope for 4.0 and > > move > > > >> things out. > > > >>> > > > >>> > > > >>> > > > >>> On Wed, May 27, 2020 at 12:59 PM Ekaterina Dimitrova < > > > >>> ekaterina.dimitr...@datastax.com> wrote: > > > >>> > > > >>>> Thank you all for your input. > > > >>>> I think an important topic is again to revise the lifecycle and > > ensure > > > >> we > > > >>>> really have the vision on what is left until beta. I will start a > > > >> separate > > > >>>> thread on the flaky tests situation soon. > > > >>>> > > > >>>> For this particular ticket I see a couple of things: > > > >>>> - There are a lot of deletions of already not used code > > > >>>> - I implemented it still in alpha as per our agreement that this > > will > > > >> give > > > >>>> us enough time for testing. Probably Dinesh as a reviewer can give > > > some > > > >>>> valuable feedback/opinion on the patch. > > > >>>> - It definitely touches around important places but the important > > > thing > > > >> is > > > >>>> to see how exactly it touches, I think > > > >>>> - Considering it for alpha before the major testing in beta sounds > > > >>>> reasonable to me but I guess it also depends on people > availability > > to > > > >>>> review it in detail and the exact test plans afterwards > > > >>>> > > > >>>> On Wed, 27 May 2020 at 7:14, Benedict Elliott Smith < > > > >> bened...@apache.org> > > > >>>> wrote: > > > >>>> > > > >>>>> I think our "pre-beta" criteria should also be our "not in a > major" > > > >>>>> criteria. > > > >>>>> > > > >>>>> If work is prohibited because it invalidates our pre-release > > > >>>> verification, > > > >>>>> then it should not land until we next perform pre-release > > > verification, > > > >>>>> which only currently happens once per major. > > > >>>>> > > > >>>>> This could mean either landing less in a major, or permitting > more > > in > > > >>>> beta > > > >>>>> etc. > > > >>>>> > > > >>>>> On 26/05/2020, 19:24, "Joshua McKenzie" <jmcken...@apache.org> > > > wrote: > > > >>>>> > > > >>>>> I think an interesting question that informs when to stop > > accepting > > > >>>>> specific changes in a release is when we expect any extensive > > > >>>>> pre-release > > > >>>>> testing to take place. > > > >>>>> > > > >>>>> If we go by our release lifecycle, gutting deprecated code > seems > > > >>>>> compatible > > > >>>>> w/Alpha but I wouldn't endorse merging it into Beta: > > > >>>>> > > > >>>>> > > > >> > > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > > > . > > > >>>>> Since almost all of the 40_quality_testing epic stuff is also > > beta > > > >>>>> phase > > > >>>>> and hasn't really taken off yet, it also seems like there will > be > > > >>>>> extensive > > > >>>>> testing after this phase transition. > > > >>>>> > > > >>>>> All that being said, I'd advocate for marking FixVer 4.x to > > > indicate > > > >>>>> optionality and disallow merge of tickets like this after we're > > > done > > > >>>>> w/alpha phase in keeping w/our lifecycle doc in general. > > > >>>>> > > > >>>>> Does that make sense? Should we consider revisiting and > revising > > > the > > > >>>>> lifecycle doc re: larger deprecation / changes and cycle > stages? > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Tue, May 26, 2020 at 12:53 PM Oleksandr Petrov < > > > >>>>> oleksandr.pet...@gmail.com> wrote: > > > >>>>> > > > >>>>>>> 1) Would you block the release over this ticket? > > > >>>>>> > > > >>>>>> I would definitely not block the release on this ticket. > > > >>>>>> > > > >>>>>>> 2) Would you prioritize this ticket over testing? > > > >>>>>> > > > >>>>>> Same here, I would prioritise testing. > > > >>>>>> > > > >>>>>>> 3) Does fixing this ticket make 4.0 a more stable release? > > > >>>>>> > > > >>>>>> I wanted to give some context: I wrote that in August 2018. > While > > I > > > >>>>> still > > > >>>>>> believe it is important to get rid of this code, I'm disinclined > > to > > > >>>>> merge > > > >>>>>> it into 4.0. > > > >>>>>> > > > >>>>>> Given that the patch is rather big (421 additions and 1,480 > > > >>>>> deletions) and > > > >>>>>> touches many important places, including parser, I would be > > > >>>> extremely > > > >>>>>> cautious to merge it that late in release cycle. It would be > great > > > >>>>> to also > > > >>>>>> hear arguments that would justify the risk. > > > >>>>>> > > > >>>>>> Thank you for starting this discussion, > > > >>>>>> -- Alex > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On Tue, May 26, 2020 at 5:20 PM Ekaterina Dimitrova < > > > >>>>>> ekaterina.dimitr...@datastax.com> wrote: > > > >>>>>> > > > >>>>>>> Dear all, > > > >>>>>>> > > > >>>>>>> Following the ticket review sent on 12th May I wanted to bring > up > > > >>>>>>> https://issues.apache.org/jira/browse/CASSANDRA-13994: Remove > > > >>>>> COMPACT > > > >>>>>>> > > > >>>>>>> STORAGE internals before 4.0 release. > > > >>>>>>> > > > >>>>>>> It is already under review by Dinesh Joshi and Alex Petrov. > Not a > > > >>>>>>> blocker but already under review. > > > >>>>>>> > > > >>>>>>> Below are my responses to the questions brought up. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> 1) Would you block the release over this > > > >>>>>>> > > > >>>>>>> ticket? - probably not > > > >>>>>>> > > > >>>>>>> 2) Would you prioritize this ticket over testing? - already > > > >>>>>>> implemented but if there are some big changes needed after the > > > >>>>> review, > > > >>>>>>> I doubt it we will want to prioritize over the testing > > > >>>>>>> > > > >>>>>>> 3) Does fixing > > > >>>>>>> this ticket make 4.0 a more stable release? - I will just cite > > > >>>> Alex > > > >>>>>>> Petrov who reported this Jira and I think the rest of us would > > > >>>>> agree > > > >>>>>>> with him here. > > > >>>>>>> > > > >>>>>>> "I would say it's quite important to clean up compact storage > > > >>>>>>> internals in 4.0 before the release. It should have no visible > > > >>>>>>> side-effects, but it'd be very good to have as it simplifies > > > >>>>> multiple > > > >>>>>>> code paths." > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Ekaterina Dimitrova > > > >>>>>>> e. ekaterina.dimitr...@datastax.com > > > >>>>>>> w. www.datastax.com > > > >>>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> -- > > > >>>>>> alex p > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > --------------------------------------------------------------------- > > > >>>>> 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 > > > >>> > > > >> > > > >> > > > >> > --------------------------------------------------------------------- > > > >> 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 > > > > > > > > >
