I am +1 to both removal from the template and "we need this" On Wed, Jul 14, 2021 at 9:05 AM Joshua McKenzie <jmcken...@apache.org> wrote: > > > > > Yes, we should perhaps remove target version from the template, and > > introduce guidance on describing stability impact etc. > > Strong +1 to remove this from the template. I got sucked into the mistake > of conflating implementation details and implications on where it lands > instead of staying high level in the "do we agree we need this". > > And I'm a +1 on the "I agree we need this". > > > On Wed, Jul 14, 2021 at 7:32 AM bened...@apache.org <bened...@apache.org> > wrote: > > > > I think CEPs would benefit from describing their compatibility and > > stability impacts, rather than trying to tie themselves to a > > version, regardless of what context a specific version provides. > > > > Yes, we should perhaps remove target version from the template, and > > introduce guidance on describing stability impact etc. > > > > Regarding waivers, I’m not sure we’ve really agreed as a community what > > the criteria are for determining if work goes into a patch release – so I’m > > not sure it would be right to call it a waiver. But I agree that scheduling > > the release to contain some work should be a mixture of project roadmap > > planning (distinct from CEP), and Jira/dev list discussion near the point > > of merge. > > > > The question is if there is still value in the CEP pages maintaining the > > endeavour’s goal for when the work will be ready, but perhaps this can be > > communicated in normal date format, and used to inform project roadmap > > planning. > > > > > > From: Mick Semb Wever <m...@apache.org> > > Date: Wednesday, 14 July 2021 at 10:41 > > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > > Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations > > > > > > PRs will land soon for people to look at, but honestly we’re getting into > > > an unnecessary tangle over target release. I think it would be a mistake > > to > > > push this to a later release, because it is valuable and it will bring > > pain > > > by creating divergence - but the question a CEP is meant to answer is > > _if_ > > > the community wants a piece of work. > > > > > > Since it’s become an explicit point of contention, we can perhaps > > > disaggregate a vote on _when_ to happen in parallel, once discussion on > > > _if_ wraps up. > > > > > > > > Totally agree, can we remove the "Target Version" from the CEP, so the vote > > is based on the _if_ ? > > > > Some further thoughts… > > > > I think CEPs would benefit from describing their compatibility and > > stability impacts, rather than trying to tie themselves to a > > version, regardless of what context a specific version provides. > > > > Rather than a subsequent vote on the CEP trying to get it into 4.0.x, what > > about requests for waivers on each jira ticket as they are ready to land? I > > suspect much of the work (once we see it) will be easier to agree to such > > waivers than the only other position we have to stand by currently, which > > is categories defined by SemVer. (A lot of people are really keen to see us > > practice PATCH-only patch versions.) This also ties back to my request to > > see a "rough timeline/plan of how the proposed changes are to be defined in > > JIRAs and ordered." > > > > It's worth noting that the code divergence will happen between two branches > > no matter what, e.g. 3.11, and next April is really not far away at all. Is > > it really a problem if the LWT fix is also pushed back to 4.1 (though I > > understand this is a bigger discussion) for the sake of driving home > > we are a project now serious about stability? > > > > All in all, I am betting this discussion will be a lot more productive a) > > when we see more of the work involved and its impact, and b) in a month or > > two when we have better witnessed the stability of 4.0.0 and what has gone > > into 4.0.1 and 4.0.2. > >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
