> > These are all further reasons to codify our project governance, as we keep > referring to things that don't map to project norms.
Strong +1 here. To reiterate: I don't necessarily agree w/all the stated defaults for project management and behavior, we just haven't really articulated our own culture for people to align to it either so seems a reasonable starting point. On Mon, Sep 30, 2019 at 12:20 PM Benedict Elliott Smith <bened...@apache.org> wrote: > Hmm, you're right, I'm not sure what I was remembering. Fortunately you > can just ignore the first sentence of my email; mea culpa. > > However, I'm not sure how useful it is as a mechanism for achieving > consensus if there's no way for voting members to know a decision is being > made. The value of a formal vote email is that participants know a > decision is being made, and should participate if they care. > > Unfortunately, it seems like current project norms also don't map well to > the concepts provided in the ASF wikis. For instance, we do not follow the > review-then-commit policy, as this requires 3 +1 votes from a PMC to > authorise a commit. However we also do not follow the commit-then-review > policy, as we require reviews from committers, and do not generally require > any cooling-off period before commit, so long as at least one review vote > has been cast - and not even necessarily by a PMC member (or even always by > a committer). Lazy consensus appears to have been intended to operate > primarily for code modifications (given the examples and caveats), and > seems problematic for larger decisions, particularly procedural ones. > > These are all further reasons to codify our project governance, as we keep > referring to things that don't map to project norms. > > > On 30/09/2019, 19:06, "Joshua McKenzie" <jmcken...@apache.org> wrote: > > I believe your statement is inaccurate, or perhaps just overly broad: " > Lazy consensus still requires a formal vote, just one that is declared > to > be governed by lazy consensus"; the article I linked explicitly states: > > "You don't have to insist people discuss and/or approve your plan, > *and you > certainly don't need to call a vote to get approval*. You just assume > you > have the communities support unless someone says otherwise." > > Seems like the intersection of this is: "Lazy consensus is simply an > announcement of 'silence gives assent.'" with a caveat of "you have N > hours > to dissent before we take silence as assent" when you're unsure or a > topic > is contentious, which tracks with what I've seen kind of informally > happen > on the project in the past 5.5 years. > > And for the record, this is just me attempting to open a conversation > on > this since there's some pre-defined guidelines from the ASF on how to > handle this and it seems like we're not all aware of them as evidenced > by > this thread. We've had some change recently on both PMC and committer > list > as well. This isn't me advocating for the process fwiw; lazy consensus > has > historically led to last minute interventions by people raising > significant > concerns on design, process, or worse implementation that gum up the > works, > and they even speak to this in the article: "However, it does require > everyone who cares for the health of the project to watch what is > happening, as it is happening. Objecting too far down the road will > cause > upset, but objecting (or asking for clarification of intent) early is > likely to be greeted with relief that someone is watching and cares." > > And I think the formal ASF cultural expectations are completely in > keeping > with what you've stated here bes: "participation in decision-making is > costly, and that proposers should understand that they need to work to > lower the cost of decision-making on their proposal, and that we as a > project need to figure out how to help them do this." > > Not to hijack the thread > > #fail > > > > On Mon, Sep 30, 2019 at 10:22 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > Lazy consensus still requires a formal vote, just one that is > declared to > > be governed by lazy consensus. > > > > I think we need to spend some time formalising our governance, so > that we > > can employ it confidently. At the very least, we should try to > codify > > where we are comfortable employing lazy consensus, and where we > might want > > majority vote, and where a veto is acceptable, since at present it's > > self-declared which is a bit peculiar IMO. We might also want to > codify > > the process for disputing a lazy consensus vote that didn't receive > enough > > participation / attention. > > > > I personally felt the Jira changes were (accidentally) quite a > successful > > model for community decision-making, even if they were a bit higher > traffic > > than we might ordinarily desire - but there were a lot of technical > > details, and a lot of opinions, which is probably uncommon. The > successful > > feature, I think, having been to solicit regular feedback in the > form of > > non-binding +1/-1s on each part of the proposal, before rolling them > up > > into a formal vote representing the collective decision-making. This > > lowered the bar to participation, and increased the number of > opportunities > > to participate, and didn't require ongoing participation by any > particular > > person. I'm unsure if it could effectively be employed in other > cases, but > > it might be worth a try. > > > > This is also the goal of the CEP/CIP, and some people have also > proposed > > working groups. Wider user of lazy consensus fits into the same > category, > > I think. These are all attempts to improve the speed and quality of > > decision-making on the project. I think codifying the rules of the > project > > would help as a starting point, but also simply recognising that > > participation in decision-making is costly, and that proposers should > > understand that they need to work to lower the cost of > decision-making on > > their proposal, and that we as a project need to figure out how to > help > > them do this. > > > > > > On 30/09/2019, 14:57, "Joshua McKenzie" <jmcken...@apache.org> > wrote: > > > > For what it's worth, lazy consensus is a very important concept > in the > > Apache Way < > https://community.apache.org/committers/lazyConsensus.html > > >. > > > > Methinks if we got a little more comfortable w/lazy consensus and > > majority > > voting on process <https://www.apache.org/foundation/voting.html> > we > > might > > see some quicker evolution on the project. > > > > Not to hijack the thread; just figured I'd point it out since it > was > > on my > > mind and it may not be common knowledge. > > > > On Fri, Sep 27, 2019 at 12:20 PM Sankalp Kohli < > kohlisank...@gmail.com > > > > > wrote: > > > > > Let’s put this to vote next week unless someone thinks it is > not > > required > > > > > > > On Sep 25, 2019, at 10:56 AM, sankalp kohli < > > kohlisank...@gmail.com> > > > wrote: > > > > > > > > > > > > Can we put it on vote(if required) if no one has more > comments? > > > > > > > >> On Wed, Sep 18, 2019 at 5:44 PM Jonathan Koppenhofer < > > > j...@koppedomain.com> wrote: > > > >> Nice work... I like this and have no additions/comments at > this > > time > > > >> > > > >> On Wed, Sep 18, 2019, 4:18 PM sankalp kohli < > > kohlisank...@gmail.com> > > > wrote: > > > >> > > > >> > We added and changed a lot of things to this doc during a > > discussion > > > in > > > >> > NGCC. Can everyone take a look at it and provide feedback. > > > >> > > > > >> > On Wed, Sep 11, 2019 at 10:51 PM Dinesh Joshi < > > djo...@apache.org> > > > wrote: > > > >> > > > > >> > > I have left some comments on the document. Apart from a > few > > > >> > clarifications > > > >> > > and some minor changes, I feel its in a good shape. I > think we > > > should > > > >> > move > > > >> > > forward with it. We can refine the process, definitions > & > > criteria > > > as we > > > >> > > learn. > > > >> > > > > > >> > > Dinesh > > > >> > > > > > >> > > > On Sep 11, 2019, at 11:15 AM, Sumanth Pasupuleti < > > > >> > > sumanth.pasupuleti...@gmail.com> wrote: > > > >> > > > > > > >> > > > One more call for any additional comments/ feedback > on the > > release > > > >> > > > lifecycle document > > > >> > > > > > > >> > > > > > >> > > > > > > > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > > > >> > > > > > > >> > > > Thanks, > > > >> > > > Sumanth > > > >> > > > > > > >> > > > On Sat, Jul 27, 2019 at 1:01 AM Sumanth Pasupuleti < > > > >> > > > sumanth.pasupuleti...@gmail.com> wrote: > > > >> > > > > > > >> > > >> Submitted patch to add release lifecycle information > to the > > > website > > > >> > > >> > https://issues.apache.org/jira/browse/CASSANDRA-15249 > > > >> > > >> > > > >> > > >> On Tue, Jun 25, 2019 at 6:57 AM Oleksandr Petrov < > > > >> > > >> oleksandr.pet...@gmail.com> wrote: > > > >> > > >> > > > >> > > >>> Maybe a bit off-topic: > > > >> > > >>> > > > >> > > >>> Before we cut a release, we should make sure we > take care > > of > > > beta > > > >> > > protocol > > > >> > > >>> [1], include released driver versions [2] and remove > > compact > > > storage > > > >> > > >>> remainders [3]. Third one is optional, but I'd > argue we > > should > > > do it > > > >> > > >>> sooner > > > >> > > >>> rather than later. > > > >> > > >>> > > > >> > > >>> [1] > https://issues.apache.org/jira/browse/CASSANDRA-14973 > > > >> > > >>> [2] > https://issues.apache.org/jira/browse/CASSANDRA-13951 > > > >> > > >>> [3] > https://issues.apache.org/jira/browse/CASSANDRA-13994 > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> On Sat, Jun 22, 2019 at 1:25 AM Sumanth Pasupuleti < > > > >> > > >>> sumanth.pasupuleti...@gmail.com> wrote: > > > >> > > >>> > > > >> > > >>>> Thanks for the feedback Scott. I have incorporated > all > > the > > > >> > incremental > > > >> > > >>>> feedback I have thus far. > > > >> > > >>>> > > > >> > > >>>> Looking for any additional feedback folks may have. > > > >> > > >>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > > > > >> > > > > > > > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > > > >> > > >>>> > > > >> > > >>>> On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas < > > > >> > sc...@paradoxica.net> > > > >> > > >>>> wrote: > > > >> > > >>>> > > > >> > > >>>>> Thanks for starting this discussion, Sumanth! > Added a > > round of > > > >> > > >>> comments > > > >> > > >>>> as > > > >> > > >>>>> well. > > > >> > > >>>>> > > > >> > > >>>>> Summarizing my non-binding feedback: I feel that > many > > of the > > > items > > > >> > > >>> under > > > >> > > >>>>> "Alpha" and "Beta" should be achieved prior to the > > release of > > > an > > > >> > > >>> alpha, > > > >> > > >>>>> especially those related to correctness/safety, > scope > > lock, > > > feature > > > >> > > >>>>> completeness, deprecation, and backwards > compatibility. > > > >> > Establishing > > > >> > > a > > > >> > > >>>>> higher standard for official project releases > (even at > > the > > > alpha > > > >> > and > > > >> > > >>> beta > > > >> > > >>>>> stage) will help us really polish the final build > > together. > > > >> > > >>>>> > > > >> > > >>>>> Ideally, I feel that contributors should have > completed > > > extensive > > > >> > > >>>>> testing/validation to ensure that no critical or > severe > > bugs > > > exist > > > >> > > >>> prior > > > >> > > >>>> to > > > >> > > >>>>> the release of an alpha (e.g., data loss, > consistency > > > violations, > > > >> > > >>>> incorrect > > > >> > > >>>>> responses to queries, etc). Perhaps we can add a > line > > to this > > > >> > effect. > > > >> > > >>>>> > > > >> > > >>>>> Ensuring that we've met that bar prior to alpha > will > > help us > > > focus > > > >> > > the > > > >> > > >>>>> final stages of the release on gathering feedback > from > > users + > > > >> > > >>> developers > > > >> > > >>>>> to validate tooling and automation; compatibility > with > > less > > > >> > > >>> commonly-used > > > >> > > >>>>> client libraries, testing new features, evaluating > > > performance and > > > >> > > >>>>> stability under their workloads, etc. > > > >> > > >>>>> > > > >> > > >>>>> – Scott > > > >> > > >>>>> > > > >> > > >>>>> On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" < > > > >> > > >>>>> sumanth.pasupuleti...@gmail.com> wrote: > > > >> > > >>>>> > > > >> > > >>>>> Thanks for the feedback on the product stages/ > > release life > > > >> > cycle > > > >> > > >>>>> document. > > > >> > > >>>>> I have incorporated the suggestions and > looking for > > any > > > >> > additional > > > >> > > >>>>> feedback > > > >> > > >>>>> folks may have. > > > >> > > >>>>> > > > >> > > >>>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > > > > >> > > > > > > > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > > > >> > > >>>>> > > > >> > > >>>>> Thanks, > > > >> > > >>>>> Sumanth > > > >> > > >>>>> > > > >> > > >>>>> On Tue, May 28, 2019 at 10:43 PM Scott Andreas > < > > > >> > > >>> sc...@paradoxica.net > > > >> > > >>>>> > > > >> > > >>>>> wrote: > > > >> > > >>>>> > > > >> > > >>>>>> Echoing Jon’s point here – > > > >> > > >>>>>> > > > >> > > >>>>>> JH: “My thinking is I'd like to be able to > recommend > > 4.0.0 > > > as a > > > >> > > >>>>> production > > > >> > > >>>>>> ready > > > >> > > >>>>>> database for business critical cases” > > > >> > > >>>>>> > > > >> > > >>>>>> I feel that this is a standard that is both > > appropriate and > > > >> > > >>>>> achievable, > > > >> > > >>>>>> and one I’m legitimately excited about. > > > >> > > >>>>>> > > > >> > > >>>>>> Re: the current state of the test plan wiki in > > Confluence, I > > > owe > > > >> > > >>>>> another > > > >> > > >>>>>> pass through. There has been a lot of progress > here, > > but I’ve > > > >> > > >>> let > > > >> > > >>>>> perfect > > > >> > > >>>>>> be the enemy of the good in getting updates out. > I’ll > > > complete > > > >> > > >>> that > > > >> > > >>>>> pass > > > >> > > >>>>>> later this week. > > > >> > > >>>>>> > > > >> > > >>>>>> Cheers, > > > >> > > >>>>>> > > > >> > > >>>>>> — Scott > > > >> > > >>>>>> > > > >> > > >>>>>>> On May 28, 2019, at 10:48 AM, Dinesh Joshi < > > > djo...@apache.org > > > >> > > >>>> > > > >> > > >>>>> wrote: > > > >> > > >>>>>>> > > > >> > > >>>>>>> +1. Wiki could be useful to document what the > overall > > plan. > > > >> > > >>> Jira > > > >> > > >>>> to > > > >> > > >>>>>> track progress. > > > >> > > >>>>>>> > > > >> > > >>>>>>> Dinesh > > > >> > > >>>>>>> > > > >> > > >>>>>>>>> On May 28, 2019, at 10:20 AM, Joshua McKenzie > < > > > >> > > >>>>> jmcken...@apache.org> > > > >> > > >>>>>> wrote: > > > >> > > >>>>>>>>> > > > >> > > >>>>>>>>> > > > >> > > >>>>>>>>> The unofficial rule is to not upgrade to prod > till > > .10 is > > > >> > > >>> cut. > > > >> > > >>>>>>>> > > > >> > > >>>>>>>> FWIW, I believe it's historically .6. Which is > still > > not a > > > >> > > >>> great > > > >> > > >>>>> look > > > >> > > >>>>>> for > > > >> > > >>>>>>>> the project. > > > >> > > >>>>>>>> > > > >> > > >>>>>>>> There's a ton of work going into testing 4.0 > already. > > > >> > > >>>>>>>> > > > >> > > >>>>>>>> While I intuitively and anecdotally (from the > people > > I've > > > >> > > >>>>> backchanneled > > > >> > > >>>>>>>> with) believe this to be true as well, the > > referenced wiki > > > >> > > >>>>> page[1] and > > > >> > > >>>>>>>> jql[2] doesn't look like it's an up to date > > reflection of > > > the > > > >> > > >>>>> testing > > > >> > > >>>>>>>> efforts going on. Is there another place this > > information > > > is > > > >> > > >>>>> stored / > > > >> > > >>>>>>>> queryable we can surface to people to keep us > all > > > >> > > >>> coordinated? > > > >> > > >>>>>>>> > > > >> > > >>>>>>>> [1] > > > >> > > >>>>>>>> > > > >> > > >>>>>> > > > >> > > >>>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > > > > >> > > > > > > > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > > > >> > > >>>>>>>> [2] > > > >> > > >>>>>>>> > > > >> > > >>>>>> > > > >> > > >>>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > > > > >> > > > > > > > https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA > > > >> > > >>>>>>>> > > > >> > > >>>>>>>> On Tue, May 28, 2019 at 12:57 PM sankalp kohli > < > > > >> > > >>>>> kohlisank...@gmail.com> > > > >> > > >>>>>>>> wrote: > > > >> > > >>>>>>>> > > > >> > > >>>>>>>>> Hi Jon, > > > >> > > >>>>>>>>> When you say 4.0 release, how do u > match it > > with > > > >> > > >>> 3.0 > > > >> > > >>>>> minor > > > >> > > >>>>>>>>> releases. The unofficial rule is to not > upgrade to > > prod > > > till > > > >> > > >>>> .10 > > > >> > > >>>>> is > > > >> > > >>>>>> cut. > > > >> > > >>>>>>>>> Also due to heavy investment in testing, I > dont > > think it > > > >> > > >>> will > > > >> > > >>>>> take as > > > >> > > >>>>>> long > > > >> > > >>>>>>>>> as 3.0 but want to know what is your thinking > with > > this. > > > >> > > >>>>>>>>> > > > >> > > >>>>>>>>> Thanks, > > > >> > > >>>>>>>>> Sankalp > > > >> > > >>>>>>>>> > > > >> > > >>>>>>>>>> On Tue, May 28, 2019 at 9:40 AM Jon Haddad < > > > >> > > >>> j...@jonhaddad.com > > > >> > > >>>>> > > > >> > > >>>>> wrote: > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>> Sept is a pretty long ways off. I think the > ideal > > case > > > is > > > >> > > >>> we > > > >> > > >>>>> can > > > >> > > >>>>>>>>> announce > > > >> > > >>>>>>>>>> 4.0 release at the summit. I'm not putting > this > > as a "do > > > >> > > >>> or > > > >> > > >>>>> die" > > > >> > > >>>>>> date, > > > >> > > >>>>>>>>> and > > > >> > > >>>>>>>>>> I don't think we need to announce it or make > > promises. > > > >> > > >>>>> Sticking with > > > >> > > >>>>>>>>> "when > > > >> > > >>>>>>>>>> it's ready" is the right approach, but we > need a > > target, > > > >> > > >>> and > > > >> > > >>>>> this is > > > >> > > >>>>>> imo > > > >> > > >>>>>>>>> a > > > >> > > >>>>>>>>>> good one. > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>> This date also gives us a pretty good > runway. We > > could > > > cut > > > >> > > >>>> our > > > >> > > >>>>> first > > > >> > > >>>>>>>>>> alphas in mid June / early July, betas in > August > > and > > > >> > > >>> release > > > >> > > >>>> in > > > >> > > >>>>> Sept. > > > >> > > >>>>>>>>>> There's a ton of work going into testing 4.0 > > already. > > > >> > > >>>>>>>>>> Landing CASSANDRA-15066 will put us in a > pretty > > good > > > spot. > > > >> > > >>>>> We've > > > >> > > >>>>>>>>> developed > > > >> > > >>>>>>>>>> tooling at TLP that will make it a lot > easier to > > spin up > > > >> > > >>> dev > > > >> > > >>>>> clusters > > > >> > > >>>>>> in > > > >> > > >>>>>>>>>> AWS as well as stress test them. I've > written > > about > > > this a > > > >> > > >>>> few > > > >> > > >>>>> times > > > >> > > >>>>>> in > > > >> > > >>>>>>>>>> the past, and I'll have a few blog posts > coming up > > that > > > >> > > >>> will > > > >> > > >>>>> help show > > > >> > > >>>>>>>>> this > > > >> > > >>>>>>>>>> in more details. > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>> There's some other quality of life things we > > should try > > > to > > > >> > > >>>>> hammer out > > > >> > > >>>>>>>>>> before then. Updating our default JVM > settings > > would be > > > >> > > >>> nice, > > > >> > > >>>>> for > > > >> > > >>>>>>>>>> example. Improving documentation (the data > > modeling > > > >> > > >>> section > > > >> > > >>>> in > > > >> > > >>>>>>>>>> particular), fixing the dynamic snitch > issues [1], > > and > > > some > > > >> > > >>>>>> improvements > > > >> > > >>>>>>>>> to > > > >> > > >>>>>>>>>> virtual tables like exposing the sstable > metadata > > [2], > > > and > > > >> > > >>>>> exposing > > > >> > > >>>>>> table > > > >> > > >>>>>>>>>> statistics [3] come to mind. The dynamic > snitch > > > >> > > >>> improvement > > > >> > > >>>>> will help > > > >> > > >>>>>>>>>> performance in a big way, and the virtual > tables > > will go > > > a > > > >> > > >>>> long > > > >> > > >>>>> way to > > > >> > > >>>>>>>>>> helping with quality of life. I showed a > few folks > > > virtual > > > >> > > >>>>> tables at > > > >> > > >>>>>> the > > > >> > > >>>>>>>>>> Accelerate conference last week and the > missing > > table > > > >> > > >>>>> statistics was a > > > >> > > >>>>>>>>> big > > > >> > > >>>>>>>>>> shock. If we can get them in, it'll be a > big help > > to > > > >> > > >>>> operators. > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>> [1] > > > https://issues.apache.org/jira/browse/CASSANDRA-14459 > > > >> > > >>>>>>>>>> [2] > > > https://issues.apache.org/jira/browse/CASSANDRA-14630 > > > >> > > >>>>>>>>>> [3] > > > https://issues.apache.org/jira/browse/CASSANDRA-14572 > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>>>> On Mon, May 27, 2019 at 2:36 PM Nate McCall > < > > > >> > > >>>>> zznat...@gmail.com> > > > >> > > >>>>>> wrote: > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>>> Hi Sumanth, > > > >> > > >>>>>>>>>>> Thank you so much for taking the time to > put this > > > >> > > >>> together. > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>>> Cheers, > > > >> > > >>>>>>>>>>> -Nate > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>>> On Tue, May 28, 2019 at 3:27 AM Sumanth > > Pasupuleti < > > > >> > > >>>>>>>>>>> sumanth.pasupuleti...@gmail.com> wrote: > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>>>> I have taken an initial stab at documenting > > release > > > types > > > >> > > >>>> and > > > >> > > >>>>> exit > > > >> > > >>>>>>>>>>> criteria > > > >> > > >>>>>>>>>>>> in a google doc, to get us started, and to > > collaborate > > > >> > > >>> on. > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>> > > > >> > > >>>>>> > > > >> > > >>>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > > > > >> > > > > > > > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=sharing > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>>> Thanks, > > > >> > > >>>>>>>>>>>> Sumanth > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>>> On Thu, May 23, 2019 at 12:04 PM Dinesh > Joshi < > > > >> > > >>>>> djo...@apache.org> > > > >> > > >>>>>>>>>> wrote: > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> Sankalp, > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> Great point. This is the page created for > > testing. > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>> > > > >> > > >>>>>> > > > >> > > >>>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > > > > >> > > > > > > > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> I think we need to define the various > release > > types > > > and > > > >> > > >>> the > > > >> > > >>>>> exit > > > >> > > >>>>>>>>>>> criteria > > > >> > > >>>>>>>>>>>>> for each type of release. Anybody want to > take > > a stab > > > at > > > >> > > >>>>> this or > > > >> > > >>>>>>>>>> start > > > >> > > >>>>>>>>>>> a > > > >> > > >>>>>>>>>>>>> thread to discuss it? > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> Thanks, > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> Dinesh > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>> On May 23, 2019, at 11:57 AM, sankalp > kohli < > > > >> > > >>>>>>>>>> kohlisank...@gmail.com> > > > >> > > >>>>>>>>>>>>> wrote: > > > >> > > >>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>> Hi, > > > >> > > >>>>>>>>>>>>>> Is there a page where it is written what > is > > expected > > > >> > > >>> from > > > >> > > >>>>> an > > > >> > > >>>>>>>>>>> alpha, > > > >> > > >>>>>>>>>>>>>> beta, rc and a 4.0 release? > > > >> > > >>>>>>>>>>>>>> Also how are we coming up with Q4 2019 > > timeline. Is > > > >> > > >>> this > > > >> > > >>>> for > > > >> > > >>>>>>>>> alpha, > > > >> > > >>>>>>>>>>>> beta, > > > >> > > >>>>>>>>>>>>>> rc or 4.0 release? > > > >> > > >>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>> Thanks, > > > >> > > >>>>>>>>>>>>>> Sankalp > > > >> > > >>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>> On Thu, May 23, 2019 at 11:27 AM Attila > Wind > > > >> > > >>>>>>>>>> <attilaw@swf.technology > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> wrote: > > > >> > > >>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>> +1+1+1 I read a blog post was talking > about > > last > > > >> > > >>> sept(?) > > > >> > > >>>> to > > > >> > > >>>>>>>>> freeze > > > >> > > >>>>>>>>>>>>>>> features and start extensive testing. > Maybe > > its > > > really > > > >> > > >>>>> time to > > > >> > > >>>>>>>>> hit > > > >> > > >>>>>>>>>>> it! > > > >> > > >>>>>>>>>>>>> :-) > > > >> > > >>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>> Attila Wind > > > >> > > >>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>> http://www.linkedin.com/in/attilaw > > > >> > > >>>>>>>>>>>>>>> Mobile: +36 31 7811355 > > > >> > > >>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>> On 2019. 05. 23. 19:30, ajs6f wrote: > > > >> > > >>>>>>>>>>>>>>>> +1 in the fullest degree. A date that > needs > > to be > > > >> > > >>>> changed > > > >> > > >>>>> is > > > >> > > >>>>>>>>>> still > > > >> > > >>>>>>>>>>>>>>> enormously more attractive than no date > at > > all. > > > >> > > >>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>> Adam Soroka > > > >> > > >>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>> On May 23, 2019, at 12:01 PM, Sumanth > > Pasupuleti < > > > >> > > >>>>>>>>>>>>>>> spasupul...@netflix.com.INVALID> wrote: > > > >> > > >>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>> Having at least a ballpark target on > the > > website > > > >> > > >>> will > > > >> > > >>>>>>>>> definitely > > > >> > > >>>>>>>>>>>> help. > > > >> > > >>>>>>>>>>>>>>> +1 > > > >> > > >>>>>>>>>>>>>>>>> on setting it to Q4 2019 for now. > > > >> > > >>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>> On Thu, May 23, 2019 at 8:52 AM Dinesh > > Joshi < > > > >> > > >>>>>>>>> djo...@apache.org > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> wrote: > > > >> > > >>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>>> +1 on setting a date. > > > >> > > >>>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>>> Dinesh > > > >> > > >>>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>>>> On May 23, 2019, at 11:07 AM, > Michael > > Shuler < > > > >> > > >>>>>>>>>>>>> mich...@pbandjelly.org> > > > >> > > >>>>>>>>>>>>>>>>>> wrote: > > > >> > > >>>>>>>>>>>>>>>>>>> We've had 4.0 listed as TBD release > date > > for a > > > >> > > >>> very > > > >> > > >>>>> long > > > >> > > >>>>>>>>> time. > > > >> > > >>>>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>>>> Yesterday, Alexander Dejanovski got > a > > "when's > > > 4.0 > > > >> > > >>>>> going to > > > >> > > >>>>>>>>>>>> release?" > > > >> > > >>>>>>>>>>>>>>>>>> question after his repair talk and he > > suggested > > > >> > > >>>>> possibly Q4 > > > >> > > >>>>>>>>>> 2019. > > > >> > > >>>>>>>>>>>>> This > > > >> > > >>>>>>>>>>>>>>>>>> morning Nate McCall hinted at > possibly > > being > > > close > > > >> > > >>> by > > > >> > > >>>>>>>>> ApacheCon > > > >> > > >>>>>>>>>>> Las > > > >> > > >>>>>>>>>>>>>>> Vegas > > > >> > > >>>>>>>>>>>>>>>>>> in September. These got me thinking.. > > > >> > > >>>>>>>>>>>>>>>>>>> Think we can we shoot for having a > 4.0 > > > >> > > >>> alpha/beta/rc > > > >> > > >>>>> ready > > > >> > > >>>>>>>>> to > > > >> > > >>>>>>>>>>>>>>>>>> announce/release at ApacheCon? At > that > > time, > > > we'll > > > >> > > >>>> have > > > >> > > >>>>> been > > > >> > > >>>>>>>>>>> frozen > > > >> > > >>>>>>>>>>>>>>> for 1 > > > >> > > >>>>>>>>>>>>>>>>>> year, and I think we can. We'll GA > release > > when > > > >> > > >>> it's > > > >> > > >>>>> ready, > > > >> > > >>>>>>>>>> but I > > > >> > > >>>>>>>>>>>>>>> think Q4 > > > >> > > >>>>>>>>>>>>>>>>>> could be an realistic target. > > > >> > > >>>>>>>>>>>>>>>>>>> With that said, I'd like to change > "TBD" > > on the > > > >> > > >>>>> downloads > > > >> > > >>>>>>>>> page > > > >> > > >>>>>>>>>>> to > > > >> > > >>>>>>>>>>>>>>> "Est. > > > >> > > >>>>>>>>>>>>>>>>>> Q4 2019". We can always push or pull > the > > > estimate, > > > >> > > >>>> but I > > > >> > > >>>>>>>>> think > > > >> > > >>>>>>>>>>> it's > > > >> > > >>>>>>>>>>>>>>> time to > > > >> > > >>>>>>>>>>>>>>>>>> have a goal line. This lines up with > > ApacheCon > > > >> > > >>> nicely > > > >> > > >>>>> for a > > > >> > > >>>>>>>>>>> preview > > > >> > > >>>>>>>>>>>>>>> release. > > > >> > > >>>>>>>>>>>>>>>>>>> Any concerns or objections to > editing the > > > download > > > >> > > >>>>> page? > > > >> > > >>>>>>>>> Have > > > >> > > >>>>>>>>>>> some > > > >> > > >>>>>>>>>>>>>>> other > > > >> > > >>>>>>>>>>>>>>>>>> goal timeframe in mind? > > > >> > > >>>>>>>>>>>>>>>>>>> -- > > > >> > > >>>>>>>>>>>>>>>>>>> Warm regards, > > > >> > > >>>>>>>>>>>>>>>>>>> Michael > > > >> > > >>>>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>> > > > >> > > >>>>> > > > >> > > > --------------------------------------------------------------------- > > > >> > > >>>>>>>>>>>>>>>>>>> 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 > > > >> > > >>>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>>>>> > > > >> > > >>>>>>>>>>> > > > >> > > >>>>> > > > >> > > > --------------------------------------------------------------------- > > > >> > > >>>>>>>>>>>>>>>> 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 > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>>> > > > >> > > >>>>>>>>>>>> > > > >> > > >>>>>>>>>>> > > > >> > > >>>>>>>>>> > > > >> > > >>>>>>>>> > > > >> > > >>>>>>> > > > >> > > >>>>>>> > > > >> > > >>>>>>> > > > >> > > >>>>> > > > >> > > > --------------------------------------------------------------------- > > > >> > > >>>>>>> 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 > > > >> > > >>>>> > > > >> > > >>>>> > > > >> > > >>>> > > > >> > > >>> > > > >> > > >>> > > > >> > > >>> -- > > > >> > > >>> 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 > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
