Re: CQL Drivers
On Fri, Sep 2, 2011 at 3:49 PM, Jonathan Ellis wrote: > On Thu, Sep 1, 2011 at 9:08 AM, Eric Evans wrote: >> I posed a similar question about the JDBC driver in CASSANDRA-2936. >> >> Should these tests be considered functional tests of Cassandra, and >> left be left where they are? I know that was my intention WRT >> test_cql.py (the driver itself has a few tests of its own that do not >> require a server). >> >> I guess I don't have a strong opinion either way, though it seems >> easier to say that Cassandra's tests will require you to have a driver >> installed, versus having to configure the build/test of a driver to >> point to a Cassandra tree. > > I'd lean towards "the tests should be in the client trees." It feels > odd to move the drivers out, but leave their test suites in core. > (Keeping in mind that, as you pointed out, we have two more drivers > almost done.) Referring to the mail I sent before seeing this does that mean option #1 or #3, require a Cassandra tree, or point to running instance? -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
On Thu, Sep 1, 2011 at 9:08 AM, Eric Evans wrote: > On Wed, Aug 31, 2011 at 10:58 PM, Jonathan Ellis wrote: >> On Wed, Aug 31, 2011 at 4:24 PM, Eric Evans wrote: >>> CASSANDRA-2936 is in progress (patches attached), but is there any >>> reason not to get started with the Python driver now? >> >> Heads up that test/system/test_cql.py depends on the Python driver. >> It should probably be moved to the Python driver's test suite. (Which >> then needs the same kind of "start a Cassandra server" ability that >> the Cassandra system tests have.) > > I posed a similar question about the JDBC driver in CASSANDRA-2936. > > Should these tests be considered functional tests of Cassandra, and > left be left where they are? I know that was my intention WRT > test_cql.py (the driver itself has a few tests of its own that do not > require a server). > > I guess I don't have a strong opinion either way, though it seems > easier to say that Cassandra's tests will require you to have a driver > installed, versus having to configure the build/test of a driver to > point to a Cassandra tree. No opinions on this? To summarize, the options as I see them are: 1. Keep the tests that query Cassandra, as-is, with the drivers they use. 2. Leave the tests that query Cassandra with Cassandra, (i.e. consider them Cassandra tests). 3. Keep the tests that query Cassandra, but alter them to be idempotent and to connect to an existent node, instead of spinning up/down an instance in test setup/teardown. (1) requires that you have some way of pointing the build at a local copy of a Cassandra tree (as I remember it, there were some that didn't care for this). (2) means that you'd need the corresponding driver installed (or an embedded copy as the case may be) in order to run those tests. (3) seems to be most consistent with how other people do it for code that connects to some service. -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
On Wed, Aug 31, 2011 at 10:58 PM, Jonathan Ellis wrote: > On Wed, Aug 31, 2011 at 4:24 PM, Eric Evans wrote: >> CASSANDRA-2936 is in progress (patches attached), but is there any >> reason not to get started with the Python driver now? > > Heads up that test/system/test_cql.py depends on the Python driver. > It should probably be moved to the Python driver's test suite. (Which > then needs the same kind of "start a Cassandra server" ability that > the Cassandra system tests have.) I posed a similar question about the JDBC driver in CASSANDRA-2936. Should these tests be considered functional tests of Cassandra, and left be left where they are? I know that was my intention WRT test_cql.py (the driver itself has a few tests of its own that do not require a server). I guess I don't have a strong opinion either way, though it seems easier to say that Cassandra's tests will require you to have a driver installed, versus having to configure the build/test of a driver to point to a Cassandra tree. -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
On Tue, Aug 30, 2011 at 8:26 AM, Jonathan Ellis wrote: > On Mon, Aug 29, 2011 at 10:16 PM, Eric Evans wrote: >> No one else has sounded off on this, does that mean it's safe to >> assume there is consensus on this? > > Looks like it. The opinions on irc were positive, too. > >> If so, is it Apache Extras or Github (either would be fine by me). > > No strong feelings here. CASSANDRA-2936 is in progress (patches attached), but is there any reason not to get started with the Python driver now? It'd be nice to have this all in place for 1.0. We also seem to be getting somewhat close (?) to having drivers for PHP and Ruby, and it'd be nice if we didn't have to double-handle them. -- Eric Evans Acunu | http://www.acunu.com | @acunu
[VOTE] release 0.7.9 (redux)
If at first you don't succeed[3], try, try again; I propose the following for release as 0.7.9. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1163795 Debian Package Artifacts: http://people.apache.org/~eevans Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-008/ The vote will be open for 72 hours, or until the next lunar apogee if needed. Thanks, [1]: http://goo.gl/uenGn (CHANGES.txt) [2]: http://goo.gl/AQ2KY (NEWS.txt) [3]: http://article.gmane.org/gmane.comp.db.cassandra.devel/4081 -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 0.7.9
On Tue, Aug 30, 2011 at 1:08 AM, Sylvain Lebresne wrote: > I'm back from that beach. Eric, do you want me to do the re-roll ? I was planning to, (later this morning or early afternoon), but if you'd rather take it, you're welcome to it. :) Also, welcome back. -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
On Tue, Aug 30, 2011 at 5:34 AM, Robert Jackson wrote: > On Aug 29, 2011, at 11:17 PM, Eric Evans wrote: >> If so, is it Apache Extras or Github (either would be fine by me). >> > Either would be good, but I have a preference for GitHub (easier workflow). Generally I prefer Github too, but the branding is better on Apache Extras. I almost want to say that Google's issue tracker is better too, but maybe not. I guess if we're fair about it, the ability to choose between Git, Mercurial, and Subversion is probably a "feature" as well. :) -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
On Thu, Aug 25, 2011 at 1:49 PM, Eric Evans wrote: > On Wed, Aug 24, 2011 at 11:57 PM, Jonathan Ellis wrote: >> The git mirror is also a symptom of a deeper problem. Managing the >> drivers from the same Jira system as core is awkward too. Nor does >> three-day release voting or patch-oriented development feel like a >> good fit for CQL drivers. > > I emphatically agree. > >> If we're going to move the drivers out-of-tree, why not move them all >> the way to github? We'll still be able to link "official" drivers >> from cassandra.apache.org, so I'm not worried about the kind of >> fragmentation we have with Thrift clients today. But if we want a >> little more official-ness, we could use Apache Extras on google code >> instead. Which IMO has better bug tracker and code review systems, >> but I don't really have strong feelings either way. >> >> So, of the problems with the original move, the cqlsh "problem" is the >> only one that by definition can't be solved if we move the drivers out >> of tree. I'm not enthusiastic about inflicting that on ourselves in >> exchange for problems with the git mirror. But in exchange for a >> clean separation as a separate project? That makes more sense to >> me.** > > Setting aside my shock from a suggestion that is 1000 miles in the > opposite direction, I love it. No one else has sounded off on this, does that mean it's safe to assume there is consensus on this? If so, is it Apache Extras or Github (either would be fine by me). -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CqlResult in CassandraConnection
On Sun, Aug 28, 2011 at 3:47 AM, Vivek Mishra wrote: > Recently i can see changes made in jdbc connection API. > > Wondering why are we returning CqlResult from CassandraConnection, ideally it > should return ResultSet as jdbc api. > > Any thoughts? The execute methods aren't a part of the java.sql.Connection interface, but they are public, and so shouldn't be returning Thrift structs. Maybe we just need to drop the public modifier. Can you open a ticket Vivek? -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: [VOTE] Release Apache Cassandra 0.7.9
On Fri, Aug 26, 2011 at 11:36 AM, Jonathan Ellis wrote: > Is this really a -1-worthy problem? It will log an assertion but my > reading is that GCInspector should continue to run the next time it is > scheduled. What's the verdict here? Should we close out this vote and re-roll after https://issues.apache.org/jira/browse/CASSANDRA-3076 is resolved? > On Thu, Aug 25, 2011 at 9:31 AM, Jake Luciani wrote: >> -1 due to https://issues.apache.org/jira/browse/CASSANDRA-3076 >> >> On Tue, Aug 23, 2011 at 5:06 PM, Eric Evans wrote: >> >>> While Sylvain is sunning himself on a beach somewhere[3], I propose >>> the following for release as 0.7.9[4]. >>> >>> SVN: >>> https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1160879 >>> Debian Package Artifacts: http://people.apache.org/~eevans >>> Staging repository: >>> https://repository.apache.org/content/repositories/orgapachecassandra-063 >>> >>> The vote will remain open for 72 hours, or until the autumnal equinox if >>> needed. >>> >>> Thanks, >>> >>> [1]: http://goo.gl/1b0Jj (CHANGES.txt) >>> [2]: http://goo.gl/TSqrq (NEWS.txt) >>> [3]: I made that up, I've no idea what he's doing. >>> [4]: It's an assist, not a coup. >>> [5]: http://goo.gl/zPOD >>> >>> -- >>> Eric Evans >>> Acunu | http://www.acunu.com | @acunu >>> >> >> >> >> -- >> http://twitter.com/tjake >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com > -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
On Wed, Aug 24, 2011 at 11:57 PM, Jonathan Ellis wrote: > The JDBC problems can be subdivided into two categories: too-tight > coupling that having it in-tree masks (but is really a problem either > way), and java build systems being a PITA. By the second part I mean, > yes, we had JDBC building after the first month or so, but it still > required that the main Cassandra source tree be checked out and built > locally, with a cumbersome manual process to point the driver build to > it. > > The build headache is actually a symptom of the coupling. None of the > other drivers have this problem; they were forced to do things > "right"* instead of re-using things that shouldn't be re-used. If we > were going to take another stab at it we should fix this first. (More > accurately, we should fix it anyway whether we move drivers or not.) The other drivers never had any choice but to create their own implementations of term encoding/decoding, which you could probably use as an argument for us inflicting this whole mess on ourselves with the JDBC driver. That said, I agree that the Right solution is still to fix the tight coupling and reuse. > The git mirror is also a symptom of a deeper problem. Managing the > drivers from the same Jira system as core is awkward too. Nor does > three-day release voting or patch-oriented development feel like a > good fit for CQL drivers. I emphatically agree. > If we're going to move the drivers out-of-tree, why not move them all > the way to github? We'll still be able to link "official" drivers > from cassandra.apache.org, so I'm not worried about the kind of > fragmentation we have with Thrift clients today. But if we want a > little more official-ness, we could use Apache Extras on google code > instead. Which IMO has better bug tracker and code review systems, > but I don't really have strong feelings either way. > > So, of the problems with the original move, the cqlsh "problem" is the > only one that by definition can't be solved if we move the drivers out > of tree. I'm not enthusiastic about inflicting that on ourselves in > exchange for problems with the git mirror. But in exchange for a > clean separation as a separate project? That makes more sense to > me.** Setting aside my shock from a suggestion that is 1000 miles in the opposite direction, I love it. > * actually, relying on manual updating of Thrift is definitely > suboptimal, but we've gotten away with it since the Thrift API hasn't > been changing much. A better solution might use an svn:external > reference to the interface/ directory. Not sure what we can do other > than copy the .thrift file if we move to git though. Maybe we should consider publishing releases of generated code versioned using the VERSION constant. > ** And yes, I do remember arguing for keeping them in-project > originally. Mea culpa. -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
On Wed, Aug 24, 2011 at 10:09 PM, Gary Dusbabek wrote: > On Wed, Aug 24, 2011 at 17:22, Eric Evans wrote: >> There are some workarounds that have been proposed for moving the >> drivers back under Cassandra's source tree while creating independent >> releases from there. For example, keeping them only in trunk/ and >> deleting drivers/ in new branches (which doesn't solve the case for >> #3010). In my opinion, these are half-measures that fail to create >> the needed separation while making the release process brittle, or >> complicated, or both, and generate confusion (which incidentally is >> exactly why they were moved in the first place). > > Some apache projects organize their code into multiple trunks, and > that sounds like it would help us out here. If you mean what Stephen describes here, http://article.gmane.org/gmane.comp.db.cassandra.devel/3974, then I'd be down for it. Seems like it would be pretty disruptive though. -- Eric Evans Acunu | http://www.acunu.com | @acunu
CQL Drivers
There's been discussion happening in #2761 (https://issues.apache.org/jira/browse/CASSANDRA-2761) on and off now for more than 3 months, and I think it could benefit from some wider exposure. The issue was created in the wake of the driver move from asf/cassandra/trunk/drivers to asf/cassandra/drivers and the original scope was to create a working build for the JDBC driver post-move (at the time it had no build of its own). That work has since been completed, but it was left open to include some related items, in hindsight it should have been closed and other issues opened as needed. The remainder of the discussion that's taken place in CASSANDRA-2761 revolves around moving the driver code back under Cassandra's tree. I don't want this to happen because, as I've mentioned elsewhere, drivers are supposed to be coded to a specification, not a Cassandra version; Any given driver release is expected to work with any version of Cassandra that uses a CQL version >= to that of the driver. As such there is a need to release them independently, with their own versions, on a more or less frequently basis than Cassandra does. To this point I think there is agreement. Where we disagree I guess is in how to accomplish this. Moving the driver has made things less convenient in part because in it's current location it isn't mirrored by git.apache.org, and in part because it's quite obviously less convenient than having everything all in one monolithic tree. Most often cited for the latter is #3010 (https://issues.apache.org/jira/browse/CASSANDRA-3010), an issue opened to create a CQL-based shell written in Java. The lack of Git mirroring is unfortunate, but shouldn't be a blocker IMO since the equivalent could be accomplished using git-svn. I would however be willing to do this once, for everyone, and publish the result on Github if that would help. As for cases like #3010, these are applications and it's no more or less convenient than it would be for any other application. If the JDBC driver is unsuitable for use by us as a dependency, then it's unsuitable for our users as well. My suggestion here was to do what we do with every other dependency we have and store a jar in lib/. There are some workarounds that have been proposed for moving the drivers back under Cassandra's source tree while creating independent releases from there. For example, keeping them only in trunk/ and deleting drivers/ in new branches (which doesn't solve the case for #3010). In my opinion, these are half-measures that fail to create the needed separation while making the release process brittle, or complicated, or both, and generate confusion (which incidentally is exactly why they were moved in the first place). One other point that seems relevant is that all of the discussion has centered around the JDBC driver only. If we were to eliminate it from the equation, it appears there'd be no (or at least a lot less) opposition to the move. This seems to reinforce the idea that we're special-casing our own uses. Thoughts? Suggestions? -- Eric Evans Acunu | http://www.acunu.com | @acunu
[VOTE] Release Apache Cassandra 0.7.9
While Sylvain is sunning himself on a beach somewhere[3], I propose the following for release as 0.7.9[4]. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1160879 Debian Package Artifacts: http://people.apache.org/~eevans Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-063 The vote will remain open for 72 hours, or until the autumnal equinox if needed. Thanks, [1]: http://goo.gl/1b0Jj (CHANGES.txt) [2]: http://goo.gl/TSqrq (NEWS.txt) [3]: I made that up, I've no idea what he's doing. [4]: It's an assist, not a coup. [5]: http://goo.gl/zPOD -- Eric Evans Acunu | http://www.acunu.com | @acunu
Re: Questions regarding the future of CQL
On Fri, 2011-07-29 at 09:28 +1200, Todd Nine wrote: > 1. Will CQL ultimately replace thrift as a client api? Personally, I don't think there is a lot of room for alternative interfaces at this level. Which is to say that ultimately, one will become the de facto standard just because that's what everyone uses. More and more that looks like it will be CQL. > 2. If CQL will become the interface, has any thought been given to > order by and rownum equivalent functionality in CQL? This seems like > a major requirement for most webapps when dealing with secondary > indexing and paging. Currently I handle this with dynamic composites, > and build a secondary query index with ordering via columns by adding > order fields between the indexed fields and the RK in my column. > Would something like this be possible directly in Cassandra, or would > Lucene style iterators be preferred? Personally, I prefer to take the > disk space hit and construct the ordering at the column level. If I understand what you're asking, then it doesn't sound like a CQL issue per say. For example, the RPC API doesn't allow reordering of row keys because it would be prohibitively expensive in the general case, and this is no different for CQL. > 3. Do you guys feel I should focus efforts on improving the CQL > functionality then migrating the JPA plugin to it, or do you feel it > is too early to begin using the JDBC CQL drivers for this type of > functionality? Short of things like super columns, the functionality is equivalent, so I would say go for it. -- Eric Evans eev...@rackspace.com
Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
On Sun, 2011-07-24 at 11:33 +0300, David Boxenhorn wrote: > Could we have a strict mode that would enforce quoting terms (this would be > used in code) and a lax version that could be used in interactive mode, > where backward compatibility is not so important? It's possible, but the skeptic (cynic?) in me thinks that's just one more variable in the equation, and one people will frequently trip over. > > > On Fri, Jul 22, 2011 at 6:10 PM, Eric Evans > > > > I have a feeling that #2 is easier said than done. So long as we're > > > > allowing the unquoted form, people will use it and be surprised when > > > > bit. Aside from that it seems OK. -- Eric Evans eev...@rackspace.com
Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
On Fri, 2011-07-22 at 21:29 -0500, paul cannon wrote:
> I definitely vote for reserving words that are expected to be needed
> in the future. It seems we have a pretty good chance of predicting
> most of the syntactical needs for the next couple years (especially
> with suggestions from common SQL variants), and the (hopefully) rare
> exceptions could get their major version bumps.
I agree that of the 3, the "reserve future keywords; bump major when
expanding the list becomes necessary" option looks the best on paper,
but I'm skeptical that it will work in practice.
Reserving SQL keywords is a given (we should probably do that anyway),
but that wouldn't have been enough to catch the case that tripped us up,
("type" is not a reserved word). And, considering how much
back-and-forth there is over syntax, before, during, and after an
implementation, I could definitely see us bumping that major more than
once every 2 years.
It *could* work, it would just require a great deal of discipline.
> 2 and 3 feel like they would cripple CQL too much.
Option 2 isn't so much crippling IMO, as it is weak. That being said, I
already council people to quote all of their terms for everything but
interactively entered queries or trivial tests, so it doesn't seem like
*too* much of a stretch.
For the record, I dislike all 3 of these options and am hoping someone
offers an alternative that blows me away. :)
> On Fri, Jul 22, 2011 at 6:10 PM, Eric Evans
> wrote:
>
> >
> > I just ran into an issue where CQL queries that were written at the
> time
> > of 0.8.0 no longer work against 0.8.1. This was caused by r1130200
> > (CASSANDRA-1709) which introduced ALTER support. The queries in
> > question made use of unquoted terms for one of the newly added
> keywords
> > ("type" in this case though any one of "alter", "table" or "add"
> would
> > have caused the same problem).
> >
> > This case never occurred to me, but it is fairly serious since it
> breaks
> > the expectation that code will remain backward compatible. The
> options
> > I see are:
> >
> > 1. Bump the major of the language version when new keywords are
> added.
> > 2. Set the expectation that unquoted terms could collide with future
> > keywords.
> > 3. Disallow the unquoted term variant (would require bumping the
> major
> > once).
> >
> > #1 sucks because building out new features that would otherwise be
> > backward compatible will result in a major bump. Looking at the
> roadmap
> > and trying to reserve everything now that we'll need for the
> foreseeable
> > future might make this less of an issue though.
> >
> > I have a feeling that #2 is easier said than done. So long as we're
> > allowing the unquoted form, people will use it and be surprised when
> > bit. Aside from that it seems OK.
> >
> > #3 is probably the most technically correct solution, but would make
> > hand-crafted queries entered into interactive interpreters less
> > friendly.
--
Eric Evans
eev...@rackspace.com
Backward incompatible CQL changes 0.8.0 -> 0.8.1
I just ran into an issue where CQL queries that were written at the time
of 0.8.0 no longer work against 0.8.1. This was caused by r1130200
(CASSANDRA-1709) which introduced ALTER support. The queries in
question made use of unquoted terms for one of the newly added keywords
("type" in this case though any one of "alter", "table" or "add" would
have caused the same problem).
This case never occurred to me, but it is fairly serious since it breaks
the expectation that code will remain backward compatible. The options
I see are:
1. Bump the major of the language version when new keywords are added.
2. Set the expectation that unquoted terms could collide with future
keywords.
3. Disallow the unquoted term variant (would require bumping the major
once).
#1 sucks because building out new features that would otherwise be
backward compatible will result in a major bump. Looking at the roadmap
and trying to reserve everything now that we'll need for the foreseeable
future might make this less of an issue though.
I have a feeling that #2 is easier said than done. So long as we're
allowing the unquoted form, people will use it and be surprised when
bit. Aside from that it seems OK.
#3 is probably the most technically correct solution, but would make
hand-crafted queries entered into interactive interpreters less
friendly.
Thoughts?
--
Eric Evans
eev...@rackspace.com
Re: Reoganizing drivers
On Tue, 2011-07-12 at 16:47 -0700, Jonathan Ellis wrote:
> >> What do you mean by "but not have multiple versions for 0.8
> branch"?
>
> I mean it would live in trunk but only in trunk -- there would be no
> branches/0.8/drivers or branches/1.0/drivers.
Maybe I'm missing some svn-fu here, but how would you even do this?
Delete the directory after branching? Wouldn't merging forward to trunk
try to remove it there again?
>
> > Can't we keep the /drivers code in the trunk and just have separate
> Ant tasks for building the driver parts independent of the tasks for
> for the server?
>
> Right, this feels ideal to me. Otherwise the "right" way to handle it
> is to download a Cassandra stuff-the-driver-needs jar from the maven
> repo. I'd rather just have {cassandra} and {driver} build targets
> personally, from the same tree, rather than introducing this
> intermediate dependency.
The JDBC driver seems to be the only reason this is being brought up,
there wouldn't be much to discuss if you removed that from the equation.
None of the original reasons for moving the drivers in the first place
have changed.
I don't think the story here is any different than it would be for any
other project that depended on Cassandra like this, (i.e. it would be
unnecessarily difficult for them as well). Of course it will never be
as easy as treating it all like one big monolithic project, but it could
be a whole lot easier (for anyone) and if it makes sense that they be
treated separately (I feel strongly that it does), then I'd rather we
fix it the right way.
I realize that implicitly means that I've volunteered. :)
--
Eric Evans
eev...@rackspace.com
Re: Reoganizing drivers
On Sat, 2011-07-09 at 23:29 -0400, Rick Shaw wrote: > On Jul 7, 2011, at 10:53 AM, Eric Evans wrote: > > On Wed, 2011-07-06 at 13:33 -0500, Jonathan Ellis wrote: > >> - building the Java drivers is fragile and complicated, and > >> there's a lot of duplication with the "main" ant build > > > > Fragile how so? Because of the build-dependency on Cassandra > > (and/or how it is satisfied)? > Yes. The issues with the former are something that need to be solved either way. Fixing that would all but take care of the latter, but there are things that could be done there in the meantime. It seems like the biggest problem is that there seems to be very little progress here at all recently; I'll try and peel off some time in the next few days to help. -- Eric Evans eev...@rackspace.com
Re: Reoganizing drivers
On Wed, 2011-07-06 at 13:33 -0500, Jonathan Ellis wrote: > - the git mirror won't pick up anything under drivers/ Has there been any effort made to have INFRA add it? > - building the Java drivers is fragile and complicated, and there's a > lot of duplication with the "main" ant build Fragile how so? Because of the build-dependency on Cassandra (and/or how it is satisfied)? What duplication are you referring to? I don't see much beyond all of the boilerplate you'd see between any two ant projects. > - patches that affect both Cassandra and JDBC are cumbersome since > they have to be committed separately (e.g. > https://issues.apache.org/jira/browse/CASSANDRA-2857) Well, the idea of moving it was to be able to treat it as a separate project (more or less), so it follows that you'd have to independently patch anything using AbstractCassandraDaemon. Well, it follows that if we change an API that any project using it will need to be updated as well. Since the idea behind moving the drivers was to be able to treat them as separate projects, it follows that we'd have to do it here as well. > I'm inclined to think we should move it back to trunk (but not have > multiple versions for 0.8 branch). We can still tag/branch separately > from there. What do you mean by "but not have multiple versions for 0.8 branch"? -- Eric Evans eev...@rackspace.com
Re: thrift generated java changes
On Sat, 2011-07-02 at 22:29 -0400, Joseph Stein wrote: > right now I just manually put this function back in since it is the > only thing (well the license too of course) that the generation > changed from what is in source besides my change required. I wouldn't worry much about this. Do the best you can when it comes to matching thrift compiler to the currently supported version, and then put any changes to generated files in a separate patch (the important change here is the IDL). If the person committing is concerned about what was generated, then they can always regenerate using their own compiler. -- Eric Evans eev...@rackspace.com
Re: Cassandra 1.0
On Thu, 2011-06-16 at 16:36 +0200, Sylvain Lebresne wrote: > Sticking to that 4 months schedule, I propose the following deadlines: > - September 8th: feature freeze > - October 8th: release (tentative date) +1 -- Eric Evans eev...@rackspace.com
Re: Cassandra 1.0
On Thu, 2011-06-16 at 09:15 -0700, Ryan King wrote: > I think maybe 4 months was too short? Do we optimistically want to try > that again or plan on taking a bit more time? I think 4 months is about the right amount of time. Also, our upgrade story is better than it has ever been, which changes things here considerably. > Either way I'm happy to have a plan. :) Yup. -- Eric Evans eev...@rackspace.com
Re: Reoganizing drivers
On Tue, 2011-06-07 at 18:40 +0200, Sylvain Lebresne wrote: > On Tue, Jun 7, 2011 at 3:18 PM, Jonathan Ellis > wrote: > > Sounds fine as far as it goes, but don't we want some concept of > > branches/tags for driver releases too? > > Our idea so far (Eric can correct me if I'm wrong :)) was to consider > the drivers directory as the 'trunk' for drivers, and create branches > and tags for them alongside the cassandra ones. Yup. In fact, I already tagged the Python and Java drivers as tags/drivers// during the last release (neither of those driver artifacts corresponded to the same SVN rev, nor did they correspond to the rev for 0.8.0). > > Truth is, I even think that consider the drivers as a whole is not > granular enough. It's unlikely the different drivers will move at the > same pace. As far as I know, there is no reason that a tag (say tags/drivers/py/1.1.1) can't point to a subdirectory of drivers/ (i.e. drivers/py). In fact, that's how the tags mentioned above were done (except those pointed to branches/cassandra-0.8.0/drivers/). I think it just boils down to a matter convention. > > *But*, we believe that moving the drivers up one level is at least a > first step towards something better than the status quo. Yeah, even if we decide to do something different later on, this is an improvement over what we have now. -- Eric Evans eev...@rackspace.com
Reoganizing drivers
Sylvain and I have been discussing release issues while here at buzzwords, and some of the issues are related to drivers. Not surprising since that's a new concept for us, and there wasn't much thought given to the current organization. Because the CQL drivers are independently versioned and capable of releasing on their own timelines, the current location in SVN is suboptimal. There are a number of reasons why, not least of which is that it sets the expectation that the correct version of a driver is whatever corresponds to the release version of Cassandra. So, we'd like to move the drivers sub-directory up one level, making it look something like the following: |- branches |- tags |- site |- drivers | |- java | |- py | |- txpy |- trunk There are a few additional implied changes here as well, for example the JDBC driver will need its own build, and Cassandra's will need some minor changes as well (JDBC driver tests, release artifacts, etc). Does anyone object to this? -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] Release Apache Cassandra 0.8.0 (take #3)
On Mon, 2011-05-30 at 14:04 -0500, Eric Evans wrote: > OK, let's try this yet again; I propose the following artifacts for release > as 0.8.0 (final). > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8.0@r1129278 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-018/ > Driver Artifacts and Debian Package: http://people.apache.org/~eevans > > The vote will remain open for 72 hours (longer if needed). Wow. I count 7 binding +1s and 1 other, and no -1s. The vote passes! I'll get everything published and whatnot presently. > [1]: http://goo.gl/QY5dm (CHANGES.txt) > [2]: http://goo.gl/CrJqJ (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE] Release Apache Cassandra 0.8.0 (take #3)
OK, let's try this yet again; I propose the following artifacts for release as 0.8.0 (final). SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8.0@r1129278 Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-018/ Driver Artifacts and Debian Package: http://people.apache.org/~eevans The vote will remain open for 72 hours (longer if needed). [1]: http://goo.gl/QY5dm (CHANGES.txt) [2]: http://goo.gl/CrJqJ (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE] Release Apache Cassandra 0.8.0 (take #2)
OK, let's try this again; I propose the following artifacts for release as 0.8.0 (final). SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8.0@r1127672 Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-010 Driver Artifacts and Debian Package: http://people.apache.org/~eevans The vote will remain open for 72 hours (longer if needed). [1]: http://goo.gl/tjU2P (CHANGES.txt) [2]: http://goo.gl/NII5h (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE CLOSED] was: [VOTE] Release Apache Cassandra 0.8.0
On Tue, 2011-05-24 at 22:22 -0500, Jonathan Ellis wrote: > Pig is broken in this build; Brandon fixed it in r1127188. So considering this vote closed. > On Mon, May 23, 2011 at 6:09 PM, Eric Evans wrote: > > > > I propose the following artifacts for release as 0.8.0 (final). > > > > SVN: > > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8.0@r1126747 > > Artifacts: > > https://repository.apache.org/content/repositories/orgapachecassandra-002/ > > Driver Artifacts and Debian Package: http://people.apache.org/~eevans > > > > The vote will remain open for 72 hours (longer if that's what it takes). > > > > [1]: http://goo.gl/wlt2e (CHANGES.txt) > > [2]: http://goo.gl/jR5sU (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0
On Tue, 2011-05-24 at 22:22 -0500, Jonathan Ellis wrote: > Pig is broken in this build; Brandon fixed it in r1127188. Are we blocking releases for contrib and example code now? -- Eric Evans eev...@rackspace.com
[VOTE] Release Apache Cassandra 0.8.0
I propose the following artifacts for release as 0.8.0 (final). SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8.0@r1126747 Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-002/ Driver Artifacts and Debian Package: http://people.apache.org/~eevans The vote will remain open for 72 hours (longer if that's what it takes). [1]: http://goo.gl/wlt2e (CHANGES.txt) [2]: http://goo.gl/jR5sU (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE CLOSED] was: [VOTE] Release Apache Cassandra 0.8.0 rc1 (take 2)
On Thu, 2011-05-12 at 19:13 -0500, Eric Evans wrote: > OK, let's try this again; I propose the following artifacts for release > as 0.8.0 RC1. > > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1102510 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-009/ > Driver Artifacts and Debian Package: http://people.apache.org/~eevans > > The will remain open for 72 hours, (longer if need be). I count 5 +1s and no -1s; The vote passes. I'll get things published. > [1]: http://goo.gl/Rh3A3 (CHANGES.txt) > [2]: http://goo.gl/wbXGM (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0 rc1 (take 2)
On Fri, 2011-05-13 at 12:06 -0500, Jonathan Ellis wrote: > cqlsh is broken in these artifacts. (I've fixed it in r1102793.) There hasn't been a lot of thought put into the When and How, but we should be able to release drivers independently. When the vote was first called, I didn't even include the Python driver since it wouldn't have resulted in a new version. So, I've create an artifact for version 1.0.2 of the Python driver that corresponds to r1102850, and placed that along-side the new JDBC driver and the 0.8.0~rc2 Debian package. If no one objects, I'd like to leave this vote running on the existing timetable, and have it be inclusive of this new artifact. > On Thu, May 12, 2011 at 7:13 PM, Eric Evans > wrote: > > > > OK, let's try this again; I propose the following artifacts for > release > > as 0.8.0 RC1. > > > > SVN: > > > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1102510 > > Artifacts: > > > https://repository.apache.org/content/repositories/orgapachecassandra-009/ > > Driver Artifacts and Debian Package: > http://people.apache.org/~eevans -- Eric Evans eev...@rackspace.com
[VOTE] Release Apache Cassandra 0.8.0 rc1 (take 2)
OK, let's try this again; I propose the following artifacts for release as 0.8.0 RC1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1102510 Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-009/ Driver Artifacts and Debian Package: http://people.apache.org/~eevans The will remain open for 72 hours, (longer if need be). [1]: http://goo.gl/Rh3A3 (CHANGES.txt) [2]: http://goo.gl/wbXGM (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE CLOSED] was: [VOTE] Release Apache Cassandra 0.8.0 rc1
On Thu, 2011-05-12 at 10:09 -0500, Jonathan Ellis wrote: > Agreed. OK, consider this vote closed. Another will be opened soon. > On Thu, May 12, 2011 at 9:10 AM, Sylvain Lebresne > wrote: > > I hate to ruin the party but I think that we may have to reroll for > > https://issues.apache.org/jira/browse/CASSANDRA-2642 > > if we want to call this a release candidate. > > > > -- > > Sylvain > > > > On Thu, May 12, 2011 at 1:13 AM, Eric Evans wrote: > >> On Wed, 2011-05-11 at 16:23 +0100, Stephen Connolly wrote: > >>> > Not sure what you mean. The driver is part of this vote, it's in my > >>> > home directory on people.a.o. > >>> > > >>> > > >>> https://repository.apache.org/content/repositories/orgapachecassandra-004/org/apache/cassandra/ > >>> > >>> I see no cassandra-cql > >>> > >>> (Because we took it out of the publish to central over a disagreement > >>> on version numbering and release scheduling) > >> > >> We are voting on the release of version 1.0.2 of the JDBC driver (in > >> addition to the 0.8.0 rc1 artifacts staged on Maven Central, and the > >> Debian package). The driver artifacts we are voting on are in my home > >> directory on people.apache.org. The URL is: > >> > >> http://people.apache.org/~eevans > >> > >> If the vote succeeds, the driver will be moved to > >> http://www.apache.org/dist/cassandra/drivers/java (where the others > >> are). > >> > >>> > > On 11 May 2011 01:46, Eric Evans wrote: > >>> > > > Driver Artifacts and Debian Package: > >>> > > http://people.apache.org/~eevans > >> > >> -- > >> Eric Evans > >> eev...@rackspace.com > >> > >> > > > > > -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0 rc1
On Wed, 2011-05-11 at 16:23 +0100, Stephen Connolly wrote: > > Not sure what you mean. The driver is part of this vote, it's in my > > home directory on people.a.o. > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-004/org/apache/cassandra/ > > I see no cassandra-cql > > (Because we took it out of the publish to central over a disagreement > on version numbering and release scheduling) We are voting on the release of version 1.0.2 of the JDBC driver (in addition to the 0.8.0 rc1 artifacts staged on Maven Central, and the Debian package). The driver artifacts we are voting on are in my home directory on people.apache.org. The URL is: http://people.apache.org/~eevans If the vote succeeds, the driver will be moved to http://www.apache.org/dist/cassandra/drivers/java (where the others are). > > > On 11 May 2011 01:46, Eric Evans wrote: > > > > Driver Artifacts and Debian Package: > > > http://people.apache.org/~eevans -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0 rc1
On Wed, 2011-05-11 at 11:53 +0100, Stephen Connolly wrote: > When can we expect to see release votes for CQL (and if you need me to > help with getting that into Maven central, just shout) Not sure what you mean. The driver is part of this vote, it's in my home directory on people.a.o. > On 11 May 2011 01:46, Eric Evans wrote: > > Driver Artifacts and Debian Package: > http://people.apache.org/~eevans -- Eric Evans eev...@rackspace.com
[VOTE] Release Apache Cassandra 0.8.0 rc1
I propose the following artifacts for release as 0.8.0 RC1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1101689 Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-004/ Driver Artifacts and Debian Package: http://people.apache.org/~eevans The will remain open for 72 hours, (longer if need be). [1]: http://goo.gl/fsaH8 (CHANGES.txt) [2]: http://goo.gl/IWE0T (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: Build failed in Jenkins: Cassandra-0.8 #81
On Sun, 2011-05-08 at 06:36 -0400, Jesse Melton wrote: > Unsubscribe me from this list please. If unsubscribe is not working, then you should report the issue to apache infrastructure (https://issues.apache.org/jira/browse/INFRA). I seriously doubt there is anyone watching this list that has the ability to take you off it. -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] Release Apache Cassandra 0.8.0 beta2
On Mon, 2011-05-02 at 20:36 -0500, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1098882 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-011 > Driver Artifacts and Debian Package: http://people.apache.org/~eevans > > The will remain open for 72 hours, (longer if need be). I count 5 binding +1 votes and no -1s; The vote passes. -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
On Thu, 2011-04-28 at 20:42 +0100, Stephen Connolly wrote: > ok well I will see about deleting it from the staging repo, can I get > a conditional + 1 on that basis? +1 -- Eric Evans eev...@rackspace.com
[VOTE] Release Apache Cassandra 0.8.0 beta2
I propose the following artifacts for release as 0.8.0 beta2. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1098882 Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-011 Driver Artifacts and Debian Package: http://people.apache.org/~eevans The will remain open for 72 hours, (longer if need be). [1]: http://goo.gl/Ser5q (CHANGES.txt) [2]: http://goo.gl/DSG4q (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
On Thu, 2011-04-28 at 16:44 +0100, Stephen Connolly wrote: > > Unlike the RPC, CQL is meant to be stable. It is a significant > feature > > that you should be able to use the same version of a driver across > many > > versions of Cassandra. This is why the versions must be different, > so > > that you can evaluate each new driver version in the context of how > it > > changed, not (necessarily )how Cassandra changed during some > arbitrary > > release. > > > > This version number is all about versioning the information in the > __pom__. The pom defines transitive dependencies. You might not > rebuild the cql jar at all, but keep redeploying with different poms > (each getting their own version number... because we can only use a > version number once)... yes that is somewhat wasteful of space on the > central repository, but that's the way it works... [1] > > The 0.8.0-beta1 version number is only for the coordinates of the pom > of cassandra-cql that will pull down the dependencies for using cql > with cassandra 0.8.0-beta1. > > If that subtlety helps you understand the versioning I have chosen for > the poms, well that is better. It sounds to me like you need to omit the CQL jar entirely then, and not add it to Maven Central except as a different project. -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
On Thu, 2011-04-28 at 06:52 +0100, Stephen Connolly wrote: > On 28 April 2011 00:55, Eric Evans wrote: > > On Tue, 2011-04-26 at 14:44 +0100, Stephen Connolly wrote: > >> * I have given the CQL driver jar the same version number as > >> everything else, because it is only going to work with the 0.8.0-beta1 > >> jars anyway. > >> > >> Please vote (see > >> http://www.apache.org/foundation/voting.html#ReleaseVotes) > >> > >> +1: Go ahead and release it > >> 0: I have some issues with the release > >> -1: I have something I think merits re-spinning this release > > > > -1 > > > > Why are we making up a different version number for the client code? > > 1. because that version of the driver has a hard dependency on the > other two jars, and because it is still in tree, therefore it is > released in sync. Neither of those is a good reason. > 2. I cannot release another 1.0.0 artifact as you cannot overwrite > versions in maven central. once you release a version it is released, > so unless 0.8.0-beta2 comes with cql 1.0.1 then we are in trouble. You > will literally have to increment the cql version for _every single > release of the main jars_ or else I will have to make two sets of > build targets one which releases cql only and the other which releases > everything but cql. That is a messy release process to follow, but if > that's what you want... The likelihood that that driver won't receive even a minor bug fix (resulting in version 1.0.1) is low but not non-existent, so whatever the process, it shouldn't absolutely require that driver releases occur when Cassandra releases do. It sounds like that is your problem. > from my PoV, there will be many issues releasing (oh why is this fix > for cql not in the new release... yes it is... no it isn't... oh, > somebody forgot to increment the cql version when doing the release > and you are using maven central) unless you do one of several options: > * move cql out of tree (so that it is released on its own > schedule... we do this @maven for everything... many trees with many > independent release schedules) > * tie the cql version to the main tree version (what I did) > * make the cql version a combo of the main and the cql version (i.e. > 1.0.0-0.8.0-beta1) > * keep cql in tree but make the build have two targets, 1st for > everything but cql, 2nd for only cql (that will be a mess but it is a > solution) Unlike the RPC, CQL is meant to be stable. It is a significant feature that you should be able to use the same version of a driver across many versions of Cassandra. This is why the versions must be different, so that you can evaluate each new driver version in the context of how it changed, not (necessarily )how Cassandra changed during some arbitrary release. I don't know if driver releases will be made in the time between Cassandra releases, but I suspect that at some point they probably will be. I don't that every driver will need to be released every time that Cassandra does, they probably won't. None of of this should prevent them all from living in the same tree. > We can bemoan Maven Central's policy (you can only release a specific > version number once and only once), but that does not solve the issue > that users want dependencies from a Maven repository, and Maven's > architecture will not re-download a release version because of it's > central assumption that releases do not change, so even if you could > re-release a 1.0.0, anyone who used the old 1.0.0 would not get the > new release (this is why -SNAPSHOTs are different from releases, Maven > expects -SNAPSHOTs might change and will check for new versions... but > you cannot put -SNAPSHOTs in a release repository) -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.8.0-beta1 artifacts in Maven Central
On Tue, 2011-04-26 at 14:44 +0100, Stephen Connolly wrote: > * I have given the CQL driver jar the same version number as > everything else, because it is only going to work with the 0.8.0-beta1 > jars anyway. > > Please vote (see > http://www.apache.org/foundation/voting.html#ReleaseVotes) > > +1: Go ahead and release it > 0: I have some issues with the release > -1: I have something I think merits re-spinning this release -1 Why are we making up a different version number for the client code? -- Eric Evans eev...@rackspace.com
Another beta?
Are we ready for a second beta? Or, is confidence is high enough for a release candidate? -- Eric Evans eev...@rackspace.com
Re: [VOTE] Release Apache Cassandra 0.7.5
On Fri, 2011-04-22 at 19:17 +0200, Sylvain Lebresne wrote: > I propose the following artifacts for release as 0.7.5. +1 > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1095960 > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-113/org/apache/cassandra/apache-cassandra/0.7.5/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-113 > > The artifacts as well as a debian package are also available here: > http://people.apache.org/~slebresne/ -- Eric Evans eev...@rackspace.com
Re: Why is the CQL jar versioned independently?
On Tue, 2011-04-26 at 22:42 +0100, Stephen Connolly wrote: > so will cql get its own tree from which releases well be cut, or will > it get released always at the same time? It would probably make sense at some point to separate the build for the Java client code so that releases could be made independently. But, even if the releases continue to occur only when Cassandra does, the version numbers need to move independently. -- Eric Evans eev...@rackspace.com
Re: Why is the CQL jar versioned independently?
On Tue, 2011-04-26 at 13:31 +0100, Stephen Connolly wrote: > From what I can see, the intent is to always release lock-step in sync > with cassandra, in which case the version number should be the > cassandra version number... > > unless you are implying that this is "CQL version 1.0.0" and there may > be a future time when you could have "CQL version 2.0.0" with a > different incompatible syntax... CQL client versioning does *not* move in lock-step with either Cassandra or the CQL specification (though if you adhere to semver.org for both the spec and the library then *major* versions will effectively move in lock-step). -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] Apache Cassandra 0.8.0-beta1 (take #2)
On Tue, 2011-04-19 at 20:35 -0500, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1095239 > 0.8.0-beta1 artifacts: http://people.apache.org/~eevans > > The vote will be open for 72 hours, longer if needed. I'm going to go ahead and call this one. We have 5 binding +1s, plus 3 others and no -1s. The vote passes. I'll get everything published. -- Eric Evans eev...@rackspace.com
[VOTE] Apache Cassandra 0.8.0-beta1 (take #2)
Let's try this again. I propose the following artifacts for release as 0.8.0 beta1. You will note the addition of three new artifacts, cql-1.0.0.tar.gz, txcql-1.0.0.tar.gz and apache-cassandra-cql-1.0.0.jar. These are language drivers for CQL; Be sure to include them in your review. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1095239 0.8.0-beta1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours, longer if needed. Thanks! -- Eric Evans eev...@rackspace.com
[VOTE CLOSED] was: [VOTE] Apache Cassandra 0.8.0-beta1
On Tue, 2011-04-19 at 19:13 -0500, Jonathan Ellis wrote: > My fault, fixed. (Built w/ "ant" but it was confused as "ant clean" > demonstrated.) OK, then consider this vote closed all, I'll reopen another shortly. > On Tue, Apr 19, 2011 at 7:04 PM, Eric Evans wrote: > > On Tue, 2011-04-19 at 16:59 -0500, Jonathan Ellis wrote: > >> On Tue, Apr 19, 2011 at 11:45 AM, Eric Evans wrote: > >> > https://issues.apache.org/jira/browse/CASSANDRA-2501 > >> > https://issues.apache.org/jira/browse/CASSANDRA-2488 > >> > https://issues.apache.org/jira/browse/CASSANDRA-2505 > >> > https://issues.apache.org/jira/browse/CASSANDRA-2507 > >> > > >> > All of those apply to the Python driver and/or the CQL shell in some > >> > way. > >> > >> These are all fixed now. I'm fine w/ re-rolling the beta if you are. > > > > It doesn't build, I think r1095223 (a merge from 0.7) is to blame. -- Eric Evans eev...@rackspace.com
Re: [VOTE] Apache Cassandra 0.8.0-beta1
On Tue, 2011-04-19 at 16:59 -0500, Jonathan Ellis wrote: > On Tue, Apr 19, 2011 at 11:45 AM, Eric Evans wrote: > > https://issues.apache.org/jira/browse/CASSANDRA-2501 > > https://issues.apache.org/jira/browse/CASSANDRA-2488 > > https://issues.apache.org/jira/browse/CASSANDRA-2505 > > https://issues.apache.org/jira/browse/CASSANDRA-2507 > > > > All of those apply to the Python driver and/or the CQL shell in some > > way. > > These are all fixed now. I'm fine w/ re-rolling the beta if you are. It doesn't build, I think r1095223 (a merge from 0.7) is to blame. -- Eric Evans eev...@racklabs.com
Re: [VOTE] Apache Cassandra 0.8.0-beta1
On Tue, 2011-04-19 at 07:46 -0500, Jonathan Ellis wrote: > We typically only block betas for major regressions, not bugs that are > already present in a released version (all of 0.7 releases in this > case). So yes, this will be in the next one after beta1 (probably rc1 > since 0.8 won't be a moving target like 0.7 was). Just to add to the list, (so that everyone is aware): https://issues.apache.org/jira/browse/CASSANDRA-2501 https://issues.apache.org/jira/browse/CASSANDRA-2488 https://issues.apache.org/jira/browse/CASSANDRA-2505 https://issues.apache.org/jira/browse/CASSANDRA-2507 All of those apply to the Python driver and/or the CQL shell in some way. Most are very recent regressions, none are critical, but together they make CQL mostly unusable from Python, and will likely give some a bad first-impression. -- Eric Evans eev...@rackspace.com
Re: [VOTE] Apache Cassandra 0.8.0-beta1 *correction*
On Mon, 2011-04-18 at 13:44 -0500, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1094668 That URL should actually be: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8@r1094668 Sorry for the confusion. -- Eric Evans eev...@racklabs.com
[VOTE] Apache Cassandra 0.8.0-beta1
OK. Here are artifacts for a proposed 0.8 beta1 release. You will note the addition of three new artifacts, cql-1.0.0.tar.gz, txcql-1.0.0.tar.gz and apache-cassandra-cql-1.0.0.jar. These are language drivers for CQL; Be sure to include them in your review. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1094668 0.8.0-beta1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours, longer if needed. Thanks! -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] Release Apache Cassandra 0.6.13
On Wed, 2011-04-13 at 17:13 -0500, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6@r1091922 > Artifacts: http://people.apache.org/~eevans > > The will remain open for 72 hours, (longer if need be). > > [1]: http://goo.gl/4WKDv (CHANGES.txt) > [2]: http://goo.gl/sOWE0 (NEWS.txt) I count 4 +1 binding and no -1s; The vote passes. The artifacts will be published shortly. -- Eric Evans eev...@rackspace.com
Re: Release Manager Volunteers?
(You don't need to Cc me, I am subscribed) On Thu, 2011-04-14 at 08:56 +0100, Stephen Connolly wrote: > Why should you limit to just one volunteer? I wouldn't; I didn't. > The idea is that the procedure in > http://wiki.apache.org/cassandra/HowToPublishReleases should be > followable by any Cassandra committer. > > I would propose that the release manager is the person who steps up to > run the release for that specific release. If it is just one person > always making releases then that becomes a SPOF... better to have more > than one and round-robin it, or have one do the stable releases and > the other do the new releases... That's a good idea, we can start round-robining between Sylvain and Sylvain right away! :) -- Eric Evans eev...@rackspace.com
[VOTE] Release Apache Cassandra 0.6.13
I propose the following artifacts for release as 0.6.13. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6@r1091922 Artifacts: http://people.apache.org/~eevans The will remain open for 72 hours, (longer if need be). [1]: http://goo.gl/4WKDv (CHANGES.txt) [2]: http://goo.gl/sOWE0 (NEWS.txt) -- Eric Evans eev...@rackspace.com
request for help/testing
I banged http://caqel.deadcafe.org out as something we could point folks to, something they could use to demo CQL without installing Cassandra. Now I could use help with a couple of things. 1. Testing. If you have the time/inclination, have a go at it and report any bugs to http://github.com/eevans/caqel/issues. Or better yet, send me a pull request! :) 2. Design/styling. It is butt-ugly; I suck at this. If you can do better (I suspect most of you can), please help. I'll buy you a beer, coffee, tea, lunch, or just give you a great big hug if that's what you prefer. Thanks! -- Eric Evans eev...@rackspace.com
Re: Release Manager Volunteers?
On Mon, 2011-04-11 at 16:40 -0500, Eric Evans wrote: > The amount of time I'm able to commit to Cassandra going forward is > uncertain, plus, it wouldn't hurt give someone else a turn, or to have > some redundancy here. Do we have any volunteers? > > The requirements are: > * Committer > * Gluten for punishment That would be "glutton" of course, release management is 100% gluten-free. -- Eric Evans eev...@racklabs.com
Release Manager Volunteers?
The amount of time I'm able to commit to Cassandra going forward is uncertain, plus, it wouldn't hurt give someone else a turn, or to have some redundancy here. Do we have any volunteers? The requirements are: * Committer * Gluten for punishment -- Eric Evans eev...@rackspace.com
Re: [ANN] Branched; freeze in effect
On Mon, 2011-04-11 at 12:41 +0200, Sylvain Lebresne wrote: > Ok, I know that will sound like I'm already starting to ask for favor, > but would that be possible to just merge CASSANDRA-2191 and > CASSANDRA-2156 to 0.8. I just committed it to trunk and honestly > though the freeze would be in effect later today. Go ahead. -- Eric Evans eev...@rackspace.com
[ANN] Branched; freeze in effect
Ladies and Gents, pursuant with The Plan[1], we have branched[2] and a freeze is now in effect. First and foremost this means no new features[3]. The idea is to release in 4 weeks, which will be here before you know it. We need the bug count to trend downward, which will be difficult enough without feature/scope-creep. We also need to maintain compatibility. I believe it is very important that we set this expectation for our betas. If users feel certain that each is unarguably more release-ready than the last, and that it is reasonably straightforward to upgrade from one to the next, (including the final), then we should see more serious testing during these periods. The upshots are that anything you didn't get in only needs to wait ~4 months, and trunk is still open for business (so go nuts). I'd like to get going on the first beta as soon as possible, (this week would be great). If you know of issues that should be dealt with before that happens, please let me know. Thanks everyone! [1]: http://thread.gmane.org/gmane.comp.db.cassandra.devel/2867 [2]: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.8 [3]: Common-sense / consensus will prevail, of course. -- Eric Evans eev...@rackspace.com
Re: Cassandra documentation (and in this case the datastax anti-entropy docs)
On Thu, 2011-03-31 at 18:57 +0100, Nick Telford wrote: > I don't think the Wiki is the right place for community maintained > user docs; it doesn't have the necessary structure. The wiki is great at what wikis are great at, lowering the barrier to contribution. There is a lot of good stuff (some of it is even translated to other languages!); I'm guessing there would be much less if people had to jump through more hoops. > Perhaps some generated docs maintained in-tree and hosted somewhere on > cassandra.apache.org might be an idea? This would also enforce some > order over changes made to them as changes would be controlled by > committers and managed through JIRA. I had this exact idea, I even checked the CQL language documentation into the tree as doc/cql/CQL.textile. I had expected that to either set a precedent, or to be told to get it out of there, but neither happened. :) I don't think we need to choose one or the other. If someone would rather add documentation to the wiki, we should let them (thank them even). People interested in something maintained with more rigor can invite the wiki peeps to submit patches, and steal their content if they won't! -- Eric Evans eev...@rackspace.com
Re: State Of: CQL - driver devs
On Thu, 2011-03-31 at 13:56 +0200, Bjorn Borud wrote: > > (Hopefully )for the next version, we'll replace Thrift with a > > dedicated protocol, one that eliminates the Thrift dependency, and > > more importantly, implements streaming. This should be transparent > > to applications for the most part though. > > pardon my ignorance, is there a JIRA issue for this or a wiki page > that describes this? I'd be very interested in reading up a bit about > this. There isn't an issue yet, no. Rackspace (my employer), is scaling back its involvement with Cassandra post-0.8. I'm not yet sure what that will mean, but I'll almost certainly have less time to spend on this (worst-case none at all). So, I have a running list of thoughts/plans I plan to dump into JIRA before I become scarce, and this one is high on my list. However, if this is something you have an interest in, don't feel like you need to wait on me. Feel free to submit a ticket and get started! > I've been using Netty lately to implement a protocol for streaming > messages and I've had quite good results. I used the varint framing > codec that comes with Netty in conjunction with protobuffers. the > performance is quite good. on my laptop I was able to push 400k+ > messages per second from the client to the server on a warm JVM and > about 350k messages per second on a cold JVM. cursory measurements > seem to indicate that serializing protobuffer messages was more > expensive than de-serializing them. I know it sounds like NIH, but I'd like to see us roll our own serialization. It's really not as much work as it sounds; It amounts to a small subset of a generalized framework like PB or Thrift. I'm of the opinion that the benefits derived from specialization, and the reduced external dependencies makes it worth it here. > I like the Netty API. I was going to use my own, minimal NIO library > (just a simple implementation of the Reactor Pattern), but after > playing with Netty for a bit I decided that I'd be much better off > using that. > > a bonus is that adding encryption, compression etc to a pipeline > appears to be relatively easy with Netty. I think it would make sense > to just implement the new protocol as a Netty codec. > > (Originally I tried Apache MINA, but I got a tip from a colleague that > development on Netty is more active. I haven't really compared the > two projects thoroughly enough to have an opinion on this). Full ACK; I have some recent experience with Netty as well and quite like it. -- Eric Evans eev...@rackspace.com
Re: How to begin contributing
On Wed, 2011-03-30 at 13:59 +0530, Manu Gupta wrote: > I would like to contribute to Cassandra project. How should I go about > it? I have downloaded its git repo and also I have downloaded and > isntalled thrift python-nose. > > Please guide me. http://wiki.apache.org/cassandra/HowToContribute -- Eric Evans eev...@rackspace.com
Re: PHP Cassandra CQL driver
On Tue, 2011-03-29 at 17:22 -0500, Jonathan Ellis wrote: > >> My suggestion as a means of heavily mitigating the damage of these > >> attacks would be to only permit a single query at a time (i.e. > >> remove the ';' token). > > > > This is effectively the case. The parser is run exactly once for > > each request and is only capable of parsing exactly one statement > > (no less, no more). Terminating a query with ';' is allowed, but > > has no effect on this. > > Batches allow multiple semicolon-delimited statements. Actually, they require it (since you won't find an EOF terminating any of the individual statements), but that is a bug. > I think we'd need to have a separate cql_batch rpc method that took a > list of statements to solve this. (I.e., begin/apply batch and the > semicolons would be strictly interactive markers that would be used to > break it up into the statements to send in that list.) The intended behavior was to allow but not require them (the same for statements appearing inside the batch or out), and that's easy enough to fix. The semicolon doesn't have any effect on the parser result, it's just tolerant of them because people are going to use them, and it's one more condition that we can deal with instead of pushing it on clients. -- Eric Evans eev...@rackspace.com
Re: PHP Cassandra CQL driver
On Tue, 2011-03-29 at 12:06 +0100, Nick Telford wrote: > With regards to injection, I saw someone state "it's a red herring as > it's a client concern". While this may be true, experience teaches us > that pushing the responsibility to the client is dangerous due to the > many implementations. At the very least, the possibility of injection > attacks should be *considered*. No, it's basically the point of this exercise to push as much as possible server-side. > My suggestion as a means of heavily mitigating the damage of these > attacks would be to only permit a single query at a time (i.e. remove > the ';' token). This is effectively the case. The parser is run exactly once for each request and is only capable of parsing exactly one statement (no less, no more). Terminating a query with ';' is allowed, but has no effect on this. > Only trusted, administrative client applications (e.g. a GUI or > console) should really permit issuing multiple queries like this. Such > clients could decompose the queries in to separate queries and issue > them individually. Easier still, because nothing has that ability. There is a very basic interactive interpreter bundled with the Python driver, it splits on ';' and issues individual requests. -- Eric Evans eev...@rackspace.com
Re: PHP Cassandra CQL driver
On Tue, 2011-03-29 at 10:34 +0100, Courtney Robinson wrote: > Firstly, has it already been taken into consideration that CQL > implicitly means injections may become a problem? It is only possible to submit one query at a time w/ CQL. -- Eric Evans eev...@rackspace.com
Reminder: 2 weeks until feature-freeze
Another quick reminder; The tentative freeze date of April 11th is 2 weeks from today. Per the discussion[1] we had back in January, this is when we'll branch and feature-freeze (bug fixes only, everything else goes to trunk). [1]: http://thread.gmane.org/gmane.comp.db.cassandra.devel/2867 -- Eric Evans eev...@rackspace.com
Re: State Of: CQL - driver devs
On Sun, 2011-03-20 at 22:11 +, Courtney Robinson wrote: > I've been looking at the Java and Python drivers and they are both > using Thrift. I thought the idea was to get rid of thrift/avro? The idea is to create an alternative to the tightly-coupled object-oriented RPC interface. This initial version uses Thrift so that effort could be focused on implementing the language, and have something useful for this release. And, until it's complete (see my original mail for the list of outstanding items), the RPC methods can serve to fill in the holes. Baby steps. (Hopefully )for the next version, we'll replace Thrift with a dedicated protocol, one that eliminates the Thrift dependency, and more importantly, implements streaming. This should be transparent to applications for the most part though. > The two implemented (however partial) drivers seem to have similar > naming conventions for class and methods. Has it been agreed to try > and do this? Yes, insomuch as this is reasonable/practical. > I reckon it'd be a good idea if that was the case because then no > matter which language driver you're using you you can easily use any > other driver/language since the methods/function names would be the > same or similar and would mean its easier to develop different > components in different languages since you won't have to learn a new > API for the various drivers... or at least you'd have an easier time > > I think this would address one of the problems now with different > clients providing their own API which vary widely across the board. For the record, I don't see CQL (and its drivers) as a replacement for high-level idiomatic client libraries. In much the same way as projects like Spring, and Hiberate, or SQLAlchemy provide abstraction for RBDMS and SQL, we'll still have client libraries which build their own APIs, according to their own requirements, on top of CQL. -- Eric Evans eev...@rackspace.com
State Of: CQL
With 3 weeks and change until the branch-and-feature-freeze, I thought I'd take a few moments to update everyone on the current state of CQL. Goals and Progress[1] - The overarching goal of course, is to create a compelling replacement for the RPC interface, one that is less baroque, comparable in performance, and stable across Cassandra release versions. The goals for Cassandra 0.8 are to meet or exceed the point of minimum usability. That is to say, a significant number of users/applications can make use of it. I believe we're on track to achieve that. Already complete: * Complete data manipulation (SELECT, UPDATE, DELETE, TRUNCATE ...) * Partial DDL, enough to create a schema, (ALTER is missing). * Drivers for Python (including Twisted), and Java (JDBC). * Language documentation (doc/cql/CQL.html) Remaining for 0.8: * Support for typed keys[2]. * Tests, tests, and more tests. What comes next (after 0.8) --- * Benchmarking and optimization * Completion of DDL (ALTER ...). * Prepared statements * Custom, line protocol (no more Thrift). * ... ? What you can do --- * Play/test/experiment, and file bug reports. The Python driver's interactive interpreter is a good place to start (drivers/py/cqlsh). * Write system tests (test/system/test_cql.py). * Write language drivers. * Write documentation. * Pick up unclaimed tickets tagged "cql"[3]. * Port libraries and applications (and file bug reports). Thoughts, comments, questions? [1]: https://issues.apache.org/jira/browse/CASSANDRA-1703 [2]: https://issues.apache.org/jira/browse/CASSANDRA-2311 [3]: http://goo.gl/cSPlc -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.4
On Fri, 2011-03-11 at 18:50 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1080811 > 0.7.4 artifacts: http://people.apache.org/~eevans > > The vote will be open for 72 hours. I count 5 binding +1s and 1 other, with no -1s; The vote passes. I'll working on getting everything published. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.4
It's that time again. I propose the following for release as 0.7.4. What say you? SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1080811 0.7.4 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: http://goo.gl/ZwACq (CHANGES.txt) [2]: http://goo.gl/Ib28x (NEWS.txt) -- Eric Evans eev...@rackspace.com
Reminder: 5 weeks until feature freeze
Just a friendly reminder: The tentative freeze date of April 11th is 5 weeks from today. Per the discussion[1] we had back in January, this is when we'll branch and feature-freeze (bug fixes only, everything else goes to trunk). Please try to keep this schedule in mind as you work on your respective release goals. We aren't frozen until we are, but the idea is to release 4 weeks later (say May 9th), which isn't a lot time to shake the bugs out. Disruptive changes should been given ample time to stabilize, (or be hidden behind configuration, etc). Thanks! [1]: http://thread.gmane.org/gmane.comp.db.cassandra.devel/2867 -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] 0.7.3 take #2
On Tue, 2011-03-01 at 13:32 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.3@r1075977 > 0.7.3 artifacts: http://people.apache.org/~eevans > > The vote will be open for 72 hours. > > Thanks. > > [1]: http://goo.gl/hX02M (CHANGES.txt) > [2]: http://goo.gl/HXlNH (NEWS.txt) I count 4 +1s and 1 other, with no -0s; The vote passes. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.3 take #2
Here goes attempt #2 of 0.7.3 (see http://goo.gl/Y1l7n for background); I propose the following for release as 0.7.3. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.3@r1075977 0.7.3 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. Thanks. [1]: http://goo.gl/hX02M (CHANGES.txt) [2]: http://goo.gl/HXlNH (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.3
On Tue, 2011-03-01 at 10:38 -0600, Jonathan Ellis wrote: > Created a 0.7.3 branch as the original 0.7.3 artifacts plus > > https://issues.apache.org/jira/browse/CASSANDRA-2240 > https://issues.apache.org/jira/browse/CASSANDRA-2253 > https://issues.apache.org/jira/browse/CASSANDRA-2254 > https://issues.apache.org/jira/browse/CASSANDRA-2255 So consider the vote closed, and another will follow shortly. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.3
Shall we? I propose the following for release as 0.7.3. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1074693 0.7.3 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. Thanks. [1]: http://goo.gl/0CykW (CHANGES.txt) [2]: http://goo.gl/9NNKv (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.6.12
On Thu, 2011-02-17 at 15:57 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.2@r1071063 > 0.6.12 artifacts: http://people.apache.org/~eevans > > The vote will be open for 72 hours. Alright then, I have 4 +1s and no -1s; The vote passes. I'll get it published. -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.6.12 (corrected links)
Sorry folks, cut-and-paste errors. On Thu, 2011-02-17 at 15:57 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.2@r1071063 That should be: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6@r1071793 > 0.6.12 artifacts: http://people.apache.org/~eevans > > The vote will be open for 72 hours. > > [1]: http://goo.gl/iI7U2 (CHANGES.txt) > [2]: http://goo.gl/b2dCq (NEWS.txt) Those should be: [1]: http://goo.gl/Gcr5P (CHANGES.txt) [2]: http://goo.gl/zYIdN (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE] 0.6.12
By popular demand, I propose the following for release as 0.6.12. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.2@r1071063 0.6.12 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: http://goo.gl/iI7U2 (CHANGES.txt) [2]: http://goo.gl/b2dCq (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] 0.7.2
On Tue, 2011-02-15 at 15:57 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.2@r1071063 > 0.7.2 artifacts: http://people.apache.org/~eevans > > The delta here is pretty small, so if no one objects, we can reduce > the voting period to 24 hours. With 5 +1s and 2 others, and no objections to expediting, I'm calling it and will get the artifacts published. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.2
CASSANDRA-2165[1] is troublesome enough to warrant a new release. I propose the following for 0.7.2. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7.2@r1071063 0.7.2 artifacts: http://people.apache.org/~eevans The delta here is pretty small, so if no one objects, we can reduce the voting period to 24 hours. [1]: https://issues.apache.org/jira/browse/CASSANDRA-2165 [2]: http://goo.gl/iI7U2 (CHANGES.txt) [3]: http://goo.gl/b2dCq (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE RESULT] was: [VOTE] 0.7.1 (what are we at now, 4?)
On Thu, 2011-02-10 at 11:52 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1069461 > 0.7.1 artifacts: http://people.apache.org/~eevans > > The vote will be open for 72 hours. By my count that's 5 binding +1s, 2 others, and no -1s; The vote passes. I'll start work on publishing everything. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.1 (what are we at now, 4?)
I propose the following for release as 0.7.1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1069461 0.7.1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: http://goo.gl/5VAPP (CHANGES.txt) [2]: http://goo.gl/C9M5W (NEWS.txt) [3]: http://goo.gl/8dZUr -- Eric Evans eev...@rackspace.com
[VETOED] was: [VOTE] 0.7.1 (3 times the charm?)
On Mon, 2011-02-07 at 18:52 -0600, Jonathan Ellis wrote: > Should be fixed in r1068241. Thanks! I guess it goes without saying that this one is a bust. Expect a new vote to be started presently. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.1 (3 times the charm?)
Lather. Rinse. Repeat. Ya'll know the drill. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1067260 0.7.1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: http://goo.gl/axEK0 (CHANGES.txt) [2]: http://goo.gl/66yGY (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.1 (attempt #2)
On Mon, 2011-01-31 at 09:18 -0600, Jonathan Ellis wrote: > -1, CASSANDRA-1951 broke startup when propertyfilesnich is configured Alright, consider this one a bust; A new vote starts soon! > On Fri, Jan 28, 2011 at 2:32 PM, Eric Evans wrote: > > SVN: > > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1064845 > > 0.7.1 artifacts: http://people.apache.org/~eevans > > > > The vote will be open for 72 hours. > > > > > > [1]: https://issues.apache.org/jira/browse/CASSANDRA-2058 > > [2]: http://goo.gl/5Tafg (CHANGES.txt) > > [3]: http://goo.gl/PkreZ (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] 0.6.11
On Thu, 2011-01-27 at 12:18 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6@r1064231 > 0.6.11 artifacts: http://people.apache.org/~eevans > > I've been asked to expedite the release process, so if no one is in > disagreement, we can call this one after 24 hours. I count 5 +1s and no -1s; The vote passes. I'll get everything published shortly. Thanks. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.1 (attempt #2)
CASSANDRA-2058[1] has landed in 0.7, so let's give this another shot. I propose the following for release as 0.7.1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1064845 0.7.1 artifacts: http://people.apache.org/~eevans The vote will be open for 72 hours. [1]: https://issues.apache.org/jira/browse/CASSANDRA-2058 [2]: http://goo.gl/5Tafg (CHANGES.txt) [3]: http://goo.gl/PkreZ (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.1
On Wed, 2011-01-26 at 22:04 -0600, Jonathan Ellis wrote: > We should fix https://issues.apache.org/jira/browse/CASSANDRA-2058 > first. (As of this writing the 0.6 version of the patch has been > tested, but the 0.7 version has not yet.) So we'll count this as a veto and close this vote. #2058 has since landed in 0.7 so expect a new vote presently. -- Eric Evans eev...@rackspace.com
Re: [PMC VOTE] Approve use of Cassandra mark by mojo.codehaus.org
On Fri, 2011-01-28 at 19:25 +, ant elder wrote: > -1. This isn't a veto yet but I've read CASSANDRA-1997 and > CASSANDRA-1805 but still have no real understanding of why the > contribution of this maven plugin is being rejected and told to go do > it somewhere out of the ASF. Why isn't this wanted to be developed > here? It wasn't rejected (vetoed). I don't feel strongly enough to veto it outright. I'm not committing it because to me it seems to fall into the same category of stuff we're in the process of removing as part of CASSANDRA-1997, and because I believe CASSANDRA-1997 was opened to solve a legitimate problem. -- Eric Evans eev...@rackspace.com
Re: [PMC VOTE] Approve use of Cassandra mark by mojo.codehaus.org
On Fri, 2011-01-28 at 19:07 +, Stephen Connolly wrote: > Since there does not seem to be any desire to accept CASSANDRA-1997 > > Can the PMC vote to approve the use of the Cassandra mark by the > mojo.codehaus.org project for the Cassandra Maven Plugin I don't understand why you'd need permission. Help me to understand why this is necessary. If it is necessary, then I suspect there are other cases ongoing where we need to defend our mark. > +1 Approve > 0 don't care > -1 Veto I'm not going to vote on something I don't understand. -- Eric Evans eev...@rackspace.com
[VOTE] 0.6.11
CASSANDRA-2058[1] is serious enough to warrant a new 0.6 point release. I propose the following for release as 0.6.11. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6@r1064231 0.6.11 artifacts: http://people.apache.org/~eevans I've been asked to expedite the release process, so if no one is in disagreement, we can call this one after 24 hours. [1]: https://issues.apache.org/jira/browse/CASSANDRA-2058 [2]: http://goo.gl/0bC9M (CHANGES.txt) [3]: http://goo.gl/s9Pbo (NEWS.txt) -- Eric Evans eev...@rackspace.com
Re: [VOTE] 0.7.1
On Thu, 2011-01-27 at 06:57 +, Stephen Connolly wrote: > ...as I would either need approval to use the cassandra mark if > hosting outside cassandra... Why is that? "cassandra-maven-plugin" would seem to use the term "cassandra" descriptively, surely that isn't a problem. -- Eric Evans eev...@rackspace.com
[VOTE] 0.7.1
Shall we? I propose the following artifacts for release as 0.7.1. SVN: https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.7@r1063491 0.7.1 artifacts: http://people.apache.org/~eevans The will remain open for 72 hours, (longer if need be). [1]: http://goo.gl/4cJkq (CHANGES.txt) [2]: http://goo.gl/SBGPA (NEWS.txt) -- Eric Evans eev...@rackspace.com
[VOTE RESULTS] was: [VOTE] 6.10
On Wed, 2011-01-19 at 13:40 -0600, Eric Evans wrote: > SVN: > https://svn.apache.org/repos/asf/cassandra/branches/cassandra-0.6@r1060906 > 0.6.10 artifacts: http://people.apache.org/~eevans > > The vote will be open for the usual 72 hours. By my count that's 5 +1s, and no -1s; The vote passes, and I'll have the artifacts published shortly. -- Eric Evans eev...@rackspace.com
