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 > > > > > > > > > > > > > >
