It was moved to alpha following the lifecycle document and the latest discussion on the ML. Sylvain made a review yesterday. To me the biggest question is about the indexing. (Posted questions on the ticket itself, waiting for opinion and agreement) For the rest of the ticket I support Sylvain that it is primarily removal of dead code.
My understanding is either it lands in alpha before the big testing in beta or it is delayed for v.5 Ekaterina On Wed, 10 Jun 2020 at 12:59, Joshua McKenzie <jmcken...@apache.org> wrote: > Where did we land on inclusion of this ticket in 4.0? Since it's now > flagged as blocking beta rel, I am now very interested in this question. > > :) > > > On Wed, May 27, 2020 at 7:52 PM Jordan West <jorda...@gmail.com> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > >
