> Caleb, you appear to be the only one objecting, and it does not appear that you have made any compromises in this thread.
All I'm really objecting to is making special exceptions for particular CEPs in relation to our freeze date. In other words, let's not have a pseudo-freeze date and a "real" freeze date, when the thing that makes the latter supposedly necessary is a very invasive change to the database that risks our desired GA date. Also, again, I don't understand how cutting a 5.0 branch makes anything substantially easier to start testing. Perhaps I'm the only one who thinks this. If so, I'm not going to make further noise about it. On Tue, Apr 18, 2023 at 7:26 AM Henrik Ingo <henrik.i...@datastax.com> wrote: > I forgot one last night: > > From Benjamin we have a question that I think went unanswered? > > *> Should it not facilitate the work if the branch stops changing heavily?* > > This is IMO a good perspective. To me it seems weird to be too hung up on > a "hard limit" on a specific day, when we are talking about merges where a > single merge / rebase takes more than one day. We will have to stop merging > smaller work to trunk anyway, when CEP-21 is being merged. No? > > henrik > > On Tue, Apr 18, 2023 at 3:24 AM Henrik Ingo <henrik.i...@datastax.com> > wrote: > >> Trying to collect a few loose ends from across this thread >> >> *> I'm receptive to another definition of "stabilize", * >> >> I think the stabilization period implies more than just CI, which is >> mostly a function of unit tests working correctly. For example, at Datastax >> we have run a "large scale" test with >100 nodes, over several weeks, both >> for 4.0 and 4.1. For obvious reasons such tests can't run in nightly CI >> builds. >> >> Also it is not unusual that during the testing phase developers or >> specialized QA engineers can develop new tests (which are possibly added to >> CI) to improve coverage for and especially targeting new features in the >> release. For example the fixes to Paxos v2 were found by such work before >> 4.1. >> >> Finally, maybe it's a special case relevant only for this release, but >> as a significant part of the Datastax team has been focused on porting >> these large existing features from DSE, and to get them merged before the >> original May date, we also have tens of bug fixes waiting to be upstreamed >> too. (It used to be an even 100, but I'm unsure what the count is today.) >> >> In fact! If you are worried about how to occupy yourself between a May >> "soft freeze" and September'ish hard freeze, you are welcome to chug on >> that backlog. The bug fixes are already public and ASL licensed, in the 4.0 >> based branch here >> <https://github.com/datastax/cassandra/commits/ds-trunk>. >> Failed with an unknown error. >> >> *> 3a. If we allow merge of CEP-15 / CEP-21 after branch, we risk >> invalidating stabilization and risk our 2023 GA date* >> >> I think this is the assumption that I personally disagree with. If this >> is true, why do we even bother running any CI before the CEP-21 merge? It >> will all be invalidated anyway, right? >> >> In my experience, it is beneficial to test as early as possible, and at >> different checkpoints during development. If we wouldn't do it, and we >> find some issue in late November, then the window to search for the commit >> that introduced the regression is all the way back to the 4.1 GA. If on the >> other hand the same test was already rune during the soft freeze, then we >> can know that we may focus our search onto CEP-15 and CEP-21. >> >> >> *> get comfortable with cutting feature previews or snapshot alphas like >> we agreed to for earlier access to new stuff* >> >> Snapshots are in fact a valid compromise proposal: A snapshot would >> provide a constant version / point in time to focus testing on, but on the >> other hand would allow trunk (or the 5.0 branch, in other proposals) to >> remain open to new commits. Somewhat "invalidating" the testing work, but >> presumably the branch will be relatively calm anyway. Which leads me to 2 >> important questions: >> >> *WHO would be actively merging things into 5.0 during June-August? * >> >> By my count at that point I expect most contributors to either furiously >> work on Acccord and TCM, or work on stabilization (tests, fixes). >> >> Also, if someone did contribute new feature code during this time, they >> might find it hard to get priority for reviews, if others are focused on >> the above tasks. >> >> Finally, I expect most Europeans to be on vacation 33% of that time. >> Non-Europeans may want to try it too! >> >> >> *WHAT do we expect to get merged during June-August?* >> >> Compared to the tens of thousands of lines of code being merged by >> Accord, SAI, UCS and Tries... I imagine even the worst case during a >> non-freeze in June-August would be just a tiny percentage of the large CEPs. >> >> In this thread I only see Paulo announcing an intent to commit against >> trunk during a soft freeze, and even he agrees with a 5.0 branch freeze. >> >> This last question is basically a form of saying I hope we aren't >> discussing a problem that doesn't even exist? >> >> henrik >> >> -- >> >> Henrik Ingo >> >> c. +358 40 569 7354 >> >> w. www.datastax.com >> >> <https://www.facebook.com/datastax> <https://twitter.com/datastax> >> <https://www.linkedin.com/company/datastax/> >> <https://github.com/datastax/> >> >> > > -- > > Henrik Ingo > > c. +358 40 569 7354 > > w. www.datastax.com > > <https://www.facebook.com/datastax> <https://twitter.com/datastax> > <https://www.linkedin.com/company/datastax/> > <https://github.com/datastax/> > >
