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