+1
--
Sylvain
On Tue, Apr 22, 2025 at 10:47 AM Maxim Muzafarov wrote:
> Also +1
>
> On Tue, 22 Apr 2025 at 07:57, guo Maxwell wrote:
> >>
> >> We have already agreed some time ago that any incompatible API change
> requires a DISCUSS thread. I’m fairly sure it’s documented on the wiki.
> >
> >
+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 folks
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-n
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
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 a
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 tic
+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 considere
+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,
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
> >> was to
> >> > > > > > > demonstrate that my opinion is based on experience and I
> >> wasn't
> >> > > > > > suggesting
> >> > > > > > > we switch tooling based on a whim. I also wasn't
//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
&g
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
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 commu
> > 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 fi
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
> 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 sugges
+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/CASSA
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 extreme
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 ca
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.
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 m
opriate” 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
> >
> >
>
eel 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&
>
> > 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
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
am
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
-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
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 (Data
>
>
> 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 would
ons.
>
> But I do agree with your statement to "make it clear what kind of
> contributions are "preferred" at any given time". But really "any given
> time", not just when it's convenient for us to have people help fix
> testing, before they "ma
ay 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 wrote:
>
> >>
> >> I agree there&#
>
> 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?
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
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
On Mon, Apr 9, 2018 at 10:56 PM Jonathan Haddad wrote:
> There's always more stuff to try to shoehorn in. We've done big releases
> with all the things, it never was stable. We tried the opposite end of the
> spectrum, release every month, that really wasn't great either. Personally
> I'd be O
For what it's worth (and based on the project experience), I think the
strategy
of "let's agree on a list of tickets everyone would love to get in before we
freeze 4.0" doesn't work very well (it's largely useless, expect for making
us
feel good about not releasing anything). Those lists always end
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
n
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
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
Just one more data point, but I personally don't feel that disabling
new MV creation (or new SAS index creation for that matter) by default
_in a patch release_ is terribly nice. There can absolutely be code
out there that creates MV/SASI indexes somewhat automatically on some
events and it would b
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
> verific
+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,
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 ma
+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
+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?
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
view if someone's interested.
>
> On Tue, Jan 17, 2017 at 4:26 AM, Sylvain Lebresne
> 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 du
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 w
+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=cassa
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
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
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
wrote:
> As there has been no strong objection, I'm going to proceed and create the
> branc
ue, Sep 27, 2016 at 2:48 PM, Michael Shuler
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
:
2.1 -> 2.2 -> 3.0 -> 3.X -> 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:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.
+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.gi
uating 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
> 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
names may be to blam
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:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.g
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
ely. 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
> &g
ips 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
> wrote:
>
> > My very own
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
;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
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 al
n -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
> >
> &
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 particu
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 ha
+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.or
+1
On Fri, Jul 1, 2016 at 5:15 PM, Aleksey Yeschenko
wrote:
> +1
>
> --
> AY
>
> On 30 June 2016 at 20:31:11, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 2.1.15.
>
> sha1: cb14186f8d6c2d1105a51e409c59a4e424958171
> Git:
>
> http://git-wip-us.apache.
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 p
+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://re
+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://reposi
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..
>
+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.apa
+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=
+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?
> 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 c
On Tue, May 3, 2016 at 6:57 PM, Eric Evans
wrote:
> On Mon, May 2, 2016 at 11:26 AM, Sylvain Lebresne
> 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
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
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
(htt
+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
+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/as
On Fri, Apr 8, 2016 at 1:54 PM, Salih Gedik wrote:
> Hi,
> I am wondering who are eligible to vote for these?
>
Officially, only PMC member (list here if you're interested:
https://projects.apache.org/committee.html?cassandra) votes are binding.
In practice though, we're grateful to anyone havin
We also realized that some commits had been badly merge to trunk some times
ago (3.0 isn't affected) on
https://issues.apache.org/jira/browse/CASSANDRA-11353, so it also makes
sense to re-roll for those since they were supposed to be fixed a long time
ago and at least #11353 is worth not delaying f
+1
On Fri, Apr 8, 2016 at 9:24 AM, Benjamin Lerer
wrote:
> +1
>
> On Fri, Apr 8, 2016 at 12:10 AM, Jake Luciani wrote:
>
> > I propose the following artifacts for release as 3.0.5.
> >
> > sha1: c6e6fa94d28c0d23a8154e3743c05b355dba710a
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p
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
+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=cas
+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=c
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
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.
>
>
+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
+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
+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://re
1 - 100 of 548 matches
Mail list logo
