Re: Failed Dtest will block cutting releases

[Josh McKenzie]

Caveat: I'm strongly in favor of us blocking a release on a non-green test
board of either utest or dtest.


> put something in prod which is known to be broken in obvious ways

In my experience the majority of fixes are actually shoring up low-quality
/ flaky tests or fixing tests that have been invalidated by a commit but do
not indicate an underlying bug. Inferring "tests are failing so we know
we're asking people to put things in prod that are broken in obvious ways"
is hyperbolic. A more correct statement would be: "Tests are failing so we
know we're shipping with a test that's failing" which is not helpful.

Our signal to noise ratio with tests has been very poor historically; we've
been trying to address that through aggressive triage and assigning out
test failures however we need far more active and widespread community
involvement if we want to truly *fix* this problem long-term.

On Mon, Nov 21, 2016 at 2:33 PM, Jonathan Haddad  wrote:

> +1.  Kind of silly to put advise people to put something in prod which is
> known to be broken in obvious ways
>
> On Mon, Nov 21, 2016 at 11:31 AM sankalp kohli 
> wrote:
>
> > Hi,
> > We should not cut a releases if Dtest are not passing. I won't block
> > 3.10 on this since we are just discussing this.
> >
> > Please provide feedback on this.
> >
> > Thanks,
> > Sankalp
> >
>

Re: Failed Dtest will block cutting releases

[Jonathan Haddad]

+1.  Kind of silly to put advise people to put something in prod which is
known to be broken in obvious ways

On Mon, Nov 21, 2016 at 11:31 AM sankalp kohli 
wrote:

> Hi,
> We should not cut a releases if Dtest are not passing. I won't block
> 3.10 on this since we are just discussing this.
>
> Please provide feedback on this.
>
> Thanks,
> Sankalp
>

Failed Dtest will block cutting releases

[sankalp kohli]

Hi,
We should not cut a releases if Dtest are not passing. I won't block
3.10 on this since we are just discussing this.

Please provide feedback on this.

Thanks,
Sankalp

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

[sankalp kohli]

We voted in the dev list discussion[1] that we wont cut a release till all
unit tests are passing. I can see that testall are failing for trunk and
3.X. Hence I need to do a -1 on this release. My -1 is not due to Dtest
failing as we discussed about unit tests only in that thread. I will start
another thread for making Dtest a blocker for release.

-1 due to testall failing.

1. http://mail-archives.apache.org/mod_mbox/incubator-
cassandra-dev/201607.mbox/%3cCAEPxca1TGo6S1O8DcpM7dmXsBe4
4EniSezkpq5_=qksctk3...@mail.gmail.com%3e



On Mon, Nov 21, 2016 at 9:19 AM, Sankalp Kohli 
wrote:

> We had decided in an email thread initiated by me that we won't cut
> releases till all tests are passing.
>
> Why not wait till these patches are merged? Is there any critical fix in
> it which need to be rushed out ?
>
> > On Nov 20, 2016, at 23:36, Oleksandr Petrov 
> wrote:
> >
> > From just a quick glance, I can say at least some of the tests are either
> > PA or are getting there:
> >
> > For example:
> > http://cassci.datastax.com/job/cassandra-3.X_novnode_
> dtest/lastCompletedBuild/testReport/paging_test/
> TestPagingData/test_paging_with_filtering_on_partition_key/
> > Should be fixed by
> > https://issues.apache.org/jira/browse/CASSANDRA-12666
> >
> > http://cassci.datastax.com/job/cassandra-3.X_testall/
> lastCompletedBuild/testReport/org.apache.cassandra.cql3.
> validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionK
> eyWithSecondaryIndex/
> > Should be fixed by
> > https://issues.apache.org/jira/browse/CASSANDRA-12651
> >
> > Although there can be more tests in PA.
> >
> > On Sun, Nov 20, 2016 at 10:35 PM sankalp kohli 
> > wrote:
> >
> >> Hi,
> >>I see the following test runs are failing. Are they for this release?
> >>
> >> http://cassci.datastax.com/job/cassandra-3.X_utest_cdc/
> >> http://cassci.datastax.com/job/cassandra-3.X_testall/
> >> http://cassci.datastax.com/job/cassandra-3.X_offheap_dtest/
> >> http://cassci.datastax.com/job/cassandra-3.X_novnode_dtest/
> >> http://cassci.datastax.com/job/cassandra-3.X_dtest/40/
> >>
> >> Thanks,
> >> Sankalp
> >>
> >>
> >>> On Sun, Nov 20, 2016 at 12:50 PM, Nate McCall 
> wrote:
> >>>
> >>> +1
> >>>
> >>> On Sat, Nov 19, 2016 at 7:08 AM, Michael Shuler <
> mich...@pbandjelly.org>
> >>> wrote:
>  I propose the following artifacts for release as 3.10.
> 
>  sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e
>  Git:
>  http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >>> shortlog;h=refs/tags/3.10-tentative
>  Artifacts:
>  https://repository.apache.org/content/repositories/
> >>> orgapachecassandra-1135/org/apache/cassandra/apache-cassandra/3.10/
>  Staging repository:
>  https://repository.apache.org/content/repositories/
> >>> orgapachecassandra-1135/
> 
>  The Debian packages are available here: http://people.apache.org/~
> >>> mshuler
> 
>  The vote will be open for 72 hours (longer if needed).
> 
>  [1]: (CHANGES.txt) https://goo.gl/vah74X
>  [2]: (NEWS.txt) https://goo.gl/In3vp7
> 
> >>>
> >>
> > --
> > Alex Petrov
>

Re: Proposals for releases - 4.0 and beyond

[Jonathan Haddad]

+1 as well

On Mon, Nov 21, 2016 at 10:59 AM kurt Greaves  wrote:

> yep +1 to this. The LTS release solves my previous concern
>

Re: Proposals for releases - 4.0 and beyond

[kurt Greaves]

yep +1 to this. The LTS release solves my previous concern

Re: Status of dtest donation?

[Jeff Jirsa]

Incubator handles the ICLA / IP transfer for the subrepo. 


On 11/21/16, 10:11 AM, "Jonathan Ellis"  wrote:

>I thought we could just pull dtest into another repo managed by C* PMC.  Do
>we need to involve incubator?
>
>On Mon, Nov 21, 2016 at 11:50 AM, Nate McCall  wrote:
>
>> Not sure where we got with the ICLA (and I think filling out the
>> paperwork fell off my plate while we were waiting to hear about that).
>>
>> I'll finish getting the forms together for the Incubator (again,
>> incubation folks also handle review, we don't need to "incubate"
>> dtest) since that was on me.
>>
>> Dave (Jake F. also?) can we still submit to incubator if we can't
>> track down a couple of folks?
>>
>> On Tue, Nov 22, 2016 at 3:56 AM, Jake Luciani  wrote:
>> > I think the main blocker is identifying and contacting the folks who have
>> > contributed code to dtest without an ICLA
>> >
>> > On Mon, Nov 21, 2016 at 4:40 AM, Dave Lester  wrote:
>> >
>> >> I may have missed further email discussion or updates, but since the
>> >> October 3rd email accepting dtest to the project has there been any
>> >> movement?
>> >>
>> >> Nate, is this something you're driving?
>> >>
>> >> Best,
>> >> Dave
>> >>
>> >
>> >
>> >
>> > --
>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_tjake=DgIBaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=Uk2FslKK6ZEMIFTWmSAKed5aEL9McVSp_ei-935cfp4=IeZw5xbZ4cgHs-cJGze8hvFgQAnwL7Ejv2LYvArxKzA=
>> >  
>>
>
>
>
>-- 
>Jonathan Ellis
>co-founder, 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.datastax.com=DgIBaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=Uk2FslKK6ZEMIFTWmSAKed5aEL9McVSp_ei-935cfp4=0BBL8Kzhed_b-2QXqPVo2ws0gqTZAX7Vly3B1coBCU0=
> 
>@spyced


smime.p7s
Description: S/MIME cryptographic signature

Re: Cassandra Mutation object decoding

[Sanal Vasudevan]

Thank you Vladimir.
Anyone else has any other ideas as to how this can be done?


Many thanks,
Sanal


On Sun, Nov 20, 2016 at 4:46 AM, Vladimir Yudovin 
wrote:

> Hi Sanal,
>
>
>
> do we have metadata inside Mutation object to decode whether the CQL
> was an INSERT or UPDATE operation?
>
> I'm not sure it's possible to distinguish them - both of them just add
> data to SSTable.
>
>
>
>
>
> Best regards, Vladimir Yudovin,
>
> Winguzone - Hosted Cloud Cassandra
> Launch your cluster in minutes.
>
>
>
>
>
>  On Fri, 18 Nov 2016 15:55:00 -0500Sanal Vasudevan &
> lt;get2sa...@gmail.com wrote 
>
>
>
>
> Hi there,
>
>
>
> I am trying to read the Commit logs to decode the original CQL which used.
>
> I get to the point an implemention of CommitLogReadHandler is able to push
>
> back Mutation objects from the Commit logs.
>
>
>
> Questions:
>
> 1) CQL: delete from myks.mytable where key1 = 1;
>
> For the above CQL, the Mutation object has zero objects of
>
> org.apache.cassandra.db.rows.Row inside ParitionUpdate object.
>
> Is this the only way to detect a DELETE operation? or we have any other
>
> metadata to indicate a DELETE operation?
>
>  mutation.getPartitionUpdates().forEach(rows - { if(rows.isEmpty())
>
> System.out.println("May be a DELETE operation") });
>
> 2) Likewise do we have metadata inside Mutation object to decode whether
>
> the CQL was an INSERT or UPDATE operation?
>
>
>
> Josh Mckenzie indicated that PartitionUpdate.deletionInfo
>
> (MutableDeletionInfo) may have some information but deletionInfo is
> private.
>
>
>
> Basically, I am looking for help to find a way to classify Mutation object
>
> to INSERT/UPDATE/DELETE with related column and key information.
>
>
>
> Many thanks.
>
> --
>
> Sanal
>
>
>
>
>
>
>


-- 
Sanal Vasudevan Nair

Re: Status of dtest donation?

[Jonathan Ellis]

I thought we could just pull dtest into another repo managed by C* PMC.  Do
we need to involve incubator?

On Mon, Nov 21, 2016 at 11:50 AM, Nate McCall  wrote:

> Not sure where we got with the ICLA (and I think filling out the
> paperwork fell off my plate while we were waiting to hear about that).
>
> I'll finish getting the forms together for the Incubator (again,
> incubation folks also handle review, we don't need to "incubate"
> dtest) since that was on me.
>
> Dave (Jake F. also?) can we still submit to incubator if we can't
> track down a couple of folks?
>
> On Tue, Nov 22, 2016 at 3:56 AM, Jake Luciani  wrote:
> > I think the main blocker is identifying and contacting the folks who have
> > contributed code to dtest without an ICLA
> >
> > On Mon, Nov 21, 2016 at 4:40 AM, Dave Lester  wrote:
> >
> >> I may have missed further email discussion or updates, but since the
> >> October 3rd email accepting dtest to the project has there been any
> >> movement?
> >>
> >> Nate, is this something you're driving?
> >>
> >> Best,
> >> Dave
> >>
> >
> >
> >
> > --
> > http://twitter.com/tjake
>



-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: Status of dtest donation?

[Nate McCall]

Not sure where we got with the ICLA (and I think filling out the
paperwork fell off my plate while we were waiting to hear about that).

I'll finish getting the forms together for the Incubator (again,
incubation folks also handle review, we don't need to "incubate"
dtest) since that was on me.

Dave (Jake F. also?) can we still submit to incubator if we can't
track down a couple of folks?

On Tue, Nov 22, 2016 at 3:56 AM, Jake Luciani  wrote:
> I think the main blocker is identifying and contacting the folks who have
> contributed code to dtest without an ICLA
>
> On Mon, Nov 21, 2016 at 4:40 AM, Dave Lester  wrote:
>
>> I may have missed further email discussion or updates, but since the
>> October 3rd email accepting dtest to the project has there been any
>> movement?
>>
>> Nate, is this something you're driving?
>>
>> Best,
>> Dave
>>
>
>
>
> --
> http://twitter.com/tjake

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

[Sankalp Kohli]

We had decided in an email thread initiated by me that we won't cut releases 
till all tests are passing.

Why not wait till these patches are merged? Is there any critical fix in it 
which need to be rushed out ?

> On Nov 20, 2016, at 23:36, Oleksandr Petrov  
> wrote:
> 
> From just a quick glance, I can say at least some of the tests are either
> PA or are getting there:
> 
> For example:
> http://cassci.datastax.com/job/cassandra-3.X_novnode_dtest/lastCompletedBuild/testReport/paging_test/TestPagingData/test_paging_with_filtering_on_partition_key/
> Should be fixed by
> https://issues.apache.org/jira/browse/CASSANDRA-12666
> 
> http://cassci.datastax.com/job/cassandra-3.X_testall/lastCompletedBuild/testReport/org.apache.cassandra.cql3.validation.entities/SecondaryIndexTest/testAllowFilteringOnPartitionKeyWithSecondaryIndex/
> Should be fixed by
> https://issues.apache.org/jira/browse/CASSANDRA-12651
> 
> Although there can be more tests in PA.
> 
> On Sun, Nov 20, 2016 at 10:35 PM sankalp kohli 
> wrote:
> 
>> Hi,
>>I see the following test runs are failing. Are they for this release?
>> 
>> http://cassci.datastax.com/job/cassandra-3.X_utest_cdc/
>> http://cassci.datastax.com/job/cassandra-3.X_testall/
>> http://cassci.datastax.com/job/cassandra-3.X_offheap_dtest/
>> http://cassci.datastax.com/job/cassandra-3.X_novnode_dtest/
>> http://cassci.datastax.com/job/cassandra-3.X_dtest/40/
>> 
>> Thanks,
>> Sankalp
>> 
>> 
>>> On Sun, Nov 20, 2016 at 12:50 PM, Nate McCall  wrote:
>>> 
>>> +1
>>> 
>>> On Sat, Nov 19, 2016 at 7:08 AM, Michael Shuler 
>>> wrote:
 I propose the following artifacts for release as 3.10.
 
 sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e
 Git:
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>>> shortlog;h=refs/tags/3.10-tentative
 Artifacts:
 https://repository.apache.org/content/repositories/
>>> orgapachecassandra-1135/org/apache/cassandra/apache-cassandra/3.10/
 Staging repository:
 https://repository.apache.org/content/repositories/
>>> orgapachecassandra-1135/
 
 The Debian packages are available here: http://people.apache.org/~
>>> mshuler
 
 The vote will be open for 72 hours (longer if needed).
 
 [1]: (CHANGES.txt) https://goo.gl/vah74X
 [2]: (NEWS.txt) https://goo.gl/In3vp7
 
>>> 
>> 
> -- 
> Alex Petrov

cassandra-3.11 and the new merge order

[Benjamin Lerer]

Hi,

I created a new cassandra-3.11 branch.

By consequence, the new merge order for bug fixe is:

2.2 -> 3.0.X -> 3.11 -> 3.X -> trunk

and the new merge order for improvements is:

3.X -> trunk

3.X will then be released as 3.12 and trunk as 4.0.

Benjamin

Re: Proposals for releases - 4.0 and beyond

[Blake Eggleston]

I really like Stefan's Ubuntu model (because of the LTS release), with 
Sylvain's suggestion a close second. Both because I think we should do a 
supported, non-dev release every 6 months, and release bug fixes for them for a 
at least a year.


On November 19, 2016 at 10:30:02 AM, Stefan Podkowinski (spo...@gmail.com) 
wrote:

I’d like to suggest an option similar to what Jeremiah described and that  
would basically follow the Ubuntu LTS release model [1], but with shorter  
time periods. The idea would be to do a stable release every 6 months with  
1 year bug fixing support. At the same time, every third stable release  
will serve as a LTS release and will be supported for 2 years.  

Have a look at the following gist for illustration:  
https://gist.github.com/spodkowinski/b9659169c73de3231f99bd17f74f5d1f  

As you can see, although the support periods are relatively long, only 3  
releases must be supported at the same time, which should be comparable to  
what is done now.  

At the same time, we also keep doing monthly releases, but they will only  
serve as a milestone for the next stable release. Call them “dev”, “beta”,  
“testing” or whatever you like. Users will be able to start developing for  
those dev releases and deploy to production with the next standard or LTS  
release, after development is finished. Another option for users would be  
to start a project with a standard release and later settle down on a LTS  
release for maintenance only. It's pretty flexible from a user perspective,  
easy to understand and not too much effort to implement from the  
development side.  

On Sat, Nov 19, 2016 at 12:49 AM, Jeff Jirsa   
wrote:  

> With 3.10 voting in progress (take 3), 3.11 in December/January  
> (probably?), we should solidify the plan for 4.0.  
>  
> I went through the archives and found a number of proposals. We (PMC) also  
> had a very brief chat in private to make sure we hadn’t missed any, and  
> here are the proposals that we’ve seen suggested.  
>  
> Option #1: Jon proposed [1] a feature release every 3 months and bugfixes  
> for 6 months after that.  
> Option #2: Mick proposed [2] bimonthly feature, semver, labelling release  
> with stability/quality during voting, 3 GA branches at a time.  
> Option #3: Sylvain proposed [3] feature / testing / stable branches, Y  
> cadence for releases, X month rotation from feature -> testing -> stable ->  
> EOL (X to be determined). This is similar to an Ubuntu/Debian like release  
> schedule – I asked Sylvain for an example just to make sure I understood  
> it, and I’ve copied that to github at [4].  
> Option #4: Jeremiah proposed [5] keeping monthly cadence, and every 12  
> months break off X.0.Y which becomes LTS (same as 3.0.x now). This  
> explicitly excludes alternating tick/tock feature/bugfix for the monthly  
> cadence on the newest/feature/4.x branch.  
> Option #5: Jason proposed a revision to Jeremiah’s proposal such that  
> releases to the LTS branches are NOT tied to a monthly cadence, but are  
> released “as needed”, and the LTS branches are also “as needed”, not tied  
> to a fixed (annual/semi-annual/etc) schedule.  
>  
> Please use this thread as an opportunity to discuss these proposals or  
> feel free to make your own proposals. I think it makes sense to treat this  
> like a nomination phase of an election – let’s allow at least 72 hours for  
> submitting and discussing proposals, and then we’ll open a vote after that.  
>  
> - Jeff  
>  
> [1]: https://lists.apache.org/thread.html/0b2ca82eb8c1235a4e44a406080729  
> be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E  
> [2]: https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b  
> 2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E  
> [3]: https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538ee  
> f34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E  
> [4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf  
> [5]: https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b2  
> 03b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E  
>  
>  
>  
>  
>  

Re: Status of dtest donation?

[Jake Luciani]

I think the main blocker is identifying and contacting the folks who have
contributed code to dtest without an ICLA

On Mon, Nov 21, 2016 at 4:40 AM, Dave Lester  wrote:

> I may have missed further email discussion or updates, but since the
> October 3rd email accepting dtest to the project has there been any
> movement?
>
> Nate, is this something you're driving?
>
> Best,
> Dave
>



-- 
http://twitter.com/tjake

Status of dtest donation?

[Dave Lester]

I may have missed further email discussion or updates, but since the October 
3rd email accepting dtest to the project has there been any movement?

Nate, is this something you're driving?

Best,
Dave