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
