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
