Re: [VOTE] Accept java-driver

[Sylvain Lebresne]

+1
--
Sylvain


On Tue, Oct 3, 2023 at 8:43 PM Jon Haddad 
wrote:

> +1
>
>
> On 2023/10/03 04:52:47 Mick Semb Wever wrote:
> > The donation of the java-driver is ready for its IP Clearance vote.
> > https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
> >
> > The SGA has been sent to the ASF.  This does not require acknowledgement
> > before the vote.
> >
> > Once the vote passes, and the SGA has been filed by the ASF Secretary, we
> > will request ASF Infra to move the datastax/java-driver as-is to
> > apache/java-driver
> >
> > This means all branches and tags, with all their history, will be kept.
> A
> > cleaning effort has already cleaned up anything deemed not needed.
> >
> > Background for the donation is found in CEP-8:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
> >
> > PMC members, please take note of (and check) the IP Clearance
> requirements
> > when voting.
> >
> > The vote will be open for 72 hours (or longer). Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding +1s
> > and no -1's.
> >
> > regards,
> > Mick
> >
>

Re: [DISCUSS] CEP-15: General Purpose Transactions

[Sylvain Lebresne]

Fwiw, it makes sense to me to talk about CQL syntax evolution separately.

It's pretty clear to me that we _can_ extend CQL to make sure of a general
purpose transaction mechanism, so I don't think deciding if we want a
general purpose transaction mechanism has to depend on deciding on the
syntax. Especially since the syntax question can get pretty far on its own
and could be a serious upfront distraction.

And as you said, there are even queries that can be expressed with the
current syntax that we refuse now and would be able to accept with this, so
those could be "ground zero" of what this work would allow.

But outside of pure syntax questions, one thing that I don't see discussed
in the CEP (or did I miss it) is what the relationship of this new
mechanism with the existing paxos implementation would be? I would kind of
expect this work, if it pans out, to _replace_ the current paxos
implementation (because 1) why not and 2) the idea of having 2
serialization mechanisms that serialize separately sounds like a nightmare
from the user POV) but it isn't stated clearly. If replacement is indeed
the intent, then I think there needs to be a plan for the upgrade path. If
that's not the intent, then what?
--
Sylvain


On Wed, Sep 15, 2021 at 12:09 PM bened...@apache.org 
wrote:

> Ok, so the act of typing out an example was actually a really good
> reminder of just how limited our functionality is today, even for single
> partition operations.
>
> I don’t want to distract from any discussion around the underlying
> protocol, but we could kick off a separate conversation about how to evolve
> CQL sooner than later if there is the appetite. There are no concrete
> proposals to discuss, it would be brainstorming.
>
> Do people also generally agree this work warrants a distinct CEP, or would
> people prefer to see this developed under the same umbrella?
>
>
>
> From: bened...@apache.org 
> Date: Wednesday, 15 September 2021 at 09:19
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
> > perhaps we can prepare these as examples
>
> There are grammatically correct CQL queries today that cannot be executed,
> that this work will naturally remove the restrictions on. I’m certainly
> happy to specify one of these for the CEP if it will help the reader.
>
> I want to exclude “new CQL commands” or any other enhancement to the
> grammar from the scope of the CEP, however. This work will enable a range
> of improvements to the UX, but I think this work is a separate, long-term
> project of evolution that deserves its own CEPs, and will likely involve
> input from a wider range of contributors and users. If nobody else starts
> such CEPs, I will do so in due course (much further down the line).
>
> Assuming there is not significant dissent on this point I will update the
> CEP to reflect this non-goal.
>
>
>
> From: C. Scott Andreas 
> Date: Wednesday, 15 September 2021 at 00:31
> To: dev@cassandra.apache.org 
> Cc: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
> Adding a few notes from my perspective as well –
>
> Re: the UX question, thanks for asking this.
>
> I agree that offering a set of example queries and use cases may help make
> the specific use cases more understandable; perhaps we can prepare these as
> examples to be included in the CEP.
>
> I do think that all potential UX directions begin with the specification
> of the protocol that will underly them, as what can be expressed by it may
> be a superset of what's immediately exposed by CQL. But at minimum it's
> great to have a sense of the queries one might be able to issue to focus a
> reading of the whitepaper.
>
> Re: "Can we not start using it as an external dependency, and later
> re-evaluate if it's necessary to bring it into the project or even incubate
> it as another Apache project"
>
> I think it would be valuable to the project for the work to be incubated
> in a separate repository as part of the Apache Cassandra project itself,
> much like the in-JVM dtest API and Harry. This pattern worked well for
> those projects as they incubated as it allowed them to evolve outside the
> primary codebase, but subject to the same project governance, set of PMC
> members, committers, and so on. Like those libraries, it also makes sense
> as the Cassandra project is the first (and at this time) only known
> intended consumer of the library, though there may be more in the future.
>
> If the proposal is accepted, the time horizon envisioned for this work's
> completion is ~9 months to a standard of production readiness. The
> contributors see value in the work being donated to and governed by the
> contribution practices of the Foundation. Doing so ensures that it is being
> developed openly and with full opportunity for review and contribution of
> others, while also solidifying contribution of the IP to the project.
>
> Spinning up a separate ASF incubation project is an 

Re: Welcome Jordan West, David Capwell, Zhao Yang and Ekaterina Dimitrova as Cassandra committers

[Sylvain Lebresne]

Congratulations to all of you. Well deserved.
--
Sylvain


On Thu, Dec 17, 2020 at 12:27 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> Hearty congratulations everyone!!
>
> On Wed, Dec 16, 2020 at 2:53 PM Joshua McKenzie 
> wrote:
>
> > Congrats everyone! Great to see new folks joining the project.
> >
> > On Wed, Dec 16, 2020 at 3:55 PM Dinesh Joshi  wrote:
> >
> > > Congratulations everyone!
> > >
> > > Dinesh
> > >
> > > > On Dec 16, 2020, at 8:55 AM, Benjamin Lerer <
> > benjamin.le...@datastax.com>
> > > wrote:
> > > >
> > > > The PMC's members are pleased to announce that Jordan West, David
> > > Capwell,
> > > > Zhao Yang and Ekaterina Dimitrova have accepted the invitations to
> > become
> > > > committers this year.
> > > >
> > > > Jordan West accepted the invitation in April
> > > > David Capwell accepted the invitation in July
> > > > Zhao Yang accepted the invitation in September
> > > > Ekaterina Dimitrova accepted the invitation in December
> > > >
> > > > Thanks a lot for everything you have done.
> > > >
> > > > Congratulations and welcome
> > > >
> > > > The Apache Cassandra PMC members
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

[Sylvain Lebresne]

I hope I haven't misread this, but it appears we've reached a kind of
consensus for committing the fix, so I went ahead and did it.
I added a NEWS entry that I hope is clear (and points to the flag that
disables the fix if someone wants to go that route), but any committers can
feel free to ninja-nitpick that NEWS entry if they so wish.

Many thanks to Benjamin for driving the discussion here.
--
Sylvain


On Tue, Nov 24, 2020 at 3:43 PM Ekaterina Dimitrova 
wrote:

> I am +1 on Benjamin’s proposal
> and less interruptions during upgrades. For more visibility maybe we can
> also write a short article about the options and the tradeoffs, further to
> NEWS.txt (that’s not something to decide now, of course :-) )
>
>
> On Tue, 24 Nov 2020 at 9:13, Benjamin Lerer 
> wrote:
>
> > Paulo, what you propose with the yaml seems different from default to
> > *correctness*. It means to me that we are forcing the user to choose
> > between *correctness *and *performance*. Most of us have a good
> > understanding of the problem and it is a hard choice for us. I imagine
> that
> > most of the users do not fully understand LWTs and will not know what to
> > choose. Some might not even use LWTs and will suddenly be forced to make
> a
> > choice that they do not understand. It does not feel right to me to push
> > them to make that choice.
> >
> > I also agree with Benedict and Mick that it is a risky thing to do.
> >
> > something that can bring a cluster down upon an unprepared user.
> >
> >
> > I do not think that it will be the case (feel free to correct me
> Benedict).
> > The impact will probably be an increase in the number of write/read
> > timeouts for the LWTs read/writes. For a heavy load that would cause the
> > services depending on those queries to become unreliable. On the other
> hand
> > the impact of the current problem is that we can hit some correctness
> issue
> > without even knowing it.
> >
> > We need to choose between two imperfect solutions and we have some
> > difficulties to agree on which one to choose.
> >
> > Benedict suggested that Sylvain and I made the choice. Sylvain did not
> want
> > to make the final call.
> > I chose correctness. If it is a problem and people prefer to vote. It is
> > perfectly fine for me too :-)
> >
> > I just want us to move forward.
> >
> >
> >
> > On Tue, Nov 24, 2020 at 12:52 PM Mick Semb Wever  wrote:
> >
> > > > I think the keyword there is "normally" - if we can't say
> _certainly_,
> > > > then this is probably an unsafe change to make.
> > > >
> > > > I can imagine any number of hacky upgrade processes that would be
> > > > dangerous with this change.
> > > >
> > >
> > >
> > > I agree. We just don't know what users are doing, this is risky.
> > >
> > > IMO the same applies to a performance degradation, i.e. something that
> > can
> > > bring a cluster down upon an unprepared user. Despite our best efforts
> > with
> > > NEWS.txt we should still look after such users. IMHO the imperfection
> of
> > > LWTs on past branches we have to carry. I'm well aware this is easier
> > said
> > > than done, even for far simpler changes. Having the flag there to
> switch
> > to
> > > "correct LWT" is still a huge win for users.
> > >
> >
>

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

[Sylvain Lebresne]

Regarding option #4, I'll remark that experience tends to suggest users
don't consistently read the `NEWS.txt` file on upgrade, so option #4 will
likely essentially mean "LWT has a correctness issue, but once it broke
your data enough that you'll notice, you'll be able to dig the proper flag
to fix it for next time". I guess it's better than nothing, of course, but
I'll admit that defaulting to "opt-in correctness", especially for a
feature (LWT) that exists uniquely to provide additional guarantees, is
something I have a hard rallying behind.

But a performance regression is a regression, I'm not shrugging it off.
Still, I feel we shouldn't leave LWT with a fairly serious known
correctness bug and I frankly feel bad for "the project" that this has been
known for so long without action, so I'm a bit biased in wanting to get it
fixed asap.

But maybe I'm overstating the urgency here, and maybe option #1 is a better
way forward.

--
Sylvain

Re: Merge implementation details

[Sylvain Lebresne]

If you want something precise, I'm afraid you'll have to go to the source
code.

The code to merge "cells" (internally, a "cell" corresponds pretty much to
the
value of specific column in a specific row, though a non-frozen collection
column is actually multiple cells) is in `Cells#reconcile` at:

https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/rows/Cells.java#L117

You may also want to look one step up at `Rows#merge` (which calls the
former
`Cells#reconcile`):

https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/rows/Rows.java#L278

You'll also find a few unit tests for those methods in:

https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/CellTest.java

https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/rows/RowsTest.java
but it's not necessarily exhaustive.

That said, you'll see that on equal timestamps, tombstones do have
priorities,
and otherwise the "biggest" value has priority (comparing the underlying
values as unsigned byte arrays). The latter rule is fairly random and just
a deterministic way to break ties.

--
Sylvain


On Mon, Nov 9, 2020 at 11:10 PM Benjamin Stadin <
benjamin.sta...@bridging-it.de> wrote:

> Hi List,
>
> I need to synchronize Cassandra with some sort of proprietary distributed
> cache. One of the things I‘m looking at is the exact behaviour of the merge
> operation (LWW) as it is implemented in Cassandra, in order to maintain an
> (eventually) consistent state between Cassandra and this cache.
>
> Could you point me to actual source code and test cases, and eventually to
> documentation? I didn‘t find much, other than a short hint in the docs. For
> example, what‘s the exact behaviour on delete when timestamps are equal? My
> guess is that writes are prioritized over deletes (since there is a -1
> applied to the timestamp in the paxos code path), but I need to figure
> those details exactly.
>
>  Cheers
> Ben
>
>
>

Re: [DISCUSS] Change style guide to recommend use of @Override

[Sylvain Lebresne]

+1
--
Sylvain


On Wed, Sep 2, 2020 at 10:21 AM Sam Tunnicliffe  wrote:

> +1
>
> > On 2 Sep 2020, at 09:03, Benjamin Lerer 
> wrote:
> >
> > +1
> >
> >
> >
> > On Wed, Sep 2, 2020 at 5:36 AM Berenguer Blasi  >
> > wrote:
> >
> >> +1
> >>
> >> On 2/9/20 5:09, Joshua McKenzie wrote:
> >>> +1
> >>>
> >>> On Tue, Sep 1, 2020 at 6:26 PM Jordan West  wrote:
> >>>
>  +1
> 
>  On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith <
>  bened...@apache.org>
>  wrote:
> 
> > +1
> >
> >
> >
> > On 01/09/2020, 20:09, "Caleb Rackliffe" 
>  wrote:
> >
> >
> >+1
> >
> >
> >
> >On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang <
> > jasonstack.z...@gmail.com>
> >
> >wrote:
> >
> >
> >
> >> +1
> >
> >>
> >
> >> On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi 
>  wrote:
> >>
> >
> >>> +1
> >
> >>>
> >
>  On Sep 1, 2020, at 11:27 AM, David Capwell <
> >> dcapw...@gmail.com
> >
> > wrote:
> >
> 
> >
>  Currently our style guide recommends to avoid using @Override
>  and
> >> updates
> >
>  intellij's code style to exclude it by default; I would like
> >> to
> > propose
> >
> >>> we
> >
>  change this recommendation to use it and to update intellij's
> > style to
> >
>  include it by default.
> >
> 
> >
>  @Override is used by javac to enforce that a method is in
> >> fact
> >
> >> overriding
> >
>  from an abstract class or an interface and if this stops
> >> being
> > true
> >
> >> (such
> >
>  as a refactor happens) then a compiler error is thrown; when
> >> we
> > default
> >
> >>> to
> >
>  excluding, it makes it harder to detect that a refactor
> >> catches
> > all
> >
>  implementations and can lead to subtle and hard to track down
> > bugs.
> >
> 
> >
>  This proposal is for new code and would not be to go rewrite
>  all
> > code
> >
> >> at
> >
>  once, but would recommend new code adopt this style, and to
>  pull
> > old
> >
> >> code
> >
>  forward which is related to changes being made (similar to
> >> our
> > stance
> >
> >> on
> >
>  imports).
> >
> 
> >
>  If people are ok with this, I will file a JIRA, update the
>  docs,
> > and
> >
>  update intellij's formatting.
> >
> 
> >
>  Thanks for your time!
> >
> >>>
> >
> >>>
> >
> >>>
> > -
> >
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >>>
> >
> >>>
> >
> >>
> >
> >
> >
> >
> >
> >
> >
> > -
> >
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> >
> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] When to branch 4.0

[Sylvain Lebresne]

Fwiw, I agree with that POV in general (that it's probably beneficial on
balance to branch now/soonish for the reasonings Josh mentioned).
--
Sylvain


On Fri, Jun 26, 2020 at 3:43 PM Joshua McKenzie 
wrote:

> As we close on cutting beta1, a new consequence of our release lifecycle is
> becoming apparent. With guarantees of API stability in the beta phase, any
> work that is deferred from alpha to the next major due to API impacting
> changes will atrophy for as long as the beta is active.
>
> Cutting a branch for the 4.0 line upon release of beta1 would mitigate this
> problem and allow work in flight to be merged in, as well as unblock the
> work of others who may not be focusing on testing 4.0, whether it be due to
> their interest and focus or due to saturation on the work in scope for the
> release.
>
> The obvious downsides to cutting a branch of a major and allowing dev on
> trunk to continue separately is 1) the need to merge up to trunk on changes
> going into beta, and 2) a risk of a lack of focus on testing the release
> due to the availability of developing on trunk. My personal thoughts on
> those two points:
>
> 1) changes going into beta should be small enough that a fast-forward merge
> should be available in the majority of cases up to trunk. We've done this
> with previous releases and it wasn't prohibitively expensive in terms of
> time. Further, I would posit that changes going into beta should be on the
> smaller side, further mitigating the burden of this process.
>
> 2) We've been feature frozen since late 2018 with the expressed intention
> to encourage work on testing and stabilizing 4.0. I am not aware of any
> contributors whose time and energy has been invested in testing 4.0 that
> would otherwise have gone to trunk (i.e. this approach achieving its
> desired outcomes), however I do know of several major contributors and
> contributions that have atrophied and been deterred from further work on
> the project due to waiting for 4.0 to release.
>
> I don't think it's appropriate for us as an existing body of contributors
> to mandate either how each other or more detrimentally how other new
> contributors engage with and contribute to the project by disallowing
> contributions past 4.0; I take the position that we should do everything
> reasonably possible to encourage a diversity of contributions to the
> project. I deeply believe that making deliberate decisions to prioritize
> new engagement and interaction on the project as the context in which it's
> used evolves is vital to the project's health long term.
>
> That's just my .02 - I'd be curious to hear what everyone else thinks.
>
> ~Josh
>

Re: [DISCUSS] CASSANDRA-13994

[Sylvain Lebresne]

There appears to be a rather important misunderstanding here.

Compact storage *is removed* from 4.0, it has been since at least
CASSANDRA-10857 which prevented 4.0 to start if any compact tables existed.
This was done 2.5+ years ago and is explicitly indicated in the NEWS file
since
then.

The ticket we're discussing, CASSANDRA-13994, truly is a minor and
unconsequential patch. It does not remove "COMPACT STORAGE", since it is
already removed, it removes some leftover "COMPACT STORAGE *internals*". In
other words, it removes *dead* code, code that cannot ever be run, and
that is just polluting the codebase. None of those changes are invasive. I
don't
know where the idea this patch was invasive came from, but it's just not.

It is not meant to have user-visible consequences and it won't impact any
(past
or future) testing in any meaningful way.

And yes, the patch does cover a non trivial amount of _lines_, but it's all
either the removal of clearly unreachable code, or near automatic changes.

So, tbc, my PMC and reviewer opinion is that this is fine to commit in
either
4.0-alpha or 4.0-beta. It cleans the internal, feels as safe as safe can be
and does not impact testing.

--
Sylvain


On Wed, Jun 24, 2020 at 9:03 PM Dinesh Joshi  wrote:

> I might be missing some context here but I thought we did not intend to
> remove compact storage for 4.0 as it was deemed to be too invasive at this
> point. Did that decision change?
>
> Dinesh
>
> > On Jun 24, 2020, at 10:48 AM, Ekaterina Dimitrova <
> ekaterina.dimitr...@datastax.com> wrote:
> >
> > Dear all,
> > As we talked yesterday during our meeting, I am bringing back to the
> table
> > CASSANDRA-13994 .
> > Description
> >
> > 4.0 comes without thrift (after CASSANDRA-5
> > ) and COMPACT
> > STORAGE (after CASSANDRA-10857
> > ), and since
> Compact
> > Storage flags are now disabled, all of the related functionality is
> useless.
> >
> > There are still some things to consider:
> > 1. One of the system tables (built indexes) was compact. For now, we just
> > added value column to it to make sure it's backwards-compatible, but we
> > might want to make sure it's just a "normal" table and doesn't have
> > redundant columns.
> > 2. Compact Tables were building indexes in KEYS mode. Removing it is
> > trivial, but this would mean that all built indexes will be defunct. We
> > could log a warning for now and ask users to migrate off those for now
> and
> > completely remove it from future releases. It's just a couple of classes
> > though.
> >
> >
> > Thank you Sylvain for the first pass of review.
> >
> > An option, as also Sylvain suggested, is to split the ticket in two
> tickets
> > - clean the Compact storage dead code in this one and open a new ticket
> to
> > handle the indexes.
> >
> > I am pasting here the latest comment, hopefully this makes it easier for
> > the audience:
> >
> > I have made a first pass of review and offered a few remarks above.
> >
> > But I think this ticket is hanging up on us deciding whether removing the
> > KEYS 2ndary index code is ok or not. And this yields, to me, the question
> > of what is the upgrade path to 4.0 for users that still have KEYS index
> > (which, reminder, could only be created with Thrift, but could *used*
> with
> > CQL and thus still be around).
> >
> > Because, while I haven't tested this myself, I suspect we have a hole
> here.
> >
> > Namely, KEYS index were compact tables, and 4.0 does not start if there
> is
> > still compact tables. And while for user tables, user are asked to use
> DROP
> > COMPACT STORAGE before upgrading, this cannot be done on KEYS index
> (there
> > is just no syntax to do it), so unless there is code I'm not aware of
> (and
> > please, someone correct me if I'm wrong), I don't think user can upgrade
> to
> > 4.0 at all if they still have KEYS index. They'd have to drop those index
> > first.
> >
> > So If I'm right here, this technically mean removing the KEYS index code
> in
> > 4.0 is fine, since you cannot upgrade in the first place if you have KEYS
> > index. But the more important question for 4.0 imo is what is the upgrade
> > path for users if they have a KEYS index in 3.X?
> >
> > Currently (without code changes), the only available option I can think
> of
> > is that before upgrade to 4.0, users would have to 1) drop their KEYS
> index
> > and then 2) re-create a "normal" (non-KEYS) equivalent index.
> >
> > Are we comfortable with that being the upgrade path for KEYS index?
> >
> > Personally, I'm not sure I am because this is not a seamless upgrade, as
> > between the 1) and 2) above, there is a window where there is no
> accessible
> > index, so if the user application rely on it, it means a period of
> downtime
> > for the application to perform the upgrade. However, if we want a more
> > seamless 

Re: [VOTE] Project governance wiki doc (take 2)

[Sylvain Lebresne]

+1
--
Sylvain


On Mon, Jun 22, 2020 at 9:48 AM Benjamin Lerer 
wrote:

> +1
>
> On Mon, Jun 22, 2020 at 8:54 AM Marcus Eriksson 
> wrote:
>
> > +1
> >
> >
> > On 22 June 2020 at 08:37:39, Mick Semb Wever (m...@apache.org) wrote:
> >
> > > - Vote will run through 6/24/20
> > > - pmc votes considered binding
> > > - simple majority of binding participants passes the vote
> > > - committer and community votes considered advisory
> >
> >
> >
> > +1 (binding)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] Project governance wiki doc

[Sylvain Lebresne]

+1 (binding)
--
Sylvain


On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer 
wrote:

> +1 (binding)
>
> On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson 
> wrote:
>
> > +1
> >
> >
> > On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> > > +1 (binding)
> > >
> > > > On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> > > >
> > > > +1 nb
> > > >
> > > > On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> > > >
> > > >> +1 (binding)
> > > >>
> > > >> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> > > >> wrote:
> > > >>
> > > >>> Added unratified draft to the wiki here:
> > > >>>
> > > >>>
> > > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > >>>
> > > >>> I propose the following:
> > > >>>
> > > >>> 1. We leave the vote open for 1 week (close at end of day 6/23/20)
> > > >>> unless there's a lot of feedback on the wiki we didn't get on gdoc
> > > >>> 2. pmc votes are considered binding
> > > >>> 3. committer and community votes are considered advisory /
> > non-binding
> > > >>>
> > > >>> Any objections / revisions to the above?
> > > >>>
> > > >>> Thanks!
> > > >>>
> > > >>> ~Josh
> > > >>>
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Proof of concept for Cassandra docs conversion

[Sylvain Lebresne]

Agreed the navigation is nicer.

The content rst conversion is however far from perfect, especially in the
CQL parts. The grammar parts are all broken, most tables are really weird
(example:
https://polandll.github.io/site/ASCIIDOC_POC/4.0/cassandra/cql/types.html)
and we lost almost all linking in those parts.

I think that's up to pandoc not handling rst too well, and while that could
be fixed manually, it's going to be some work. So I'd suggest giving a shot
at https://pypi.org/project/sphinx-asciidoc/ as an alternative. I haven't
tested it, but it supposedly exists to be a better converter than pandoc
and it may save some of that manual work.
--
Sylvain


On Thu, Jun 11, 2020 at 4:45 PM Ekaterina Dimitrova 
wrote:

> I told the same to Lorina in person, +1 more fan
>
> On Thu, 11 Jun 2020 at 10:36, Joshua McKenzie 
> wrote:
>
> > Left bar navigation and content navigation on top right are both
> > aesthetically and usability-wise quite superior IMO (comparing to
> > https://cassandra.apache.org/doc/latest/getting_started/configuring.html
> ).
> >
> > I'm a fan.
> >
> > On Wed, Jun 10, 2020 at 2:21 PM Lorina Poland 
> wrote:
> >
> > > Hello all!
> > >
> > > Based on an earlier discussion about moving the OSS C* docs to
> > > asciidoc, to allow more flexibility in maintaining the docs, I've done
> > > a proof of concept about what it would take to accomplish a
> > > conversion. I converted rSt files to asciidoc files using pandoc, did
> > > some additional editing, and use antora (antora.org) as a static site
> > > generator to build the docs. The result is here:
> > >
> > >
> >
> https://polandll.github.io/site/ASCIIDOC_POC/4.0/cassandra/getting_started/configuring.html#changing-the-location-of-directoriesThe
> > > editing of the docs is NOT complete, but I completed enough to feel
> > > confident that this process can be accomplished. Some YAML
> > > configuration for antora was required, and I did a minimum of UI
> > > configuration (added color banner, logo). Looking for feedback and
> > > questions anyone may have.
> > >
> > > Thanks,
> > >
> > > Lorina Poland (DataStax tech writer)
> > >
> >
>

Re: [DISCUSS] Documentation donation

[Sylvain Lebresne]

h the technical writers at datastax to make this
> happen.  The investment cost is irrelevant to the project because time is
> donated, and unless you're someone's manager it shouldn't matter how much
> time they invest.  Even if you are, that's a private matter not relevant to
> the list.  If the writers are willing to help migrate documentation, I'm
> willing to shepherd the process, and I absolutely love that they're willing
> to help in this area.
>
> From a technical angle, I ask that you trust my experience and judgement
> using all three tools extensively over a long period of time (3 years
> minimum, 10 years of rst).  I have written thousands of pages of technical
> documentation in my life and I understand the pros and cons of all three
> systems and have weighed the costs of each of them for the last several
> months.  Otherwise, you're asking for the rest of the project to wait while
> you become an expert in the remaining tooling.  I doubt you have the time
> (or interest) in doing that.
>
> I know, without question, asciidoctor will give us the richest
> documentation with a very quick learning curve, so it's my personal
> preference.  I'm 100% sure someone someone that is already familiar with
> markdown will find it easy to move to asciidoc since they're so similar in
> structure and the syntax is mostly compatible.
>
> I understand you don't want to see the project docs fall into a state of
> disrepair and as the person maintaining most of the docs today, I agree!  I
> remember you did the initial work because I created the JIRA to do so.
> We've both invested a lot of time in the docs, so hopefully you trust that
> I don't take this lightly and wouldn't want to make the change without
> expecting to see a big payoff in the end.
>
> Jon
>
> [1] https://cqlengine.readthedocs.io/en/latest/
> [2] http://cassandra-reaper.io
> [3] http://thelastpickle.com/tlp-stress/
> [4]
> https://github.com/thelastpickle/tlp-stress/blob/master/manual/MANUAL.adoc
> [5]
>
> https://github.com/thelastpickle/tlp-cluster/blob/master/manual/src/index.adoc
> [6] http://github.com/thelastpickle/tlp-cluster
> [7] https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/
> [8] https://docutils.sourceforge.io/docs/user/rst/quickref.html#tables
> [9] https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#tables
> [10] https://issues.apache.org/jira/browse/CASSANDRA-8700
>
>
> On Thu, Apr 30, 2020 at 6:05 AM Sylvain Lebresne 
> wrote:
>
> > I do worry Markdown might not be a great choice.
> >
> > It's definitively most well know by a large margin, and that's a good,
> but
> > it's also a bit limited (even with common extensions). It's perfect for
> > comments, README or even somewhat informal docs, but we're talking the
> > fairly
> > large (and meant to grow) user facing documentation of a large and
> somewhat
> > complex software, and a bit more flexibility is of definite use imo. I
> > truly
> > worry Markdown will effectively yield a lesser experience for user of the
> > doc.
> >
> > By how much, I'm not sure, but insofar that the documentation is read
> order
> > of
> > magnitudes more (and by order of magnitudes more people) than written,
> I'm
> > not
> > a fan of shrugging this off too quickly.
> >
> > Regarding asciidoc, it looks most likely capable enough, and I have no
> > technical
> > objection to its use on principle. But I'm also unconvinced it's a
> > significantly better
> > choice than restructuredText (currently used). Both syntax are different
> > enough from Markdown that there is a bit of muscle memory to retrain, but
> > both are also easy enough in general (it's all human readable markup)
> that
> > it
> > doesn't feel like a huge deal either. And while it's hard to get perfect
> > data
> > on this, a simple Google trends search
> > (
> >
> >
> https://trends.google.fr/trends/explore?date=today%205-y=markdown,asciidoc,restructuredText
> > )
> > suggests that while asciidoc is a tad more popular (than rst), neither
> are
> > ubiquitous enough for me to imagine that it'd make a meaningful
> difference.
> >
> > I'm really not against asciidoc, but also keep in mind the current doc
> has
> > had
> > some amount of setup: it's somewhat integrated to the website (though
> I'll
> > admit it's debatable whether that's important to preserve or not),
> > automatic
> > syntax highlighting for CQL is already setup, etc. Switching to asciidoc
> is
> > not "no work". Are we sufficiently certain it is worth it?
> >
> > Tl;dr, my current position is:
>

Re: [DISCUSS] Documentation donation

[Sylvain Lebresne]

I do worry Markdown might not be a great choice.

It's definitively most well know by a large margin, and that's a good, but
it's also a bit limited (even with common extensions). It's perfect for
comments, README or even somewhat informal docs, but we're talking the
fairly
large (and meant to grow) user facing documentation of a large and somewhat
complex software, and a bit more flexibility is of definite use imo. I truly
worry Markdown will effectively yield a lesser experience for user of the
doc.

By how much, I'm not sure, but insofar that the documentation is read order
of
magnitudes more (and by order of magnitudes more people) than written, I'm
not
a fan of shrugging this off too quickly.

Regarding asciidoc, it looks most likely capable enough, and I have no
technical
objection to its use on principle. But I'm also unconvinced it's a
significantly better
choice than restructuredText (currently used). Both syntax are different
enough from Markdown that there is a bit of muscle memory to retrain, but
both are also easy enough in general (it's all human readable markup) that
it
doesn't feel like a huge deal either. And while it's hard to get perfect
data
on this, a simple Google trends search
(
https://trends.google.fr/trends/explore?date=today%205-y=markdown,asciidoc,restructuredText
)
suggests that while asciidoc is a tad more popular (than rst), neither are
ubiquitous enough for me to imagine that it'd make a meaningful difference.

I'm really not against asciidoc, but also keep in mind the current doc has
had
some amount of setup: it's somewhat integrated to the website (though I'll
admit it's debatable whether that's important to preserve or not),
automatic
syntax highlighting for CQL is already setup, etc. Switching to asciidoc is
not "no work". Are we sufficiently certain it is worth it?

Tl;dr, my current position is:
1. I'm rather cold on using markdown. I would insist on making a good case
   this won't meaningfully degrade the output quality before jumping ship.
2. I see the ROI of switching to asciidoc as rather small (the investment is
   non null, and the return not that clear to me, though I obviously may be
   missing some of the advantages of asciidoc over reStructuredText and
will,
   as always, happily re-evaluate on new information). It won't oppose it if
   someone makes the work (and it's not botched), but I think the effort
would
   be better spent elsewhere.
--
Sylvain


On Thu, Apr 30, 2020 at 5:02 AM John Sanda  wrote:

> +1 to asciidoc. My guess would be that more people are familiar with
> markdown, but asciidoc definitely has more to offer and is easy enough to
> use if you are familiar with markdown.
>
> On Fri, Apr 24, 2020 at 11:24 AM Jon Haddad  wrote:
>
> > I'd like to get the docs out of Sphinx.  I hate it.  The syntax is crap
> and
> > almost nobody knows it.
> >
> > I'm fine with markdown (it makes it easy for most people) and have a
> > personal preference for asciidoc, since it makes it easier to generate
> PDFs
> > and is a bit richer / better for documentation.  I'd go with markdown if
> it
> > means more contributions though.
> >
> > I'd love to see the site maintained with Hugo.  It's a really nice tool,
> I
> > used it to build the reaper website [1] and the docs [2].  Source example
> > for documentation here [3].
> >
> > I won't have time for the conversion anytime soon, but if someone's
> willing
> > to take it on I think it would really help with both writing and
> reviewing
> > docs.
> >
> > [1] http://cassandra-reaper.io
> > [2] http://cassandra-reaper.io/docs/
> > [3]
> >
> >
> https://github.com/thelastpickle/cassandra-reaper/blob/master/src/docs/content/docs/development.md
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Apr 24, 2020 at 8:11 AM Joshua McKenzie 
> > wrote:
> >
> > > All,
> > >
> > > A few of us have the opportunity to offer a large portion of
> > documentation
> > > to the apache foundation and specifically the Apache Cassandra project
> as
> > > well as dedicate a good portion of time to maintaining this going
> > forward.
> > > For those of you familiar, this is the DataStax sponsored / authored
> > > Cassandra documentation people often refer to in the community. Links
> can
> > > be found here
> > > <
> >
> https://docs.datastax.com/en/landing_page/doc/landing_page/cassandra.html
> > > >.
> > >
> > > I've spoken with some of the doc writers and there's going to be
> > > significant work involved to go from the doc writing system these are
> > > authored in to Sphinx, or some other doc authoring system if we as a
> > > project decide to switch things. I know Jon Haddad has some opinions
> here
> > > and I think that'd be a great conversation to have on this thread for
> > those
> > > interested. A couple of people in the near future are going to have the
> > > opportunity to continue working on these docs full-time in the in-tree
> > > docs, so maintenance going forward should represent little disruption
> to
> > > the project's 

Re: DataStax Driver Donation to Apache Cassandra Project

[Sylvain Lebresne]

On Tue, Apr 28, 2020 at 5:10 PM Joshua McKenzie 
wrote:

> >
> >  If we're talking day to day
> > maintenance, so the bulk of the work really, then I feel rather confident
> > saying that you are wrong,
>
> You're confidently responding to something I wasn't trying to say. :) I may
> not have communicated clearly. I was attempting to enumerate:
>
>1. New feature development will likely require coordination between
>server and drivers (i.e. driver changes are required to support new
>features in server)
>2. Future roadmap for the core server and drivers will likely overlap
>(see #1)
>3. CEP's for 1 and 2, assuming one accepts the assertion that features
>require driver changes, mean CEP's will have components of both
>4. Independent architectural or API changes in the drivers will likely
>impact the server, and thus also require coordination. Especially with
>drivers being nested and used extensively in cqlsh, tests, etc.
>
> I was not speaking to the day to day maintenance of the projects but rather
> the larger feature-level, roadmap, architectural planning of them. I would
> not expect day to day maintenance to intersect with the governance of the
> projects on a regular basis.
>

As often, disagreement is more often than not a communication issue. I
apologize
for not doing a better job at understanding your points (and apologize for
my less
than optimal phrasing on that sentence).

But hopefully the rest of my email had also clarified that I do not
disagree with the
general roadmapping and project planning to be common (for drivers and
server).
In fact, I'm in favor of that. That's why I suggesting a single "Apache"
project, not
to incubate different ones in particular.

But I also want us to ensure that whatever change of organization we make
while
accepting the drivers does not make the day-to-day maintenance harder. And
again, at that level, I think server and driver are more different than
they are same,
so some separation a "some" level is likely necessary. I'll refer to my
previous email
for where I'd personally keep things separated and were I wouldn't.

--
Sylvain

Re: DataStax Driver Donation to Apache Cassandra Project

[Sylvain Lebresne]

does anyone know of any other apache projects that have either
> > > subprojects or complementary sideprojects they're interdependent upon
> in
> > > their ecosystems? I'd like to reach out to some other pmc's for advice
> > and
> > > feedback on this topic since there's no sense in reinventing the wheel
> if
> > > other projects have wisdom to share on this.
> > >
> > > On Mon, Apr 27, 2020 at 12:42 PM Joshua McKenzie  >
> > > wrote:
> > >
> > > > re: ML noise, how hard would it be to filter out JIRA updates
> > w/component
> > > > "Drivers"? Or from JIRA queries?
> > > >
> > > > For governance, I see it cutting both ways. If we have two separate
> > > > projects and ML's for drivers and C*, how do we keep a coherent view
> of
> > > new
> > > > features and roadmap stuff? Do we have CEP's for both projects and
> tie
> > > them
> > > > together? Do we drive changes in the driver feature ecosystem via
> CEP's
> > > in
> > > > C*?
> > > >
> > > > In the Venn diagram of overlap vs. non between the two projects, I
> see
> > > > there being more overlap than not.
> > > >
> > > > On Mon, Apr 27, 2020 at 12:34 PM Dinesh Joshi 
> > wrote:
> > > >
> > > >>
> > > >>
> > > >> > On Apr 27, 2020, at 2:50 AM, Sylvain Lebresne  >
> > > >> wrote:
> > > >> >
> > > >> > Fwiw, I agree with the concerns raised by Benedict, and think we
> > > should
> > > >> > carefully think about how this is handled. Which isn't not a
> > rejection
> > > >> of
> > > >> > the donation in any way.
> > > >> >
> > > >> > Drivers are not small projects, and the majority of their day to
> day
> > > >> > maintenance is unrelated to the server (and the reverse is true).
> > > >> >
> > > >> > From the user point of view, I think it would be fabulous that
> > > Cassandra
> > > >> > appears like one project with a server and some official drivers,
> > with
> > > >> one
> > > >> > coherent website and documentation for all. I'm all for striving
> for
> > > >> that.
> > > >>
> > > >> +1
> > > >>
> > > >> > Behind the scenes however, I feel tings should be setup so that
> some
> > > >> amount
> > > >> > of
> > > >> > separation remains between server and whichever drivers are
> donated
> > > and
> > > >> > accepted, or I'm fairly sure things would get messy very
> > quickly[1]).
> > > >> In my
> > > >>
> > > >> Can you say more about what "getting messy very quickly" means here?
> > > >>
> > > >> > mind that means *at a minimum*:
> > > >> > - separate JIRA projects.
> > > >> > - dedicated _dev_ (and commits) mailing lists.
> > > >>
> > > >> If we're thinking through how this would be setup, initially we had
> > the
> > > >> same Jira project for sidecar but now there is a separate one to
> track
> > > >> sidecar specific jiras. At the moment we do not have a separate
> > mailing
> > > >> list. I think Cassandra dev mailing list's volume is low enough to
> > keep
> > > >> using the same ML. There is an added value that it gives visibility
> > and
> > > >> developers don't need to go between multiple mailing lists.
> > > >>
> > > >> > But it's also worth thinking whether a single pool of
> committers/PMC
> > > >> > members is
> > > >> > desirable.
> > > >> >
> > > >> > Tbc, I'm not sure what is the best way to achieve this within the
> > > >> > constraint of
> > > >> > the Apache fundation, and maybe I'm just stating the obvious here.
> > > >> >
> > > >> >
> > > >> > [1] fwiw, I say this as someone that at some points in time was
> > > >> > simultaneously
> > > >> > somewhat actively involved in both Cassandra and the DataStax Java
> > > >> driver.
> > > >> >
> > > >> > --
> > > >> > Sylvain
> > > >>

Re: DataStax Driver Donation to Apache Cassandra Project

[Sylvain Lebresne]

Fwiw, I agree with the concerns raised by Benedict, and think we should
carefully think about how this is handled. Which isn't not a rejection of
the donation in any way.

Drivers are not small projects, and the majority of their day to day
maintenance is unrelated to the server (and the reverse is true).

>From the user point of view, I think it would be fabulous that Cassandra
appears like one project with a server and some official drivers, with one
coherent website and documentation for all. I'm all for striving for that.

Behind the scenes however, I feel tings should be setup so that some amount
of
separation remains between server and whichever drivers are donated and
accepted, or I'm fairly sure things would get messy very quickly[1]). In my
mind that means *at a minimum*:
- separate JIRA projects.
- dedicated _dev_ (and commits) mailing lists.

But it's also worth thinking whether a single pool of committers/PMC
members is
desirable.

Tbc, I'm not sure what is the best way to achieve this within the
constraint of
the Apache fundation, and maybe I'm just stating the obvious here.


[1] fwiw, I say this as someone that at some points in time was
simultaneously
somewhat actively involved in both Cassandra and the DataStax Java driver.

--
Sylvain


On Fri, Apr 24, 2020 at 12:54 AM Benedict Elliott Smith 
wrote:

> Do you have some examples of issues?
>
> So, to explain my thinking: I believe there is value in most contributors
> being able to know and understand a majority of what the project
> undertakes.  Many people track a wide variety of activity on the project,
> and whether they express an opinion they probably form one and will involve
> themselves if they consider it important to do so.  I worry that importing
> several distinct and only loosely related projects to the same governance
> and communication structures has a strong potential to undermine that
> capability, as people begin to assume that activity and decision-making is
> unrelated to them - and if that happens I think something important is lost.
>
> The sidecar challenges this already but seems hopefully manageable: it is
> a logical extension of Cassandra, existing primarily to plug gaps in
> Cassandra's own functionality, and features may migrate to Cassandra over
> time.  It is likely to have releases closely tied to Cassandra itself.
> Other subprojects are so far exclusively for consumption by the Cassandra
> project itself, and are all naturally coupled.
>
> Drivers however are inherently arms-length endeavours: we publish a
> protocol specification, and driver maintainers implement it.  They are
> otherwise fairly independent, and while a dialogue is helpful it does not
> need to be controlled by a single entity.  Many drivers will continue to be
> controlled by others, as they have been until now.  We're of course able to
> ensure there's a strong overlap of governance, which I think would be very
> helpful, and something Curator and Zookeeper seem not to have managed.
>
> Looking at the Curator website, it also seems to pitch itself as a
> relatively opinionated product, and much more than a driver.  I hope the
> recipe for conflict in our case is much more limited given the functional
> scope of a driver - and anyway better avoided with more integrated, but
> still distinct governance.
>
> That's not to say I don't see some value in the project controlling the
> driver directly, I just worry about the above.
>
>
>
> On 22/04/2020, 21:25, "Nate McCall"  wrote:
>
> On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > I welcome the donation, and hope we are able to accept all of the
> > drivers.  This is really great news IMO.
> >
> >  I do however wonder if the project may be accumulating too many
> > sub-projects?  I wonder if it's time to think about splitting, and
> perhaps
> > incubating a project for the drivers?
> >
>
> This is a legit concern and good question, but I think this is more a
> natural evolution of growing a project. There is precedent for this in
> Spark, Beam, Hadoop and others who have a number of different
> repositories
> under the general project umbrella.
>
> What I would like to avoid is a situation like with Apache Curator and
> Apache Zookeeper. The former being a zookeeper client donation from
> Netflix
> that came in as a top level project. From the peanut gallery, it seems
> like
> that has been less than ideal a couple of times in the past
> coordinating
> releases, trademarks and such with separate project management.
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Documentation donation

[Sylvain Lebresne]

> Are there any questions or concerns about this donation?

Getting substantial contributions to the documentation is a great thing to
me
in principle.

My main question was around the exact form this donation would take since
the
project has already lots of documentation. And I was about to suggest that a
good option would be individual tickets to contribute specific additions to
existing parts and probably a few new parts. But your last email suggests
exactly this from what I understand, so I'm personally satisfied on that
front.

> Any thoughts on documentation system to use long-term, since a donation
> of this size would be a reasonable time to consider switching to something
> more preferable

My advise would be to ignore that consideration from the process of such
contribution. I  don't think the impact is that big, and my experience is
that
such "only-semi-related" dependencies often needlessly slows the
contribution
process for little benefit.

To justify this a bit, my reasoning is that assuming we do change the
existing
system, given our usual process for contributions works better with
text-based
things, then it's hard for me to imagine a strong argument made for moving
out
of a somewhat standard markup format (but I'd welcome good arguments that
proves me wrong).

So it would be a change from one "somewhat standard markup format" to
another,
and those have tools to convert between each other (pandoc
(https://pandoc.org/) comes to mind, and while I think its rst support is
not
extensive, https://pypi.org/project/sphinx-asciidoc/ is probably good
enough).

Tbc, such conversion probably need some light post-processing in practice,
but
that's unlikely a huge undertaking, even with significantly more
documentation
than the project currently has.

> I'd like to get the docs out of Sphinx.  I hate it.  The syntax is crap
and
> almost nobody knows it.

> As a stopgap, Sphinx can generate docs based on markdown (and possibly
even
> asciidoc but I haven't checked).  Probably easiest to do the conversion to
> markdown incrementally that way, then we can flip everything over to Hugo.

I respect your opinions, but before considering such change "acted", I would
hope that (as for anything else) a case with as-objective-as-possible
arguments
is made. One that weights the benefits against its costs.

Tbc, it's not that I care deeply for either Sphinx or reStructuredText on a
personal level, nor that I'm opposing such changes on principle. Just that
the ROI is not _that_ obvious to me, in that while I can see some pros, I
don't
find them overwhelming and I do see some cons (this needs a longer
discussion,
but to mention just one of the top of my head: the
CQL reference doc does use 'grammar' conveniences and that is imo genuinely
nice (for users using the doc) but might be a PITA to reproduce with
asciidoc/markown).

Re: [VOTE] Change Jira Workflow

[Sylvain Lebresne]

+1
--
Sylvain


On Tue, Dec 18, 2018 at 9:34 AM Oleksandr Petrov 
wrote:

> +1
>
> On Mon, Dec 17, 2018 at 7:12 PM Nate McCall  wrote:
> >
> > On Tue, Dec 18, 2018 at 4:19 AM Benedict Elliott Smith
> >  wrote:
> > >
> > > I propose these changes <
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>*
> to the Jira Workflow for the project.  The vote will be open for 72 hours**.
> > >
> >
> >
> > +1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> --
> alex p
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Revisit the proposal to use github PR

[Sylvain Lebresne]

Fwiw, I personally find it very useful to have all discussion, review
comments included, in the same place (namely JIRA, since for better or
worse, that's what we use for tracking tickets). Typically, that means
everything gets consistently pushed to the  commits@ mailing list, which I
find extremely convenient to keep track of things. I also have a theory
that the inline-comments type of review github PR give you is very
convenient for nitpicks, shallow or spur-of-the-moment comments, but
doesn't help that much for deeper reviews, and that it thus to favor the
former kind of review.

Additionally, and to Benedict's point, I happen to have first hand
experience with a PR-based process for a multi-branch workflow very similar
to the one of this project, and suffice to say that I hate it with a
passion.

Anyway, very much personal opinion here.
--
Sylvain


On Thu, Dec 13, 2018 at 2:13 AM dinesh.jo...@yahoo.com.INVALID
 wrote:

> I've been already using github PRs for some time now. Once you specify the
> ticket number, the comments and discussion are persisted in Apache Jira as
> work log so it can be audited if desired. However, committers usually
> squash and commit the changes once the PR is approved. We don't use the
> merge feature in github. I don't believe github we can merge the commit
> into multiple branches through the UI. We would need to merge it into one
> branch and then manually merge that commit into other branches. The big
> upside of using github PRs is that it makes collaborating a lot easier.
> Downside is that it makes it very difficult to follow along the progress in
> Apache Jira. The messages that github posts back include huge diffs and are
> aweful.
> Dinesh
>
> On Thursday, December 13, 2018, 1:10:12 AM GMT+5:30, Benedict Elliott
> Smith  wrote:
>
>  Perhaps somebody could summarise the tradeoffs?  I’m a little concerned
> about how it would work for our multi-branch workflow.  Would we open
> multiple PRs?
>
> Could we easily link with external CircleCI?
>
> It occurs to me, in JIRA proposal mode, that an extra required field for a
> permalink to GitHub for the patch would save a lot of time I spend hunting
> for a branch in the comments.
>
>
>
>
> > On 12 Dec 2018, at 19:20, jay.zhu...@yahoo.com.INVALID wrote:
> >
> > It was discussed 1 year's ago:
> https://www.mail-archive.com/dev@cassandra.apache.org/msg11810.html
> > As all Apache projects are moving to gitbox:
> https://reference.apache.org/committer/github, should we revisit that and
> change our review/commit process to use github PR?A good example is
> Spark:"Changes to Spark source code are proposed, reviewed and committed
> via Github pull requests" (https://spark.apache.org/contributing.html).
> > /jay
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

On Wed, Dec 12, 2018 at 7:14 PM Benedict Elliott Smith 
wrote:

> Ok, so feel free to keep your votes coming, but we have a pretty clear
> majority for everything except Wish - which presently stands at -1 (maybe
> -2 if Sylvain updates his vote).
>

Yes, I did meant -1 on the wish issue if that can help.


>
> Thanks everyone who has voted on either poll!
>
>
> Results so far:
> 2. [B C A] x6 [A B C] x1
> 3. A x7
> 4. +1 -2
>
> For 1, we have:
> D C B A E
> D C B A E
> D C B E A
> D C E B A
> A D E B C
> A B C D E
> E D C B A
> C D A B E
>
> Which currently leads to eliminating B, C and E first choice votes,
> leading to a strong win for option D.
>
> I’ll leave it a few days to see if anymore votes roll in, but I don’t
> anticipate a major shift in opinion.  I will update the proposal with the
> outcome, and call a formal vote on the final proposal in a few days.
>
> Thanks again everyone for participating in what I realise was not the most
> exciting discussion.  I’m glad everyone got a chance to air their opinions,
> and that we managed to come to a decision that I hope we can all endorse.
>
>
> On 12 Dec 2018, at 16:00, Ariel Weisberg  wrote:
>
> Hi,
>
> Updating to reflect the new options for 1. 2, 3, and 4 remain unchanged.
>
> 1. E, D, C,  B, A
>
> 2. B, C, A
>
> 3. A
>
> 4. -.5
>
> Ariel
> On Tue, Dec 11, 2018, at 10:55 AM, Ariel Weisberg wrote:
>
> Hi,
>
> Sorry I was just slow on the uptake as to what auto-populate meant RE #2.
>
> 1. -1, while restricting editing on certain fields or issues that people
> did not submit themselves is OK I don't think  it's reasonable to block
> edits to subject, or description on issues a user has submitted.
>
> Do we actually have a problem that needs solving with restricting edits?
> I feel like we aren't being harmed right now by the current power people
> are wielding?
>
> 2. B, C, A
>
> 3. A
>
> 4. -.5, I really don't see Wish as something other then a synonym for
> low priority. Only -.5 because I don't think it's that harmful either.
>
> Ariel
>
> On Mon, Dec 10, 2018, at 8:51 PM, Benedict Elliott Smith wrote:
>
> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
>
>
> Hi,
>
> RE #1, does this mean if you submit a ticket and you are not a contributor
> you can't modify any of the fields including description or adding/removing
> attachments?
>
>
> Attachment operations have their own permissions, like comments.
> Description would be prohibited though.  I don’t see this as a major
> problem, really; it is generally much more useful to add comments.  If
> we particularly want to make a subset of fields editable there is a
> workaround, though I’m not sure anybody would have the patience to
> implement it:
>
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> <
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> >
>
> RE #2, while bugs don't necessarily have a priority it's helpful to have
> it sort logically with other issue types on that field. Seems like ideally
> what we want to preserve is a useful sort order without having to populate
> the field manually.
>
>
> Do you have a suggestion that achieves this besides auto-populating (if
> that’s even possible)?  More than happy to add suggestions to the list.
>
> RE #4, Do we need to keep wish at all?
>
>
> I’m unclear on what you’re asking?  I included exactly this question,
> directly in response to your opinion that it should not be kept.  If you
> have more to add to your earlier view, please feel free to share it.
>
> Not voting yet just because I'm not sure on some.
>
> Ariel
>
> On Mon, Dec 10, 2018, at 7:43 AM, Benedict Elliott Smith wrote:
>
> New questions.  This is the last round, before I call a proper vote on
> the modified proposal (so we can take a mandate to Infra to modify our
> JIRA workflows).
>
> Thanks again to everyone following and contributing to this discussion.
> I’m not sure any of these remaining questions are critical, but for the
> best democratic outcome it’s probably worth running them through the
> same process.  I also forgot to include (1) on the prior vote.
>
> 1. Limit edits to JIRA ‘contributor’ role: +1/-1
> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
> leave it.  Please rank.
> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation
> of why I chose Urgent
> <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> >>.
> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
>
> For 2, if we cannot remove it, we can make it non-editable and default
> to Normal; for auto-populate I propose using Severity (Low->Low, Normal-
>
> Normal, Critical->Urgent).  No guarantees entirely on what we can
>
> achieve, 

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

1: D C E B A (with a particularly strong feeling against A)
2: A B C
3: A (but don't mind much overall)
4: Don't mind (I neither particularly like 'wish' as a priority or issue
type really)
--
Sylvain


On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
 wrote:

> 1. C, D, A, B, E
> 2. B, C, A
> 3. A
> 4. Meh
>
> > On 11 Dec 2018, at 16:28, Benedict Elliott Smith 
> wrote:
> >
> > Just to re-summarise the questions for people:
> >
> > 1. (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> > 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
> leave it.  Please rank.
> > 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation
> of why I chose Urgent <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> >>.
> > 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> >
> > With my answers (again, sorry):
> >
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> >
> >> On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
> wrote:
> >>
> >> It looks like we have a multiplicity of views on permissions, so
> perhaps we should complicate this particular vote with all of the possible
> options that have been raised so far (including one off-list).  Sorry
> everyone for the confusion.
> >>
> >> (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> >>
> >> * Today apparently ‘Anyone’ can perform this operation
> >>
> >> A ranked vote, please.  This makes my votes:
> >>
> >> 1: A B C D E
> >> 2: B C A
> >> 3: A
> >> 4: +0.5
> >>
> >>
> >>> On 11 Dec 2018, at 05:51, Dinesh Joshi 
> wrote:
> >>>
> >>> I agree with this. I generally am on the side of freedom and
> responsibility. Limiting edits to certain fields turns people off.
> Something I want to very much avoid if we can.
> >>>
> >>> Dinesh
> >>>
>  On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
> murukesh.moha...@gmail.com> wrote:
> 
>  On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>   wrote:
> >
> >> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> >>
> >> Hi,
> >>
> >> RE #1, does this mean if you submit a ticket and you are not a
> contributor you can't modify any of the fields including description or
> adding/removing attachments?
> >
> > Attachment operations have their own permissions, like comments.
> Description would be prohibited though.  I don’t see this as a major
> problem, really; it is generally much more useful to add comments.  If we
> particularly want to make a subset of fields editable there is a
> workaround, though I’m not sure anybody would have the patience to
> implement it:
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> <
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> >
> >
> 
>  That would be disappointing. Descriptions with broken or no formatting
>  aren't rare (say, command output without code formatting). And every
>  now and then the description might need to be updated. For example, in
>  https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
> the
>  paper had rotted, but I managed to find a new one, so I could edit it
>  in. If such a change had to be posted as a comment, it might easily
>  get lost in some of the more active issues.
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

Not much to add really, but just to close the loop, responses inline.

On Wed, Dec 5, 2018 at 11:58 AM Benedict Elliott Smith 
wrote:

> Thanks for the feedback and further questions.  I’m sure there will be
> more, particularly around permissions and roles, so it’s good to get some
> of these other discussions moving.
>
> No doubt we’ll do a second poll once the first one concludes.  Please,
> everyone, keep your first poll answers coming!
>
> > On 5 Dec 2018, at 09:50, Sylvain Lebresne  wrote:
> >
> > Thanks for all those that contributed to the proposal, and specifically
> to
> > Benedict for leading the discussion.
> >
> > On the general proposal, I suspect there is a few details we may have to
> > tweak going forward, but hard to be sure before trying and as I do think
> > it's progress, I'm personally happy to move forward with this. But for
> the
> > sake of discussions, a minor remarks that I don't think have been
> mentioned
> > above:
> > - at least the platform and feature fields will be moving targets (the
> > features hopefully more so than the platform, but new java version gets
> > release regularly for instance). Do we know technically if we can get
> those
> > easily updated without requiring an infra JIRA ticket?
>
> This is actually a really good question.  I had assumed this would be
> treated much like Component, Version, etc
>
> However, I was wrong:
>
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> <
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> >
>
> There are some possible workarounds, but none of them seem great.  There’s
> a plugin, but not sure if Infra would be OK with this:
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server=overview
> <
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server=overview
> >
>
> This is potentially a real blocker for these two fields.
>
> So, for feature an alternative is to merge Feature/[Feature] into
> Component.  This would implicitly make it non-mandatory, however.  This
> could potentially be fixed with a custom field validator, but this might
> need a plugin.
>
> For Platform, I don’t have a good alternative idea right now.  This is
> something that is best curated, but definitely needs to be easily updated.
>

That's what I feared, and that sucks. And I'm coming short as well of a
good alternative that don't require plugins.
That said, if push comes to shove, if we just make them free-form but
mandatory to get out of triage (with "all" and "none" being explicitly ok
values), and have a bit of documentation, there is still a good change
we'll get meaningful information out of this. Better than what we have at
least.


> > - I'd personally probably remove the condition of being "jira
> contributor"
> > to move tickets out of triage. Being a "jira contributor" is a pretty
> > arbitrary in practice. Anyone that ever asked has been added, no question
> > asked, but it can actually be annoying to get added if no-one that knows
> > how to do it is around. So if, as I assume, the goal is to ensure that
> > fields are properly fielded, I don't think it will help much, and so I
> > suspect it would just be an annoyance to new, not-yet-"jira contributor"
> > users that are willing to fill all the required fields seriously (but
> will
> > see their ticket stuck in triage until they either get added, or some
> other
> > random user flip the switch). And why assume people will mis-field
> stuffs?
> > So I'd vote for just letting anyone transition out of triage as long as
> all
> > required field are there. Side-note: fwiw, I'd very much be in favor of
> > removing the "jira contributor" concept for the reasons exposed above: I
> > never felt it was anything else than an hindrance.
>
> I realise we have no real barrier to becoming a contributor, and that many
> of these permissions are going to have limited impact.  But I think a
> really easy to jump gate can still be helpful, and I don’t recall
> contributors overstepping their role.  But this isn’t a critical point, and
> it would be great to hear other’s opinions.
>

Yeah, curious to see how other feel. That said, to be clear, I'm not really
feeling any strong on this. I'd just prefer trusting people by default to
do the right thing, especially when the "JIRA contributor" barrier is so
low/largely meaningless, and save ourselves the trouble of having to add
people to the "JI

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

Thanks for all those that contributed to the proposal, and specifically to
Benedict for leading the discussion.

On the general proposal, I suspect there is a few details we may have to
tweak going forward, but hard to be sure before trying and as I do think
it's progress, I'm personally happy to move forward with this. But for the
sake of discussions, a minor remarks that I don't think have been mentioned
above:
- at least the platform and feature fields will be moving targets (the
features hopefully more so than the platform, but new java version gets
release regularly for instance). Do we know technically if we can get those
easily updated without requiring an infra JIRA ticket?
- I'd personally probably remove the condition of being "jira contributor"
to move tickets out of triage. Being a "jira contributor" is a pretty
arbitrary in practice. Anyone that ever asked has been added, no question
asked, but it can actually be annoying to get added if no-one that knows
how to do it is around. So if, as I assume, the goal is to ensure that
fields are properly fielded, I don't think it will help much, and so I
suspect it would just be an annoyance to new, not-yet-"jira contributor"
users that are willing to fill all the required fields seriously (but will
see their ticket stuck in triage until they either get added, or some other
random user flip the switch). And why assume people will mis-field stuffs?
So I'd vote for just letting anyone transition out of triage as long as all
required field are there. Side-note: fwiw, I'd very much be in favor of
removing the "jira contributor" concept for the reasons exposed above: I
never felt it was anything else than an hindrance.
- Once we have 'complexity' and 'severity', I'm not entirely sure what
'priority' really means in a voluntary-based project? Is it the gut-feeling
for how useful the ticket is of whomever triage the ticket? If that,
outside of not being convinced of the value, I'd argue that 1) it doesn't
make sense for bugs and 2) it's sufficiently imprecise that it's imo worth
keeping it simple, something like low/normal/high ought to be enough. If
it's not that, then what is it, cause it's genuinely not immediately
obvious to me?

And with that, my poll results:
1:A
2:+1
3:+1
4:Don't mind
5:Don't mind
--
Sylvain


On Tue, Dec 4, 2018 at 8:12 PM Benedict Elliott Smith 
wrote:

> Ok, so after an initial flurry everyone has lost interest :)
>
> I think we should take a quick poll (not a vote), on people’s positions on
> the questions raised so far.  If people could try to take the time to stake
> a +1/-1, or A/B, for each item, that would be really great.  This poll will
> not be the end of discussions, but will (hopefully) at least draw a line
> under the current open questions.
>
> I will start with some verbiage, then summarise with options for everyone
> to respond to.  You can scroll to the summary immediately if you like.
>
> - 1. Component: Multi-select or Cascading-select (i.e. only one component
> possible per ticket, but neater UX)
> - 2. Labels: rather than litigate people’s positions, I propose we do the
> least controversial thing, which is to simply leave labels intact, and only
> supplement them with the new schema information.  We can later revisit if
> we decide it’s getting messy.
> - 3. "First review completed; second review ongoing": I don’t think we
> need to complicate the process; if there are two reviews in flight, the
> first reviewer can simply comment that they are done when ready, and the
> second reviewer can move the status once they are done.  If the first
> reviewer wants substantive changes, they can move the status to "Change
> Request” before the other reviewer completes, if they like.  Everyone
> involved can probably negotiate this fairly well, but we can introduce some
> specific guidance on how to conduct yourself here in a follow-up.
> - 4. Priorities: Option A: Wish, Low, Normal, High, Urgent; Option B:
> Wish, Low, Normal, Urgent
> - 5. Mandatory Platform and Feature. Make mandatory by introducing new
> “All” and “None” (respectively) options, so always possible to select an
> option.
> - 6. Environment field: Remove?
>
> I think this captures everything that has been brought up so far, except
> for the suggestion to make "Since Version” a “Version” - but that needs
> more discussion, as I don’t think there’s a clear alternative proposal yet.
>
> Summary:
>
> 1: Component. (A) Multi-select; (B) Cascading-select
> 2: Labels: leave alone +1/-1
> 3: No workflow changes for first/second review: +1/-1
> 4: Priorities: Including High +1/-1
> 5: Mandatory Platform and Feature: +1/-1
> 6: Remove Environment field: +1/-1
>
> I will begin.
>
> 1: A
> 2: +1
> 3: +1
> 4: +1
> 5: Don’t mind
> 6: +1
>
>
>
>
> > On 29 Nov 2018, at 22:04, Scott Andreas  wrote:
> >
> > If I read Josh’s reply right, I think the suggestion is to periodically
> review active labels and promote those that are demonstrably useful to
> components (cf. 

Re: Implicit Casts for Arithmetic Operators

[Sylvain Lebresne]

 We fundamentally
> disagree with each other, on points of principle.
> >
> > This also feels like it’s becoming antagonistic, perhaps through
> misinterpreting each other, which was far from my intent.  So I will limit
> my reply to the only point of interpretation of my position.
> >
> > Given that I personally consider this to be an ideological or
> project-axiomatic decision, I therefore only consider other ideological or
> axiomatic facts to be relevant to a decision like this. So:
> >
> > 1) By “where appropriate” I mean, for instance, that this project will
> likely never support ANSI SQL in toto, by virtue of the fundamental nature
> of the project.
> > 2) I agree that which standard we choose to follow, and why we follow
> it, are both relevant questions
> >
> >
> >
> >> On 22 Nov 2018, at 11:56, Sylvain Lebresne  wrote:
> >>
> >> On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith <
> bened...@apache.org>
> >> wrote:
> >>
> >>> We’re not presently voting*; we’re only discussing, whether we should
> base
> >>> our behaviour on a widely agreed upon standard.
> >>>
> >>
> >> Well, you *explicitely* asked if people though we should do a vote, and
> I
> >> responded to that part. Let's not pretend I'm interpreting stuff, it's
> >> insulting.
> >>
> >>
> >>> I think perhaps the nub of our disagreement is that, in my view, this
> is
> >>> the only relevant fact to decide. There is no data to base this
> decision
> >>> upon.  It’s axiomatic, or ideological; procedural, not technical:  Do
> we
> >>> think we should try to hew to standards (where appropriate), or do we
> think
> >>> we should stick with what we arrived at in an adhoc manner?
> >>
> >>
> >> Yes, that is probably the nub of our disagreement. I disagree that
> hewing
> >> to standards is something we should agree on absolutely, with no other
> >> consideration in the balance. Hell, I read your "where appropriate" as
> an
> >> admission that you don't even truly think that. I think this is always a
> >> pros versus cons analysis. Adhering to standards is certainly a pro.
> >>
> >> *If* e were starting from scratch, I might maybe agree there isn't much
> >> "cons" in the balance (there is always _some_ consideration though;
> >> adhering to standard might force you into complexity that might not be
> >> justified; not saying it's our case here, just pointing again that I
> don't
> >> adhere to the absolutist view), making it an easy decision. So that I'm
> not
> >> sure we'd even need a vote to agree that "we should try to hew to
> standards
> >> (where appropriate)", even if we'd still want to discuss 1) if it is
> >> appropriate in that case and 2) which standard, so it wouldn't even be a
> >> "no data involved" decision.
> >>
> >> But we're not starting from scratch. You explicitly say yourself that it
> >> "extends to any features we have already released". So backward
> >> compatibility is a parameter we imo *must* take into account. Again,
> >> doesn't mean we don't end up breaking backward compatibility, just that
> it
> >> is a non negligible downside, so we better make sure the "pros" of
> adhering
> >> to a standard makes up for it.
> >>
> >> So yes, I do pretty strongly disagree that adhering to a standard is
> >> something that should be decided absolutely, with no other consideration
> >> taken into account.
> >>
> >>
> >>> and how meandering the discussion was with no clear consensus, it
> seemed
> >>> to need a vote in the near future.
> >>
> >>
> >> Fwiw, I also don't have the same read here. What I see on this thread
> is a
> >> bit of discussion on the specific cast issue you initially brought,
> >> discussion that didn't feel especially stuck to me, but I don't much on
> a
> >> larger discussion on adhering to standards for all our arithmetic before
> >> your suggestion a vote on it might be warranted.
> >>
> >> --
> >> Sylvain
> >>
> >>
> >>>> On 22 Nov 2018, at 09:26, Sylvain Lebresne 
> wrote:
> >>>>
> >>>> I'm not saying "let's not do this no matter what and ever fix
> technical
> >>>> debt", nor am I fearing decision.
> >>>>
> >>>> But I

Re: Implicit Casts for Arithmetic Operators

[Sylvain Lebresne]

On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith 
wrote:

> We’re not presently voting*; we’re only discussing, whether we should base
> our behaviour on a widely agreed upon standard.
>

Well, you *explicitely* asked if people though we should do a vote, and I
responded to that part. Let's not pretend I'm interpreting stuff, it's
insulting.


> I think perhaps the nub of our disagreement is that, in my view, this is
> the only relevant fact to decide. There is no data to base this decision
> upon.  It’s axiomatic, or ideological; procedural, not technical:  Do we
> think we should try to hew to standards (where appropriate), or do we think
> we should stick with what we arrived at in an adhoc manner?


Yes, that is probably the nub of our disagreement. I disagree that hewing
to standards is something we should agree on absolutely, with no other
consideration in the balance. Hell, I read your "where appropriate" as an
admission that you don't even truly think that. I think this is always a
pros versus cons analysis. Adhering to standards is certainly a pro.

*If* e were starting from scratch, I might maybe agree there isn't much
"cons" in the balance (there is always _some_ consideration though;
adhering to standard might force you into complexity that might not be
justified; not saying it's our case here, just pointing again that I don't
adhere to the absolutist view), making it an easy decision. So that I'm not
sure we'd even need a vote to agree that "we should try to hew to standards
(where appropriate)", even if we'd still want to discuss 1) if it is
appropriate in that case and 2) which standard, so it wouldn't even be a
"no data involved" decision.

But we're not starting from scratch. You explicitly say yourself that it
"extends to any features we have already released". So backward
compatibility is a parameter we imo *must* take into account. Again,
doesn't mean we don't end up breaking backward compatibility, just that it
is a non negligible downside, so we better make sure the "pros" of adhering
to a standard makes up for it.

So yes, I do pretty strongly disagree that adhering to a standard is
something that should be decided absolutely, with no other consideration
taken into account.


> and how meandering the discussion was with no clear consensus, it seemed
> to need a vote in the near future.


Fwiw, I also don't have the same read here. What I see on this thread is a
bit of discussion on the specific cast issue you initially brought,
discussion that didn't feel especially stuck to me, but I don't much on a
larger discussion on adhering to standards for all our arithmetic before
your suggestion a vote on it might be warranted.

--
Sylvain


> > On 22 Nov 2018, at 09:26, Sylvain Lebresne  wrote:
> >
> > I'm not saying "let's not do this no matter what and ever fix technical
> > debt", nor am I fearing decision.
> >
> > But I *do* think decisions, technical ones at least, should be fact and
> > data driven. And I'm not even sure why we're talking of having a vote
> here.
> > The Apache Way is *not* meant to be primarily vote-driven, votes are
> > supposed to be a last resort when, after having debated facts and data,
> no
> > consensus can be reached. Can we have the debate on facts and data first?
> > Please.
> >
> > At the of the day, I object to: "There are still a number of unresolved
> > issues, but to make progress I wonder if it would first be helpful to
> have
> > a vote on ensuring we are ANSI SQL 92 compliant for our arithmetic?".
> More
> > specifically, I disagree that such vote is a good starting point. Let's
> > identify and discuss the unresolved issues first. Let's check precisely
> > what getting our arithmetic ANSI SQL 92 compliant means and how we can
> get
> > it. I do support the idea of making such analysis btw, it would be good
> > data, but no vote is needed whatsoever to make it. Again, I object to
> > voting first and doing the analysis 2nd.
> >
> > --
> > Sylvain
> >
> >
> > On Thu, Nov 22, 2018 at 1:25 AM Jonathan Haddad 
> wrote:
> >
> >> I can’t agree more. We should be able to make changes in a manner that
> >> improves the DB In the long term, rather than live with the technical
> debt
> >> of arbitrary decisions made by a handful of people.
> >>
> >> I also agree that putting a knob in place to let people migrate over is
> a
> >> reasonable decision.
> >>
> >> Jon
> >>
> >> On Wed, Nov 21, 2018 at 4:54 PM Benedict Elliott Smith <
> >> bened...@apache.org>
> >> wrote:
> >>
> >>> The goal is simply to agree on a set of well-d

Re: Implicit Casts for Arithmetic Operators

[Sylvain Lebresne]

I'm not saying "let's not do this no matter what and ever fix technical
debt", nor am I fearing decision.

But I *do* think decisions, technical ones at least, should be fact and
data driven. And I'm not even sure why we're talking of having a vote here.
The Apache Way is *not* meant to be primarily vote-driven, votes are
supposed to be a last resort when, after having debated facts and data, no
consensus can be reached. Can we have the debate on facts and data first?
Please.

At the of the day, I object to: "There are still a number of unresolved
issues, but to make progress I wonder if it would first be helpful to have
a vote on ensuring we are ANSI SQL 92 compliant for our arithmetic?". More
specifically, I disagree that such vote is a good starting point. Let's
identify and discuss the unresolved issues first. Let's check precisely
what getting our arithmetic ANSI SQL 92 compliant means and how we can get
it. I do support the idea of making such analysis btw, it would be good
data, but no vote is needed whatsoever to make it. Again, I object to
voting first and doing the analysis 2nd.

--
Sylvain


On Thu, Nov 22, 2018 at 1:25 AM Jonathan Haddad  wrote:

> I can’t agree more. We should be able to make changes in a manner that
> improves the DB In the long term, rather than live with the technical debt
> of arbitrary decisions made by a handful of people.
>
> I also agree that putting a knob in place to let people migrate over is a
> reasonable decision.
>
> Jon
>
> On Wed, Nov 21, 2018 at 4:54 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > The goal is simply to agree on a set of well-defined principles for how
> we
> > should behave.  If we don’t like the implications that arise, we’ll have
> > another vote?  A democracy cannot bind itself, so I never understood this
> > fear of a decision.
> >
> > A database also has a thousand toggles.  If we absolutely need to, we can
> > introduce one more.
> >
> > We should be doing this upfront a great deal more often.  Doing it
> > retrospectively sucks, but in my opinion it's a bad reason to bind
> > ourselves to whatever made it in.
> >
> > Do we anywhere define the principles of our current behaviour?  I
> couldn’t
> > find it.
> >
> >
> > > On 21 Nov 2018, at 21:08, Sylvain Lebresne  wrote:
> > >
> > > On Tue, Nov 20, 2018 at 5:02 PM Benedict Elliott Smith <
> > bened...@apache.org>
> > > wrote:
> > >
> > >> FWIW, my meaning of arithmetic in this context extends to any features
> > we
> > >> have already released (such as aggregates, and perhaps other built-in
> > >> functions) that operate on the same domain.  We should be consistent,
> > after
> > >> all.
> > >>
> > >> Whether or not we need to revisit any existing functionality we can
> > figure
> > >> out after the fact, once we have agreed what our behaviour should be.
> > >>
> > >
> > > I'm not sure I correctly understand the process suggested, but I don't
> > > particularly like/agree with what I understand. What I understand is a
> > > suggestion for voting on agreeing to be ANSI SQL 92 compliant, with no
> > real
> > > evaluation of what that entails (at least I haven't seen one), and that
> > > this vote, if passed, would imply we'd then make any backward
> > incompatible
> > > change necessary to achieve compliance ("my meaning of arithmetic in
> this
> > > context extends to any features we have already released" and "Whether
> or
> > > not we need to revisit any existing functionality we can figure out
> after
> > > the fact, once we have agreed what our behaviour should be").
> > >
> > > This might make sense of a new product, but at our stage that seems
> > > backward to me. I think we owe our users to first make the effort of
> > > identifying what "inconsistencies" our existing arithmetic has[1] and
> > > _then_ consider what options we have to fix those, with their pros and
> > cons
> > > (including how bad they break backward compatibility). And if _then_
> > > getting ANSI SQL 92 compliant proves to not be disruptive (or at least
> > > acceptably so), then sure, that's great.
> > >
> > > [1]: one possibly efficient way to do that could actually be to compare
> > our
> > > arithmetic to ANSI SQL 92. Not that all differences found would imply
> > > inconsistencies/wrongness of our arithmetic, but still, it should be
> > > helpful. And I guess my whole point is that we sh

Re: Implicit Casts for Arithmetic Operators

[Sylvain Lebresne]

On Tue, Nov 20, 2018 at 5:02 PM Benedict Elliott Smith 
wrote:

> FWIW, my meaning of arithmetic in this context extends to any features we
> have already released (such as aggregates, and perhaps other built-in
> functions) that operate on the same domain.  We should be consistent, after
> all.
>
> Whether or not we need to revisit any existing functionality we can figure
> out after the fact, once we have agreed what our behaviour should be.
>

I'm not sure I correctly understand the process suggested, but I don't
particularly like/agree with what I understand. What I understand is a
suggestion for voting on agreeing to be ANSI SQL 92 compliant, with no real
evaluation of what that entails (at least I haven't seen one), and that
this vote, if passed, would imply we'd then make any backward incompatible
change necessary to achieve compliance ("my meaning of arithmetic in this
context extends to any features we have already released" and "Whether or
not we need to revisit any existing functionality we can figure out after
the fact, once we have agreed what our behaviour should be").

This might make sense of a new product, but at our stage that seems
backward to me. I think we owe our users to first make the effort of
identifying what "inconsistencies" our existing arithmetic has[1] and
_then_ consider what options we have to fix those, with their pros and cons
(including how bad they break backward compatibility). And if _then_
getting ANSI SQL 92 compliant proves to not be disruptive (or at least
acceptably so), then sure, that's great.

[1]: one possibly efficient way to do that could actually be to compare our
arithmetic to ANSI SQL 92. Not that all differences found would imply
inconsistencies/wrongness of our arithmetic, but still, it should be
helpful. And I guess my whole point is that we should that analysis first,
and then maybe decide that being ANSI SQL 92 is a reasonable option, not
decide first and live with the consequences no matter what they are.

--
Sylvain


> I will make this more explicit for the vote, but just to clarify the
> intention so that we are all discussing the same thing.
>
>
> > On 20 Nov 2018, at 14:18, Ariel Weisberg  wrote:
> >
> > Hi,
> >
> > +1
> >
> > This is a public API so we will be much better off if we get it right
> the first time.
> >
> > Ariel
> >
> >> On Nov 16, 2018, at 10:36 AM, Jonathan Haddad 
> wrote:
> >>
> >> Sounds good to me.
> >>
> >> On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith <
> bened...@apache.org>
> >> wrote:
> >>
> >>> So, this thread somewhat petered out.
> >>>
> >>> There are still a number of unresolved issues, but to make progress I
> >>> wonder if it would first be helpful to have a vote on ensuring we are
> ANSI
> >>> SQL 92 compliant for our arithmetic?  This seems like a sensible
> baseline,
> >>> since we will hopefully minimise surprise to operators this way.
> >>>
> >>> If people largely agree, I will call a vote, and we can pick up a
> couple
> >>> of more focused discussions afterwards on how we interpret the leeway
> it
> >>> gives.
> >>>
> >>>
>  On 12 Oct 2018, at 18:10, Ariel Weisberg  wrote:
> 
>  Hi,
> 
>  From reading the spec. Precision is always implementation defined. The
> >>> spec specifies scale in several cases, but never precision for any
> type or
> >>> operation (addition/subtraction, multiplication, division).
> 
>  So we don't implement anything remotely approaching precision and
> scale
> >>> in CQL when it comes to numbers I think? So we aren't going to follow
> the
> >>> spec for scale. We are already pretty far down that road so I would
> leave
> >>> it alone.
> 
>  I don't think the spec is asking for the most approximate type. It's
> >>> just saying the result is approximate, and the precision is
> implementation
> >>> defined. We could return either float or double. I think if one of the
> >>> operands is a double we should return a double because clearly the
> schema
> >>> thought a double was required to represent that number. I would also
> be in
> >>> favor of returning a double all the time so that people can expect a
> >>> consistent type from expressions involving approximate numbers.
> 
>  I am a big fan of widening for arithmetic expressions in a database to
> >>> avoid having to error on overflow. You can go to the trouble of only
> >>> widening the minimum amount, but I think it's simpler if we always
> widen to
> >>> bigint and double. This would be something the spec allows.
> 
>  Definitely if we can make overflow not occur we should and the spec
> >>> allows that. We should also not return different types for the same
> operand
> >>> types just to work around overflow if we detect we need more precision.
> 
>  Ariel
> > On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote:
> > If it’s in the SQL spec, I’m fairly convinced.  Thanks for digging
> this
> > out (and Mike for getting some empirical 

Re: CASSANDRA-13241 lower default chunk_length_in_kb

[Sylvain Lebresne]

Fwiw, as much as I agree this is a change worth doing in general, I do am
-0 for 4.0. Both the "compact sequencing" and the change of default really.
We're closing on 2 months within the freeze, and for me a freeze do include
not changing defaults, because changing default ideally imply a decent
amount of analysis/benchmark of the consequence of that change[1] and that
doesn't enter in my definition of a freeze.

[1]: to be extra clear, I'm not saying we've always done this, far from it.
But I hope we can all agree we were wrong to no do it when we didn't and
should strive to improve, not repeat past mistakes.
--
Sylvain


On Thu, Oct 18, 2018 at 8:55 PM Ariel Weisberg  wrote:

> Hi,
>
> For those who were asking about the performance impact of block size on
> compression I wrote a microbenchmark.
>
> https://pastebin.com/RHDNLGdC
>
>  [java] Benchmark   Mode
> Cnt  Score  Error  Units
>  [java] CompactIntegerSequenceBench.benchCompressLZ4Fast16kthrpt
>  15  331190055.685 ±  8079758.044  ops/s
>  [java] CompactIntegerSequenceBench.benchCompressLZ4Fast32kthrpt
>  15  353024925.655 ±  7980400.003  ops/s
>  [java] CompactIntegerSequenceBench.benchCompressLZ4Fast64kthrpt
>  15  365664477.654 ± 10083336.038  ops/s
>  [java] CompactIntegerSequenceBench.benchCompressLZ4Fast8k thrpt
>  15  305518114.172 ± 11043705.883  ops/s
>  [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast16k  thrpt
>  15  688369529.911 ± 25620873.933  ops/s
>  [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast32k  thrpt
>  15  703635848.895 ±  5296941.704  ops/s
>  [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast64k  thrpt
>  15  695537044.676 ± 17400763.731  ops/s
>  [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast8k   thrpt
>  15  727725713.128 ±  4252436.331  ops/s
>
> To summarize, compression is 8.5% slower and decompression is 1% faster.
> This is measuring the impact on compression/decompression not the huge
> impact that would occur if we decompressed data we don't need less often.
>
> I didn't test decompression of Snappy and LZ4 high, but I did test
> compression.
>
> Snappy:
>  [java] CompactIntegerSequenceBench.benchCompressSnappy16k   thrpt
> 2  196574766.116  ops/s
>  [java] CompactIntegerSequenceBench.benchCompressSnappy32k   thrpt
> 2  198538643.844  ops/s
>  [java] CompactIntegerSequenceBench.benchCompressSnappy64k   thrpt
> 2  194600497.613  ops/s
>  [java] CompactIntegerSequenceBench.benchCompressSnappy8kthrpt
> 2  186040175.059  ops/s
>
> LZ4 high compressor:
>  [java] CompactIntegerSequenceBench.bench16k  thrpt2
> 20822947.578  ops/s
>  [java] CompactIntegerSequenceBench.bench32k  thrpt2
> 12037342.253  ops/s
>  [java] CompactIntegerSequenceBench.bench64k  thrpt2
>  6782534.469  ops/s
>  [java] CompactIntegerSequenceBench.bench8k   thrpt2
> 32254619.594  ops/s
>
> LZ4 high is the one instance where block size mattered a lot. It's a bit
> suspicious really when you look at the ratio of performance to block size
> being close to 1:1. I couldn't spot a bug in the benchmark though.
>
> Compression ratios with LZ4 fast for the text of Alice in Wonderland was:
>
> Chunk size 8192, ratio 0.709473
> Chunk size 16384, ratio 0.667236
> Chunk size 32768, ratio 0.634735
> Chunk size 65536, ratio 0.607208
>
> By way of comparison I also ran deflate with maximum compression:
>
> Chunk size 8192, ratio 0.426434
> Chunk size 16384, ratio 0.402423
> Chunk size 32768, ratio 0.381627
> Chunk size 65536, ratio 0.364865
>
> Ariel
>
> On Thu, Oct 18, 2018, at 5:32 AM, Benedict Elliott Smith wrote:
> > FWIW, I’m not -0, just think that long after the freeze date a change
> > like this needs a strong mandate from the community.  I think the change
> > is a good one.
> >
> >
> >
> >
> >
> > > On 17 Oct 2018, at 22:09, Ariel Weisberg  wrote:
> > >
> > > Hi,
> > >
> > > It's really not appreciably slower compared to the decompression we
> are going to do which is going to take several microseconds. Decompression
> is also going to be faster because we are going to do less unnecessary
> decompression and the decompression itself may be faster since it may fit
> in a higher level cache better. I ran a microbenchmark comparing them.
> > >
> > >
> https://issues.apache.org/jira/browse/CASSANDRA-13241?focusedCommentId=16653988=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16653988
> > >
> > > Fetching a long from memory:   56 nanoseconds
> > > Compact integer sequence   :   80 nanoseconds
> > > Summing integer sequence   :  165 nanoseconds
> > >
> > > Currently we have one +1 from Kurt to change the representation and
> possibly a -0 from Benedict. That's not really enough to make an exception
> to the code freeze. If you want it to happen (or not) you need 

Re: [VOTE] Development Approach for Apache Cassandra Management process

[Sylvain Lebresne]

That's probably a stupid question, and excuse me if it is, but what does
those votes on the dev mailing list even mean?

How do you count votes at the end? Just by counting all votes cast,
irregardless of whomever cast it? Or are we intending to only count PMC
members, or maybe committers votes?
If the former, that is a bit weird to me because we simply don't know who
votes. And I don't mean to be rude towards anyone, but 1) someone could
easily create 10 email addresses to vote 10 times (and sure, you could
invoke trust, and I'm not entirely against trust in general, but it's the
internet...) and 2) this kind of decision will have non-trivial
consequences for the project, particularly on those that maintain it, so I
admit I'm not entirely comfortable with "anyone's voice has the same
weight".
If the latter, then this makes more sense to me (why are we even bothering
voting PMC members in if it's not to handle these kinds of decisions, which
are very "project management" related), but we should be very clear about
this from the get go (we could still use the dev list for transparency
sake, that I don't mind)? We should probably also have some deadline to the
vote, one that isn't too short.

Anyway, fwiw, my opinion on this vote is not far from the one on the golang
driver acceptance vote (for which my remark above also apply btw): no yet
100% convinced adding more pieces and scope to the project is what the
project needs just right now, but not strongly opposed if people really
wants this (and this one makes more sense to me than the golang driver
actually). But if I'm to pick between a) and b), I'm leaning b).

--
Sylvain


On Wed, Sep 12, 2018 at 8:45 PM Joseph Lynch  wrote:

> +1 for piecemeal (option b).
>
> I think I've explained my opinion on all the various threads and tickets.
>
> -Joey
> On Wed, Sep 12, 2018 at 10:48 AM Vinay Chella 
> wrote:
> >
> > +1 for option b, considering the advantages mentioned in dev email thread
> > that Sankalp linked.
> >
> > ~Vinay
> >
> >
> > On Wed, Sep 12, 2018 at 10:36 AM Dinesh Joshi
> >  wrote:
> >
> > > +1 for piecemeal (option b)
> > >
> > > Dinesh
> > >
> > > > On Sep 12, 2018, at 8:18 AM, sankalp kohli 
> > > wrote:
> > > >
> > > > Hi,
> > > >Community has been discussing about Apache Cassandra Management
> > > process
> > > > since April and we had lot of discussion about which approach to
> take to
> > > > get started. Several contributors have been interested in doing this
> and
> > > we
> > > > need to make a decision of which approach to take.
> > > >
> > > > The current approaches being evaluated are
> > > > a. Donate an existing project to Apache Cassandra like Reaper. If
> this
> > > > option is selected, we will evaluate various projects and see which
> one
> > > > fits best.
> > > > b. Take a piecemeal approach and use the features from different OSS
> > > > projects and build a new project.
> > > >
> > > > Available options to vote
> > > > a. +1 to use existing project.
> > > > b. +1 to take piecemeal approach
> > > > c  -1 to both
> > > > d +0 I dont mind either option
> > > >
> > > > You can also just type a,b,c,d as well to chose an option.
> > > >
> > > > Dev threads with discussions
> > > >
> > > >
> > >
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
> > > >
> > > >
> > >
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%3Cdev.cassandra.apache.org%3E
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

[Sylvain Lebresne]

-0

The project seems to have a hard time getting on top of reviewing his
backlog
of 'patch available' issues, so that I'm skeptical adopting more code to
maintain is the thing the project needs the most right now. Besides, I'm
also
generally skeptical that augmenting the scope of a project makes it better:
I feel
keeping this project focused on the core server is better. I see risks
here, but
the upsides haven't been made very clear for me, even for end users: yes, it
may provide a tiny bit more clarity around which Golang driver to choose by
default, but I'm not sure users are that lost, and I think there is other
ways to
solve that if we really want.

Anyway, I reckon I may be overly pessimistic here and it's not that strong
of
an objection if a large majority is on-board, so giving my opinion but not
opposing.

--
Sylvain


On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan 
wrote:

> +1
>
> But I also think getting this through incubation might take a while/be
> impossible given how large the contributor list looks…
>
> > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> >
> > +1
> >
> > (Incubation looks like it may be challenging to get acceptance from all
> existing contributors, though)
> >
> > --
> > Jeff Jirsa
> >
> >
> >> On Sep 12, 2018, at 8:12 AM, Nate McCall  wrote:
> >>
> >> This will be the same process used for dtest. We will need to walk
> >> this through the incubator per the process outlined here:
> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o=
> >>
> >> Pending the outcome of this vote, we will create the JIRA issues for
> >> tracking and after we go through the process, and discuss adding
> >> committers in a separate thread (we need to do this atomically anyway
> >> per general ASF committer adding processes).
> >>
> >> Thanks,
> >> -Nate
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: UDF

[Sylvain Lebresne]

I'm +1 with this solution going in 4.0.

That said, this make we realize that through this dependency we've
ended up exposing (publicly) a bit too much to UDF. Namely, all we really
need/want to expose for UDF is the "value" classes (UDTValue, TupleValue,
Duration and LocalDate) and the types (DataType and his 2 subclasses
UserType
and TupleType).

But we end up exposing quite a bit more: some abstract classes that are
public
(AbstractGettableData, AbstractSettableData, ...), but more problematic imo,
the CodecRegistry class (whose only need to be public is, as far as I can
tell, the UserType/TupeType.of() methods, which aren't useful to UDF at
all)
which 1) is overly complex for what we care about in UDF and 2) brings
transitive dependencies (TypeCodec and all his sub-classes, TypeToken).

So my suggestion is that we go with Robert's patch, but on top of that we
add detection for usage of all those classes/methods that have no business
being
exposed. For brand new UDFs, we could just reject them if they use any of
those
in 4.0. For existing UDFs, we'd log a warning at startup that say it's
deprecated and that the UDF should be replaced or things will break in the
next
major. Honestly, my expectation is that no-one uses those classes/methods
(since again, they aren't exactly useful) so I don't anticipate doing so
being
a big deal. But unless we do it, we won't be able to clean up the code
added by
this.

And there is quite a bit that would be nice to cleanup at some point here
imo.
Not that the driver code is bad in any way; just that 1) some of the
complexity
it exposes is overkill for UDF (registering TypeCodec typically), and that a
lot of the code added duplicates things we already have server side).

--
Sylvain


On Wed, Sep 12, 2018 at 11:46 AM Aleksey Yeschenko 
wrote:

> It’s my understanding that the duplicated code is being fully donated - so
> it’ll have all the usual ASF license/copyright headers when it lands in
> trunk. No special steps to take here.
>
> —
> AY
>
> On 11 September 2018 at 19:43:58, Jeremiah D Jordan (
> jeremiah.jor...@gmail.com) wrote:
>
> Be careful when pulling in source files from the DataStax Java Driver (or
> anywhere) to make sure and respect its Apache License, Version 2.0 and keep
> all Copyright's etc with said files.
>
> -Jeremiah
>
> > On Sep 11, 2018, at 12:29 PM, Jeff Jirsa  wrote:
> >
> > +1 as well.
> >
> > On Tue, Sep 11, 2018 at 10:27 AM Aleksey Yeschenko 
>
> > wrote:
> >
> >> If this is about inclusion in 4.0, then I support it.
> >>
> >> Technically this is *mostly* just a move+donation of some code from
> >> java-driver to Cassandra. Given how important this seemingly is to the
> >> board and PMC for us to not have the dependency on the driver, the
> sooner
> >> it’s gone, the better.
> >>
> >> I’d be +1 for committing to trunk.
> >>
> >> —
> >> AY
> >>
> >> On 11 September 2018 at 14:43:29, Robert Stupp (sn...@snazy.de)
> wrote:
> >>
> >> The patch is technically complete - i.e. it works and does its thing.
> >>
> >> It's not strictly a bug fix but targets trunk. That's why I started
> the
> >> discussion.
> >>
> >>
> >> On 09/11/2018 02:53 PM, Jason Brown wrote:
> >>> Hi Robert,
> >>>
> >>> Thanks for taking on this work. Is this message a heads up that a
> patch
> >> is
> >>> coming/complete, or to spawn a discussion about including this in
> 4.0?
> >>>
> >>> Thanks,
> >>>
> >>> -Jason
> >>>
> >>> On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp 
> wrote:
> >>>
>  In an effort to clean up our hygiene and limit the dependencies used
> >> by
>  UDFs/UDAs, I think we should refactor the UDF code parts and remove
> >> the
>  dependency to the Java Driver in that area without breaking existing
>  UDFs/UDAs.
> 
>  A working prototype is in this branch:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM=6lUpmmETCKbmt_zcp_DCLIxCGPjVyf7zdX0UjBVOZX4=
>
>  cassandra/tree/feature/remove-udf-driver-dep-trunk <
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_snazy_cassandra_tree_feature_remove-2D=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=Gesm79MRSHznQEKqQabvh3Ie1L3xzqlPsfLfEfadHTM=fBx64l59d8Y9Q7m9j0nNH9VvcaHc3QfoCAx4st5UJDM=
>
>  udf-driver-dep-trunk> . The changes are rather trivial and provide
> >> 100%
>  backwards compatibility for existing UDFs.
> 
>  The prototype copies the necessary parts from the Java Driver into
> the
> >> C*
>  source tree to org.apache.cassandra.cql3.functions.types and adopts
> >> its
>  usages - i.e. UDF/UDA code plus CQLSSTableWriter +
> >> StressCQLSSTableWriter.
>  The latter two classes have a reference to UDF’s UDHelper and had to
> >> be
>  changed as well.
> 
>  Some functionality, like type parsing & handling, is duplicated in
> the
>  code base with this prototype 

Re: Evolving the client protocol

[Sylvain Lebresne]

>
>
> Those were just given as examples. Each would be discussed on its own,
> assuming we are able to find a way to cooperate.
>
>
> These are relatively simple and it wouldn't be hard for use to patch
> Cassandra. But I want to find a way to make more complicated protocol
> changes where it wouldn't be realistic for us to modify Cassandra.
>

That's where I'm confused with what you are truly asking.

The native protocol is the protocol of the Apache Cassandra project and was
never meant to be a standard protocol. If the ask is to move towards more
of handling the protocol as a standard that would evolve independently of
whether Cassandra implements it (would the project commit to implement it
eventually?), then let's be clear on what the concrete suggestion is and
have this discussion (but to be upfront, the short version of my personal
opinion is that this would likely be a big distraction with relatively low
merits for the project, so I'm very unconvinced).

But if that's not the ask, what is it exactly? That we agree to commit
changes
to the protocol spec before we have actually implemented them? If so, I just
don't get it. The downsides are clear (we risk the feature is either never
implemeted due to lack of contributions/loss of interest, or that the
protocol
changes committed are not fully suitable to the final implementation) but
what
benefit to the project can that ever have?

Don't get me wrong, protocol-impacting changes/additions are very much
welcome
if reasonable for Cassandra, and both CASSANDRA-14311 and CASSANDRA-2848 are
certainly worthy. Both the definition of done of those ticket certainly
include the server implementation imo, not just changing the protocol spec
file. As for the shard notion, it makes no sense for Cassandra at this point
in time, so unless an additional contribution makes it so that it start to
make
sense, I'm not sure why we'd add anything related to it to the protocol.

--
Sylvain



>
> > RE #3,
> >
> > It's hard to be +1 on this because we don't benefit by boxing ourselves
> in by defining a spec we haven't implemented, tested, and decided we are
> satisfied with. Having it in ScyllaDB de-risks it to a certain extent, but
> what if Cassandra decides to go a different direction in some way?
>
> Such a proposal would include negotiation about the sharding algorithm
> used to prevent Cassandra being boxed in. Of course it's impossible to
> guarantee that a new idea won't come up that requires more changes.
>
> > I don't think there is much discussion to be had without an example of
> the the changes to the CQL specification to look at, but even then if it
> looks risky I am not likely to be in favor of it.
> >
> > Regards,
> > Ariel
> >
> > On Thu, Apr 19, 2018, at 9:33 AM, glom...@scylladb.com wrote:
> >>
> >> On 2018/04/19 07:19:27, kurt greaves  wrote:
>  1. The protocol change is developed using the Cassandra process in
>  a JIRA ticket, culminating in a patch to
>  doc/native_protocol*.spec when consensus is achieved.
> >>> I don't think forking would be desirable (for anyone) so this seems
> >>> the most reasonable to me. For 1 and 2 it certainly makes sense but
> >>> can't say I know enough about sharding to comment on 3 - seems to me
> >>> like it could be locking in a design before anyone truly knows what
> >>> sharding in C* looks like. But hopefully I'm wrong and there are
> >>> devs out there that have already thought that through.
> >> Thanks. That is our view and is great to hear.
> >>
> >> About our proposal number 3: In my view, good protocol designs are
> >> future proof and flexible. We certainly don't want to propose a design
> >> that works just for Scylla, but would support reasonable
> >> implementations regardless of how they may look like.
> >>
> >>> Do we have driver authors who wish to support both projects?
> >>>
> >>> Surely, but I imagine it would be a minority. ​
> >>>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For
> >> additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Sylvain Lebresne]

On Thu, Apr 12, 2018 at 11:21 AM Sankalp Kohli <kohlisank...@gmail.com>
wrote:

> We can fix test after freezing if there are resources people are willing
> to put. We need to gather support to see who can help with the 3 points I
> have mentioned and when.
>

Again though, without disagreeing with your points, those don't play into
when we freeze. If we freeze tomorrow, even if it take 3 months to gather
sufficient support for testing, there will still be less to test than if we
push the freeze in 3 months and more things are committed in that
time-frame. And in fact, the sooner we freeze, the sooner the project is
making the statement that people that are willing to contribute to the
project should now do so helping testing rather than continuing working on
their pet ticket. And don't get me wrong, it's an open source project, we
can't force anyone to do anything, so people may continue working on there
pet ticket even after freeze. But we can at least, as a project, make it
clear what kind of contributions are "preferred" at any given time.


>
> On Apr 12, 2018, at 02:13, Sylvain Lebresne <lebre...@gmail.com> wrote:
>
> >>
> >> I agree there's little point freezing if we can't even test the system
> >> properly.
> >>
> >
> > I'll mention that I really don't follow the logic of such claim. Why
> can't
> > we
> > fix the testing of the system after freezing? In fact, isn't the whole
> > point of freezing agreeing that it's high time to fix that? Isn't it
> easier
> > to fix tests (and focus on the testing environment if needs be) when
> > things are frozen and code isn't changing from under you?
> >
> > PS: all the questions of this email are rhetorical.
> >
> > --
> > Sylvain
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Roadmap for 4.0

[Sylvain Lebresne]

>
>  I agree there's little point freezing if we can't even test the system
> properly.
>

I'll mention that I really don't follow the logic of such claim. Why can't
we
fix the testing of the system after freezing? In fact, isn't the whole
point of freezing agreeing that it's high time to fix that? Isn't it easier
to fix tests (and focus on the testing environment if needs be) when
things are frozen and code isn't changing from under you?

PS: all the questions of this email are rhetorical.

--
Sylvain

Re: Roadmap for 4.0

[Sylvain Lebresne]

I feel this discussion is starting to go in every directions and getting
farther away from any decision/progress so I'll attempt to summarize what I
hear, where I stand and *more importantly*, why.

So as far as "what do we do for 4.0", I hear it boil down to 3 options:
1) we freeze June 1. It says nothing on when we do release but starting
testing early, which also by extension limit the scope of what needs to be
tested, give believability in an earlier and more stable release. Everyone
seems to agree stability is good, and having no major release for too long
run the risk of everyone outside our own bubble thinking the project is
dead.
2) we decide on a freeze date now, but later than June 1 (the question is
then "when?"). I'm listing this because there has been some explicit "+1 to
freezing but not June 1" but I'll admit I'm not entirely sure of the
reasoning behind this, and if there has been explicit argument for this,
I've missed them.
3) we don't decide on a freeze date, 4.0 freeze is feature related. So we
build a list of features that needs to be in to freeze (which can have some
color for sure, some may be harder requirements than others). The best
argument I've heard for this is Blake's one, which is that people won't
truly test the release unless it is sexy (implying trunk isn't at all right
now) and that it would therefore yield more stability.

I'll acknowledge that some have expresses a preference for a freeze earlier
than June 1, but I think those are fine with June 1 as well so I think we
can fold this into option 1 to simplify. I also suspect option 2 was really
meant as option 3, but with some deadline to avoid slipping too much (but
without really changing the main intent), so maybe the initial question is
really just option 1 versus option 3 (and we decide the details of option 3
if we can agree this is what we want).

As should be clear, I'm a proponent of 1 for the reasoning I expressed on
that point. I don't deny there is some logic behind the "it needs to be
sexy to be tested" argument for 3, but it's simply imo more risky, and too
much so. And this because:
1) I'm convinced it will delay the release *a lot* in practice compared to
option 1 and I think we're underestimating the damage not releasing a major
for years will do to the project.
2) it's all predicated on people doing unprecedented level of testing that
they wouldn't do if we go with option 1, but there is no historical
evidence to support the notion that it is a safe bet. If this doesn't
happen, which we *have* to consider, then the project will be in a *much*
worst state than with option 1. We'll have taken forever to release a less
stable release.



--
Sylvain


On Thu, Apr 12, 2018 at 3:58 AM kurt greaves  wrote:

> >
> > I also don't see a place for minor releases as they exist today. It seems
> > like they are almost all the overhead of a major release with unnecessary
> > restrictions on what is possible.
>
> Yeah this, I've never heard of anything that we don't do in "minors", and
> it seems to me that everyone treats the minors as majors (hell, we're doing
> that here re 4.1). It seems to me that we should just have .
> versioning based on the way we treat minors.
>
> Who can sign up for testing the alpha1. I know Ben has shown interest.
>
> We can certainly do it, and we plan to do a lot of testing of 4.0, but I
> doubt we'll have anything ready to properly test it by June 1st.
> Another thing worth noting is dtests currently only partially run on
> CircleCI and it seems to me that Apple is the only one that actually runs
> them even there. It's going to take us a while to get the testing
> environment in a state that covers all bases post-freeze, and it's a good
> idea to have some commitment to doing that before we go ahead and freeze. I
> agree there's little point freezing if we can't even test the system
> properly.
>
> Not to mention the total lack of any kind of standard performance testing
> environment...
> ​
>

Re: Roadmap for 4.0

[Sylvain Lebresne]

On Wed, Apr 11, 2018 at 12:35 AM Jeff Jirsa  wrote:

> Seriously, what's the rush to branch? Do we all love merging so much we
> want to do a few more times just for the sake of merging? If nothing
> diverges, there's nothing gained from the branch, and if it did diverge, we
> add work for no real gain.
>

Again, to me, the "rush" is that 1) there is tons of changes sitting in
trunk
that some user (_not all_, granted)[1], especially new ones, would likely
benefits, and sooner for those is better than later, 2) we want to favor
release stability and we *know* from years of experience (and frankly,
common
sense) that the bigger the release is, the harder it is to test it/ensuring
overall stability[2] and 3) not having major releases for years[3] is
impacting at least the perceived dynamism/liveness of the project to
external
actors (prospective new user come in mind here, but not only) and that's
simply bad for the project.

And having listed arguments for a soon freeze/not accumulating much more
before release, I'd like to reverse the question to you: what are the big
downsides of not doing that? Are we really that hung up on our own
developers
comfort that the annoyance of a bit more merging trumps the arguments above?

Anyway, the reasons above make me thing that it's better _for the project_
to freeze 4.0 soon, which doesn't exclude a "short" cycle for the following
major (where my definition of short here is something like 6-8 months), and
I'm happy to decide to make 4.0 a non-mandatory upgrade to whatever
comes next so that folks that prefer upgrading rarely can simply skip it and
go to the next one. Likely nobody will die if we wait more though, and it's
clear it will make a few people here more happy if we do, but I believe the
project as a whole will be a bit worst off, that's all.

--
Sylvain


[1]: I'll note that I don't deny upgrading is huge deal for some users, but
let's not skew arguments too much based on any one user interest. For many
users, upgrading even every year to get improvements is still considered as
a
good deal, and that's not counting new users for which it's super
frustrating
to miss out on improvements because we release major only every 2+ years.
[2]: I'll be clear: I will simply not buy anyone argument that "we'll do
so much better testing this time" on face value. Not anymore. If you want to
use that argument to sell having bigger releases, then prove it first. Let's
do reasonably sized 4.0 and 4.1/5.0 and prove that our testing/stability
story
is iron clad now, and then for 4.2/6.0 I'll be willing to agree that making
bigger release may not impact stability too much.
[3]: Conservative estimate, if we do care about stable releases as we all
seem
to, even if we were to freeze June 1, we will almost surely not release
before
October/November, which will be ~1.3 year since the last major release
(again,
that's the conservative estimate). If we push a few months to get some big
complex feature in, not only this push the freeze of those few months, but
will also require more testing, so we're looking at 2+ years, with a
possibly
large '+'.




>
> Beyond that, I still don't like June 1. Validating releases is hard. It
> sounds easy to drop a 4.1 and ask people to validate again, but it's a hell
> of a lot harder than it sounds. I'm not saying I'm a hard -1, but I really
> think it's too soon. 50'ish days is too short to draw a line in the sand,
> especially as people balance work obligations with Cassandra feature
> development.
>
>
>
>
> On Tue, Apr 10, 2018 at 3:18 PM, Nate McCall  wrote:
>
> > A lot of good points and everyone's input is really appreciated.
> >
> > So it sounds like we are building consensus towards June 1 for 4.0
> > branch point/feature freeze and the goal is stability. (No one has
> > come with a hard NO anyway).
> >
> > I want to reiterate Sylvain's point that we can do whatever we want in
> > terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.
> >
> > In thinking about this, what is stopping us from branching 4.0 a lot
> > sooner? Like now-ish? This will let folks start hacking on trunk with
> > new stuff, and things we've gotten close on can still go in 4.0
> > (Virtual tables). I guess I'm asking here if we want to disambiguate
> > "feature freeze" from "branch point?" I feel like this makes sense.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Paying off tech debt and correctly naming things

[Sylvain Lebresne]

I really don't think anyone has been recently against such renaming, and in
fact, a _lot_ of renaming *has* already happen over time. The problem, as
you carefully noted, is that it's such a big task that there is still a lot
to do. Anyway, I've yet to see a patch renaming things to match the CQL
naming scheme be rejected, so I'd personally encourage such submission. But
maybe with a few caveats (already mentioned largely, so repeating here to
signify my personal agreement with them):
- renaming with large surface area can be painful for ongoing patches or
even future merge. That's not a reason for not doing them, but that's imo a
good enough reason to do things incrementally/in as-small-as-reasonable
steps. Making sure a renaming commit only does renaming and doesn't change
the logic is also pretty nice when you rebase such things.
- breaking hundreds of tests is obviously not ok :)
- pure code renaming is one reasonably simple aspect, but quite a few
renaming may have user visible impact. Particularly around JMX where many
things are name based on their class, and to a lesser extend some of our
tools still use "old" naming. We can't and shouldn't ignore those impact:
such user visible changes should imo be documented, and we should make sure
we have a reasonably painless (and thus incremental) upgrade path. My hunch
is the latter isn't as simple as it seems.


--
Sylvain


On Wed, Mar 21, 2018 at 9:06 AM kurt greaves  wrote:

> As someone who came to the codebase post CQL but prior to thrift being
> removed, +1 to refactor. The current mixing of terminology is a complete
> nightmare. This would also give a good opportunity document a lot of code
> that simply isn't documented (or incorrect). I'd say it's worth doing it in
> multiple steps though, such as refactor of a single class at a time, then
> followed by refactor of variable names. We've already done one pretty big
> refactor (InetAddressAndPort) for 4.0, I don't see how a few more could
> make it any worse (lol).
>
> Row vs partition vs key vs PK is killing me
>
> On 20 March 2018 at 22:04, Jon Haddad  wrote:
>
> > Whenever I hop around in the codebase, one thing that always manages to
> > slow me down is needing to understand the context of the variable names
> > that I’m looking at.  We’ve now removed thrift the transport, but the
> > variables, classes and comments still remain.  Personally, I’d like to go
> > in and pay off as much technical debt as possible by refactoring the code
> > to be as close to CQL as possible.  Rows should be rows, not partitions,
> > I’d love to see the term column family removed forever in favor of always
> > using tables.  That said, it’s a big task.  I did a quick refactor in a
> > branch, simply changing the ColumnFamilyStore class to TableStore, and
> > pushed it up to GitHub. [1]
> >
> > Didn’t click on the link?  That’s ok.  The TL;DR is that it’s almost 2K
> > LOC changed across 275 files.  I’ll note that my branch doesn’t change
> any
> > of the almost 1000 search results of “columnfamilystore” found in the
> > codebase and hundreds of tests failed on my branch in CircleCI, so that
> 2K
> > LOC change would probably be quite a bit bigger.  There is, of course, a
> > lot more than just renaming this one class, there’s thousands of variable
> > names using any manner of “cf”, “cfs”, “columnfamily”, names plus
> comments
> > and who knows what else.  There’s lots of references in probably every
> file
> > that would have to get updated.
> >
> > What are people’s thoughts on this?  We should be honest with ourselves
> > and know this isn’t going to get any easier over time.  It’s only going
> to
> > get more confusing for new people to the project, and having to figure
> out
> > “what kind of row am i even looking at” is a waste of time.  There’s
> > obviously a much bigger impact than just renaming a bunch of files,
> there’s
> > any number of patches and branches that would become outdated, plus
> anyone
> > pulling in Cassandra as a dependency would be affected.  I don’t really
> > have a solution for the disruption other than “leave it in place”, but in
> > my mind that’s not a great (or even good) solution.
> >
> > Anyways, enough out of me.  My concern for ergonomics and naming might be
> > significantly higher than the rest of the folks working in the code, and
> I
> > wanted to put a feeler out there before I decided to dig into this in a
> > more serious manner.
> >
> > Jon
> >
> > [1]
> >
> https://github.com/apache/cassandra/compare/trunk...rustyrazorblade:refactor_column_family_store?expand=1
> > <
> >
> https://github.com/apache/cassandra/compare/trunk...rustyrazorblade:refactor_column_family_store?expand=1
> > >
>

Re: Proposal to retroactively mark materialized views experimental

[Sylvain Lebresne]

For the record, in case I was unclear, it was never my intention to
suggest that we shouldn't warn about MVs: I would agree that we still
should and I'm happy that we do. I would also agree that the remaining
caveats and limitations should be more clearly documented.

But, I kind of got the feeling that people were trying to justify
taking what I consider somewhat drastic measures (disabling MVs by
default _in a patch release_) by piling on on how bad MV were and how
impossible it was for anyone ever to use them without dying of a
horrible death. This, to me, felt a bit unfair to the hard work that
has gone into fixing the more blatant problems.

Tl;dr, MVs are certainly not perfect (spoiler alert: they probably
will never be) but they are now imo in a state where some users can
use them productively, so OK to warn about their remaining
problems/limitations, but not ok for me to risk breaking existing user
in a patch release.


On Wed, Oct 4, 2017 at 3:31 AM, Benedict Elliott Smith
<_...@belliottsmith.com> wrote:
> So, I'm of the opinion there's a difference between users misusing a well 
> understood feature whose shortcomings are widely discussed in the community, 
> and providing a feature we don't fully understand, have not fully documented 
> the caveats of, let alone discovered all the problems with nor had that 
> knowledge percolate fully into the wider community.
>
> I also think there's a huge difference between users shooting themselves in 
> the foot, and us shooting them in the foot.
>
> There's a degree of trust - undeserved - that goes with being a database.  
> People assume you're smarter than them, and that it Just Works.  Given this, 
> and that squandering this trust as a bad thing, I personally believe it is 
> better to offer the feature as experimental until we iron out all of the 
> problems, fully understand it, and have a wider community knowledge base 
> around it.
>
> We can still encourage users that can tolerate problems to use it, but we 
> won't be giving any false assurances to those that don't.  Doesn't that seem 
> like a win-win?
>
>
>
>> On 3 Oct 2017, at 21:07, Jeremiah D Jordan  wrote:
>>
>> So for some perspective here, how do users who do not get the guarantees of 
>> MV’s implement this on their own?  They used logged batches.
>>
>> Pseudo CQL here, but you should get the picture:
>>
>> If they don’t ever update data, they do it like so, and it is pretty safe:
>> BEGIN BATCH
>> INSERT tablea blah
>> INSERT tableb blahview
>> END BATCH
>>
>> If they do update data, they likely do it like so, and get it wrong in the 
>> face of concurrency:
>> SELECT * from tablea WHERE blah;
>>
>> BEGIN BATCH
>> INSERT tablea blah
>> INSERT tableb blahview
>> DELETE tableb oldblahview
>> END BATCH
>>
>> A sophisticated user that understands the concurrency issues may well try to 
>> implement it like so:
>>
>> SELECT key, col1, col2 FROM tablea WHERE key=blah;
>>
>> BEGIN BATCH
>> UPDATE tablea col1=new1, col2=new2 WHERE key=blah IF col1=old1 and col2=old2
>> UPDATE tableb viewc1=new2, viewc2=blah WHERE key=new1
>> DELETE tableb WHERE key=old1
>> END BATCH
>>
>> And it wouldn’t work because you can only use LWT in a BATCH if all updates 
>> have the same partition key value, and the whole point of a view most of the 
>> time is that it doesn't (and there are other issues with this, like most 
>> likely needing to use uuid’s or something else to distinguish between 
>> concurrent updates, that are not realized until it is too late).
>>
>> A user who does not dig in and understand how MV’s work, most likely also 
>> does not dig in to understand the trade offs and draw backs of logged 
>> batches to multiple tables across different partition keys.  Or even 
>> necessarily of read before writes, and concurrent updates and the races 
>> inherent in them.  I would guess that using MV’s, even as they are today is 
>> *safer* for these users than rolling their own.  I have seen these patterns 
>> implemented by people many times, including the “broken in the face of 
>> concurrency” version.  So lets please not try to argue that a casual user 
>> that does not dig in to the specifics of feature A is going dig in and 
>> understand the specifics of any other features.  So yes, I would prefer my 
>> bank to use MV’s as they are today over rolling their own, and getting it 
>> even more wrong.
>>
>> Now, even given all that, if we want to warn users of the pit falls of using 
>> MV’s, then lets do that.  But lets keep some perspective on how things 
>> actually get used.
>>
>> -Jeremiah
>>
>>> On Oct 3, 2017, at 8:12 PM, Benedict Elliott Smith <_...@belliottsmith.com> 
>>> wrote:
>>>
>>> While many users may apparently be using MVs successfully, the problem is 
>>> how few (if any) know what guarantees they are getting.  Since we aren’t 
>>> even absolutely certain ourselves, it cannot be many.  Most of the 
>>> shortcomings we are aware of are complicated, concern 

Re: Proposal to retroactively mark materialized views experimental

[Sylvain Lebresne]

On Tue, Oct 3, 2017 at 5:54 PM, Aleksey Yeshchenko  wrote:
> There are a couple compromise options here:
>
> a) Introduce the flag (enalbe_experimental_features, or maybe one per 
> experimental feature), set it to ‘false’ in the yaml, but have the default be 
> ‘true’. So that if you are upgrading from a previous minor to the next 
> without updating the yaml, you notice nothing.
>
> b) Introduce the flag in the minor, and set it to ‘true’ in the yaml in 3.0 
> and 3.11, but to ‘false’ in 4.0. So the operators and in general people who 
> know better can still disable it with one flip, but nobody would be affected 
> by it in a minor otherwise.
>
> B might be more correct, and I’m okay with it

Does feel more correct to me as well

> although I do feel that we are behaving irresponsibly as developers by 
> allowing MV creation by default in their current state

You're giving little credit to the hard work that people have put into
getting MV in a usable state. To quote Kurt's email:

> And finally, back onto the original topic. I'm not convinced that MV's need
> this treatment now. Zhao and Paulo (and others+reviewers) have made quite a
> lot of fixes, granted there are still some outstanding bugs but the
> majority of bad ones have been fixed in 3.11.1 and 3.0.15, the remaining
> bugs mostly only affect views with a poor data model. Plus we've already
> required the known broken components require a flag to be turned on.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Integrating vendor-specific code and developing plugins

[Sylvain Lebresne]

On Fri, May 12, 2017 at 12:29 AM, Jason Brown  wrote:

> Hey all,
>
> I'm on-board with what Rei is saying. I think we should be open to, and
> encourage, other platforms/architectures for integration. Of course, it
> will come down to specific maintainers/committers to do the testing and
> verification on non-typical platforms. Hopefully those maintainers will
> also contribute to other parts of the code base, as well, so I see this as
> another way to bring more folks into the project.
>

Without going so far as to say we shouldn't merge any
platform/architecture/vendor specific code ever and for no reason, I
personally think we should avoid doing so as much as practical and
encourage the "plugins" route instead. It's just much cleaner imo on
principle and amounts to good software development hygiene.

I don't want to not be able to commit some changes because it breaks the
build because there is code for X number of super specific
platform/architecture I don't have access to/don't know anything about
and the maintainers are on vacation or hasn't been reachable in a while.
And what if such maintainer do go away? Sure we can have some "process"
to remove the code in such cases, but why add that burden on us? Plus
we, the Apache Cassandra project, would still be seen as the ones that
drop support for said platform/architecture even though we really have
no choice if it's something we don't have access to anyway.

And sure, I'm painting a bleak picture here, and we would probably have
none of those problems in most cases. But if we do start encourage
actual merge of such code, you can be sure we'll have some of those
problems at some point.

Encouraging plugins have imo pretty much all the benefits with none of
the risks. In particular, I'm unconvinced that someone will be
much more likely to meaningfully contribute to other part of the code
if his "plugins" is in-tree versus out of it.

*But* I can certainly agree with the part about us not having done a
good job to promote plugins and it make sense to me to try to improve on
that.


>
> WRT extensibility, it just requires someone to do the work of making
> reasonable abstraction points - and documenting them ;). The interesting
> question comes down to how to host/ship any pluggable dependencies. Much
> like what we had with jna before they relicensed, we'll probably ship some
> things in-tree and some things users will have to fetch and deploy
> themselves; it's a case-by-case basis.
>
> Thanks,
>
> -Jason
>
>
> On Thu, May 11, 2017 at 2:59 PM, 大平怜  wrote:
>
> > Hi all,
> >
> > In this JIRA ticket https://issues.apache.org/
> jira/browse/CASSANDRA-13486,
> > we proposed integrating our code to support a fast flash+FPGA card
> (called
> > CAPI Flash) only available in the ppc architecture. Although we will keep
> > discussing the topics specific to the patch (e.g. documentation, license,
> > code quality) in the JIRA, we would like to start in this dev list more
> > general discussion about how to (and how not to) merge
> > architecture-specific (or vendor-specific) changes.
> >
> > I think in the end the problem boils down to how to test the
> > architecture-specific code. The original contributors of the
> > architecture-specific code can keep "supporting" the code in a sense that
> > when a problem arises they can fix it and send a patch, but the
> committers
> > cannot test it anyway.  Are there any other factors we must consider?
> >
> > Also, in this particular case, it is relatively easy to turn the code
> > change into a plugin because it extended the already-pluggable
> RowCache.  I
> > feel Cassandra has promoted the plugins not so much as other pluggable
> > software have done like Eclipse, Apache HTTP server, fluentd, etc.  For
> > example, they have a list of plugins in their Web pages.  I think if the
> > community wants to encourage developers to maintain vendor-specific code
> as
> > plugins outside of the main source tree, a deeper commitment to the
> plugin
> > ecosystem would be appreciated.
> >
> > What do you think?
> >
> >
> > Thanks,
> > Rei Odaira
> >
>

Re: [VOTE] self-assignment of jira tickets

[Sylvain Lebresne]

+1

On Wed, Mar 29, 2017 at 4:42 PM, Benjamin Lerer  wrote:

> Non binding +1
>
> On Wed, Mar 29, 2017 at 4:24 PM, Jonathan Haddad 
> wrote:
>
> > Non binding +1
> > On Wed, Mar 29, 2017 at 7:22 AM Jeff Jirsa  wrote:
> >
> > > +1
> > >
> > > --
> > > Jeff Jirsa
> > >
> > >
> > > > On Mar 29, 2017, at 6:21 AM, Jason Brown 
> wrote:
> > > >
> > > > Hey all,
> > > >
> > > > Following up my thread from a week or two ago (
> > > >
> > > https://lists.apache.org/thread.html/0665f40c7213654e99817141972c00
> > 3a2131aba7a1c63d6765db75c5@%3Cdev.cassandra.apache.org%3E
> > > ),
> > > > I'd like to propose a vote to change to allow any potential
> contributor
> > > to
> > > > assign a jira to themselves without needing to be added to the
> > > contributors
> > > > group first.
> > > >
> > > > https://issues.apache.org/jira/browse/INFRA-11950 is an example of
> how
> > > to
> > > > get this done with INFRA.
> > > >
> > > > Vote will be open for 72 hours.
> > > >
> > > > Thanks,
> > > >
> > > > -Jason Brown
> > >
> >
>

Re: Approximate 4.0 timeframe

[Sylvain Lebresne]

On Thu, Feb 16, 2017 at 12:12 AM, Shashank Joshi <
shashank.jo...@ericsson.com> wrote:

> Hi all,
>
> Is there a rough idea of when 4.0 might be released ?


No, there isn't.


> Also, once that happens and 2.1 is no longer supported in the community,
> does that mean that there will be no fixes made, even for critical security
> related issues ?
>

Yes, that's what it means.

Re: [VOTE] Release Apache Cassandra 2.1.17

[Sylvain Lebresne]

+1

On Thu, Feb 16, 2017 at 3:21 AM, Brandon Williams  wrote:

> +1
>
> On Wed, Feb 15, 2017 at 7:16 PM, Michael Shuler 
> wrote:
>
> > I propose the following artifacts for release as 2.1.17.
> >
> > sha1: 943db2488c8b62e1fbe03b132102f0e579c9ae17
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/2.1.17-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1140/org/apache/cassandra/apache-cassandra/2.1.17/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1140/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/17RivH
> > [2]: (NEWS.txt) https://goo.gl/axKXys
> >
> > --
> > Kind regards,
> > Michael Shuler
> >
> >
>

Re: [VOTE] Release Apache Cassandra 2.2.9

[Sylvain Lebresne]

+1

On Thu, Feb 16, 2017 at 3:22 AM, Brandon Williams  wrote:

> +1
>
> On Wed, Feb 15, 2017 at 7:16 PM, Michael Shuler 
> wrote:
>
> > I propose the following artifacts for release as 2.2.9.
> >
> > sha1: 70a08f1c35091a36f7d9cc4816259210c2185267
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/2.2.9-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1139/org/apache/cassandra/apache-cassandra/2.2.9/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1139/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/AYblr5
> > [2]: (NEWS.txt) https://goo.gl/gIXxgR
> >
> > --
> > Kind regards,
> > Michael Shuler
> >
> >
>

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

[Sylvain Lebresne]

Fyi, I just committed CASSANDRA-13025 so it's ready for a re-roll as far as
I can tell.

On Tue, Jan 24, 2017 at 12:31 AM, Michael Shuler 
wrote:

> This vote is being failed for CASSANDRA-13058 (committed after tentative
> tag) and CASSANDRA-13025 (patch available).
>
> Vote count was 5 binding +1, 1 binding -1, and one non-binding -1.
>
> I'll re-roll a "Take 5" when CASSANDRA-13025 gets committed, tests
> appear stable, and we'll try again.
>
> --
> Kind regards,
> Michael
>
> On 01/13/2017 06:46 PM, Michael Shuler wrote:
> > I propose the following artifacts for release as 3.10.
> >
> > sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.10-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1136/org/apache/cassandra/apache-cassandra/3.10/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1136/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/WaAEVn
> > [2]: (NEWS.txt) https://goo.gl/7deAsG
> >
> > All of the unit tests passed and the main dtest job passed.
> >
> > https://cassci.datastax.com/job/cassandra-3.11_testall/47/
> > https://cassci.datastax.com/job/cassandra-3.11_utest/55/
> > https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/
> > https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/
> > https://cassci.datastax.com/job/cassandra-3.11_dtest/31/
> >
>
>
>

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

[Sylvain Lebresne]

On Mon, Jan 23, 2017 at 2:31 AM, Nate McCall <zznat...@gmail.com> wrote:

> What was the resolution on this?
>
> Looks like we resolved/Fixed CASSANDRA-13058. Can we re-roll and go again?
>

As I mentioned, CASSANDRA-13025 is also a regression and should be fix
before we re-roll. It's ready for review if someone's interested.


>
> On Tue, Jan 17, 2017 at 4:26 AM, Sylvain Lebresne <sylv...@datastax.com>
> wrote:
> > I'm a bit sorry about it, but I'm kind of -1 on the account of
> > https://issues.apache.org/jira/browse/CASSANDRA-13025. It's a genuine
> > regression during upgrade that we should really fix before it's released
> in
> > the wild. I apologize for not having bump the priority on this ticket
> > sooner but I think we need the fix in.
> >
> > On Mon, Jan 16, 2017 at 2:25 AM, Paulo Motta <pauloricard...@gmail.com>
> > wrote:
> >
> >> -1 since CASSANDRA-13058
> >> <https://issues.apache.org/jira/browse/CASSANDRA-13058> introduces a
> >> regression that prevents successful decommission when the
> decommissioning
> >> node has hints to transfer. While this is relatively minor and there is
> a
> >> workaround (force hint replay before decommission), there is already a
> >> patch available so I committed this to cassandra-3.11 and upper
> branches so
> >> we will also have a green testboard for cassandra-3.11_novnode_dtest
> >> <https://cassci.datastax.com/view/cassandra-3.11/job/
> >> cassandra-3.11_novnode_dtest/>
> >> .
> >>
> >> If there are no objections on getting this in, can you re-roll this once
> >> again Michael? Sorry for the late update on this, I had other things on
> my
> >> plate and could only get to this now.
> >>
> >> 2017-01-15 10:48 GMT-02:00 Aleksey Yeschenko <alek...@apache.org>:
> >>
> >> > +1
> >> >
> >> > --
> >> > AY
> >> >
> >> > On 14 January 2017 at 00:47:08, Michael Shuler (
> mich...@pbandjelly.org)
> >> > wrote:
> >> >
> >> > I propose the following artifacts for release as 3.10.
> >> >
> >> > sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27
> >> > Git:
> >> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >> > shortlog;h=refs/tags/3.10-tentative
> >> > Artifacts:
> >> > https://repository.apache.org/content/repositories/
> >> > orgapachecassandra-1136/org/apache/cassandra/apache-cassandra/3.10/
> >> > Staging repository:
> >> > https://repository.apache.org/content/repositories/
> >> > orgapachecassandra-1136/
> >> >
> >> > The Debian packages are available here: http://people.apache.org/~
> >> mshuler
> >> >
> >> > The vote will be open for 72 hours (longer if needed).
> >> >
> >> > [1]: (CHANGES.txt) https://goo.gl/WaAEVn
> >> > [2]: (NEWS.txt) https://goo.gl/7deAsG
> >> >
> >> > All of the unit tests passed and the main dtest job passed.
> >> >
> >> > https://cassci.datastax.com/job/cassandra-3.11_testall/47/
> >> > https://cassci.datastax.com/job/cassandra-3.11_utest/55/
> >> > https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/
> >> > https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/
> >> > https://cassci.datastax.com/job/cassandra-3.11_dtest/31/
> >> >
> >> > --
> >> > Kind regards,
> >> > Michael Shuler
> >> >
> >> >
> >>
>

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

[Sylvain Lebresne]

I'm a bit sorry about it, but I'm kind of -1 on the account of
https://issues.apache.org/jira/browse/CASSANDRA-13025. It's a genuine
regression during upgrade that we should really fix before it's released in
the wild. I apologize for not having bump the priority on this ticket
sooner but I think we need the fix in.

On Mon, Jan 16, 2017 at 2:25 AM, Paulo Motta 
wrote:

> -1 since CASSANDRA-13058
>  introduces a
> regression that prevents successful decommission when the decommissioning
> node has hints to transfer. While this is relatively minor and there is a
> workaround (force hint replay before decommission), there is already a
> patch available so I committed this to cassandra-3.11 and upper branches so
> we will also have a green testboard for cassandra-3.11_novnode_dtest
>  cassandra-3.11_novnode_dtest/>
> .
>
> If there are no objections on getting this in, can you re-roll this once
> again Michael? Sorry for the late update on this, I had other things on my
> plate and could only get to this now.
>
> 2017-01-15 10:48 GMT-02:00 Aleksey Yeschenko :
>
> > +1
> >
> > --
> > AY
> >
> > On 14 January 2017 at 00:47:08, Michael Shuler (mich...@pbandjelly.org)
> > wrote:
> >
> > I propose the following artifacts for release as 3.10.
> >
> > sha1: 9c2ab25556fad06a6a4d58f4bb652719a8a1bc27
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/3.10-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1136/org/apache/cassandra/apache-cassandra/3.10/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1136/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/WaAEVn
> > [2]: (NEWS.txt) https://goo.gl/7deAsG
> >
> > All of the unit tests passed and the main dtest job passed.
> >
> > https://cassci.datastax.com/job/cassandra-3.11_testall/47/
> > https://cassci.datastax.com/job/cassandra-3.11_utest/55/
> > https://cassci.datastax.com/job/cassandra-3.11_utest_cdc/25/
> > https://cassci.datastax.com/job/cassandra-3.11_utest_compression/23/
> > https://cassci.datastax.com/job/cassandra-3.11_dtest/31/
> >
> > --
> > Kind regards,
> > Michael Shuler
> >
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.10

[Sylvain Lebresne]

+1

On Mon, Oct 31, 2016 at 6:29 PM, Nate McCall  wrote:

> +1
>
> On Tue, Nov 1, 2016 at 3:12 AM, Michael Shuler 
> wrote:
> > I propose the following artifacts for release as 3.0.10.
> >
> > sha1: 817ba038783212b716f6981b26c8348ffdc92f59
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.10-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1131/org/apache/cassandra/apache-cassandra/3.0.10/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1131/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/4e1P3e
> > [2]: (NEWS.txt) https://goo.gl/AwLFr1
>

Re: A home for 4.0

[Sylvain Lebresne]

And of course I've been retarded and created a '3.X' branch with is
completely inconsistent with our usual branch naming. So I actually just
renamed that to 'cassandra-3.X' instead. I apologize for the inconvenience
if any (there hasn't been any commit since I created the branch though, so
hopefully nobody was inconvenienced).

Again, my bad, but we should be good to go now.

On Thu, Sep 29, 2016 at 10:22 AM, Sylvain Lebresne <sylv...@datastax.com>
wrote:

> So, this is done now and I've renamed the version on trunk to 4.0, so be
> sure to commit/merge to 3.X before going to trunk from now on.
>
> On Thu, Sep 29, 2016 at 10:20 AM, Sylvain Lebresne <sylv...@datastax.com>
> wrote:
>
>> As there has been no strong objection, I'm going to proceed and create
>> the branch.
>>
>> Note that I'm discarding Michael remark as a joke due to the use of a
>> smiley, but just in case that was a genuine concern, I'll argue that 1)
>> 'trunk' isn't really more arithmetic friendly so I don't think there is too
>> much reliance on this for branch names out there and 2) I really don't care
>> about the branch name, 3.X just feels the more natural, but if something
>> thing just calling it '3' or something else would be better, be my guest
>> and rename it.
>>
>> On Tue, Sep 27, 2016 at 2:48 PM, Michael Shuler <mich...@pbandjelly.org>
>> wrote:
>>
>>> I foresee many arithmetic errors with 3.X.. :)
>>>
>>> --
>>> Michael
>>>
>>> On 09/27/2016 05:18 AM, Sylvain Lebresne wrote:
>>> > We have a number of tickets that we now have to wait on 4.0 due to
>>> needing a
>>> > messaging protocol change or major sstable format (
>>> https://goo.gl/OvqNQp),
>>> > and
>>> > we currently have no branch for those. And as 4.0 was initially
>>> supposed to
>>> > come
>>> > after 3.11, which is coming, it's probably time to have a home for
>>> those
>>> > tickets.
>>> >
>>> > And as 4.0 should probably be the 'trunk' (at least it's how we've
>>> always
>>> > done),
>>> > I'm proposing to create a new '3.X' branch from trunk as home for the
>>> > remaining
>>> > 3.x tick-tock release. In that configuration, the merge path will
>>> become:
>>> >
>>> > 2.1 -> 2.2 -> 3.0 -> 3.X -> trunk (future 4.0)
>>> >
>>> > Any strong objection to me creating that branch?
>>> >
>>> > Sylvain Lebresne
>>> >
>>>
>>>
>>
>

Re: A home for 4.0

[Sylvain Lebresne]

So, this is done now and I've renamed the version on trunk to 4.0, so be
sure to commit/merge to 3.X before going to trunk from now on.

On Thu, Sep 29, 2016 at 10:20 AM, Sylvain Lebresne <sylv...@datastax.com>
wrote:

> As there has been no strong objection, I'm going to proceed and create the
> branch.
>
> Note that I'm discarding Michael remark as a joke due to the use of a
> smiley, but just in case that was a genuine concern, I'll argue that 1)
> 'trunk' isn't really more arithmetic friendly so I don't think there is too
> much reliance on this for branch names out there and 2) I really don't care
> about the branch name, 3.X just feels the more natural, but if something
> thing just calling it '3' or something else would be better, be my guest
> and rename it.
>
> On Tue, Sep 27, 2016 at 2:48 PM, Michael Shuler <mich...@pbandjelly.org>
> wrote:
>
>> I foresee many arithmetic errors with 3.X.. :)
>>
>> --
>> Michael
>>
>> On 09/27/2016 05:18 AM, Sylvain Lebresne wrote:
>> > We have a number of tickets that we now have to wait on 4.0 due to
>> needing a
>> > messaging protocol change or major sstable format (
>> https://goo.gl/OvqNQp),
>> > and
>> > we currently have no branch for those. And as 4.0 was initially
>> supposed to
>> > come
>> > after 3.11, which is coming, it's probably time to have a home for those
>> > tickets.
>> >
>> > And as 4.0 should probably be the 'trunk' (at least it's how we've
>> always
>> > done),
>> > I'm proposing to create a new '3.X' branch from trunk as home for the
>> > remaining
>> > 3.x tick-tock release. In that configuration, the merge path will
>> become:
>> >
>> > 2.1 -> 2.2 -> 3.0 -> 3.X -> trunk (future 4.0)
>> >
>> > Any strong objection to me creating that branch?
>> >
>> > Sylvain Lebresne
>> >
>>
>>
>

Re: A home for 4.0

[Sylvain Lebresne]

As there has been no strong objection, I'm going to proceed and create the
branch.

Note that I'm discarding Michael remark as a joke due to the use of a
smiley, but just in case that was a genuine concern, I'll argue that 1)
'trunk' isn't really more arithmetic friendly so I don't think there is too
much reliance on this for branch names out there and 2) I really don't care
about the branch name, 3.X just feels the more natural, but if something
thing just calling it '3' or something else would be better, be my guest
and rename it.

On Tue, Sep 27, 2016 at 2:48 PM, Michael Shuler <mich...@pbandjelly.org>
wrote:

> I foresee many arithmetic errors with 3.X.. :)
>
> --
> Michael
>
> On 09/27/2016 05:18 AM, Sylvain Lebresne wrote:
> > We have a number of tickets that we now have to wait on 4.0 due to
> needing a
> > messaging protocol change or major sstable format (https://goo.gl/OvqNQp
> ),
> > and
> > we currently have no branch for those. And as 4.0 was initially supposed
> to
> > come
> > after 3.11, which is coming, it's probably time to have a home for those
> > tickets.
> >
> > And as 4.0 should probably be the 'trunk' (at least it's how we've always
> > done),
> > I'm proposing to create a new '3.X' branch from trunk as home for the
> > remaining
> > 3.x tick-tock release. In that configuration, the merge path will become:
> >
> >     2.1 -> 2.2 -> 3.0 -> 3.X -> trunk (future 4.0)
> >
> > Any strong objection to me creating that branch?
> >
> > Sylvain Lebresne
> >
>
>

A home for 4.0

[Sylvain Lebresne]

We have a number of tickets that we now have to wait on 4.0 due to needing a
messaging protocol change or major sstable format (https://goo.gl/OvqNQp),
and
we currently have no branch for those. And as 4.0 was initially supposed to
come
after 3.11, which is coming, it's probably time to have a home for those
tickets.

And as 4.0 should probably be the 'trunk' (at least it's how we've always
done),
I'm proposing to create a new '3.X' branch from trunk as home for the
remaining
3.x tick-tock release. In that configuration, the merge path will become:

2.1 -> 2.2 -> 3.0 -> 3.X -> trunk (future 4.0)

Any strong objection to me creating that branch?

Sylvain Lebresne

Re: [VOTE] Release Apache Cassandra 3.8

[Sylvain Lebresne]

+1

On Tue, Sep 27, 2016 at 3:03 AM, Jeff Jirsa  wrote:

>
> +1
>
> On 2016-09-26 07:52 (-0700), Michael Shuler 
> wrote:
> > I propose the following artifacts for release as 3.8.
> >
> > sha1: ce609d19fd130e16184d9e6d37ffee4a1ebad607
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.8-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1126/org/apache/cassandra/apache-cassandra/3.8/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1126/
> >
> > The debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/b80Qe2
> > [2]: (NEWS.txt) https://goo.gl/Aen2iN
> >
> > --
> > Kind regards,
> > Michael
> >
>

Re: [VOTE] Release Apache Cassandra 3.9

[Sylvain Lebresne]

+1

On Tue, Sep 27, 2016 at 3:03 AM, Jeff Jirsa  wrote:

> +1
>
> On 2016-09-26 08:12 (-0700), Michael Shuler 
> wrote:
> > I propose the following artifacts for release as 3.9.
> >
> > sha1: c1fa21458777b51a9b21795330ed6f298103b436
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.9-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1127/org/apache/cassandra/apache-cassandra/3.9/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1127/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/TEMHqi
> > [2]: (NEWS.txt) https://goo.gl/1w6Ec1
> >
> > --
> > Kind regards,
> > Michael Shuler
> >
>

Re: Proposal - 3.5.1

[Sylvain Lebresne]

On Fri, Sep 16, 2016 at 6:59 PM, Blake Eggleston <beggles...@apple.com>
wrote:

> Clearly, we won’t get to this point right away, but it should definitely
> be a goal.
>

I'm not entirely clear on why anyone would read in what I'm saying that it
shouldn't be a goal. I'm a huge proponent of this and of putting emphasis
on quality in general, and because it's Friday night and I'm tired, I'm
gonna add that I think I have a bigger track record of actually acting on
improving quality for Cassandra than anyone else that is putting word in my
mouth.

Mainly, I'm suggesting that we don't have to tie the existence of a clearly
labeled stable branch (useful to user, especially newcomers) to future
improvement in the "releasability" of trunk in our design of a new release
cycle. If we do so, but releasability don't improve as quickly as we'd
hope, we penalize users in the end. Adopting a release cycle that ensure
said clearly labeled stable branch does exist no matter the rate of
improvement to the level of "trunk" releasibility is feels safer, and
doesn't preclude any effort in improving said releasibilty, nor
re-evaluating this in 1-2 year to move to release stable releases from
trunk directly if we have proven we're there.



>
> On September 16, 2016 at 9:04:03 AM, Sylvain Lebresne (
> sylv...@datastax.com) wrote:
>
> On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad <j...@jonhaddad.com>
> wrote:
>
> >
> > This is a different mentality from having a "features" branch, where it's
> > implied that at times it's acceptable that it not be stable.
>
>
> I absolutely never implied that, though I willingly admit my choice of
> branch
> names may be to blame. I 100% agree that no releases should be done
> without a green test board moving forward and if something was implicit
> in my 'feature' branch proposal, it was that.
>
> Where we might not be in the same page is that I just don't believe it's
> reasonable to expect the project will get any time soon in a state where
> even a green test board release (with new features) meets the "can be
> confidently put into production". I'm not even sure it's reasonable to
> expect from *any* software, and even less so for an open-source
> project based on volunteering. Not saying it wouldn't be amazing, it
> would, I just don't believe it's realistic. In a way, the reason why I
> think
> tick-tock doesn't work is *exactly* because it's based on that unrealistic
> assumption.
>
> Of course, I suppose that's kind of my opinion. I'm sure some will think
> that the "historical trend" of release instability is simply due to a lack
> of
> effort (obviously Cassandra developers don't give a shit about users, that
> must the simplest explanation).
>

Re: Proposal - 3.5.1

[Sylvain Lebresne]

On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad  wrote:

>
> This is a different mentality from having a "features" branch, where it's
> implied that at times it's acceptable that it not be stable.


I absolutely never implied that, though I willingly admit my choice of
branch
names may be to blame. I 100% agree that no releases should be done
without a green test board moving forward and if something was implicit
in my 'feature' branch proposal, it was that.

Where we might not be in the same page is that I just don't believe it's
reasonable to expect the project will get any time soon in a state where
even a green test board release (with new features) meets the "can be
confidently put into production". I'm not even sure it's reasonable to
expect from *any* software, and even less so for an open-source
project based on volunteering. Not saying it wouldn't be amazing, it
would, I just don't believe it's realistic. In a way, the reason why I think
tick-tock doesn't work is *exactly* because it's based on that unrealistic
assumption.

Of course, I suppose that's kind of my opinion. I'm sure some will think
that the "historical trend" of release instability is simply due to a lack
of
effort (obviously Cassandra developers don't give a shit about users, that
must the simplest explanation).

Re: Proposal - 3.5.1

[Sylvain Lebresne]

As probably pretty much everyone at this point, I agree the tick-tock
experiment
isn't working as well as it should and that it's probably worth course
correcting. I happen to have been thinking about this quite a bit already
as it
turns out so I'm going to share my reasoning and suggestion below, even
though
it's going to be pretty long, in the hope it can be useful (and if it
isn't, so
be it).

My current thinking is that a good cycle should accommodate 2 main
constraints:
  1) be useful for users
  2) be realistic/limit friction on the development side
and let me develop what I mean by both points slightly first.

I think users mostly want 2 things out of the release schedule: they want a
clearly labeled stable branch to know what they should run into production,
and
they want new features and improvements. Let me clarify that different users
will want those 2 in different degrees and with variation over time, but I
believe it's mainly some combination of those. On the development side, I
don't
think it's realistic to expect more than 2/3 branches/series to be
supported at
any one time (not going to argue that, let's call it a professional
opinion). I
also think accumulating new work for any meaningful length of time before
releasing, as we used to do, is bad as it pushes devs to rush things to
meet a
given release deadline as they don't want to wait for the next one. This in
turn
impacts quality and creates unnecessary drama. It's also good imo to have a
clear policy regarding where a given work can go (having to debate on each
ticket on which branch it should go is a waste of dev time).

With those "goals" in mind, I'll note that:
- the fixed _and_ short cadence of tick-tock is imo very good, in
particular in
  (but not limited to) avoiding the 'accumulate unreleased stuffs' problem.
- we have ample evidence that stuffs don't get truly stable until they get
only
  bug fixes for a few months. Which doesn't mean at all that we shouldn't
  continue to make progress on increasing the quality of new code btw.
- Simple is also a great quality of a release cycle. I think we should try
to
  define what's truly important to achieve (my opinion on that is above)
and do
  the simplest thing that achieve that. This does imply the release cycle
  won't make the coffee, but that's alright, it probably shouldn't anyway.

In light of all this, my suggesting for a release cycle woud be:
- To have 3 branches: 'features', 'testing' and 'stable', with an X month
  rotation: 'features' becomes 'testing' after X months and then 'stable'
after
  X more, before getting EOL X months later.
- The feature branch gets everything. The testing branch only gets bug
fixes.
  The stable branch only gets critical bug fixes. And imo, we should be very
  strict on this (I acknowledge that there is sometimes a bit of
subjectivity on
  whether something is a bug or an improvement, and if it's critical or
not, but
  I think it's not that hard to get consensus if we're all reasonable
(though it
  might worth agreeing on some rough but written guideline upfront)).
- We release on a short and fixed cadence of Y month(s) for both the
feature and
  testing branch. For the stable branch, given that it already had X months
of
  only bug fixes during the testing phase, one can hope critical fixes will
be
  fairly rare, less than 1 per Y period on average). Further, it's supposed
to
  be stable and fixes are supposed to be critical, so doing hot-fix releases
  probably makes the most sense (though it probably only work if we're
indeed
  strict on what is considered critical).

And that's about it. I think it would believably achieve stability (with a
clear
label on which releases are stable), but also provide new features and
improvements quickly for those that wants that. The testing phase is imo a
necessary intermediate step to get the stable one.

On thing to define is X and Y. For Y (the cadence of feature/testing), I
think 1
or 2 months are the only options that make sense (less than 1 month is too
fast,
and more than 2 months is imo starting to get too long). For X, that's more
debatable but it's open-source and we should recognize volunteers generally
don't want to maintain things for too long either. My 2 is that 6 or 8
months
are probably the best options here.

We'd also have to put some numbering scheme on top of that, but that's not
really the important part (the meaning is in the branch labels, not the
numbers). To give just one possible option (and assuming X=6, Y=1), in
January
2017 we could cut 4.0 as the start of both 'feature' and 'testing'. We'd
then
have 4.1, 4.2, ... on the 'feature' branch, and 4.0.1, 4.0.2, ... on the
testing
branch for the next 6 months. In July, we'd switch from 4.5 to 5.0, with
that
becoming the new 'feature' and 'testing' base. At the same time, we'd cut
4.0.6 from 4.0.5 as the new 'stable' branch. Hot-fix on that stable branch
would
be versioned 4.0.6.1, 4.0.6.2 and so on.

Of course, there can be 

Re: [VOTE] Release Apache Cassandra 3.0.9

[Sylvain Lebresne]

+1

On Fri, Sep 16, 2016 at 12:31 AM, Sam Tunnicliffe  wrote:

> +1
>
> On 15 Sep 2016 19:58, "Jake Luciani"  wrote:
>
> > I propose the following artifacts for release as 3.0.9.
> >
> > sha1: d600f51ee1a3eb7b30ce3c409129567b70c22012
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/3.0.9-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1124/org/apache/cassandra/apache-cassandra/3.0.9/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1124/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: https://goo.gl/JKkE05 (CHANGES.txt)
> > [2]: https://goo.gl/Hi8X71 (NEWS.txt)
> >
>

Re: Github pull requests

[Sylvain Lebresne]

Sorry for being obtuse but what do we win exactly?

The way we're currently working is that a lot of ticket spans 2 or more
branches so that most people currently submit patches by attaching link to
the
relevant branches (one for each version we should commit to) as well as
links
to the CI results for those branches. Unless we make serious changes to how
we
do things (but I, for one, wouldn't mind clarifications on those changes),
this doesn't seem to reduce itself well to a single pull request.

On Mon, Aug 29, 2016 at 2:45 PM, J. D. Jordan 
wrote:

> I think it goes the other way around. When you push to ASF git with the
> right commit message then the integration from that side closes the pull
> request.
>
> > On Aug 28, 2016, at 11:48 PM, Jonathan Ellis  wrote:
> >
> > Don't we need something on the infra side to turn a merged pull request
> > into a commit to the ASF repo?
> >
> > On Sun, Aug 28, 2016 at 11:07 PM, Nate McCall 
> > wrote:
> >
> >>>
> >>>
> >>> Infra is exploring options for giving PMCs greater control over GitHub
> >>> config (including allowing GitHub to be the master with a golden copy
> >>> held at the ASF) but that is a work in progress.
> >> ^  Per Mark's comment, there is not anything we can really do past what
> >> Jake F. described with Thrift. We dealt with this with Usergrid back in
> >> incubation two years ago (Jake F. actually helped us get it all sorted
> at
> >> the time) when we were using https://github.com/usergrid/usergrid as
> the
> >> source:
> >> http://mail-archives.apache.org/mod_mbox/usergrid-dev/201405.mbox/%
> >> 3CCANyrgvdTVzZQD7w3C96LUHa=h7-h4qmu4h7ajsxoat0gd0f...@mail.gmail.com%3E
> >>
> >> Here is the Thrift guide again for reference:
> >> https://github.com/apache/thrift/blob/master/
> CONTRIBUTING.md#contributing-
> >> via-github-pull-requests
> >>
> >> JClouds also has a nice write up/how-to (we based Usergrid on this,
> >> initially):
> >> https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow
> >>
> >> Maybe we just amend our 'how-to-commit' with similar details as the two
> >> references above?
> >> http://cassandra.apache.org/doc/latest/development/how_to_commit.html
> >>
> >> -Nate
> >>
> >> On Mon, Aug 29, 2016 at 10:44 AM, Nate McCall 
> >> wrote:
> >>
> >>>
>  Nate, since you have experience with this from Usergrid, can you
> figure
>  out
>  what we need to do to make this happen and follow up with infra?
> >>>
> >>> Yep - i'll look into this.
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
>

Re: [VOTE RESULT] Release Apache Cassandra 3.8

[Sylvain Lebresne]

On Wed, Jul 27, 2016 at 12:42 AM, Aleksey Yeschenko <alek...@apache.org>
wrote:

> Sorry, but I’m counting 3 binding +1s and 1 binding -1 (2, if you
> interpret Jonathan’s emails as such).
>
> Thus, if you were to do close the vote now, the vote is passing with the
> binding majority, and the required minimum # of +1s gained.
>
> I also don’t see the PMC consensus on ‘August 3.8 release target’.
>
> As such, the vote is now reopened for further discussion, and to allow PMC
> to change their votes if they feel like it (I, for one, have just returned,
> and need to reevaluate 12236 in light of new comments).
>

It has been my understanding that we took a more human approach to release
decisions than strictly and blindly adhering to the Apache written voting
rules. There has been many votes that has been re-rolled even though they
had had more than 3 binding vote already when a problem was detected, and
it never took an official PMC vote to do so, nor did we ever officially
waited on the cast votes to be officially reverted.

I'm also sad that knowing that there is a bug that breaks in-flight queries
during upgrade *and* the fact the vast majority of our upgrade tests are
failing is not _obviously_ enough to hold a release, without the need for
further considerations. This speaks imo poorly of the PMC attachment to
release quality.

But you are correct on the technicality of vote counting and their official
consequences according to the written rules ...


>
> --
> AY
>
> On 25 July 2016 at 15:46:40, Michael Shuler (mshu...@apache.org) wrote:
>
> Thanks for the clarity, Jonathan. I agree that an August 3.8 release
> target sounds like the most reasonable option, at this point in time.
>
> With Sylvain's binding -1, this vote has failed.
>
> --
> Kind regards,
> Michael Shuler
>
> On 07/21/2016 05:33 PM, Jonathan Ellis wrote:
> > I feel like the calendar is relevant though because if we delay 3.8 more
> > we're looking at a week, maybe 10 days before 3.9 is scheduled. Which
> > doesn't give us much time for the stabilizing we're supposed to do in
> 3.9.
> >
> > All in all I think I agree that releasing 3.8 in August is less confusing
> > than skipping it entirely. And I don't like the idea of ignoring a whole
> > bunch of test failures and hoping they don't mean anything, because we
> just
> > had that thread about getting more rigorous about tests, not less.
> >
> > So I would recommend we go ahead and fix this before releasing, and to
> > avoid a super compressed 3.9 window either retarget 3.8 for August, or
> 3.9
> > for September.
> >
> > On Thu, Jul 21, 2016 at 9:58 AM, Aleksey Yeschenko <alek...@apache.org>
> > wrote:
> >
> >> What we’d usually do is revert the offending ticket and push it to the
> >> next release, if this indeed were significant enough.
> >>
> >> So option 4 would be to revert CDC fast (painful) and ship.
> >> Option 5 would be to quickly fix the issue, retag, and revote, with 3.9
> >> still following up on schedule.
> >> Option 6 would be to ignore the calendar entirely. Fix or revert the
> issue
> >> eventually, and release 3.8 then. Have 3.9 and 3.0.9 out at whatever
> time
> >> we decide to, and go back to monthly cycles from there on.
> >>
> >> TBH I don’t think anybody is even going to notice, or care. So I’m fine
> >> with 1, 4, 5, 6, but not reverting my +1 so far.
> >>
> >> --
> >> AY
> >>
> >> On 21 July 2016 at 14:46:17, Sylvain Lebresne (sylv...@datastax.com)
> >> wrote:
> >>
> >> On Thu, Jul 21, 2016 at 3:21 PM, Jonathan Ellis <jbel...@gmail.com>
> wrote:
> >>
> >>> I see the alternatives as:
> >>>
> >>> 1. Release this as 3.8
> >>> 2. Skip 3.8 and release 3.9 next month on schedule
> >>> 3. Skip this month and release 3.8 next month instead
> >>>
> >>
> >> I've hopefully made it clear I don't really like 1. I'm totally fine
> with
> >> either 2 or 3 though (with a very very small preference for 3. because I
> >> suspect skipping a release might confuse a few users, but also knowing
> that
> >> 2. has the small advantage of keeping the 3.0.x and 3.x versions
> released
> >> more or less in lockstep).
> >>
> >>
> >>
> >>>
> >>> On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko <alek...@apache.org
> >
> >>> wrote:
> >>>
> >>>> I still think the issue is minor enough, and with 3.8 being extremely
> >>>> delayed, and being a non-

Re: Blockers for 4.0

[Sylvain Lebresne]

On Thu, Jul 21, 2016 at 5:40 PM, Aleksey Yeschenko <alek...@apache.org>
wrote:

> We don’t need to block 4.0 on #8110.
>
> What we need is to block those sstable-format related tickets on *either*
> #8110 *or* 4.0.
>

You're right, I kind of listed the ticket a bit quickly.


>
> #8110 itself can go anywhere in 3.x or 4.x.
>
> --
> AY
>
> On 21 July 2016 at 15:38:58, Jason Brown (jasedbr...@gmail.com) wrote:
>
> Sylvain,
>
> In the large, yes, that is the best "have enough mechanism in place that no
> further ticket _have to_ wait for a major", but many of the tickets we are
> talking about makes changes to things we've all agreed can *only* happen at
> majors, as per the
> http://wiki.apache.org/cassandra/CompatibilityGuarantees
> (changing the internode protocol, for instance).
>
> if we're willing to trade on those Guarantees, then sure, majors are just
> bike shedding the version numbers, but I suspect we don't want to do that
> ;)
>
> That being said, I completely understand the frustration of "one more week,
> X is almost ready and we don't want to wait a year to get it in". I offer
> two points, though:
> 1) This is an open source project, with no real business requirements to
> ship any version by any specific date. We want to ship often enough to be
> relevant as a project/product, of course, but there's no financial or
> business requirement to do so.
> 2) We could have better planning as to what we actually want to ship in a
> "version", or at least have some agreed upon mid- to long-term roadmap.
> This would help focus the calendar and the project. Currently, it's largely
> willy-nilly as to what ships when, and while tick-tock has introduced
> regularity wrt release dates, there's not much that shapes what goes in
> those releases.
>
> My two cents,
>
> -Jason
>
>
>
> On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne <sylv...@datastax.com>
> wrote:
>
> > My very own preference would be to actually focus on making 4.0 the
> release
> > where have enough mechanism in place that no further ticket _have to_
> wait
> > for a major. That means at least making sure CASSANDRA-12042 makes it in,
> > adding some proper versioning of schemas and CASSANDRA-8110.
> >
> > If we had all that in place, I think no other would _have to_ be ready
> for
> > 4.0 as it could then just be delayed to 4.2 (or whenever it's ready).
> >
> > If we don't do that, I'm willing to take bets that every new major
> release
> > every year will be delayed cause "one more week, X is almost ready and we
> > don't want to wait a year to get it in".
> >
> > On Wed, Jul 20, 2016 at 4:40 PM, Jonathan Ellis <jbel...@gmail.com>
> wrote:
> >
> > > The plan of record has been to ship 4.0 in November, 12 months after
> 3.0.
> > > But, there are a number of features that are going to cause backwards
> > > incompatibility and if they miss 4.0 will need to wait for 5.0. Are any
> > of
> > > these worth delaying 4.0 for?
> > >
> > > (Currently the plan is to have all of these ready for November, but
> let's
> > > get our backup plan figured out now, just in case. That way we don't
> > have
> > > to make the decision at the last minute when everything feels like an
> > > emergency.)
> > >
> > > Some candidates that might be worth delaying the release for:
> > >
> > > - "Birch" trees for the primary key index
> > > <https://issues.apache.org/jira/browse/CASSANDRA-9754>. Changes the
> > > format of data on disk so automatically in the "dot zero" category.
> > > - Decouple messaging protocol versioning
> > > <https://issues.apache.org/jira/browse/CASSANDRA-12042>. This would
> > > allow us to change the intra-node protocol on a per-message basis,
> > which
> > > gives us more flexibility with compatibility. Currently any change
> > > drops
> > > us into the "no schema changes until everyone is upgraded" world which
> > > effectively rules out making any improvements across tick-tock
> > releases.
> > > - Allow dropping COMPACT STORAGE flag
> > > <https://issues.apache.org/jira/browse/CASSANDRA-10857>. This is
> > what
> > > makes it possible to remove the deprecated Thrift support.
> > > - Schema rearchitecture
> > > <https://issues.apache.org/jira/browse/CASSANDRA-9424>. Can we live
> > > without safe and programatic CREATE and ALTER for another year?
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
>

Re: State of Unit tests (1 out of 100 passes in trunk)

[Sylvain Lebresne]

On Thu, Jul 21, 2016 at 5:42 PM, Jeremiah D Jordan <
jeremiah.jor...@gmail.com> wrote:

> > Josh, add me to the "test fixers" queue, as well. However, I think the
> > authors of patches that break the build should also be on the hook for
> > fixing problems, as well.
>
> +1 I have always been a fan of “you broke it, you fix it"
>
>
Problem is, we're still kind of in fixing the backlog mode, so we don't
know who break something, not without basically understanding the issue (at
which point writing the fix is the easiest part usually). In fact, some of
those are flaky test where the problem is sometime just a test issue, so
the one to blame would be test author but you don't really know that
without looking again.

Whenever we do get to a consistent clean green dashboard, then we might be
able to quickly find out who break thing and assign to me. I don't really
think anyone disagree with the "you broke it, you fix it" otherwise.

Re: Blockers for 4.0

[Sylvain Lebresne]

On Thu, Jul 21, 2016 at 4:38 PM, Jason Brown <jasedbr...@gmail.com> wrote:

> Sylvain,
>
> In the large, yes, that is the best "have enough mechanism in place that no
> further ticket _have to_ wait for a major", but many of the tickets we are
> talking about makes changes to things we've all agreed can *only* happen at
> majors, as per the
> http://wiki.apache.org/cassandra/CompatibilityGuarantees
> (changing the internode protocol, for instance).
>

I don't think we ever agreed that being able to only make *any* kind of
change to
the intra-node protocol (to take that example) was a good thing. We merely
agreed that this was kind of necessary due to the problem I'm suggesting we
tackle (and some other we already tackled).
That, and the fact that until tick-tock we were supposed to add feature only
in major releases in the first place. In tick-tock, every feature release
is kind
of a major, and the fact we have to wait on some "super"-major for some
issue
is wrong.


>
> if we're willing to trade on those Guarantees, then sure, majors are just
> bike shedding the version numbers, but I suspect we don't want to do that
> ;)
>

That's exactly what I'm suggesting, and I'd be somewhat surprised we don't
want to because I'm convinced it's the right thing to do :)


>
> That being said, I completely understand the frustration of "one more week,
> X is almost ready and we don't want to wait a year to get it in". I offer
> two points, though:
> 1) This is an open source project, with no real business requirements to
> ship any version by any specific date. We want to ship often enough to be
> relevant as a project/product, of course, but there's no financial or
> business requirement to do so.
> 2) We could have better planning as to what we actually want to ship in a
> "version", or at least have some agreed upon mid- to long-term roadmap.
> This would help focus the calendar and the project. Currently, it's largely
> willy-nilly as to what ships when, and while tick-tock has introduced
> regularity wrt release dates, there's not much that shapes what goes in
> those releases.
>
> My two cents,
>
> -Jason
>
>
>
> On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne <sylv...@datastax.com>
> wrote:
>
> > My very own preference would be to actually focus on making 4.0 the
> release
> > where have enough mechanism in place that no further ticket _have to_
> wait
> > for a major. That means at least making sure CASSANDRA-12042 makes it in,
> > adding some proper versioning of schemas and CASSANDRA-8110.
> >
> > If we had all that in place, I think no other would _have to_ be ready
> for
> > 4.0 as it could then just be delayed to 4.2 (or whenever it's ready).
> >
> > If we don't do that, I'm willing to take bets that every new major
> release
> > every year will be delayed cause "one more week, X is almost ready and we
> > don't want to wait a year to get it in".
> >
> > On Wed, Jul 20, 2016 at 4:40 PM, Jonathan Ellis <jbel...@gmail.com>
> wrote:
> >
> > > The plan of record has been to ship 4.0 in November, 12 months after
> 3.0.
> > > But, there are a number of features that are going to cause backwards
> > > incompatibility and if they miss 4.0 will need to wait for 5.0.  Are
> any
> > of
> > > these worth delaying 4.0 for?
> > >
> > > (Currently the plan is to have all of these ready for November, but
> let's
> > > get our backup plan figured out now, just in case.  That way we don't
> > have
> > > to make the decision at the last minute when everything feels like an
> > > emergency.)
> > >
> > > Some candidates that might be worth delaying the release for:
> > >
> > >-  "Birch" trees for the primary key index
> > ><https://issues.apache.org/jira/browse/CASSANDRA-9754>.  Changes
> the
> > >format of data on disk so automatically in the "dot zero" category.
> > >- Decouple messaging protocol versioning
> > ><https://issues.apache.org/jira/browse/CASSANDRA-12042>.  This
> would
> > >allow us to change the intra-node protocol on a per-message basis,
> > which
> > >gives us more flexibility with compatibility.  Currently any change
> > > drops
> > >us into the "no schema changes until everyone is upgraded" world
> which
> > >effectively rules out making any improvements across tick-tock
> > releases.
> > >- Allow dropping COMPACT STORAGE flag
> > ><https://issues.apache.org/jira/browse/CASSANDRA-10857>.  This is
> > what
> > >makes it possible to remove the deprecated Thrift support.
> > >- Schema rearchitecture
> > ><https://issues.apache.org/jira/browse/CASSANDRA-9424>.  Can we
> live
> > >without safe and programatic CREATE and ALTER for another year?
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
>

Re: Blockers for 4.0

[Sylvain Lebresne]

My very own preference would be to actually focus on making 4.0 the release
where have enough mechanism in place that no further ticket _have to_ wait
for a major. That means at least making sure CASSANDRA-12042 makes it in,
adding some proper versioning of schemas and CASSANDRA-8110.

If we had all that in place, I think no other would _have to_ be ready for
4.0 as it could then just be delayed to 4.2 (or whenever it's ready).

If we don't do that, I'm willing to take bets that every new major release
every year will be delayed cause "one more week, X is almost ready and we
don't want to wait a year to get it in".

On Wed, Jul 20, 2016 at 4:40 PM, Jonathan Ellis  wrote:

> The plan of record has been to ship 4.0 in November, 12 months after 3.0.
> But, there are a number of features that are going to cause backwards
> incompatibility and if they miss 4.0 will need to wait for 5.0.  Are any of
> these worth delaying 4.0 for?
>
> (Currently the plan is to have all of these ready for November, but let's
> get our backup plan figured out now, just in case.  That way we don't have
> to make the decision at the last minute when everything feels like an
> emergency.)
>
> Some candidates that might be worth delaying the release for:
>
>-  "Birch" trees for the primary key index
>.  Changes the
>format of data on disk so automatically in the "dot zero" category.
>- Decouple messaging protocol versioning
>.  This would
>allow us to change the intra-node protocol on a per-message basis, which
>gives us more flexibility with compatibility.  Currently any change
> drops
>us into the "no schema changes until everyone is upgraded" world which
>effectively rules out making any improvements across tick-tock releases.
>- Allow dropping COMPACT STORAGE flag
>.  This is what
>makes it possible to remove the deprecated Thrift support.
>- Schema rearchitecture
>.  Can we live
>without safe and programatic CREATE and ALTER for another year?
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 3.8

[Sylvain Lebresne]

On Thu, Jul 21, 2016 at 3:21 PM, Jonathan Ellis <jbel...@gmail.com> wrote:

> I see the alternatives as:
>
> 1. Release this as 3.8
> 2. Skip 3.8 and release 3.9 next month on schedule
> 3. Skip this month and release 3.8 next month instead
>

I've hopefully made it clear I don't really like 1. I'm totally fine with
either 2 or 3 though (with a very very small preference for 3. because I
suspect skipping a release might confuse a few users, but also knowing that
2. has the small advantage of keeping the 3.0.x and 3.x versions released
more or less in lockstep).



>
> On Thu, Jul 21, 2016 at 8:19 AM, Aleksey Yeschenko <alek...@apache.org>
> wrote:
>
> > I still think the issue is minor enough, and with 3.8 being extremely
> > delayed, and being a non-odd release, at that, we’d be better off just
> > pushing it.
> >
> > Also, I know we’ve been easy on -1s when voting on releases, but I want
> to
> > remind people in general that release votes can not be vetoed and only
> > require a majority of binding votes,
> > http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
> > --
> > AY
> >
> > On 21 July 2016 at 08:57:22, Sylvain Lebresne (sylv...@datastax.com)
> > wrote:
> >
> > Sorry but I'm (binding) -1 on this because of
> > https://issues.apache.org/jira/browse/CASSANDRA-12236.
> >
> > I disagree that knowingly releasing a version that will temporarily break
> > in-flight queries during upgrade, even if it's for a very short
> time-frame
> > until re-connection, is ok. I'll note in particular that in the test
> > report, there is 74! failures in the upgrade tests (for reference the 3.7
> > test report had only 2 upgrade tests failure both with open tickets).
> Given
> > that we have a known problem during upgrade, I don't really buy the "We
> are
> > assuming these are due to a recent downsize in instance size that these
> > tests run on" and that suggest to me the problem is not too minor.
> >
> >
> > On Thu, Jul 21, 2016 at 6:18 AM, Dave Brosius <dbros...@mebigfatguy.com>
> > wrote:
> >
> > > +1
> > >
> > >
> > > On 07/20/2016 05:48 PM, Michael Shuler wrote:
> > >
> > >> I propose the following artifacts for release as 3.8.
> > >>
> > >> sha1: c3ded0551f538f7845602b27d53240cd8129265c
> > >> Git:
> > >>
> > >>
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
> > >> Artifacts:
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/
> > >> Staging repository:
> > >>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1123/
> > >>
> > >> The debian packages are available here:
> > >> http://people.apache.org/~mshuler/
> > >>
> > >> The vote will be open for 72 hours (longer if needed).
> > >>
> > >> [1]: http://goo.gl/oGNH0i (CHANGES.txt)
> > >> [2]: http://goo.gl/KjMtUn (NEWS.txt)
> > >> [3]: https://goo.gl/TxVLKo (3.8 Test Summary)
> > >>
> > >>
> > >
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 3.8

[Sylvain Lebresne]

Sorry but I'm (binding) -1 on this because of
https://issues.apache.org/jira/browse/CASSANDRA-12236.

I disagree that knowingly releasing a version that will temporarily break
in-flight queries during upgrade, even if it's for a very short time-frame
until re-connection, is ok. I'll note in particular that in the test
report, there is 74! failures in the upgrade tests (for reference the 3.7
test report had only 2 upgrade tests failure both with open tickets). Given
that we have a known problem during upgrade, I don't really buy the "We are
assuming these are due to a recent downsize in instance size that these
tests run on" and that suggest to me the problem is not too minor.


On Thu, Jul 21, 2016 at 6:18 AM, Dave Brosius 
wrote:

> +1
>
>
> On 07/20/2016 05:48 PM, Michael Shuler wrote:
>
>> I propose the following artifacts for release as 3.8.
>>
>> sha1: c3ded0551f538f7845602b27d53240cd8129265c
>> Git:
>>
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative
>> Artifacts:
>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/
>> Staging repository:
>>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1123/
>>
>> The debian packages are available here:
>> http://people.apache.org/~mshuler/
>>
>> The vote will be open for 72 hours (longer if needed).
>>
>> [1]: http://goo.gl/oGNH0i (CHANGES.txt)
>> [2]: http://goo.gl/KjMtUn (NEWS.txt)
>> [3]: https://goo.gl/TxVLKo (3.8 Test Summary)
>>
>>
>

Re: Reminder: critical fixes only in 2.1

[Sylvain Lebresne]

Definitively agrees that CASSANDRA-10433 and CASSANDRA-12030 aren't
critical. In fact, they are both marked as "improvements" and "minor". I'm
to blame for their commit, so mea culpa. But to my defense, I've long
advocated for being stricter on sticking to critical-only fixes on old
releases and have long felt that this sentiment wasn't really shared in
practice by other devs/committers (could be my fault getting the wrong
impression, but I've lost track of the number of time were other
devs/committers argue for "just this time because it's really simple" when
those questions cam up), so I've partly gave up on arguing. I'm happy to
get more consistent on this and +1 reverting those.

I think CASSANDRA-11349 is the one possibly more debatable. Fabien on the
ticket seemed to suggest that on his clusters the bug was make repair
unmanageable ("a few days after filing the bug, we decided to temporarily
stop repairing some tables [...] which were heavily impacted by those
bugs"). He mention in particular having seen "around a hundred" mismatches
with the patch against "a few hundred of thousands" without. I suppose one
could make a case that having repair over-stream by 3 order of magnitude in
some case is critical-ish. Note that I wouldn't oppose reverting this too,
as it doesn't fully meet *my* definition of critical, but I'm willing to
accept my definition is on the stronger side of things and leave it in.

--
Sylvain

On Wed, Jul 20, 2016 at 5:29 PM, Aleksey Yeschenko 
wrote:

> +1 from me (and I don’t see any resistance to it either).
>
> --
> AY
>
> On 18 July 2016 at 18:36:42, Jonathan Ellis (jbel...@gmail.com) wrote:
>
> Except there really wasn't.
>
> Patch submitter: "I want this in 2.1."
> Reviewer: "Okay."
>
> That's not exactly the bar we're looking for. To consider a performance
> fix "critical" for example, you really need to show at the very least what
> new workload you found that isn't able to live with it the way everyone
> else did for the previous 15 releases.
>
> I note that on 10433 the committer even said, "I'm not [sure] I agree this
> is critical for 2.1 at this point, but as it's simple enough and has been
> somewhat vetted on 2.2 by now, not going to argue."
>
> So consider this me putting on my bad cop hat and opening up the argument.
>
> On Mon, Jul 18, 2016 at 12:24 PM, Jeremiah D Jordan  >
> wrote:
>
> > Looking at those tickets in all three of them the “is this critical to
> > fix” question came up in the JIRA discussion and it was decided that they
> > were indeed critical enough to commit to 2.1.
> >
> > > On Jul 18, 2016, at 11:47 AM, Jonathan Ellis 
> wrote:
> > >
> > > We're at the stage of the release cycle where we should be committing
> > > critical fixes only to the 2.1 branch. Many people depend on 2.1
> working
> > > reliably and it's not worth the risk of introducing regressions for
> > (e.g.)
> > > performance improvements.
> > >
> > > I think some of the patches committed so far for 2.1.16 do not meet
> this
> > > bar and should be reverted. I include a summary of what people have to
> > > live with if we leave them unfixed:
> > >
> > > https://issues.apache.org/jira/browse/CASSANDRA-11349
> > > Repair suffers false-negative tree mismatches and overstreams data.
> > >
> > > https://issues.apache.org/jira/browse/CASSANDRA-10433
> > > Reduced performance on inserts (and reads?) (for Thrift clients only?)
> > >
> > > https://issues.apache.org/jira/browse/CASSANDRA-12030
> > > Reduced performance on reads for workloads with range tombstones
> > >
> > > Anyone want to make a case that these are more critical than they
> appear
> > > and should not be reverted?
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> >
> >
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 2.2.7

[Sylvain Lebresne]

+1

On Fri, Jul 1, 2016 at 5:18 PM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On 1 July 2016 at 15:59:02, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 2.2.7.
>
> sha1: 092054170ec3daf92ec494a0db295037d3563229
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.7-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1121/org/apache/cassandra/apache-cassandra/2.2.7/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1121/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/R37fmZ (CHANGES.txt)
> [2]: http://goo.gl/PaGj7e (NEWS.txt)
> [3]: https://goo.gl/DKoHDw (Test Report)
>

Re: [VOTE] Release Apache Cassandra 3.7

[Sylvain Lebresne]

On Wed, Jun 8, 2016 at 2:45 PM, James Carman 
wrote:

> How are you guys verifying these releases so fast? Do you have verification
> scripts or something?
>

Because we're trying to release on a fixed cadence if possible, we're
freezing releases for testing in advance
so we have some time to fix problems if we find some. You can see Jake's
email from June 6 on the freeze
of both 3.0.7 and 3.7. That means most people already have validated/tested
a release when the official
vote is started.


>
> On Wed, Jun 8, 2016 at 3:44 PM Jonathan Ellis  wrote:
>
> > +1
> >
> > On Wed, Jun 8, 2016 at 2:21 PM, Jake Luciani  wrote:
> >
> > > I propose the following artifacts for release as 3.7.
> > >
> > > sha1: 6815dc970565e6cd1e0169b5379f37da7a5a8a32
> > > Git:
> > >
> > >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.7-tentative
> > > Artifacts:
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1116/org/apache/cassandra/apache-cassandra/3.7/
> > > Staging repository:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1116/
> > >
> > > The artifacts as well as the debian package are also available here:
> > > http://people.apache.org/~jake
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: http://goo.gl/uA2hU1 (CHANGES.txt)
> > > [2]: http://goo.gl/e79k5m (NEWS.txt)
> > > [3]: https://goo.gl/iBt11P (Test Report)
> > >
> >
> >
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.7

[Sylvain Lebresne]

+1

On Wed, Jun 8, 2016 at 2:35 PM, Jake Luciani  wrote:

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

Re: [VOTE] Release Apache Cassandra 3.7

[Sylvain Lebresne]

+1

On Wed, Jun 8, 2016 at 2:21 PM, Jake Luciani  wrote:

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

Re: Java Driver 3.0 for Apache Cassandra - Documentation Outdated?

[Sylvain Lebresne]

On Tue, Jun 7, 2016 at 1:50 AM, Chris Mattmann  wrote:

> Excellent, why am I the first person to ask that, and why didn’t
> a PMC member point that out right away and why did it take me asking
> to point to the Apache docs.
>
> This is what I am talking about in terms of the Apache community..
>

You seem to have make your mind on the Cassandra PMC doing a poor
job so you'll probably consider my response as just proof of how bad we are
(since I'm PMC), but I genuinely fail to see what you think was wrong on the
answer given by Nate to this original email. I mean, that original email is
very
explicitly asking a question about the DataStax java driver documentation,
which as we've established is not part of the Cassandra, and Nate helpfully
explained that fact. So I'm curious as to what else you would have wanted
us the PMC to point out as response to that initial email so we can do
better
next time.

Or, to answer your question more directly, no PMC member pointed right
away to the CQL documentation as response to Madhi original email because
his question was not about CQL, it was about the DataStax Java driver.

--
Sylvain


>
>
>
>
>
> On 6/6/16, 4:47 PM, "Michael Kjellman" 
> wrote:
>
> >http://cassandra.apache.org/doc/cql3/CQL.html
> >
> >On Jun 6, 2016, at 4:42 PM, Mattmann, Chris A (3980) <
> chris.a.mattm...@jpl.nasa.gov>
> wrote:
> >
> >Hi,
> >
> >So, the core documentation for a key part of Cassandra is hosted
> >at DataStax?
> >
> >Cheers,
> >Chris
> >
> >++
> >Chris Mattmann, Ph.D.
> >Chief Architect
> >Instrument Software and Science Data Systems Section (398)
> >NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >Office: 168-519, Mailstop: 168-527
> >Email: chris.a.mattm...@nasa.gov
> >WWW:  http://sunset.usc.edu/~mattmann/
> >++
> >Director, Information Retrieval and Data Science Group (IRDS)
> >Adjunct Associate Professor, Computer Science Department
> >University of Southern California, Los Angeles, CA 90089 USA
> >WWW: http://irds.usc.edu/
> >++
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >On 6/6/16, 7:32 AM, "Mahdi Mohammadi" > wrote:
> >
> >Team,
> >
> >I was checking the documentation for TupleType in DataStax docs here
> ><
> https://docs.datastax.com/en/latest-java-driver/java-driver/reference/tupleTypes.html
> >
> >and
> >the code example was like this:
> >
> >TupleType theType = TupleType.of(DataType.cint(), DataType.text(),
> >DataType.cfloat());
> >
> >
> >But in the code, the *TupleType.of* has two additional parameters not
> >mentioned in the documentation:
> >
> >
> >*public static TupleType of(ProtocolVersion protocolVersion, CodecRegistry
> >codecRegistry, DataType... types)*
> >
> >Maybe I am looking in the wrong place. Could someone please explain how
> can
> >I instantiate a *TupleType*?
> >
> >I have the same question for *Map* type.
> >
> >Thanks for your help.
> >
> >===
> >Best Regards
> >
>
>

Re: [VOTE] Release Apache Cassandra 3.6 (Attempt #2)

[Sylvain Lebresne]

+1

On Thu, Jun 2, 2016 at 5:16 PM, Robert Stupp  wrote:

> +1 (non-binding)
>
> —
> Robert Stupp
> @snazy
>
> On Jun 1, 2016, at 19:30, Jake Luciani  wrote:
>
> I propose the following artifacts for release as 3.6.
>
> sha1: 8d22d9fd1842c59ea65a3793aceb5a78c5852351
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.6-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1114/org/apache/cassandra/apache-cassandra/3.6/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1114/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/lg9U9a (CHANGES.txt)
> [2]: http://goo.gl/nyDyxk (NEWS.txt)
> [3]: https://goo.gl/hNyrnW (DataStax QA Report)
>
>
>

Re: [VOTE] Release Apache Cassandra 3.6

[Sylvain Lebresne]

+1

On Wed, May 11, 2016 at 6:23 AM, Jonathan Ellis  wrote:

> +1
>
> On Tue, May 10, 2016 at 8:54 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.6.
> >
> > sha1: c17cbe1875a974a00822ffbfad716abde363c8da
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.6-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1112/org/apache/cassandra/apache-cassandra/3.6/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1112/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/Yv15Qz (CHANGES.txt)
> > [2]: http://goo.gl/VyR9EG (NEWS.txt)
> > [3]: https://goo.gl/raz8ok (DataStax QA Report)
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 3.0.6

[Sylvain Lebresne]

+1

On Wed, May 11, 2016 at 6:23 AM, Jonathan Ellis  wrote:

> +1
>
> On Tue, May 10, 2016 at 8:54 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.0.6.
> >
> > sha1: 52447873a361647a5e80c547adea9cf5ee85254a
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.6-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1110/org/apache/cassandra/apache-cassandra/3.0.6/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1110/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/IiNyVb (CHANGES.txt)
> > [2]: http://goo.gl/ZAr03L (NEWS.txt)
> > [3]: https://goo.gl/2jPtss (DataStax QA Report)
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [Proposal] Mandatory comments

[Sylvain Lebresne]

> When I'm reading code i look for comments to help me understand key
points,
> points that aren't self-evident. If we institute a boilerplate "comment
> everything" rule then I lose that signpost.

Frankly, I don't love the idea of somewhat limiting comments on purpose so
the
sheer presence of a comment is a "signpost", which kind of imply they are
fairly rare. Especially because when you write and even review code, many
many
things that appears self-evident because you're deep in the code really
aren't
when you come cold to it (and doubly so when your new to the code). So that
while commenting should certainly be done intelligently (and there is such
thing as too much useless comments), you should imo lean toward more rather
than less commenting in general.

But also, I'm talking here about commenting public methods and classes. I
certainly agree that for in-code comments you don't want to mechanically
comment
every other line but rather only use comments when there is some subtlety.
But I
don't see it mattering that much for classes and methods. You're not gonna
read
the javadoc of a method that you don't use, and if you want to use one, it's
almost always nice if it has a javadoc (of course, especially if it's a
"good" one). There is a few cases where that javadoc isn't really useful
but no harm done either imo. Have you ever think while looking at the
javadoc
of a library "man I wish half of the methods had no javadoc because i'm
confused which methods are important now".

But anyway, I've worked on code base that had javadoc for every public
methods
and classes and (again provided the comments are good) didn't ever felt that
this was more confusing than helpful, so I just don't buy that it is. I
don't
deny that there is few public classes and methods that are trivial enough
that
a javadoc don't add anything. And it's not so much that I care about it in
those
case. It's that I think making the rule strict has more pros than cons by
evacuating
any debate over where the line should be for having the javadoc or not and
focusing our energy elsewhere.

Another of my reasoning is that I suspect one of the main reason our code is
badly commented is laziness (we all seem to agree that comments are
important and that our code isn't well commented enough). My hope is that by
making some minimal level of commenting mandatory, we'll be forced to stop
being lazy about comments and always be reminded that we should care about
them. And I hope that this will help improve the overall comment quality.

So hopefully I've explained my reasoning well enough. To sum it up, having a
javadoc for every public class and method certainly isn't enough (the
quality of
comments is really really important in particular), but I disagree that
it would hurt, I'm convinced it would be an improvement over our current
status
quo, and more importantly I hope it might be a useful nudge to improve our
comment situation long term.

But if we can't agree on that, so be it. In that case though, is there a
concrete alternative proposition to help turn around our current lack of
proper commenting (I'm specfically interested in fixing our ways here,
commenting existing code that isn't sufficiently commented is great and we
should
do it, but I feel we should maybe stop committing insufficiently commented
code
first)? Or do we think that having had this conversation will be enough?

--
Sylvain

Re: [Proposal] Mandatory comments

[Sylvain Lebresne]

On Tue, May 3, 2016 at 6:57 PM, Eric Evans <john.eric.ev...@gmail.com>
wrote:

> On Mon, May 2, 2016 at 11:26 AM, Sylvain Lebresne <sylv...@datastax.com>
> wrote:
> > Looking forward to other's opinions and feedbacks on this proposal.
>
> We might want to leave just a little wiggle room for judgment on the
> part of the reviewer, for the very simple cases.  Documenting
> something like setFoo(int) with "Sets foo" can get pretty tiresome for
> everyone, and doesn't add any value.
>

I knew someone was going to bring this :). In principle, I don't really
disagree. In practice though,
I suspect it's sometimes just easier to adhere to such simple rule somewhat
strictly. In particular,
I can guarantee that we don't all agree where the border lies between what
warrants a javadoc
and what doesn't. Sure, there is a few cases where you're just paraphrasing
the method name
(and while it might often be the case for getters and setters, it's worth
noting that we don't really
do much of those in C*), but how hard is it to write a one line comment?
Surely that's a negligeable
part of writing a patch and we're not that lazy.

Anyway, I have no intention of being an ass and rejecting a well commented
patch during review
just because it missing a javadoc on a setFoo(int) method. But I do intend
to try to follow the rule
strictly and I think it'll be simpler if everyone does too. If nothing
else, it'll bring consistency and
that's reassuring for newcomers.

--
Sylvain

Re: [Proposal] Mandatory comments

[Sylvain Lebresne]

On Mon, May 2, 2016 at 7:16 PM, Jonathan Ellis <jbel...@gmail.com> wrote:

> What I'd like to see is more comments like the one in StreamSession:
> something that can give me the "big picture" for a piece of functionality.
>

I wholeheartedly agree that we need more of those. I don't think though that
we need a single kind of comment, nor even that we're lacking on a single
kind.


>
> I wonder if focusing on class-based comments might miss an opportunity
> here.


I don't meant to imply any exclusive focusing by my suggestion. I'm
constantly
seeing classes that not well explained and methods that make complex and
undocumented assumptions, so I'm very much convinced improvements are
needed on that front. Without, again, invalidating the equal need for big
picture
comments.


>
> Is this a case for package-level javadoc, and organizing our class
> hierarchy better along those lines?
>

I agree that this would probably be the best place for those bit-picture
documentation. I'd be totally fine adding on top of the rule I suggested
another
one that says:
  - If you create a new package, you should have a package level javadoc
that
describe the big picture of what that package is about.

I do want to note that I'm trying to focus the discussion here on a few
simple
concrete points we could hopefully easily agree on so that we improve our
ways
moving forward and I'd personally love to focus on that first. That won't
fix
existing code by itself, but the optimistic in me hopes that if we get more
consistent
quality of comments in new code, our inconfort with the lack of comments in
old
code will grow and we'll end up fixing it naturally over time.

--
Sylvain


>
> On Mon, May 2, 2016 at 11:26 AM, Sylvain Lebresne <sylv...@datastax.com>
> wrote:
>
> > There could be disagreement on this, but I think that we are in general
> not
> > very good at commenting Cassandra code and I would suggest that we make a
> > collective effort to improve on this. And to help with that goal, I would
> > like
> > to suggest that we add the following rule to our code style guide
> > (https://wiki.apache.org/cassandra/CodeStyle):
> >   - Every public class and method must have a quality javadoc. That
> > javadoc, on
> > top of describing what the class/method does, should call particular
> > attention to the assumptions that the class/method does, if any.
> >
> > And of course, we'd also start enforcing that rule by not +1ing code
> unless
> > it
> > adheres to this rule.
> >
> > Note that I'm not pretending this arguably simplistic rule will magically
> > make
> > comments perfect, it won't. It's still up to us to write good and
> complete
> > comments, and it doesn't even talk about comments within methods that are
> > important too. But I think some basic rule here would be beneficial and
> > that
> > one feels sensible to me.
> >
> > Looking forward to other's opinions and feedbacks on this proposal.
> >
> > --
> > Sylvain
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

[Proposal] Mandatory comments

[Sylvain Lebresne]

There could be disagreement on this, but I think that we are in general not
very good at commenting Cassandra code and I would suggest that we make a
collective effort to improve on this. And to help with that goal, I would
like
to suggest that we add the following rule to our code style guide
(https://wiki.apache.org/cassandra/CodeStyle):
  - Every public class and method must have a quality javadoc. That
javadoc, on
top of describing what the class/method does, should call particular
attention to the assumptions that the class/method does, if any.

And of course, we'd also start enforcing that rule by not +1ing code unless
it
adheres to this rule.

Note that I'm not pretending this arguably simplistic rule will magically
make
comments perfect, it won't. It's still up to us to write good and complete
comments, and it doesn't even talk about comments within methods that are
important too. But I think some basic rule here would be beneficial and that
one feels sensible to me.

Looking forward to other's opinions and feedbacks on this proposal.

--
Sylvain

Re: [VOTE] Release Apache Cassandra 2.2.6

[Sylvain Lebresne]

+1

On Fri, Apr 22, 2016 at 11:37 PM, Jonathan Ellis  wrote:

> +1
>
> On Fri, Apr 22, 2016 at 4:15 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.2.6.
> >
> > sha1: 37f63ecc5d3b36fc115fd7ae98e4fc1f4bc2d1d6
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.6-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1108/org/apache/cassandra/apache-cassandra/2.2.6/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1108/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/6pLDlq (CHANGES.txt)
> > [2]: http://goo.gl/Pqv75l (NEWS.txt)
> > [3]: https://goo.gl/v0mlO1 (Datastax Test Report)
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 2.1.14

[Sylvain Lebresne]

+1

On Fri, Apr 22, 2016 at 11:37 PM, Jonathan Ellis  wrote:

> +1
>
> On Fri, Apr 22, 2016 at 4:12 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.1.14.
> >
> > sha1: 209ebd380b641c4f065e9687186f546f8a50b242
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.14-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1109/org/apache/cassandra/apache-cassandra/2.1.14/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1109/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/mMQSCa (CHANGES.txt)
> > [2]: http://goo.gl/BsauSg (NEWS.txt)
> > [3]: https://goo.gl/mlrNxH (Datastax Test Report)
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Lightweight transaction for read and update

[Sylvain Lebresne]

No, this is currently not possible. This is something that is
likely technically feasible with the LWT mechanism but it
is not currently supported (and, for info, is not on anyone
short term todo list as far as I know).

Sorry.

On Tue, Apr 5, 2016 at 10:51 AM, Priyanka Gugale 
wrote:

> Hi,
>
> Is there a possibility that we can write a cql statement which can *read a
> column value and update it in same transaction* (e.g. column has value 28,
> I read it add 7 to it and update column value to 35)? There are some
> examples for lightweight transactions
> <
> http://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_ltwt_transaction_c.html
> >
> but
> from this I couldn't figure out how do I achieve read and update in same
> statement.
>
> -Priyanka
>

Re: [VOTE] Release Apache Cassandra 3.4

[Sylvain Lebresne]

+1

On Sat, Mar 5, 2016 at 9:27 PM, Josh McKenzie  wrote:

> +1
>
> On Fri, Mar 4, 2016 at 8:43 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.4.
> >
> > sha1: 70649a8d65825144fcdbde136d9b6354ef1fb911
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.4-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1103/org/apache/cassandra/apache-cassandra/3.4/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1103/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/j9D9Se (CHANGES.txt)
> > [2]: http://goo.gl/6R89cS (NEWS.txt)
> > [3]: https://goo.gl/K5LkEL (DataStax Test Report)
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.4

[Sylvain Lebresne]

+1

On Sat, Mar 5, 2016 at 9:27 PM, Josh McKenzie  wrote:

> +1
>
> On Fri, Mar 4, 2016 at 8:46 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.0.4.
> >
> > sha1: 6328590808ff16fd026fd80cb28635d4313b8cc8
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.4-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1102/org/apache/cassandra/apache-cassandra/3.0.4/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1102/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/pRvRQH (CHANGES.txt)
> > [2]: http://goo.gl/pNiK5w (NEWS.txt)
> > [3]: https://goo.gl/aInswH (DataStax Test Report)
> >
>

Re: RandomPartitioner and new token allocation algorithm

[Sylvain Lebresne]

On Thu, Feb 11, 2016 at 11:56 AM, Romain Hardouin 
wrote:

> I targeted the dev list because I would like to know why the developer
> (patch by branimir and reviewed by benedict) mentions "Only supported with
> the Murmur3Partitioner" whereas his patch uses IPartitioner interface. (I
> will try to reach them on IRC if they don't see this message.)
>

While the patch uses the IPartitioner interface, it also requires that the
Token for the partitioner supported to implement the 2 new methods 'size'
and 'increaseSlightly', which only Murmur3Partition tokens does (it throws
UnsupportedOperationException for RandomPartitioner in particular).
So the documentation in the yaml is correct, only Murmur3Partitioner is
currently supported.

That said, I think the initial rational for only supporting
Murmur3Partitioner is that it's the default and the one recommended, but
it's certainly true that old installs are stuck to RandomPartitioner (and
honestly the difference with Murmur3 are not big enough that its worth
going through a very painful migration if that's your case) and it's not
immediately clear to me that adding support for it would be too hard. Feel
free to open an improvement ticket for that if you're interested.

--
Sylvain

Re: A short guid on how to contribute patches to Cassandra

[Sylvain Lebresne]

Can you put it on the current wiki since we don't really know when (and if)
we'll be able to move the wiki to confluence? It would be good to have a
proper url to point people to if need be.

On Tue, Feb 9, 2016 at 5:26 PM, Aleksey Yeschenko 
wrote:

> Once we have a new wiki, yup, definitely.
>
> --
> AY
>
> On 9 February 2016 at 16:25:16, Michael Kjellman (
> mkjell...@internalcircle.com) wrote:
>
> Move to Wiki?
>
> Sent from my iPhone
>
> > On Feb 9, 2016, at 5:59 AM, Aleksey Yeschenko 
> wrote:
> >
> > Hello everyone,
> >
> > I’ve compiled a short guide for contributors (who aren’t committers yet)
> about how to properly contribute Cassandra patches:
> >
> >
> https://docs.google.com/document/d/1d_AzYQo74de9utbbpyXxW2w-b0__sFhC7b24ibiJqjw/edit?usp=sharing
> >
> > Following the outlined recommendations make the lives of committers much
> easier, without adding much hassle to contributor process.
> >
> > Follow the steps and feel the love.
> >
> > --
> > AY
>

Re: [VOTE] Release Apache Cassandra 3.0.3

[Sylvain Lebresne]

+1

On Mon, Feb 8, 2016 at 10:28 PM, Brandon Williams  wrote:

> +1
>
> On Mon, Feb 8, 2016 at 2:56 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.0.3.
> >
> > sha1: b9bdd9ec648ad42d88b1377fe0e1e4ff3d162a91
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.3-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1100/org/apache/cassandra/apache-cassandra/3.0.3/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1100/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/Xz7gJz (CHANGES.txt)
> > [2]: http://goo.gl/Awjozv (NEWS.txt)
> > [3]: https://goo.gl/lZKxQa (DataStax Test Report)
> >
>

Re: [VOTE] Release Apache Cassandra 3.3

[Sylvain Lebresne]

+1
On Feb 6, 2016 06:15, "Brandon Williams"  wrote:

> +1
>
> On Fri, Feb 5, 2016 at 9:11 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.3.
> >
> > sha1: 5669c6967bbdd540f27aeebf5a2c258bc4defbe3
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.3-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1101/org/apache/cassandra/apache-cassandra/3.3/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1101/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/1nZIdi (CHANGES.txt)
> > [2]: http://goo.gl/a1UT2s (NEWS.txt)
> > [3]: https://goo.gl/aYBtW1 (DataStax Test Report)
> >
>

Re: [VOTE] Release Apache Cassandra 2.2.5

[Sylvain Lebresne]

+1

On Wed, Feb 3, 2016 at 2:51 PM, Jake Luciani  wrote:

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

Re: [VOTE] Release Apache Cassandra 2.1.13

[Sylvain Lebresne]

+1

On Wed, Feb 3, 2016 at 2:49 PM, Jason Brown  wrote:

> +1
>
> On Wed, Feb 3, 2016 at 5:44 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.1.13.
> >
> > sha1: d5b6d1b634f69709d2b3caa17cba52696ed2033d
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.13-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1098/org/apache/cassandra/apache-cassandra/2.1.13/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1098/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/ldbtfT (CHANGES.txt)
> > [2]: http://goo.gl/yToJdI (NEWS.txt)
> > [3]: https://goo.gl/eWXZLZ (DataStax Test Report)
> >
>

Re: EOL for COMPACT STORAGE

[Sylvain Lebresne]

No, there is no such plan.

On Mon, Feb 1, 2016 at 4:19 PM, Anuj Wadehra  wrote:

> I would appreciate if someone from Dev team could reply?
> ThanksAnuj
>
> Sent from Yahoo Mail on Android
>
>   On Sun, 31 Jan, 2016 at 7:23 pm, Anuj Wadehra
> wrote:   Hi,
> Is there any plan to completely phase out COMPACT STORAGE table format
> such that backward compatability is broken in future?
>
> ThanksAnuj
>
>
>
>

Re: [VOTE] Release Apache Cassandra 3.2.1

[Sylvain Lebresne]

+1

On Fri, Jan 15, 2016 at 3:20 PM, Gary Dusbabek  wrote:

> +1
>
> On Thu, Jan 14, 2016 at 9:03 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.2.1.
> >
> > sha1: 2ac95bd6c5699a605e6f4256cb17b016c99e6dda
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2.1-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1097/org/apache/cassandra/apache-cassandra/3.2.1/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1097/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 24 hours (longer if needed).
> >
> > [1]: http://goo.gl/WG3TEx (CHANGES.txt)
> > [2]: http://goo.gl/z7OsrE (NEWS.txt)
> > [3]: https://goo.gl/MLo2Kg (DataStax Test Report)
> >
>

Re: [VOTE] Release Apache Cassandra 3.1.1

[Sylvain Lebresne]

+1

On Thu, Dec 17, 2015 at 8:53 PM, Josh McKenzie  wrote:

> +1
>
> On Thu, Dec 17, 2015 at 2:40 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.1.1.
> >
> > sha1: 8347d37716d318956591ab7d5688774a083e5bfb
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.1.1-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1095/org/apache/cassandra/apache-cassandra/3.1.1/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1095/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 24 hours (longer if needed).
> >
> > [1]: http://goo.gl/dTQqsb (CHANGES.txt)
> > [2]: http://goo.gl/rHhQPO (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.2

[Sylvain Lebresne]

+1

On Thu, Dec 17, 2015 at 8:53 PM, Josh McKenzie  wrote:

> +1
>
> On Thu, Dec 17, 2015 at 2:42 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.0.2.
> >
> > sha1: 9b655ac181e732e2c489e102d6742cad6f7029e6
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.2-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1094/org/apache/cassandra/apache-cassandra/3.0.2/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1094/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 24 hours (longer if needed).
> >
> > [1]: http://goo.gl/Jymb32 (CHANGES.txt)
> > [2]: http://goo.gl/2hIFHI (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.1

[Sylvain Lebresne]

+1

On Sat, Dec 5, 2015 at 1:51 AM, Jonathan Ellis  wrote:

> +1
>
> On Fri, Dec 4, 2015 at 3:23 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.0.1.
> >
> > sha1: cf567703db2cc6859731405322f19f55345b5c57
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.1-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1092/org/apache/cassandra/apache-cassandra/3.0.1/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1092/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/fJaAjI (CHANGES.txt)
> > [2]: http://goo.gl/DgSi87 (NEWS.txt)
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: [VOTE] Release Apache Cassandra 3.1

[Sylvain Lebresne]

+1

On Sat, Dec 5, 2015 at 1:51 AM, Jonathan Ellis  wrote:

> +1
>
> On Fri, Dec 4, 2015 at 4:07 PM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 3.1.
> >
> > sha1: e092873728dc88aebc6ee10153b9bd3cd90cd858
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.1-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1093/org/apache/cassandra/apache-cassandra/3.1/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1093/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]:  http://goo.gl/HET4Bi (CHANGES.txt)
> > [2]:  http://goo.gl/LVqJJo (NEWS.txt)
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Aligning Cassandra CQL documentation

[Sylvain Lebresne]

Fyi, CASSANDRA-7225 (https://issues.apache.org/jira/browse/CASSANDRA-7225)
to basically make cqlsh point to the CQL doc to avoid that kind of
inconsistencies/duplicate work as much as possible.

> How do we make the changes to the Datastax docs to align them with the
other two sets of docs?

You send an email to d...@datastax.com.

On Wed, Nov 18, 2015 at 4:00 AM, Michael Edge 
wrote:

> Hi,
>
> It seems there are 2-3 sets of Cassandra CQL documentation that should be
> updated if we make any changes to CQL.
>
>
>- https://cassandra.apache.org/doc/cql3/CQL.html, which can be updated
>by applying changes to cassandra/doc/cql3/CQL.textile
>- The 'help' function within cqlsh, which can be updated by applying
>changes to cqlsh.py
>-
>
> http://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlRefcreateType.html
> ,
>the official Datastax docs.
>
>
> How do we make the changes to the Datastax docs to align them with the
> other two sets of docs?
>
> Are there any other docs that should also be updated?
>
> Regards,
>
> Michael
>

Re: Can't assign issues to myself

[Sylvain Lebresne]

Granted.

On Tue, Nov 17, 2015 at 3:11 PM, Michael Edge 
wrote:

> Hi All,
>
> I'm trying to assign
> https://issues.apache.org/jira/browse/CASSANDRA-10719?filter=12334050 to
> myself but it seems I'm unable to. Is someone able to grant me contributor
> permissions or do you have another preferred way of assigning issues?
>
> Cheers,
>
> Michael
>

Re: [VOTE] Release Apache Cassandra 2.1.10

[Sylvain Lebresne]

+1

On Thu, Oct 1, 2015 at 4:31 PM, Jonathan Ellis  wrote:

> +1
>
> On Thu, Oct 1, 2015 at 9:17 AM, Jake Luciani  wrote:
>
> > I propose the following artifacts for release as 2.1.10.
> >
> > sha1: 78f2e7aa01d552454fd4270fee8d600c4433df5c
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.10-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1081/org/apache/cassandra/apache-cassandra/2.1.10/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1081/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/GLMVLb (CHANGES.txt)
> > [2]: http://goo.gl/uFe1VN (NEWS.txt)
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>