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 >
