In this hypothetical, certainly not post-ga, and I'd argue we shouldn't allow it post-beta1 and we need a clear demarcation of "this type of work is ok to merge before X, it's not ok after X. Validation testing *will not occur* before X, and will start after X".
It's a bit rigid, but it's the only way to have a clear inflection point where you know subsequent work won't be invalidated. Otherwise we end up in "I'm pretty sure the validation for disruptive thing X hasn't occurred so I'm going to merge it now" hell. (does what I'm typing here make sense given the context of what you said? Had a little trouble parsing, I think because there's fuzziness around "alpha 1 release" vs. "alpha phase" on how we label things in the project. Maybe) On Wed, May 27, 2020 at 2:05 PM 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 > >
