> I’m not sure we need any additional mechanisms beyond DISCUSS threads, polls > and lazy consensus? > ... > This likely means at least another DISCUSS thread and lazy consensus if you > want to knowingly go against it, or want to modify or clarify what’s meant. > ... > It can be chucked out or rewoven at zero cost, but if the norms have taken > hold and are broadly understood in the same way, it won’t change much or at > all, because the actual glue is the norm, not the words, which only serve to > broadcast some formulation of the norm. 100% agree on all counts. Hopefully this discussion is useful for other folks as well.
So - with the clarification that our agreement on green CI represents a polled majority consensus of the folks participating on the discussion at the time but not some kind of hard unbendable obligation, is this something we want to consider relaxing for TCM and Accord? This thread ran long (and got detoured - mea culpa) - the tradeoffs seem like: 1. We merge them without green CI and cut a cassandra-5.1 branch so we can release an alpha-1 snapshot from that branch. This likely leaves cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord devs can be expected to be pulled into fixing core issues / finalizing the features and the burden for test stabilization "leaking out" across others in the community who don't have context on their breakage (see: CASSANDRA-8099, cassandra-4.0 release, cassandra-4.1 release, now push for cassandra-5.0 QA stabilization). 2. Push for green CI on Accord / TCM before merge and alpha availability, almost certainly delaying their availability to the community. 3. Cut a preview / snapshot release from the accord feature branch, made available to the dev community. We could automate creation / update of docker images with snapshot releases of all HEAD for trunk and feature branches. 4. Some other approach I'm not thinking of / missed So as Mick asked earlier in the thread: > Is anyone up for looking into adding a "preview" qualifier to our release > process? I'm in favor of this. If we cut preview snapshots from trunk and all feature branches periodically (nightly? weekly?), preferably as docker images, this satisfies the desire to get these features into the hands of the dev and user community to test them out and provide feedback to the dev process while also allowing us to keep a high bar for merge to trunk. Referencing the ASF Release Policy: https://www.apache.org/legal/release-policy.html#release-definition, this is consistent with the guidance: > During the process of developing software and preparing a release, various > packages are made available to the development community for testing > purposes. Projects MUST direct outsiders towards official releases rather > than raw source repositories, nightly builds, snapshots, release candidates, > or any other similar packages. Projects SHOULD make available developer > resources to support individuals actively participating in development or > following the dev list and thus aware of the conditions placed on unreleased > materials. We direct people to the official downloads on the website and add a section below that references the latest snapshot releases for CEP-approved feature branch work in progress + trunk. > Generically, a release is anything that is published beyond the group that > owns it. For an Apache project, that means any publication outside the > development community, defined as individuals actively participating in > development or following the dev list. I think so long as we're clear about them being preview / snapshot releases of in-development work where we're looking for feedback on the dev process, as well as clearly directing people to the dev ML and #cassandra-dev on slack, this would be a pretty big win for the project. So - that's my bid. What do others think? On Wed, Nov 1, 2023, at 8:11 PM, Benedict wrote: > > So my view is that the community is strongly built on consensus, so > expressions of sentiment within the community have strong normative weight > even without any specific legislative effect. You shouldn’t knowingly go > against what appears to be a consensus (or even widely-held) view, even if it > has no formal weight. So I’m not sure we need any additional mechanisms > beyond DISCUSS threads, polls and lazy consensus? > > Let’s treat your thread as a POLL for arguments sake: lots of folk voted, and > every vote was positive. So clearly there’s strong endorsement for the > approach, or parts thereof, in some form. Given the goal of consensus in > decision-making, it would not be reasonable to ignore this widely held view > on contributions. This likely means at least another DISCUSS thread and lazy > consensus if you want to knowingly go against it, or want to modify or > clarify what’s meant. This just falls naturally out of how we do things here > I think, and is how we go about a lot of business already. It retains the > agility you were talking about, setting norms cheaply. > > It isn’t however a tightly held policy or legislative cudgel, it’s just what > those who were talking and paying attention at the time agreed. It can be > chucked out or rewoven at zero cost, but if the norms have taken hold and are > broadly understood in the same way, it won’t change much or at all, because > the actual glue is the norm, not the words, which only serve to broadcast > some formulation of the norm. > > > >> On 1 Nov 2023, at 23:41, Josh McKenzie <jmcken...@apache.org> wrote: >> >>> but binding to the same extent 2 committers reviewing something we later >>> need to revert is binding. >> To elaborate a bit - what I mean is "it's a bar we apply to help establish a >> baseline level of consensus but it's very much a 2-way door". Obviously 2 >> committers +1'ing code is a formal agreed upon voting mechanism. >> >> On Wed, Nov 1, 2023, at 7:26 PM, Josh McKenzie wrote: >>>> Community voting is also entirely by consensus, there is no such thing as >>>> a simple majority community vote, technical or otherwise. >>> Ah hah! You're absolutely correct in that this isn't one of our "blessed" >>> ways we vote. There's nothing written down about "committers are binding, >>> simple majority" for any specific category of discussion. >>> >>> Are we ok with people creatively applying different ways to vote for things >>> where there's not otherwise guidance if they feel it helps capture >>> sentiment and engagement? Obviously the outcome of that isn't binding in >>> the same way other votes by the pmc are, but binding to the same extent 2 >>> committers reviewing something we later need to revert is binding. >>> >>> I'd rather we have a bunch of committers weigh in if we're talking about >>> changing import ordering, or Config.java structure, or refactoring out >>> singletons, or gatekeeping CI - things we've had come up over the years >>> where we've had a lot of people chime in and we benefit from more than just >>> "2 committers agree on it" but less than "We need a CEP or pmc vote for >>> this". >>> >>> >>> On Wed, Nov 1, 2023, at 5:10 PM, Benedict wrote: >>>> >>>> The project governance document does not list any kind of general purpose >>>> technical change vote. There are only three very specific kinds of >>>> community vote: code contributions, CEP and release votes. Community >>>> voting is also entirely by consensus, there is no such thing as a simple >>>> majority community vote, technical or otherwise. I suggest carefully >>>> re-reading the document we both formulated! >>>> >>>> If it is a technical contribution, as you contest, we only need a normal >>>> technical contribution vote to override it - i.e. two committer +1s. If >>>> that’s how we want to roll with it, I guess we’re not really in >>>> disagreement. >>>> >>>> None of this really fundamentally changes anything. There’s a strong norm >>>> for a commit gate on CI, and nobody is going to go about breaking this >>>> norm willy-nilly. But equally there’s no need to panic and waste all this >>>> time debating hypothetical mechanisms to avoid this supposedly ironclad >>>> rule. >>>> >>>> We clearly need to address confusion over governance though. The idea that >>>> agreeing things carefully costs us agility is one I cannot endorse. The >>>> project has leaned heavily into the consensus side of the Apache Way, as >>>> evidenced by our governance document. That doesn’t mean things can’t >>>> change quickly, it just means *before those changes become formal >>>> requirements *there needs to be *broad* consensus, as defined in the >>>> governing document. That’s it. >>>> >>>> The norm existed before the vote, and it exists whether the vote was valid >>>> or not. That is how things evolve on the project, we just formalise them a >>>> little more slowly. >>>> >>>> >>>>> On 1 Nov 2023, at 20:07, Josh McKenzie <jmcken...@apache.org> wrote: >>>>> >>>>> First off, I appreciate your time and attention on this stuff. Want to be >>>>> up front about that since these kinds of discussions can get prickly all >>>>> too easily. I'm *at least* as guilty as anyone else about getting my back >>>>> up on stuff like this. Figuring out the right things to "harden" as >>>>> shared contractual ways we behave and what to leave loose and >>>>> case-by-case is going to continue to be a challenge for us as we grow. >>>>> >>>>> The last thing I personally want is for us to have too many extraneous >>>>> rules formalizing things that just serve to slow down peoples' ability to >>>>> contribute to the project. The flip side of that - for all of us to work >>>>> in a shared space and collectively remain maximally productive, some >>>>> individual freedoms (ability to merge a bunch of broken code and/or ninja >>>>> in things as we see fit, needing 2 committers' eyes on things, etc) will >>>>> have to be given up. >>>>> >>>>> At it's core the discussion we had was prompted by divergence between >>>>> circle and ASF CI and our release process dragging on repeatedly during >>>>> the "stabilize ASF CI" phase. The "do we require green ci before merge of >>>>> tickets" seems like it came along as an intuitive rider; best I can >>>>> recall my thinking was "how else could we have a manageable load to >>>>> stabilize in ASF CI if we didn't even require green circle before merging >>>>> things in", but we didn't really dig into details; from a re-reading now, >>>>> that portion of the discussion was just taken for granted as us being in >>>>> alignment. Given it was a codifying a norm and everyone else in the >>>>> discussion generally agreed, I don't think I or anyone thought to >>>>> question it. >>>>> >>>>> >>>>>> “Votes on project structure *and governance”*. Governance, per >>>>>> Wikipedia, is "the way rules, norms and actions are structured and >>>>>> sustained.” >>>>>> >>>>> Bluntly, I'm not that worried about what wikipedia or a dictionary says >>>>> about the topic. What I'm worried about here is what *we collectively as >>>>> a community* think of as governance. "Do we have green CI pre-merge or >>>>> not", *to me personally*, didn't qualify as a governance issue but rather >>>>> a technical change. I'm open to being convinced otherwise, that things >>>>> like that should qualify for a higher bar of voting, but again, I'm leery >>>>> of that slowing down other workflow optimizations, changes, or >>>>> community-wide impacting improvements people are making. Or muddying the >>>>> waters to where people aren't sure what does or doesn't qualify as >>>>> governance so they end up not pursuing things they're interested in >>>>> improving as they're off-put by the bureaucratic burden of getting >>>>> supermajority buy-in from pmc members who are much harder to get to >>>>> participate in discussions on the ML compared to showing up for >>>>> roll-call. :innocent: >>>>> >>>>> My understanding of "The Apache Way" is that to move at speed and at >>>>> scale, we need to trust each other to do the right thing and know we can >>>>> back out if things go awry. So if some folks talk through mutating config >>>>> through virtual tables for instance, or folks working on TCM put things >>>>> up for review and I don't have cycles, I trust the folks doing that work >>>>> (the committers working on it or review it) that I personally just stay >>>>> out of it knowing that if things need refining going forward we'll do so. >>>>> Different things have a different cost to refine and/or back out, sure, >>>>> but in this case it's discussions + wiki articles. Not too painful. >>>>> >>>>> So in this case here - is there a formal counter to that side of the >>>>> discussion you'd want to open now? i.e. the case for merging bodies of >>>>> work without green CI, when we do that, how we do that, why we do that? >>>>> We very well could have missed a very meaningful and useful scenario that >>>>> would have changed the collective conversation since nobody brought it up >>>>> at the time. We simple majority committer voted in; we can simple >>>>> majority committer vote out if we think this is too constricting a policy >>>>> or if we want to add an exception to it right? >>>>> >>>>> That's the blessing and the curse of decisions made with a lower bar; >>>>> lower bar to undo. >>>>> >>>>> And I suppose secondly - if you disagree on whether something qualifies >>>>> for the super majority governance bar vs. the simple majority committer >>>>> bar... how do we navigate that? >>>>> >>>>> On Wed, Nov 1, 2023, at 12:33 PM, Benedict wrote: >>>>>> >>>>>> >>>>>> >>>>>> Your conceptualisation implies no weight to the decision, as a norm is >>>>>> not binding? >>>>>> >>>>>> >>>>>> >>>>>> The community voting section mentions only three kinds of decision, and >>>>>> this was deliberate: code contributions, CEP and releases - the latter >>>>>> of which non-PMC members are only permitted to veto; their votes do not >>>>>> count positively[1]. Everything else is a PMC decision. >>>>>> >>>>>> >>>>>> >>>>>> > I think you're arguing that voting to change our bar for merging when >>>>>> > it comes to CI falls under "votes on project structure” >>>>>> >>>>>> >>>>>> >>>>>> “Votes on project structure *and governance”*. Governance, per >>>>>> Wikipedia, is "the way rules, norms and actions are structured and >>>>>> sustained.” >>>>>> >>>>>> >>>>>> >>>>>> I do not see any ambiguity here. The community side provides no basis >>>>>> for a vote of this kind, while the PMC side specifically reserves this >>>>>> kind of decision. But evidently we need to make this clearer. >>>>>> >>>>>> >>>>>> >>>>>> Regarding the legitimacy of questioning this now: I have not come up >>>>>> against this legislation before. The norm of requiring green CI has been >>>>>> around for a lot longer than this vote, so nothing much changed until we >>>>>> started questioning the *specifics* of this legislation. At this point, >>>>>> the legitimacy of the decision also matters. Clearly there is broad >>>>>> support for a policy of this kind, but is this specific policy adequate? >>>>>> >>>>>> >>>>>> >>>>>> While I endorse the general sentiment of the policy, I do not endorse a >>>>>> policy that has no wiggle room. I have made every effort in all of my >>>>>> policy-making to ensure there are loosely-defined escape hatches for the >>>>>> community to use, in large part to minimise this kind of legalistic >>>>>> logjam, which is just wasted cycles. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 1 Nov 2023, at 15:31, Josh McKenzie <jmcken...@apache.org> wrote: >>>>>>> >>>>>>>> That vote thread also did not reach the threshold; it was incorrectly >>>>>>>> counted, as committer votes are not binding for procedural changes. I >>>>>>>> counted at most 8 PMC +1 votes. >>>>>>> This piqued my curiosity. >>>>>>> >>>>>>> Link to how we vote: >>>>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance >>>>>>> *STATUS: Ratified 2020/06/25* >>>>>>> >>>>>>> Relevant bits here: >>>>>>>> On dev@: >>>>>>>> >>>>>>>> 1. Discussion / binding votes on releases (Consensus: min 3 PMC +1, >>>>>>>> no -1) >>>>>>>> 2. Discussion / binding votes on project structure and governance >>>>>>>> changes (adopting subprojects, how we vote and govern, etc). (super >>>>>>>> majority) >>>>>>> >>>>>>> The thread where we voted on the CI bar Jeremiah referenced: >>>>>>> https://lists.apache.org/thread/2shht9rb0l8fh2gfqx6sz9pxobo6sr60 >>>>>>> Particularly relevant bit: >>>>>>>> Committer / pmc votes binding. Simple majority passes. >>>>>>> I think you're arguing that voting to change our bar for merging when >>>>>>> it comes to CI falls under "votes on project structure"? I think when I >>>>>>> called that vote I was conceptualizing it as a technical discussion >>>>>>> about a shared norm on how we as committers deal with code >>>>>>> contributions, where the "committer votes are binding, simple majority" >>>>>>> applies. >>>>>>> >>>>>>> I can see credible arguments in either direction, though I'd have >>>>>>> expected those concerns or counter-arguments to have come up back in >>>>>>> Jan of 2022 when we voted on the CI changes, not almost 2 years later >>>>>>> after us operating under this new shared norm. The sentiments expressed >>>>>>> on the discuss and vote thread were consistently positive and >>>>>>> uncontentious; this feels to me like it falls squarely under the spirit >>>>>>> of lazy consensus only at a much larger buy-in level than usual: >>>>>>> https://community.apache.org/committers/decisionMaking.html#lazy-consensus >>>>>>> >>>>>>> We've had plenty of time to call this vote and merge bar into question >>>>>>> (i.e. every ticket we merge we're facing the "no regressions" bar), and >>>>>>> the only reason I'd see us treating TCM or Accord differently would be >>>>>>> because they're much larger bodies of work at merge so it's going to be >>>>>>> a bigger lift to get to non-regression CI, and/or we would want a >>>>>>> release cut from a formal branch rather than a feature branch for >>>>>>> preview. >>>>>>> >>>>>>> An alternative approach to keep this merge and CI burden lower would >>>>>>> have been more incremental work merged into trunk periodically, an >>>>>>> argument many folks in the community have made in the past. I >>>>>>> personally have mixed feelings about it; there's pros and cons to both >>>>>>> approaches. >>>>>>> >>>>>>> All that said, I'm in favor of us continuing with this as a valid and >>>>>>> ratified vote (technical norms == committer binding + simple majority). >>>>>>> If we want to open a formal discussion about instead considering that a >>>>>>> procedural change and rolling things back based on those grounds I'm >>>>>>> fine with that, but we'll need to discuss that and think about the >>>>>>> broader implications since things like changing import ordering, >>>>>>> tooling, or other ecosystem-wide impacting changes (CI systems we all >>>>>>> share, etc) would similarly potentially run afoul of needing >>>>>>> supermajority pmc participation of we categorize that type of work as >>>>>>> "project structure" as per the governance rules. >>>>>>> >>>>>>> On Tue, Oct 31, 2023, at 1:25 PM, Jeremy Hanna wrote: >>>>>>>> I think the goal is to say "how could we get some working version of >>>>>>>> TCM/Accord into people's hands to try out at/by Summit?" That's all. >>>>>>>> People are eager to see it and try it out. >>>>>>>> >>>>>>>>> On Oct 31, 2023, at 12:16 PM, Benedict <bened...@apache.org> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> No, if I understand it correctly we’re in weird hypothetical land >>>>>>>>> where people are inventing new release types (“preview”) to avoid >>>>>>>>> merging TCM[1] in the event we want to cut a 5.1 release from the PR >>>>>>>>> prior to the summit if there’s some handful of failing tests in the >>>>>>>>> PR. >>>>>>>>> >>>>>>>>> This may or may not be a waste of everyone’s time. >>>>>>>>> >>>>>>>>> Jeremiah, I’m not questioning: it was procedurally invalid. How we >>>>>>>>> handle that is, as always, a matter for community decision making. >>>>>>>>> >>>>>>>>> [1] how this helps isn’t entirely clear >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 31 Oct 2023, at 17:08, Paulo Motta <pauloricard...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Even if it was not formally prescribed as far as I understand, we >>>>>>>>>> have been following the "only merge on Green CI" custom as much as >>>>>>>>>> possible for the past several years. Is the proposal to relax this >>>>>>>>>> rule for 5.0? >>>>>>>>>> >>>>>>>>>> On Tue, Oct 31, 2023 at 1:02 PM Jeremiah Jordan >>>>>>>>>> <jeremiah.jor...@gmail.com> wrote: >>>>>>>>>>> You are free to argue validity. I am just stating what I see on >>>>>>>>>>> the mailing list and in the wiki. We had a vote which was called >>>>>>>>>>> passing and was not contested at that time. The vote was on a >>>>>>>>>>> process which includes as #3 in the list: >>>>>>>>>>> >>>>>>>>>>> 1. Before a merge, a committer needs either a non-regressing (i.e. >>>>>>>>>>> no new failures) run of circleci with the required test suites >>>>>>>>>>> (TBD; see below) or of ci-cassandra. >>>>>>>>>>> 1. Non-regressing is defined here as "Doesn't introduce any new >>>>>>>>>>> test failures; any new failures in CI are clearly not attributable >>>>>>>>>>> to this diff" >>>>>>>>>>> 2. (NEW) After merging tickets, ci-cassandra runs against the >>>>>>>>>>> SHA and the author gets an advisory update on the related JIRA for >>>>>>>>>>> any new errors on CI. The author of the ticket will take point on >>>>>>>>>>> triaging this new failure and either fixing (if clearly >>>>>>>>>>> reproducible or related to their work) or opening a JIRA for the >>>>>>>>>>> intermittent failure and linking it in butler >>>>>>>>>>> (https://butler.cassandra.apache.org/#/) >>>>>>>>>>> >>>>>>>>>>> Which clearly says that before merge we ensure there are no known >>>>>>>>>>> new regressions to CI. >>>>>>>>>>> >>>>>>>>>>> The allowance for releases without CI being green, and merges >>>>>>>>>>> without the CI being completely green are from the fact that our >>>>>>>>>>> trunk CI has rarely been completely green, so we allow merging >>>>>>>>>>> things which do not introduce NEW regressions, and we allow >>>>>>>>>>> releases with known regressions that are deemed acceptable. >>>>>>>>>>> >>>>>>>>>>> We can indeed always vote to override it, and if it comes to that >>>>>>>>>>> we can consider that as an option. >>>>>>>>>>> >>>>>>>>>>> -Jeremiah >>>>>>>>>>> >>>>>>>>>>> On Oct 31, 2023 at 11:41:29 AM, Benedict <bened...@apache.org> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That vote thread also did not reach the threshold; it was >>>>>>>>>>>> incorrectly counted, as committer votes are not binding for >>>>>>>>>>>> procedural changes. I counted at most 8 PMC +1 votes. >>>>>>>>>>>> >>>>>>>>>>>> The focus of that thread was also clearly GA releases and merges >>>>>>>>>>>> on such branches, since there was a focus on releases being >>>>>>>>>>>> failure-free. But this predates the more general release lifecycle >>>>>>>>>>>> vote that allows for alphas to have failing tests - which >>>>>>>>>>>> logically would be impossible if nothing were merged with failing >>>>>>>>>>>> or flaky tests. >>>>>>>>>>>> >>>>>>>>>>>> Either way, the vote and discussion specifically allow for this to >>>>>>>>>>>> be overridden. >>>>>>>>>>>> >>>>>>>>>>>> 🤷♀️ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 31 Oct 2023, at 16:29, Jeremiah Jordan >>>>>>>>>>>>> <jeremiah.jor...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I never said there was a need for green CI for alpha. We do have >>>>>>>>>>>>> a requirement for not merging things to trunk that have known >>>>>>>>>>>>> regressions in CI. >>>>>>>>>>>>> Vote here: >>>>>>>>>>>>> https://lists.apache.org/thread/j34mrgcy9wrtn04nwwymgm6893h0xwo9 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Oct 31, 2023 at 3:23:48 AM, Benedict <bened...@apache.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is no requirement for green CI on alpha. We voted last >>>>>>>>>>>>>> year to require running all tests before commit and to require >>>>>>>>>>>>>> green CI for beta releases. This vote was invalid because it >>>>>>>>>>>>>> didn’t reach the vote floor for a procedural change but anyway >>>>>>>>>>>>>> is not inconsistent with knowingly and selectively merging work >>>>>>>>>>>>>> without green CI. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we reach the summit we should take a look at the state of the >>>>>>>>>>>>>> PRs and make a decision about if they are alpha quality; if so, >>>>>>>>>>>>>> and we want a release, we should simply merge it and release. >>>>>>>>>>>>>> Making up a new release type when the work meets alpha standard >>>>>>>>>>>>>> to avoid an arbitrary and not mandated commit bar seems the >>>>>>>>>>>>>> definition of silly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 31 Oct 2023, at 04:34, J. D. Jordan >>>>>>>>>>>>>>> <jeremiah.jor...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That is my understanding as well. If the TCM and Accord based >>>>>>>>>>>>>>> on TCM branches are ready to commit by ~12/1 we can cut a 5.1 >>>>>>>>>>>>>>> branch and then a 5.1-alpha release. >>>>>>>>>>>>>>> Where “ready to commit” means our usual things of two committer >>>>>>>>>>>>>>> +1 and green CI etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If we are not ready to commit then I propose that as long as >>>>>>>>>>>>>>> everything in the accord+tcm Apache repo branch has had two >>>>>>>>>>>>>>> committer +1’s, but maybe people are still working on fixes for >>>>>>>>>>>>>>> getting CI green or similar, we cut a 5.1-preview build from >>>>>>>>>>>>>>> the feature branch to vote on with known issues documented. >>>>>>>>>>>>>>> This would not be the preferred path, but would be a way to >>>>>>>>>>>>>>> have a voted on release for summit. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Jeremiah >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Oct 30, 2023, at 5:59 PM, Mick Semb Wever <m...@apache.org> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hoping we can get clarity on this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The proposal was, once TCM and Accord merges to trunk, then >>>>>>>>>>>>>>>> immediately branch cassandra-5.1 and cut an immediate >>>>>>>>>>>>>>>> 5.1-alpha1 release. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This was to focus on stabilising TCM and Accord as soon as it >>>>>>>>>>>>>>>> lands, hence the immediate branching. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And the alpha release as that is what our Release Lifecycle >>>>>>>>>>>>>>>> states it to be. >>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My understanding is that there was no squeezing in extra >>>>>>>>>>>>>>>> features into 5.1 after TCM+Accord lands, and there's no need >>>>>>>>>>>>>>>> for a "preview" release – we move straight to the alpha, as >>>>>>>>>>>>>>>> our lifecycle states. And we will describe all usability >>>>>>>>>>>>>>>> shortcomings and bugs with the alpha, our lifecycle docs >>>>>>>>>>>>>>>> permit this, if we feel the need to. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All this said, if TCM does not merge before the Summit, and we >>>>>>>>>>>>>>>> want to get a release into user hands, it has been suggested >>>>>>>>>>>>>>>> we cut a preview release 5.1-preview1 off the feature branch. >>>>>>>>>>>>>>>> This is a different scenario, and only a mitigation plan. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, 26 Oct 2023 at 14:20, Benedict <bened...@apache.org> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The time to stabilise is orthogonal to the time we branch. >>>>>>>>>>>>>>>>> Once we branch we stop accepting new features for the branch, >>>>>>>>>>>>>>>>> and work to stabilise. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> My understanding is we will branch as soon as we have a >>>>>>>>>>>>>>>>> viable alpha containing TCM and Accord. That means pretty >>>>>>>>>>>>>>>>> soon after they land in the project, which we expect to be >>>>>>>>>>>>>>>>> around the summit. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If this isn’t the expectation we should make that clear, as >>>>>>>>>>>>>>>>> it will affect how this decision is made. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 26 Oct 2023, at 10:14, Benjamin Lerer <b.le...@gmail.com> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Regarding the release of 5.1, I understood the proposal to >>>>>>>>>>>>>>>>>>> be that we cut an actual alpha, thereby sealing the 5.1 >>>>>>>>>>>>>>>>>>> release from new features. Only features merged before we >>>>>>>>>>>>>>>>>>> cut the alpha would be permitted, and the alpha should be >>>>>>>>>>>>>>>>>>> cut as soon as practicable. What exactly would we be >>>>>>>>>>>>>>>>>>> waiting for? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The problem I believe is about expectations. It seems that >>>>>>>>>>>>>>>>>> your expectation is that a release with only TCM and Accord >>>>>>>>>>>>>>>>>> will reach GA quickly. Based on the time it took us to >>>>>>>>>>>>>>>>>> release 4.1, I am simply expecting more delays (a GA around >>>>>>>>>>>>>>>>>> end of May, June). In which case it seems to me that we >>>>>>>>>>>>>>>>>> could be interested in shipping more stuff in the meantime >>>>>>>>>>>>>>>>>> (thinking of CASSANDRA-15254 or CEP-29 for example). >>>>>>>>>>>>>>>>>> I do not have a strong opinion, I just want to make sure >>>>>>>>>>>>>>>>>> that we all share the same understanding and fully >>>>>>>>>>>>>>>>>> understand what we agree upon. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer >>>>>>>>>>>>>>>>>> <b.le...@gmail.com> a écrit : >>>>>>>>>>>>>>>>>>>> I am surprised this needs to be said, but - especially for >>>>>>>>>>>>>>>>>>>> long-running CEPs - you must involve yourself early, and >>>>>>>>>>>>>>>>>>>> certainly within some reasonable time of being notified >>>>>>>>>>>>>>>>>>>> the work is ready for broader input and review. In this >>>>>>>>>>>>>>>>>>>> case, more than six months ago. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> It is unfortunately more complicated than that because six >>>>>>>>>>>>>>>>>>> month ago Ekaterina and I were working on supporting Java >>>>>>>>>>>>>>>>>>> 17 and dropping Java 8 which was needed by different >>>>>>>>>>>>>>>>>>> ongoing works. We both missed the announcement that TCM was >>>>>>>>>>>>>>>>>>> ready for review and anyway would not have been available >>>>>>>>>>>>>>>>>>> at that time. Maxim has asked me ages ago for a review of >>>>>>>>>>>>>>>>>>> CASSANDRA-15254 >>>>>>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-15254> >>>>>>>>>>>>>>>>>>> more than 6 months ago and I have not been able to help him >>>>>>>>>>>>>>>>>>> so far. We all have a limited bandwidth and can miss some >>>>>>>>>>>>>>>>>>> announcements. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The project has grown and a lot of things are going on in >>>>>>>>>>>>>>>>>>> parallel. There are also more interdependencies between the >>>>>>>>>>>>>>>>>>> different projects. In my opinion what we are lacking is a >>>>>>>>>>>>>>>>>>> global overview of the different things going on in the >>>>>>>>>>>>>>>>>>> project and some rough ideas of the status of the different >>>>>>>>>>>>>>>>>>> significant pieces. It would allow us to better organize >>>>>>>>>>>>>>>>>>> ourselves. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Le jeu. 26 oct. 2023 à 00:26, Benedict >>>>>>>>>>>>>>>>>>> <bened...@apache.org> a écrit : >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have spoken privately with Ekaterina, and to clear up >>>>>>>>>>>>>>>>>>>> some possible ambiguity: I realise nobody has demanded a >>>>>>>>>>>>>>>>>>>> delay to this work to conduct additional reviews; a couple >>>>>>>>>>>>>>>>>>>> of folk have however said they would prefer one. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> My point is that, as a community, we need to work on >>>>>>>>>>>>>>>>>>>> ensuring folk that care about a CEP participate at an >>>>>>>>>>>>>>>>>>>> appropriate time. If they aren’t able to, the consequences >>>>>>>>>>>>>>>>>>>> of that are for them to bear. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> We should be working to avoid surprises as CEP start to >>>>>>>>>>>>>>>>>>>> land. To this end, I think we should work on some >>>>>>>>>>>>>>>>>>>> additional paragraphs for the governance doc covering >>>>>>>>>>>>>>>>>>>> expectations around the landing of CEPs. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 25 Oct 2023, at 21:55, Benedict <bened...@apache.org> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I am surprised this needs to be said, but - especially >>>>>>>>>>>>>>>>>>>>> for long-running CEPs - you must involve yourself early, >>>>>>>>>>>>>>>>>>>>> and certainly within some reasonable time of being >>>>>>>>>>>>>>>>>>>>> notified the work is ready for broader input and review. >>>>>>>>>>>>>>>>>>>>> In this case, more than six months ago. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> This isn’t the first time this has happened, and it is >>>>>>>>>>>>>>>>>>>>> disappointing to see it again. Clearly we need to make >>>>>>>>>>>>>>>>>>>>> this explicit in the guidance docs. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regarding the release of 5.1, I understood the proposal >>>>>>>>>>>>>>>>>>>>> to be that we cut an actual alpha, thereby sealing the >>>>>>>>>>>>>>>>>>>>> 5.1 release from new features. Only features merged >>>>>>>>>>>>>>>>>>>>> before we cut the alpha would be permitted, and the alpha >>>>>>>>>>>>>>>>>>>>> should be cut as soon as practicable. What exactly would >>>>>>>>>>>>>>>>>>>>> we be waiting for? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If we don’t have a clear and near-term trigger for >>>>>>>>>>>>>>>>>>>>> branching 5.1 for its own release, shortly after Accord >>>>>>>>>>>>>>>>>>>>> and TCM merge, then I am in favour of instead delaying >>>>>>>>>>>>>>>>>>>>> 5.0. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 25 Oct 2023, at 19:40, Mick Semb Wever >>>>>>>>>>>>>>>>>>>>>> <m...@apache.org> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'm open to the suggestions of not branching >>>>>>>>>>>>>>>>>>>>>> cassandra-5.1 and/or naming a preview release something >>>>>>>>>>>>>>>>>>>>>> other than 5.1-alpha1. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But… the codebases and release process (and upgrade >>>>>>>>>>>>>>>>>>>>>> tests) do not currently support releases with qualifiers >>>>>>>>>>>>>>>>>>>>>> that are not alpha, beta, or rc. We can add a preview >>>>>>>>>>>>>>>>>>>>>> qualifier to this list, but I would not want to block >>>>>>>>>>>>>>>>>>>>>> getting a preview release out only because this wasn't >>>>>>>>>>>>>>>>>>>>>> yet in place. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hence the proposal used 5.1-alpha1 simply because that's >>>>>>>>>>>>>>>>>>>>>> what we know we can do today. An alpha release also >>>>>>>>>>>>>>>>>>>>>> means (typically) the branch. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Is anyone up for looking into adding a "preview" >>>>>>>>>>>>>>>>>>>>>> qualifier to our release process? >>>>>>>>>>>>>>>>>>>>>> This may also solve our previous discussions and desire >>>>>>>>>>>>>>>>>>>>>> to have quarterly releases that folk can use through the >>>>>>>>>>>>>>>>>>>>>> trunk dev cycle. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Personally, with my understanding of timelines in front >>>>>>>>>>>>>>>>>>>>>> of us to fully review and stabilise tcm, it makes sense >>>>>>>>>>>>>>>>>>>>>> to branch it as soon as it's merged. It's easiest to >>>>>>>>>>>>>>>>>>>>>> stabilise it on a branch, and there's definitely the >>>>>>>>>>>>>>>>>>>>>> desire and demand to do so, so it won't be getting >>>>>>>>>>>>>>>>>>>>>> forgotten or down-prioritised. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, 25 Oct 2023 at 18:07, Jeremiah Jordan >>>>>>>>>>>>>>>>>>>>>> <jeremiah.jor...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> If we do a 5.1 release why not take it as an >>>>>>>>>>>>>>>>>>>>>>>> opportunity to release more things. I am not saying >>>>>>>>>>>>>>>>>>>>>>>> that we will. Just that we should let that door open. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Agreed. This is the reason I brought up the >>>>>>>>>>>>>>>>>>>>>>> possibility of not branching off 5.1 immediately. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Oct 25, 2023 at 3:17:13 AM, Benjamin Lerer >>>>>>>>>>>>>>>>>>>>>>> <b.le...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> The proposal includes 3 things: >>>>>>>>>>>>>>>>>>>>>>>> 1. Do not include TCM and Accord in 5.0 to avoid >>>>>>>>>>>>>>>>>>>>>>>> delaying 5.0 >>>>>>>>>>>>>>>>>>>>>>>> 2. The next release will be 5.1 and will include only >>>>>>>>>>>>>>>>>>>>>>>> Accord and TCM >>>>>>>>>>>>>>>>>>>>>>>> 3. Merge TCM and Accord right now in 5.1 (making an >>>>>>>>>>>>>>>>>>>>>>>> initial release) >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I am fine with question 1 and do not have a strong >>>>>>>>>>>>>>>>>>>>>>>> opinion on which way to go. >>>>>>>>>>>>>>>>>>>>>>>> 2. Means that every new feature will have to wait for >>>>>>>>>>>>>>>>>>>>>>>> post 5.1 even if it is ready before 5.1 is stabilized >>>>>>>>>>>>>>>>>>>>>>>> and shipped. If we do a 5.1 release why not take it as >>>>>>>>>>>>>>>>>>>>>>>> an opportunity to release more things. I am not saying >>>>>>>>>>>>>>>>>>>>>>>> that we will. Just that we should let that door open. >>>>>>>>>>>>>>>>>>>>>>>> 3. There is a need to merge TCM and Accord as >>>>>>>>>>>>>>>>>>>>>>>> maintaining those separate branches is costly in terms >>>>>>>>>>>>>>>>>>>>>>>> of time and energy. I fully understand that. On the >>>>>>>>>>>>>>>>>>>>>>>> other hand merging TCM and Accord will make the TCM >>>>>>>>>>>>>>>>>>>>>>>> review harder and I do believe that this second round >>>>>>>>>>>>>>>>>>>>>>>> of review is valuable as it already uncovered a valid >>>>>>>>>>>>>>>>>>>>>>>> issue. Nevertheless, I am fine with merging TCM as >>>>>>>>>>>>>>>>>>>>>>>> soon as it passes CI and continuing the review after >>>>>>>>>>>>>>>>>>>>>>>> the merge. If we cannot meet at least that quality >>>>>>>>>>>>>>>>>>>>>>>> level (Green CI) we should not merge just for creating >>>>>>>>>>>>>>>>>>>>>>>> an 5.1.alpha release for the summit. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Now, I am totally fine with a preview release without >>>>>>>>>>>>>>>>>>>>>>>> numbering and with big warnings that will only serve >>>>>>>>>>>>>>>>>>>>>>>> as a preview for the summit. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Le mer. 25 oct. 2023 à 06:33, Berenguer Blasi >>>>>>>>>>>>>>>>>>>>>>>> <berenguerbl...@gmail.com> a écrit : >>>>>>>>>>>>>>>>>>>>>>>>> I also think there's many good new features in 5.0 >>>>>>>>>>>>>>>>>>>>>>>>> already they'd make a >>>>>>>>>>>>>>>>>>>>>>>>> good release even on their own. My 2 cts. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 24/10/23 23:20, Brandon Williams wrote: >>>>>>>>>>>>>>>>>>>>>>>>> > The catch here is that we don't publish docker >>>>>>>>>>>>>>>>>>>>>>>>> > images currently. The >>>>>>>>>>>>>>>>>>>>>>>>> > C* docker images available are not made by us. >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > Kind Regards, >>>>>>>>>>>>>>>>>>>>>>>>> > Brandon >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > On Tue, Oct 24, 2023 at 3:31 PM Patrick McFadin >>>>>>>>>>>>>>>>>>>>>>>>> > <pmcfa...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >> Let me make that really easy. Hell yes >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> Not everybody runs CCM, I've tried but I've met >>>>>>>>>>>>>>>>>>>>>>>>> >> resistance. >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> Compiling your own version usually involves me >>>>>>>>>>>>>>>>>>>>>>>>> >> saying the words "Yes, ant realclean exists. I'm >>>>>>>>>>>>>>>>>>>>>>>>> >> not trolling you" >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> docker pull <image> works on every OS and curates >>>>>>>>>>>>>>>>>>>>>>>>> >> a single node experience. >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> On Tue, Oct 24, 2023 at 12:37 PM Josh McKenzie >>>>>>>>>>>>>>>>>>>>>>>>> >> <jmcken...@apache.org> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>> In order for the project to advertise the release >>>>>>>>>>>>>>>>>>>>>>>>> >>> outside the dev@ list it needs to be a formal >>>>>>>>>>>>>>>>>>>>>>>>> >>> release. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> That's my reading as well: >>>>>>>>>>>>>>>>>>>>>>>>> >>> https://www.apache.org/legal/release-policy.html#release-definition >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> I wonder if there'd be value in us having a >>>>>>>>>>>>>>>>>>>>>>>>> >>> cronned job that'd do nightly docker container >>>>>>>>>>>>>>>>>>>>>>>>> >>> builds on trunk + feature branches, archived for >>>>>>>>>>>>>>>>>>>>>>>>> >>> N days, and we make that generally known to the >>>>>>>>>>>>>>>>>>>>>>>>> >>> dev@ list here so folks that want to poke at the >>>>>>>>>>>>>>>>>>>>>>>>> >>> current state of trunk or other branches could do >>>>>>>>>>>>>>>>>>>>>>>>> >>> so with very low friction. We'd probably see more >>>>>>>>>>>>>>>>>>>>>>>>> >>> engagement on feature branches if it was turn-key >>>>>>>>>>>>>>>>>>>>>>>>> >>> easy for other C* devs to spin the up and check >>>>>>>>>>>>>>>>>>>>>>>>> >>> them out. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> For what you're talking about here Patrick (a >>>>>>>>>>>>>>>>>>>>>>>>> >>> docker image for folks outside the dev@ audience >>>>>>>>>>>>>>>>>>>>>>>>> >>> and more user-facing), we'd want to vote on it >>>>>>>>>>>>>>>>>>>>>>>>> >>> and go through the formal process. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> On Tue, Oct 24, 2023, at 3:10 PM, Jeremiah Jordan >>>>>>>>>>>>>>>>>>>>>>>>> >>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> In order for the project to advertise the release >>>>>>>>>>>>>>>>>>>>>>>>> >>> outside the dev@ list it needs to be a formal >>>>>>>>>>>>>>>>>>>>>>>>> >>> release. That just means that there was a >>>>>>>>>>>>>>>>>>>>>>>>> >>> release vote and at least 3 PMC members +1’ed it, >>>>>>>>>>>>>>>>>>>>>>>>> >>> and there are more +1 than there are -1, and we >>>>>>>>>>>>>>>>>>>>>>>>> >>> follow all the normal release rules. The ASF >>>>>>>>>>>>>>>>>>>>>>>>> >>> release process doesn’t care what branch you cut >>>>>>>>>>>>>>>>>>>>>>>>> >>> the artifacts from or what version you call it. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> So the project can cut artifacts for and release >>>>>>>>>>>>>>>>>>>>>>>>> >>> a 5.1-alpha1, 5.1-dev-preview1, what ever we want >>>>>>>>>>>>>>>>>>>>>>>>> >>> to version this thing, from trunk or any other >>>>>>>>>>>>>>>>>>>>>>>>> >>> branch name we want. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> -Jeremiah >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> On Oct 24, 2023 at 2:03:41 PM, Patrick McFadin >>>>>>>>>>>>>>>>>>>>>>>>> >>> <pmcfa...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> I would like to have something for developers to >>>>>>>>>>>>>>>>>>>>>>>>> >>> use ASAP to try the Accord syntax. Very few >>>>>>>>>>>>>>>>>>>>>>>>> >>> people have seen it, and I think there's a >>>>>>>>>>>>>>>>>>>>>>>>> >>> learning curve we can start earlier. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> It's my understanding that ASF policy is that it >>>>>>>>>>>>>>>>>>>>>>>>> >>> needs to be a project release to create a docker >>>>>>>>>>>>>>>>>>>>>>>>> >>> image. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> On Tue, Oct 24, 2023 at 11:54 AM Jeremiah Jordan >>>>>>>>>>>>>>>>>>>>>>>>> >>> <jeremiah.jor...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> If we decide to go the route of not merging TCM >>>>>>>>>>>>>>>>>>>>>>>>> >>> to the 5.0 branch. Do we actually need to >>>>>>>>>>>>>>>>>>>>>>>>> >>> immediately cut a 5.1 branch? Can we work on >>>>>>>>>>>>>>>>>>>>>>>>> >>> stabilizing things while it is in trunk and cut >>>>>>>>>>>>>>>>>>>>>>>>> >>> the 5.1 branch when we actually think we are near >>>>>>>>>>>>>>>>>>>>>>>>> >>> releasing? I don’t see any reason we can not cut >>>>>>>>>>>>>>>>>>>>>>>>> >>> “preview” artifacts from trunk? >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> -Jeremiah >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> On Oct 24, 2023 at 11:54:25 AM, Jon Haddad >>>>>>>>>>>>>>>>>>>>>>>>> >>> <rustyrazorbl...@apache.org> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> I guess at the end of the day, shipping a release >>>>>>>>>>>>>>>>>>>>>>>>> >>> with a bunch of awesome features is better than >>>>>>>>>>>>>>>>>>>>>>>>> >>> holding it back. If there's 2 big releases in 6 >>>>>>>>>>>>>>>>>>>>>>>>> >>> months the community isn't any worse off. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> We either ship something, or nothing, and >>>>>>>>>>>>>>>>>>>>>>>>> >>> something is probably better. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> Jon >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> On 2023/10/24 16:27:04 Patrick McFadin wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> +1 to what you are saying, Josh. Based on the >>>>>>>>>>>>>>>>>>>>>>>>> >>> last survey, yes, everyone >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> was excited about Accord, but SAI and UCS were >>>>>>>>>>>>>>>>>>>>>>>>> >>> pretty high on the list. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> Benedict and I had a good conversation last >>>>>>>>>>>>>>>>>>>>>>>>> >>> night, and now I understand >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> more essential details for this conversation. TCM >>>>>>>>>>>>>>>>>>>>>>>>> >>> is taking far more work >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> than initially scoped, and Accord depends on a >>>>>>>>>>>>>>>>>>>>>>>>> >>> stable TCM. TCM is months >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> behind and that's a critical fact, and one I >>>>>>>>>>>>>>>>>>>>>>>>> >>> personally just learned of. I >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> thought things were wrapping up this month, and >>>>>>>>>>>>>>>>>>>>>>>>> >>> we were in the testing >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> phase. I get why that's a topic we are dancing >>>>>>>>>>>>>>>>>>>>>>>>> >>> around. Nobody wants to say >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> ship dates are slipping because that's part of >>>>>>>>>>>>>>>>>>>>>>>>> >>> our culture. It's >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> disappointing and, if new information, an >>>>>>>>>>>>>>>>>>>>>>>>> >>> unwelcome surprise, but none of >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> us should be angry or in a blamey mood because I >>>>>>>>>>>>>>>>>>>>>>>>> >>> guarantee every one of us >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> has shipped the code late. My reaction yesterday >>>>>>>>>>>>>>>>>>>>>>>>> >>> was based on an incorrect >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> assumption. Now that I have a better picture, my >>>>>>>>>>>>>>>>>>>>>>>>> >>> point of view is changing. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> Josh's point about what's best for users is >>>>>>>>>>>>>>>>>>>>>>>>> >>> crucial. Users deserve stable >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> code with a regular cadence of features that make >>>>>>>>>>>>>>>>>>>>>>>>> >>> their lives easier. If we >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> put 5.0 on hold for TCM + Accord, users will get >>>>>>>>>>>>>>>>>>>>>>>>> >>> neither for a very long >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> time. And I mentioned a disaster yesterday. A >>>>>>>>>>>>>>>>>>>>>>>>> >>> bigger disaster would be >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> shipping Accord with a major bug that causes data >>>>>>>>>>>>>>>>>>>>>>>>> >>> loss, eroding community >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> trust. Accord has to be the most bulletproof of >>>>>>>>>>>>>>>>>>>>>>>>> >>> all bulletproof features. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> The pressure to ship is only going to increase >>>>>>>>>>>>>>>>>>>>>>>>> >>> and that's fertile ground >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> for that sort of bug. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> So, taking a step back and with a clearer >>>>>>>>>>>>>>>>>>>>>>>>> >>> picture, I support the 5.0 + 5.1 >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> plan mainly because I don't think 5.1 is (or >>>>>>>>>>>>>>>>>>>>>>>>> >>> should be) a fast follow. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> For the user community, the communication should >>>>>>>>>>>>>>>>>>>>>>>>> >>> be straightforward. TCM + >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> Accord are turning out to be much more >>>>>>>>>>>>>>>>>>>>>>>>> >>> complicated than was originally >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> scoped, and for good reasons. Our first principle >>>>>>>>>>>>>>>>>>>>>>>>> >>> is to provide a stable >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> and reliable system, so as a result, we'll be >>>>>>>>>>>>>>>>>>>>>>>>> >>> de-coupling TCM + Accord from >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> 5.0 into a 5.1 branch, which is available in >>>>>>>>>>>>>>>>>>>>>>>>> >>> parallel to 5.0 while >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> additional hardening and testing is done. We can >>>>>>>>>>>>>>>>>>>>>>>>> >>> communicate this in a blog >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> post., >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> To make this much more palatable to our use >>>>>>>>>>>>>>>>>>>>>>>>> >>> community, if we can get a >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> build and docker image available ASAP with >>>>>>>>>>>>>>>>>>>>>>>>> >>> Accord, it will allow developers >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> to start playing with the syntax. Up to this >>>>>>>>>>>>>>>>>>>>>>>>> >>> point, that hasn't been widely >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> available unless you compile the code yourself. >>>>>>>>>>>>>>>>>>>>>>>>> >>> Developers need to >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> understand how this will work in an application, >>>>>>>>>>>>>>>>>>>>>>>>> >>> and up to this point, the >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> syntax is text they see in my slides. We need to >>>>>>>>>>>>>>>>>>>>>>>>> >>> get some hands-on and that >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> will get our user community engaged on Accord >>>>>>>>>>>>>>>>>>>>>>>>> >>> this calendar year. The >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> feedback may even uncover some critical changes >>>>>>>>>>>>>>>>>>>>>>>>> >>> we'll need to make. Lack of >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> access to Accord by developers is a critical >>>>>>>>>>>>>>>>>>>>>>>>> >>> problem we can fix soon and >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> there will be plenty of excitement there and >>>>>>>>>>>>>>>>>>>>>>>>> >>> start building use cases >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> before the final code ships. >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> I'm bummed but realistic. It sucks that I won't >>>>>>>>>>>>>>>>>>>>>>>>> >>> have a pony for Christmas, >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> but maybe one for my birthday? >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> Patrick >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> On Tue, Oct 24, 2023 at 7:23 AM Josh McKenzie >>>>>>>>>>>>>>>>>>>>>>>>> >>> <jmcken...@apache.org> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Maybe it won't be a glamorous release but >>>>>>>>>>>>>>>>>>>>>>>>> >>>> shipping >>>>>>>>>>>>>>>>>>>>>>>>> >>>> 5.0 mitigates our worst case scenario. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> I disagree with this characterization of 5.0 >>>>>>>>>>>>>>>>>>>>>>>>> >>>> personally. UCS, SAI, Trie >>>>>>>>>>>>>>>>>>>>>>>>> >>>> memtables and sstables, maybe vector ANN if the >>>>>>>>>>>>>>>>>>>>>>>>> >>>> sub-tasks on C-18715 are >>>>>>>>>>>>>>>>>>>>>>>>> >>>> accurate, all combine to make 5.0 a pretty >>>>>>>>>>>>>>>>>>>>>>>>> >>>> glamorous release IMO >>>>>>>>>>>>>>>>>>>>>>>>> >>>> independent of TCM and Accord. Accord is a true >>>>>>>>>>>>>>>>>>>>>>>>> >>>> paradigm-shift game-changer >>>>>>>>>>>>>>>>>>>>>>>>> >>>> so it's easy to think of 5.0 as uneventful in >>>>>>>>>>>>>>>>>>>>>>>>> >>>> comparison, and TCM helps >>>>>>>>>>>>>>>>>>>>>>>>> >>>> resolve one of the biggest pain-points in our >>>>>>>>>>>>>>>>>>>>>>>>> >>>> system for over a decade, but >>>>>>>>>>>>>>>>>>>>>>>>> >>>> I think 5.0 is a very meaty release in its own >>>>>>>>>>>>>>>>>>>>>>>>> >>>> right today. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Anyway - I agree with you Brandon re: timelines. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> If things take longer >>>>>>>>>>>>>>>>>>>>>>>>> >>>> than we'd hope (which, if I think back, they do >>>>>>>>>>>>>>>>>>>>>>>>> >>>> roughly 100% of the time on >>>>>>>>>>>>>>>>>>>>>>>>> >>>> this project), blocking on these features could >>>>>>>>>>>>>>>>>>>>>>>>> >>>> both lead to a significant >>>>>>>>>>>>>>>>>>>>>>>>> >>>> delay in 5.0 going out as well as increasing >>>>>>>>>>>>>>>>>>>>>>>>> >>>> pressure and risk of burnout >>>>>>>>>>>>>>>>>>>>>>>>> >>>> on the folks working on it. While I believe we >>>>>>>>>>>>>>>>>>>>>>>>> >>>> all need some balanced >>>>>>>>>>>>>>>>>>>>>>>>> >>>> urgency to do our best work, being under the gun >>>>>>>>>>>>>>>>>>>>>>>>> >>>> for something with a hard >>>>>>>>>>>>>>>>>>>>>>>>> >>>> deadline or having an entire project drag along >>>>>>>>>>>>>>>>>>>>>>>>> >>>> blocked on you is not where >>>>>>>>>>>>>>>>>>>>>>>>> >>>> I want any of us to be. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Part of why we talked about going to primarily >>>>>>>>>>>>>>>>>>>>>>>>> >>>> annual calendar-based >>>>>>>>>>>>>>>>>>>>>>>>> >>>> releases was to avoid precisely this situation, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> where something that >>>>>>>>>>>>>>>>>>>>>>>>> >>>> *feels* right at the cusp of merging leads us to >>>>>>>>>>>>>>>>>>>>>>>>> >>>> delay a release >>>>>>>>>>>>>>>>>>>>>>>>> >>>> repeatedly. We discussed this a couple times >>>>>>>>>>>>>>>>>>>>>>>>> >>>> this year: >>>>>>>>>>>>>>>>>>>>>>>>> >>>> 1: >>>>>>>>>>>>>>>>>>>>>>>>> >>>> https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> where Mick proposed a "soft-freeze" for >>>>>>>>>>>>>>>>>>>>>>>>> >>>> everything w/out exception and 1st >>>>>>>>>>>>>>>>>>>>>>>>> >>>> week October "hard-freeze", and there was >>>>>>>>>>>>>>>>>>>>>>>>> >>>> assumed to be lazy consensus >>>>>>>>>>>>>>>>>>>>>>>>> >>>> 2: >>>>>>>>>>>>>>>>>>>>>>>>> >>>> https://lists.apache.org/thread/mzj3dq8b7mzf60k6mkby88b9n9ywmsgw, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> where we kept along with what we discussed in 1 >>>>>>>>>>>>>>>>>>>>>>>>> >>>> but added in CEP-30 to be >>>>>>>>>>>>>>>>>>>>>>>>> >>>> waivered in as well. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> So. We're at a crossroads here where we need to >>>>>>>>>>>>>>>>>>>>>>>>> >>>> either follow through with >>>>>>>>>>>>>>>>>>>>>>>>> >>>> what we all agreed to earlier this year, or >>>>>>>>>>>>>>>>>>>>>>>>> >>>> acknowledge that our best >>>>>>>>>>>>>>>>>>>>>>>>> >>>> intention of calendar-based releases can't stand >>>>>>>>>>>>>>>>>>>>>>>>> >>>> up to our optimism and >>>>>>>>>>>>>>>>>>>>>>>>> >>>> desire to get these features into the next major. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> There's no immediate obvious better path to me >>>>>>>>>>>>>>>>>>>>>>>>> >>>> in terms of what's best for >>>>>>>>>>>>>>>>>>>>>>>>> >>>> our users. This is a situation of risk tolerance >>>>>>>>>>>>>>>>>>>>>>>>> >>>> with a lot of unknowns >>>>>>>>>>>>>>>>>>>>>>>>> >>>> that could go either way. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Any light that folks active on TCM and Accord >>>>>>>>>>>>>>>>>>>>>>>>> >>>> could shed in terms of their >>>>>>>>>>>>>>>>>>>>>>>>> >>>> best and worst-case scenarios on timelines for >>>>>>>>>>>>>>>>>>>>>>>>> >>>> those features might help us >>>>>>>>>>>>>>>>>>>>>>>>> >>>> narrow this down a bit. Otherwise, I'm inclined >>>>>>>>>>>>>>>>>>>>>>>>> >>>> to defer to our past selves >>>>>>>>>>>>>>>>>>>>>>>>> >>>> and fall back to "we agreed to yearly calendar >>>>>>>>>>>>>>>>>>>>>>>>> >>>> releases for good reason. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Let's stick to our guns." >>>>>>>>>>>>>>>>>>>>>>>>> >>>> On Tue, Oct 24, 2023, at 9:37 AM, Brandon >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Williams wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>> The concern I have with this is that is a big >>>>>>>>>>>>>>>>>>>>>>>>> >>>> slippery 'if' that >>>>>>>>>>>>>>>>>>>>>>>>> >>>> involves development time estimation, and if it >>>>>>>>>>>>>>>>>>>>>>>>> >>>> tends to take longer >>>>>>>>>>>>>>>>>>>>>>>>> >>>> than we estimate (as these things tend to do), >>>>>>>>>>>>>>>>>>>>>>>>> >>>> then I can see a future >>>>>>>>>>>>>>>>>>>>>>>>> >>>> where 5.0 is delayed until the middle of 2024, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> and I really don't want >>>>>>>>>>>>>>>>>>>>>>>>> >>>> that to happen. Maybe it won't be a glamorous >>>>>>>>>>>>>>>>>>>>>>>>> >>>> release but shipping >>>>>>>>>>>>>>>>>>>>>>>>> >>>> 5.0 mitigates our worst case scenario. >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Kind Regards, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Brandon >>>>>>>>>>>>>>>>>>>>>>>>> >>>> On Mon, Oct 23, 2023 at 4:02 PM Dinesh Joshi >>>>>>>>>>>>>>>>>>>>>>>>> >>>> <djo...@apache.org> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> I have a strong preference to move out the 5.0 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> date to have accord and >>>>>>>>>>>>>>>>>>>>>>>>> >>>> TCM. I don’t see the point in shipping 5.0 >>>>>>>>>>>>>>>>>>>>>>>>> >>>> without these features >>>>>>>>>>>>>>>>>>>>>>>>> >>>> especially if 5.1 is going to follow close >>>>>>>>>>>>>>>>>>>>>>>>> >>>> behind it. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> Dinesh >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> On Oct 23, 2023, at 4:52 AM, Mick Semb Wever >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> <m...@apache.org> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> The TCM work (CEP-21) is in its review stage >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> but being well past our >>>>>>>>>>>>>>>>>>>>>>>>> >>>> cut-off date¹ for merging, and now jeopardising >>>>>>>>>>>>>>>>>>>>>>>>> >>>> 5.0 GA efforts, I would >>>>>>>>>>>>>>>>>>>>>>>>> >>>> like to propose the following. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> We merge TCM and Accord only to trunk. Then >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> branch cassandra-5.1 and >>>>>>>>>>>>>>>>>>>>>>>>> >>>> cut an immediate 5.1-alpha1 release. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> I see this as a win-win scenario for us, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> considering our current >>>>>>>>>>>>>>>>>>>>>>>>> >>>> situation. (Though it is unfortunate that >>>>>>>>>>>>>>>>>>>>>>>>> >>>> Accord is included in this >>>>>>>>>>>>>>>>>>>>>>>>> >>>> scenario because we agreed it to be based upon >>>>>>>>>>>>>>>>>>>>>>>>> >>>> TCM.) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> This will mean… >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - We get to focus on getting 5.0 to beta and >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> GA, which already has a >>>>>>>>>>>>>>>>>>>>>>>>> >>>> ton of features users want. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - We get an alpha release with TCM and Accord >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> into users hands quickly >>>>>>>>>>>>>>>>>>>>>>>>> >>>> for broader testing and feedback. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - We isolate GA efforts on TCM and Accord – >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> giving oss and downstream >>>>>>>>>>>>>>>>>>>>>>>>> >>>> engineers time and patience reviewing and >>>>>>>>>>>>>>>>>>>>>>>>> >>>> testing. TCM will be the biggest >>>>>>>>>>>>>>>>>>>>>>>>> >>>> patch ever to land in C*. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - Give users a choice for a more incremental >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> upgrade approach, given >>>>>>>>>>>>>>>>>>>>>>>>> >>>> just how many new features we're putting on them >>>>>>>>>>>>>>>>>>>>>>>>> >>>> in one year. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - 5.1 w/ TCM and Accord will maintain its >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> upgrade compatibility with >>>>>>>>>>>>>>>>>>>>>>>>> >>>> all 4.x versions, just as if it had landed in >>>>>>>>>>>>>>>>>>>>>>>>> >>>> 5.0. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> The risks/costs this introduces are >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - If we cannot stabilise TCM and/or Accord on >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> the cassandra-5.1 branch, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> and at some point decide to undo this work, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> while we can throw away the >>>>>>>>>>>>>>>>>>>>>>>>> >>>> cassandra-5.1 branch we would need to do a bit >>>>>>>>>>>>>>>>>>>>>>>>> >>>> of work reverting the >>>>>>>>>>>>>>>>>>>>>>>>> >>>> changes in trunk. This is a _very_ edge case, >>>>>>>>>>>>>>>>>>>>>>>>> >>>> as confidence levels on the >>>>>>>>>>>>>>>>>>>>>>>>> >>>> design and implementation of both are already >>>>>>>>>>>>>>>>>>>>>>>>> >>>> tested and high. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - We will have to maintain an additional >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> branch. I propose that we >>>>>>>>>>>>>>>>>>>>>>>>> >>>> treat the 5.1 branch in the same maintenance >>>>>>>>>>>>>>>>>>>>>>>>> >>>> window as 5.0 (like we have >>>>>>>>>>>>>>>>>>>>>>>>> >>>> with 3.0 and 3.11). This also adds the merge >>>>>>>>>>>>>>>>>>>>>>>>> >>>> path overhead. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> - Reviewing of TCM and Accord will continue >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> to happen post-merge. This >>>>>>>>>>>>>>>>>>>>>>>>> >>>> is not our normal practice, but this work will >>>>>>>>>>>>>>>>>>>>>>>>> >>>> have already received its >>>>>>>>>>>>>>>>>>>>>>>>> >>>> two +1s from committers, and such ongoing review >>>>>>>>>>>>>>>>>>>>>>>>> >>>> effort is akin to GA >>>>>>>>>>>>>>>>>>>>>>>>> >>>> stabilisation work on release branches. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> I see no other ok solution in front of us that >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> gets us at least both the >>>>>>>>>>>>>>>>>>>>>>>>> >>>> 5.0 beta and TCM+Accord alpha releases this >>>>>>>>>>>>>>>>>>>>>>>>> >>>> year. Keeping in mind users >>>>>>>>>>>>>>>>>>>>>>>>> >>>> demand to start experimenting with these >>>>>>>>>>>>>>>>>>>>>>>>> >>>> features, and our Cassandra Summit >>>>>>>>>>>>>>>>>>>>>>>>> >>>> in December. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> 1) >>>>>>>>>>>>>>>>>>>>>>>>> >>>>> https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3 >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>>>>>>>>>>> >>> >>>>>>> >>>>> >>> >>
