+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
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.
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
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
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
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:
+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
> >>>
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
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
+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
+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
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
x.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
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
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
: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 sepa
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
> 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
+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 <
>
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
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
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
>
t 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 propo
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
gt; 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 Bene
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
ing 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.
&g
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.
>
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
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?
-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
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
>
>
> 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
ing, 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
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
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
>
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
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
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
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
+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
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
+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:
+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:
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).
>
>
e-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
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
+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:
> >
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 tr
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 a
ich...@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 majo
-> trunk (future 4.0)
Any strong objection to me creating that branch?
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:
> >
+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:
> >
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:
>
> >
> >
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
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,
+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:
> >
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
lendar 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, o
en, 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:
>
> >
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
s 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
> 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
> >
&
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
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
+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:
>
>
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
+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
>
+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:
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
+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:
+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:
> >
> >
>
+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:
> >
> >
>
> 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
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 l
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 Lebres
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
+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:
> >
> >
>
+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:
> >
> >
>
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
+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:
> >
> >
>
+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:
> >
> >
>
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
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,
+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:
> >
> >
>
+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:
> >
> >
>
+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
>
+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:
> >
> >
>
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:
+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:
> >
> >
>
+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:
> >
> >
>
+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:
> >
> >
>
+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:
> >
> >
>
+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:
> >
> >
>
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
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
+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:
> >
> >
>
1 - 100 of 448 matches
Mail list logo