Re: Moderation
I'm not a stakeholder here- I don't know Russell, I don't work for Datastax, and I'm not a member of the ASF. For what little it's probably worth since I haven't "been elected to have a binding voice within the project", Russell's is exactly how I read the message from Chris Mattmann. Whether or not it was intended to be so aggressive and dismissive and patronizing, I almost can't even believe something that *might* be taken this way is tolerated in a board member's *public* communications. In the end, I *can* believe it, though, as it reinforces my perception of the Foundation in general. :( p On Sat, Nov 5, 2016 at 5:16 PM, Russell Bradberry wrote: > For the record, I never said anyone was attempting to make me “look bad”. > I simply stated that his method of argument was to discredit me. Below I > will break down his response, as I see it, and as others who have messaged > me off list see it as well: > > “… You see I’ve been around since 2004 and elected by the membership to > the Board for the last three years based on merit …” > > Here he is showing his superiority by way of tenure, or merit. > > “You see I actually understand…” > > The use of the term “actually” in this sense is to provide an attack > against me in an effort to prove that I do not understand. > > “…unfortunately you do not have a voice …” > > Again, this is a blatant attempt to discredit me and provide proof that my > word is of no worth because I am not on the PMC, nor a committer. > > “You won’t have a vote in the next Apache Board election.” > > Again > > “You won’t have a vote in the next Members election.” > > Again > > “why haven’t you been elected to have a binding voice within the project? > Please ask yourself that” > > This is either an attempt to discredit me, in that I have not done enough > to be elected, or an attempt to state the PMC hasn’t been doing their job > in recognizing my efforts. > > “please ask yourself – what is a “Cassandra MVP” compared to a member of > the ASF which is home to the project”” > > This is not only insinuating that MVP is less than being a member of the > ASF, and because I was given the MVP title, that somehow I am less than as > well. (for the record, I have not asked for the MVP title, it was awarded, > and I do not think that it should have any effect on the project from an > Apache standpoint. Quite simply put, it is just another bullet point on a > resume) > > “I’ve been privy and voted on granting membership to within the foundation > since 2011” > > More attempts to discredit me by showing tenure. > > Literally, the first portion of the response was a campaign to discredit > me in order to demonstrate his merit. The rest of the email goes to defend > a point that I did not make. > > Again, I will assert that the complaints the board has are valid. > Datastax may have overstepped bounds and, as a result, put the project and > ASF at risk. I am not an authority on the subject and have not been privy > to the private messages between the board, PMC, and Datastax. What I will > say, is that the tone, vitriol, ad-hominem responses and other > unprofessional conduct has caused a rift in this community. Most of this > is coming directly from the board, specifically Chris. Furthermore, as > Aleksey has pointed out, this occurs in the private lists as well. This is > a form of toxic-leadership and is proven to not only be ineffective, but > also be directly harmful. These issues can, and should, be resolved > amicably. > > Professionalism and Respect, if aren’t, should be of the core tenets of > any foundation, especially one of the caliber of Apache. > > > > On 11/5/16, 9:38 AM, "Mark Struberg" wrote: > > Russel, I don't read that out of Chris' answer. > He just tried to show how community development might look like if > done a bit more openly. > > Do you mind going back to Chris' original reply and re-read it again? > I've not interpreted it as anyone trying to make you look bad. Au > contraire! > > > txs and LieGrue, > strub > > > > > > > On Saturday, 5 November 2016, 13:56, Russell Bradberry < > rbradbe...@gmail.com> wrote: > > > It seems that your tactic of argument is to discredit me at every > level in order > > to show your superiority of sorts. Let me set this straight, I am > not > > attempting to say that I am an authority on ASF or that I know how > things should > > be run. I also was not attempting to vilify you in front of the > board or vilify > > you in any way. My complaint is that your rhetoric is > unprofessional; and as a > > representative of the board the language you use is, plainly, > casting a bad > > light on the ASF. > > > > I understand all of your concerns and was not attempting to minimize > them in any > > way; they are legitimate concerns. The way you are handling them is > what I am > > concerned with and the tone you take is what I believe is helping > divide the >
Re: A few questions about Cassandra's native protocol
On Wed, Aug 22, 2012 at 4:53 PM, Christoph Hack wrote: > Hi, > > I am currently developing a client for Cassandra's new native protocol > in Go. Everything is working fine so far and I am quite happy with the > new protocol. Good work! Here a just a couple of questions and notes: > That's great. The sooner this new protocol can take off, the better! 1) The native_protocol.spec should probably mention that it is based > on TCP. I greped the whole document for "UDP" and "TCP" and found > nothing. > Good point. I'll see about getting that into the doc. 2) Streaming > > I'm currently allocating and reading one frame after another on the > client side. The thing that worries me - If I have understood the > current specification correctly - is that all rows are returned in a > single frame. If the database is quite large, this frames might not > fit into the memory. > This may not be as bad as it sounds here, since CQL3 doesn't have wide rows (the underlying storage engine rows may be wide, but those don't matter here). Normal CQL queries which are expected to be performant (not too many partition keys touched) should generally fit just fine in memory. But yes, definitely it will be possible (and even sometimes necessary) to have resultsets that are too big to handle. I thought about how to handle this best in the Python driver, but I couldn't come up with a good general solution; just lots of half-solutions that would only help in certain cases. When CASSANDRA-4415 lands, it should help mitigate this significantly. I was thinking about using buffered I/O instead, but that's probably > not a good solution either, because then a single thread that iterates > over the rows slowly will block the whole connection. In my opinion it > would be a good idea to split the response to a couple of frames, so > that other threads (with different stream ids) are still able to use > the connection concurrently and push notifications are still > delivered. A "last" flag might indicate the end of the response. > This is pretty much what #4415 will do. 3) Stability > > During the development of the client, I happened to send some invalid > requests to the server. In particular, I have send a startup message > with a body length of 0 (and no body afterwards). In those cases, > Cassandra immediately started to use all of my 8GBs of RAM and spawned > up to 1000 threads. The log files were full of "out of memory" and > "couldn't spawn process" messages and it was quite difficult to kill > Cassandra again. > Ouch, that's pretty bad. File a jira ticket for that, for sure. The binary protocol will still be "beta" for the 1.2 release, and not enabled by default, so it's not earth-stopping, but I'm sure we want it more stable than THAT. 4. Prepared Statements > > It should be possible to prepare statements that do not take any > arguments. This simplifies the client development significantly > (otherwise everybody has to write his own parser to determine the > number of arguments) and might also speed up common queries. > The current implementation returns a "java.lang.AssertionError" error > response in that case. > Agreed. I remember hearing about this happening with the thrift interface too - http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=21&can=1came from there- but it doesn't look like anyone bothered to file a jira ticket. Want to do that one too? Regards, > Christoph > Best of luck with progress! p
Re: A few questions about Cassandra's native protocol
On Sun, Aug 26, 2012 at 2:03 PM, Christoph Hack wrote: > Ticket+Patch: https://issues.apache.org/jira/browse/CASSANDRA-4577 Excellent- I'll take a look at that too. 5) LIMIT > > The last query with LIMIT 1 in this example returns a very strange result > imho. > Instead of just limiting the rows, it also replaces most column values > with NULL. > Is this the expected behavior? https://gist.github.com/3483042 No, it's not. This isn't related to the binary protocol, but I agree it's a bug. I filed it as https://issues.apache.org/jira/browse/CASSANDRA-4579. Thanks! p
Re: Pushing Cassandra 1.2 back a month to November?
On Tue, Sep 25, 2012 at 11:16 AM, Jonathan Ellis wrote: > 2) The binary protocol only really has a Java implementation so far. > Having the time to flesh out the Python implementation would be a good > sanity check before we commit to protocol stability. > Just to clarify, the Python implementation is complete(*) as far as I know, but lacks any significant real-world use or heavy test coverage. (*) just finished adding the snappy compression and event registration support and added some basic tests last night, and committed it to the master branch today. p
Re: Best place to discuss CQL Binary Protcol spec?
I can't usefully speak to your other questions, but the answers to the technical questions are below. On Mon, Feb 18, 2013 at 1:16 PM, Michael Alan Dorman < mdor...@ironicdesign.com> wrote: > * 4.1.2. CREDENTIALS > > My quick clarification is from this bit of text: > > The body is a list of key/value informations. It is a [short] n, > followed by n pair of [string]. These key/value pairs [...] > > Is this just a string map, and the text just isn't using consistent > terminology? > It has the same structure as a string map, but might not necessarily *be* a string map. I would guess that this phrasing is used because it may be possible to have multiple identical "keys" in this structure, which would not make sense in a [string map]. (Although I don't think it's explicitly stated, it seems safe to imply that [string map] is intended to be a plain lookup table, not a set of arbitrary pairs.) * 4.2.5.2. Rows > > My more involved question is about this text describing the column > contents: > > - is composed of ... where m is > . > Each is composed of ... where n is > and where is a [bytes] representing the value > returned for the jth column of the ith row. In other words, > > is composed of ( * ) [bytes]. > > I read this and thought, "Oh, sure I'll need to figure out the width of > the java types for the different columns, tedious but easily doable", > and then noticed some of the options are things like Blob or Varchar, > both which I would assume to be variable width. So how should one > determine how many bytes to read for different types? > As the doc says, each is a [bytes], which means it's represented on the wire as an [int] x followed by x bytes. p
Re: Best place to discuss CQL Binary Protcol spec?
On Mon, Feb 18, 2013 at 6:48 PM, Michael Alan Dorman < mdor...@ironicdesign.com> wrote: > paul cannon writes: > > As the doc says, each is a [bytes], which means it's represented > > on the wire as an [int] x followed by x bytes. > > Thank you for pointing out what I had succeeded in reading repeatedly > without actually processing. ;) > > At the same time, that seems to gloss over the structure of the > content---it's not all encoded as string values, or is it? > No, the values are serialized according to whatever data type definitions they have. The data types and serializations are technically details of Cassandra usage in general (not specific to the native protocol), and the types aren't limited to the ones which are assigned type IDs in the native protocol, so it is arguably appropriate to leave out type serialization details in the native protocol document (I could see it either way). If you do need details, the builtin cassandra types and serialization formats are defined in the various org.apache.cassandra.db.marshal.*Type classes. Or read deserialization code from the other C* libraries. p
Re: Packaging Cassandra for Ubuntu
On Thu, Jun 3, 2010 at 2:11 PM, Eric Evans wrote: > On Thu, 2010-06-03 at 07:55 -0700, Clint Byrum wrote: >> * We will most likely conflict with the Cassandra published debian packages. >> Is this acceptable? Suggested solutions? > > Ultimately, I think packages in Ubuntu/Debian can replace the builds > currently hosted on ASF mirrors. Probably not in cases where people want to use new releases; there is a non-negligible time delay in getting packages into released or "testing" suites of Ubuntu and Debian, and sometimes even into Debian unstable. With cassandra being a relatively fast-moving target, it is probably still worthwhile to provide packages straight from an ASF repository. Those same packages could be the ones submitted for inclusion in Debian/Ubuntu, though. -- paul, the
Re: Packaging Cassandra for Ubuntu
On Thu, Jun 3, 2010 at 3:42 PM, Eric Evans wrote: > The packages uploaded to the ASF mirrors have thus far been stable > releases. Those could just as easily be uploaded to backports.org. backports.org only allows versions of packages which are already in Debian testing. -- paul, the
Re: Reducing confusion around client libraries
+1 for aggressive curation, and -1 on moving clients in-tree. p On Fri, Dec 3, 2010 at 11:43 AM, Jonathan Ellis wrote: > The status quo is not working. There are way too many questions on > the user list and on irc about problems with writing Thrift code, even > when well-maintained clients exist for their language of choice. And > that's just the users who were motivated enough to ask instead of > tweeting that thrift sucks and giving up. > > I think driving people to a real client is primarily a problem we can > solve with cleanup of the wiki and web site. > > A harder problem is that Choice Is Bad from a user perspective. We > shouldn't be making people evaluate Hector vs Pelops, FluentCassandra > vs Aquiles, phpcassa vs SimpleCassie before writing their application. > At the time they need to make this decision they have the very least > amount of experience with Cassandra on which to base their evaluation; > we should be guiding them to a sensible default. > > We are failing our users if we make them click through to the version > control history to see whether phpcassa is more actively maintained > than simplecassie. > > It's a vicious cycle, too: since there are no "official" clients, > people are quicker to write their own instead of contributing to an > existing one, leading to more proliferation of (often) half-baked > clients taking up space on the wiki page. We're just getting started > on this process for 0.7, but take a look at how 0.6 ended up: > http://wiki.apache.org/cassandra/ClientOptions06. Over half of those > are abandoned now, but a new user would have to do a lot of spelunking > to figure out which was which. > > Moving clients in-tree would solve this, and the problem is bad enough > that I almost wrote an email proposing that, but I would really prefer > to avoid subjecting clients to our PMC, voting process, ticket > tracking system, etc. > > Instead, I think we we should aggressively curate the ClientOptions > page: pick an official client for each language, and move the rest to > an AlternativeClients page. This wouldn't be written in stone; if > someone wrote a Twisted client that he thinks is better than Telephus, > we can have a discussion on whether to move to the new one. But we > need to have a default choice to take the pain out of getting started > with Cassandra. > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
Re: unsubscribe
Tested. Unsubscribe works fine. p 2011/7/5 Jesse Melton > Ha ha. Good luck with that. Just spam them out. The unsubscribe system > doesn't work & even the list admins can't get you off the list. > > On Jul 5, 2011 9:41 PM, "김준영" wrote: > > unsubscribe >
Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
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.
2 and 3 feel like they would cripple CQL too much.
p
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.
>
> Thoughts?
>
> --
> Eric Evans
> eev...@rackspace.com
>
>
Re: moin wiki: ACLs give us no more textchas and re-enable images
On Mon, Jul 25, 2011 at 4:42 PM, Brandon Williams wrote: > On Mon, Jul 25, 2011 at 3:45 PM, Jeremy Hanna > wrote: > > Basically the trade-off is, if we add ACLs such that we can easily add new > contributors really easily, we can ditch the textchas and re-enable images > on the cassandra wiki. > > > > Is that people are willing to trade-off? Details on how that is managed > is in the link above. > > > > I realize that this is philosophically contrary to what a wiki really is > - editable by anyone. However they're concerned with spam and have to do > something to avoid it. > > I'm -1 on ACLs, requiring an account will only raise the bar for > participation which is not something I want to do. > Can we use the ACLs to say something like: * TrustedGroup can upload images without textcha * AnyoneWithAnAccountGroup can edit without textcha * AnyoneWithAnAccountGroup can upload images WITH textcha * AnonymousGroup can edit WITH textcha ? p
Re: Cassandra has moved to Git
On Wed, Dec 28, 2011 at 1:55 PM, Eric Evans wrote: > There are also some matters of work-flow or process that we need to > hashed out. For example, how do we handle reviews now? Do we > continue to mandate/recommend/allow rebasing? > Surely we'd want to follow normal git practices here: rebasing is almost never appropriate once a branch is pushed to a public repo, where other people might have gotten it. Where you might rebase a plain patch series on top of new developments in a target SVN branch, you probably just ought to merge the target git branch into your topic branch instead. Same effect, but retains history. p
Re: Cassandra has moved to Git
On Wed, Jan 4, 2012 at 10:57 AM, Eric Evans wrote: > On Wed, Jan 4, 2012 at 9:59 AM, Jonathan Ellis wrote: > > On Tue, Jan 3, 2012 at 1:21 PM, paul cannon wrote: > >> Surely we'd want to follow normal git practices here: rebasing is almost > >> never appropriate once a branch is pushed to a public repo, where other > >> people might have gotten it. > >> > >> Where you might rebase a plain patch series on top of new developments > in a > >> target SVN branch, you probably just ought to merge the target git > branch > >> into your topic branch instead. Same effect, but retains history. > > > > I dunno, my experience has been that merge commits cause more harm in > > my ability to understand history, than I gain in benefit. Merge > > commits mean another place to look to understand "what really changed > > in this patch." > I agree with Eric- merges shouldn't be making history searches any more difficult. > http://darwinweb.net/articles/the-case-for-git-rebase makes a good > > case for a rebase-based workflow, particularly with respect to > > bisecting (which has been instrumental in tracking down regressions > > for us more than once). > > I don't understand several of his arguments. How bisecting is made > more difficult (or impossible) is one of them. I also don't > understand how rebasing to master versus merging with master is > superior in terms of avoiding larger conflicts down the road > (especially since the example he provided didn't indicate any merges > with master(!)). > > Personally, I do prefer to rebase my branches while they are private, > but that's for purposes of easing review; I've never felt I needed a > flatter history to make life easier (with Git). > I only read through that article quickly, but it doesn't sound like he ever even addresses public repos, where rebasing remote heads and pushing non-fast-forward updates causes pretty massive confusion for people who aren't pretty familiar with git. Perhaps he's just advocating rebasing locally? I am 100% in favor of that, and it sounds like Eric is too- rebase is almost always preferable to merge as long as you're not messing up any remote heads. Although I disagree with the last bit: flatter histories do make life easier in general. Anyway, if I understand what he's saying, he's suggesting that > individual developers rebase against master to stay current, only up > until the first time they push it somewhere. Then presumably two or > more developers merge back and forth between each others topic > branches. Once the work is complete, someone rebases to master and > merges, at which point that topic branch is considered to be dead. > > In a perfect word (his private team?) that should work, and if > consensus is that we should try it, then I'm down. > > My prediction: Bedlam. :) > This. p
Re: Cassandra has moved to Git
On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis wrote: > So, can I summarize our policy as "git pull --rebase"? > I'd rather have the normal case be to use topic branches for work, so --rebase doesn't come in to the picture, but yeah, pull --rebase is a better default. A more important bit of policy is probably "don't use + with git push." p
Re: Cassandra has moved to Git
On Wed, Jan 4, 2012 at 3:19 PM, Jonathan Ellis wrote: > On Wed, Jan 4, 2012 at 11:48 AM, paul cannon wrote: > > On Wed, Jan 4, 2012 at 11:40 AM, Jonathan Ellis > wrote: > > > >> So, can I summarize our policy as "git pull --rebase"? > >> > > > > I'd rather have the normal case be to use topic branches for work, so > > --rebase doesn't come in to the picture, but yeah, pull --rebase is a > > better default. > > You're right. So in the topic branch workflow, I would write that as > "commit by cherry-pick from topic to master, then push." > If the workflow doc also makes clear that that's only for the purely-local topic branch case, and that git rebase can be a lot more helpful than cherry-picking each individual commit, then sure. p
Re: Cassandra has moved to Git
On Thu, Jan 5, 2012 at 10:58 AM, Sylvain Lebresne wrote: > Again, I was more talking about the only reasonable solution I saw. > Because to be clear, if the history for some issue 666 in say trunk looks > like: > > commit : last nits from reviewer > commit : oops, typo that prevented commit > commit : some more fix found during review > commit : refactor half of preceding patch following reviewer comments > commit : Do something awesome - patch for #666 > > then imho that's a big regression from current patch based development. > I don't see this as a problematic, given all the tools like git log --graph and graphical history viewers. Especially since long nitpick histories like this are not likely to be very common in practice. Would you care to elaborate on the issue? So basically my question is how do we meld all those commits that will > necessarily happen due to the nature of distributed reviews so that our > main history don't look like shit? And if the answer is "we don't" then > I'm not too fond of that solution. > Does "look like shit" here mean "has lots of forks and merges", or "has lots of commits", or "is not aesthetically pleasing"? p
Re: Cassandra has moved to Git
On Thu, Jan 5, 2012 at 4:50 AM, Sylvain Lebresne wrote: > Also, if committer != > reviewer, there is the slight issue of how the committer make sure > that he commits what has been reviewer (i.e, that author hasn't made > some last minute, post-review change). But I suppose we can either say > "don't do that" and trust people, or ask reviewer to comment with > something like "+1 on 666:". > Signed git tags are a real good fit for this sort of thing. Or even unsigned annotated tags, if we have a pretty high default trust level. p
Re: Cassandra has moved to Git
On Mon, Jan 9, 2012 at 10:02 AM, Peter Schuller wrote: > [speaking obviously as non-committer, just offering a perspective] > > A potential factor to consider: If one knows that all work in topic > branches end up merged without anyone first rebasing to clean up, you > now have a constant trade-off between history readability and > committing often. I personally dislike anything that causes there to > be a reason *not* to commit. I'd much rather commit like crazy and > clean it up before merge, than maintaining additional branches > privately just for the purpose, or playing around with stashes. > For sure- I think everybody agrees that it's best to rebase private branches for maximum readability/useful history. If the issue is not rebasing public branches, one can presumably > always introduce a convention whereby work happens in branch X; and if > rebasing is needed, you do that in X/rebased/1. If a further iteration > ends up happening, X/rebased/2. Or something along those lines. This > would get you: > Hmm. I haven't seen this done before, but I think it actually might work really well. As a tweak, we could require that discontinued branches (like X and X/rebased/1 in your example) be relegated to tags instead of branches, and under some standard hierarchy, i.e. "refs/tags/discontinued/X", "refs/tags/discontinued/X/rebased/1". The original branches themselves could then be removed. * History looks the way you want it to look. > * All original history is maintained if you really want to look at it > (I *do* think it could be useful when diving into a JIRA ticket after > the fact to figure out what reasoning was). > +1 on this! * You're not rebasing published branches. > > The downside I suppose is that the branch count increases. > This downside largely goes away if tags are used instead. A possibly larger downside is that if anyone has been basing some work of their own off of branch X, then they would need to rebase their own work on top of the new version, which might not be trivial if they forked off an earlier commit than the last. But people basing important+complicated work on pending ticket work probably should expect some difficulties of this nature. p
Re: [VOTE] Release Apache Cassandra 1.0.7
On Jan 12, 2012, at 5:36 AM, Sylvain Lebresne wrote:
> Note that I had to adapt a little bit to the switch to git. In particular,
> instead of using sha1 to mark the tentative commit of a release, I've decided
> to use a lightweight tag, namely 1.0.7-tentative. My goal being that once the
> vote passes, I'll delete this temporary tag and create the actual
> cassandra-1.0.7 tag. My rational for not creating the final tag right away is
> that:
> - I want it to be clear 1.0.7 is not yet released
> - If the vote fails, we would have to delete the tag anyway
> If someone has a problem with that, let me know.
I'm -1 on not announcing a specific commit hash, for historical purposes. Tags
can be changed (and probably will be under this approach, if we have to
reroll), or deleted, and they may not even agree between different repos. With
a sha1, there is no ambiguity about which exact snapshot is being (or was)
voted on.
It's still probably a good idea to have a tag, as you say
("prospective/1.0.7/1" maybe? I find tag namespaces come in handy), but it
should be intended for convenience only.
p
