Re: Cassandra-dtest versioning proposal

[Sylvain Lebresne]

I happen to see the fact that the differences between C* version are clearly
visible for a given test as a feature rather than a burden. Every
difference in
behavior between C* versions should have a good reason, and I like that
dtests
highlight them. Typically, from very quickly eyeballing the patch, I saw a
couple of differences between versions I had forgotten or that I'm not
entirely
sure about: it's a good thing, and if we split between branches we largely
lose
that (you'd have to diff the branch to figure out those differences which
imply
you already know what you're looking for). Similarly, I've used dtests a
bunch
of times to check in which version a particular change of behavior was done
and
looking at the '@since' annotation is far easier than having to bisect
through
version branches manually to find when the test was added.

I understand that there is also places where the difference between version
is
due to more boring changes like a change in the spelling of a log message
that
is checked by the test, but is that really such a big burden in practice?
Also,
there is probably some of those cases that could be made cleaner: for
instance,
I can see some diff related to changes in stress that could be partly
abstracted
out.

Anyway, I'm basically not sure "isolating version specific changes to their
own
branches" is necessarily a good thing, so I can't say I'm convinced. But I'm
not writing as much dtests as you guys, so if you think doing so would
substantially facilitate your work, then that's good enough reason (but
you asked for feedback :)).

--
Sylvain

On Thu, Jan 8, 2015 at 9:23 PM, Philip Thompson <
philip.thomp...@datastax.com> wrote:

> All,
>
> I would like to propose splitting the cassandra-dtest code base into
> versioned branches that match the structure of the C* repository. Each C*
> version branch, e.g. cassandra-2.0, would have a corresponding dtest
> branch. This will allow us to isolate version specific changes to their own
> branches, at the cost of extra merging work on contributors to
> cassandra-dtest. I have a WIP and the code has become significantly
> cleaner, and I expect the benefits to grow as we make more radical changes
> to cassandra-dtest for cassandra 3.0.
>
> I am looking for feedback from the contributors to Cassandra that use or
> contribute to cassandra-dtest. Are you in favor of this change?
>
> Thanks,
> Philip Thompson
>
> https://github.com/riptano/cassandra-dtest/compare/cassandra-2.0
> https://github.com/riptano/cassandra-dtest/compare/cassandra-2.1
> https://github.com/riptano/cassandra-dtest/compare/trunk
>

Re: Moving Cassandra's Debian repository from dist to bintray.com/apache

[Jake Luciani]

The docs seems to indicate signing happens at the organization level

https://bintray.com/docs/usermanual/interacting/interacting_gpgsigningforbintrayorganizations.html

Am I able to sign artifacts with my user GPG?  I'm not sure if
everyone is comfortable uploading their private gpg key to bintray.

On Wed, Jan 7, 2015 at 1:40 PM, Andrew Bayer  wrote:
> See https://bintray.com/docs/api/#_debian_upload for how to upload/sign
> artifacts with the Bintray API. Your release managers will need to get
> accounts on Bintray and then open INFRA tickets to get added to the
> Cassandra team in the Apache org there, at which point you'll have full
> admin rights over the cassandra repo there. If you want to start playing
> with it, go ahead and create an account and let me know the username so I
> can invite/add you.
>
> reprepro isn't relevant here - the Bintray Debian repos don't support the
> full range of reprepro's functionality by a long shot, but for what you're
> doing, I don't think you need anything that's not available through the
> Bintray API. Alternatively, if that turns out to not work for you, you can
> use a generic repo that allows you to just upload files/directories, so you
> could keep doing what you're doing now but upload to Bintray rather than
> dist.
>
> Others on the Infra team will know for sure, but I'm pretty confident that a
> redirect from dist to bintray is feasible.
>
> A.
>
> On Wed, Jan 7, 2015 at 10:17 AM, Jake Luciani  wrote:
>>
>> We have a distr per minor version. You can see them here (we only
>> currently use the last 3 major releases 21x, 20x and 12x) you can see them
>> here https://dist.apache.org/repos/dist/release/cassandra/debian/dists/
>>
>> The release managers have a local repo with our reprepro settings.  We
>> deploy the artifact and export locally then copy the whole thing over to the
>> apache dist server.
>> Here is the relevant section of the release script
>> https://github.com/tjake/cassandra-release/blob/master/finish_release.sh#L161
>>
>> As our wiki shows, users add the maintainer keys and the specific dist
>> they want
>> https://wiki.apache.org/cassandra/DebianPackaging
>>
>> Ideally, we can redirect the existing location to the new one but I'm not
>> sure if that's possible.
>>
>> How can we replicate this setup with bintray?
>>
>> -Jake
>>
>>
>> On Wed, Jan 7, 2015 at 12:41 PM, Andrew Bayer 
>> wrote:
>>>
>>> Great! So to start, can you give us a sense of what your needs for the
>>> repo are? What are you putting in it? Are you splitting it up by distro at
>>> all or just putting new versions of Cassandra in each time?
>>>
>>> A.
>>>
>>> On Wed, Jan 7, 2015 at 7:15 AM, Jake Luciani  wrote:

 Hi Andrew,

 I'm happy to help.

 -Jake

 On Tue, Jan 6, 2015 at 2:19 PM, Andrew Bayer  wrote:
>
> Hi Cassandra team -
>
> So as you're probably aware, the Cassandra Debian packages currently on
> dist need to be moved off there. The Infra team has been working on a
> solution for that - we've got an organization for ASF on bintray.com,
> which
> can store and serve Debian repositories. We'd like to work with you all
> on
> moving the existing packages over to bintray, and figuring out what
> needs
> to be done to get a working process for you to post new Debian packages
> going forward. Could someone from Cassandra (or some set of someones)
> be
> available to work with us on this? Thanks!
>
> A.


>>>
>>
>

Re: Cassandra-dtest versioning proposal

[Tyler Hobbs]

On Thu, Jan 8, 2015 at 2:23 PM, Philip Thompson <
philip.thomp...@datastax.com> wrote:

> I expect the benefits to grow as we make more radical changes
> to cassandra-dtest for cassandra 3.0.
>

What kinds of changes are you planning?  Perhaps we can come up with good
alternatives.


-- 
Tyler Hobbs
DataStax 

Re: Moving Cassandra's Debian repository from dist to bintray.com/apache

[Andrew Bayer]

I'm investigating this now - will update when I have more information.

A.

On Fri, Jan 9, 2015 at 7:54 AM, Jake Luciani  wrote:

> The docs seems to indicate signing happens at the organization level
>
>
> https://bintray.com/docs/usermanual/interacting/interacting_gpgsigningforbintrayorganizations.html
>
> Am I able to sign artifacts with my user GPG?  I'm not sure if
> everyone is comfortable uploading their private gpg key to bintray.
>
> On Wed, Jan 7, 2015 at 1:40 PM, Andrew Bayer 
> wrote:
> > See https://bintray.com/docs/api/#_debian_upload for how to upload/sign
> > artifacts with the Bintray API. Your release managers will need to get
> > accounts on Bintray and then open INFRA tickets to get added to the
> > Cassandra team in the Apache org there, at which point you'll have full
> > admin rights over the cassandra repo there. If you want to start playing
> > with it, go ahead and create an account and let me know the username so I
> > can invite/add you.
> >
> > reprepro isn't relevant here - the Bintray Debian repos don't support the
> > full range of reprepro's functionality by a long shot, but for what
> you're
> > doing, I don't think you need anything that's not available through the
> > Bintray API. Alternatively, if that turns out to not work for you, you
> can
> > use a generic repo that allows you to just upload files/directories, so
> you
> > could keep doing what you're doing now but upload to Bintray rather than
> > dist.
> >
> > Others on the Infra team will know for sure, but I'm pretty confident
> that a
> > redirect from dist to bintray is feasible.
> >
> > A.
> >
> > On Wed, Jan 7, 2015 at 10:17 AM, Jake Luciani  wrote:
> >>
> >> We have a distr per minor version. You can see them here (we only
> >> currently use the last 3 major releases 21x, 20x and 12x) you can see
> them
> >> here https://dist.apache.org/repos/dist/release/cassandra/debian/dists/
> >>
> >> The release managers have a local repo with our reprepro settings.  We
> >> deploy the artifact and export locally then copy the whole thing over
> to the
> >> apache dist server.
> >> Here is the relevant section of the release script
> >>
> https://github.com/tjake/cassandra-release/blob/master/finish_release.sh#L161
> >>
> >> As our wiki shows, users add the maintainer keys and the specific dist
> >> they want
> >> https://wiki.apache.org/cassandra/DebianPackaging
> >>
> >> Ideally, we can redirect the existing location to the new one but I'm
> not
> >> sure if that's possible.
> >>
> >> How can we replicate this setup with bintray?
> >>
> >> -Jake
> >>
> >>
> >> On Wed, Jan 7, 2015 at 12:41 PM, Andrew Bayer 
> >> wrote:
> >>>
> >>> Great! So to start, can you give us a sense of what your needs for the
> >>> repo are? What are you putting in it? Are you splitting it up by
> distro at
> >>> all or just putting new versions of Cassandra in each time?
> >>>
> >>> A.
> >>>
> >>> On Wed, Jan 7, 2015 at 7:15 AM, Jake Luciani  wrote:
> 
>  Hi Andrew,
> 
>  I'm happy to help.
> 
>  -Jake
> 
>  On Tue, Jan 6, 2015 at 2:19 PM, Andrew Bayer 
> wrote:
> >
> > Hi Cassandra team -
> >
> > So as you're probably aware, the Cassandra Debian packages currently
> on
> > dist need to be moved off there. The Infra team has been working on a
> > solution for that - we've got an organization for ASF on bintray.com
> ,
> > which
> > can store and serve Debian repositories. We'd like to work with you
> all
> > on
> > moving the existing packages over to bintray, and figuring out what
> > needs
> > to be done to get a working process for you to post new Debian
> packages
> > going forward. Could someone from Cassandra (or some set of someones)
> > be
> > available to work with us on this? Thanks!
> >
> > A.
> 
> 
> >>>
> >>
> >
>

Re: Cassandra-dtest versioning proposal

[Philip Thompson]

The change that prompted the idea is CASSANDRA-8454. As we attempt to move
cql_tests.py and other single node, CQL based dtests into unit tests in 2.1
and 3.0+, we will have a large number of tests, in the low hundreds, that
not only have minimum version restrictions, but will only be applicable for
a particular slice of C* versions, e.g. 2.0.X < x < 2.1.3.

On Fri, Jan 9, 2015 at 12:01 PM, Tyler Hobbs  wrote:

> On Thu, Jan 8, 2015 at 2:23 PM, Philip Thompson <
> philip.thomp...@datastax.com> wrote:
>
> > I expect the benefits to grow as we make more radical changes
> > to cassandra-dtest for cassandra 3.0.
> >
>
> What kinds of changes are you planning?  Perhaps we can come up with good
> alternatives.
>
>
> --
> Tyler Hobbs
> DataStax 
>

[VOTE] Release Apache Cassandra 2.0.12

[Jake Luciani]

I propose the following artifacts for release as 2.0.12.

sha1: df1f5ead0950d4d3058cf6fe0fcae9ef528014fa
Git: 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.12-tentative
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1041/org/apache/cassandra/apache-cassandra/2.0.12/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1041/

The artifacts as well as the debian package are also available here:
http://people.apache.org/~jake

The vote will be open for 72 hours (longer if needed).

[1]: http://goo.gl/7JmQWg (CHANGES.txt)
[2]: http://goo.gl/bqxiFR (NEWS.txt)

Re: [VOTE] Release Apache Cassandra 2.0.12

[Ryan McGuire]

dtests looks good except for CASSANDRA-7281
, but looks like that
got pushed up to 2.0.13.

On Fri, Jan 9, 2015 at 5:34 PM, Jake Luciani  wrote:

> I propose the following artifacts for release as 2.0.12.
>
> sha1: df1f5ead0950d4d3058cf6fe0fcae9ef528014fa
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.12-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1041/org/apache/cassandra/apache-cassandra/2.0.12/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1041/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/7JmQWg (CHANGES.txt)
> [2]: http://goo.gl/bqxiFR (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 2.0.12

[Jonathan Ellis]

+1
On Jan 9, 2015 4:35 PM, "Jake Luciani"  wrote:

> I propose the following artifacts for release as 2.0.12.
>
> sha1: df1f5ead0950d4d3058cf6fe0fcae9ef528014fa
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.12-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1041/org/apache/cassandra/apache-cassandra/2.0.12/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1041/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/7JmQWg (CHANGES.txt)
> [2]: http://goo.gl/bqxiFR (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 2.0.12

[Aleksey Yeschenko]

+1

-- 
AY

On January 10, 2015 at 1:35:46 AM, Jake Luciani (j...@apache.org) wrote:

I propose the following artifacts for release as 2.0.12.  

sha1: df1f5ead0950d4d3058cf6fe0fcae9ef528014fa  
Git: 
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.12-tentative
  
Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1041/org/apache/cassandra/apache-cassandra/2.0.12/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1041/  

The artifacts as well as the debian package are also available here:  
http://people.apache.org/~jake  

The vote will be open for 72 hours (longer if needed).  

[1]: http://goo.gl/7JmQWg (CHANGES.txt)  
[2]: http://goo.gl/bqxiFR (NEWS.txt)