Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Closing the loop on seeking consensus for UX/UI/API changes, I see a few options. Can we rank choice vote please? A - Jira suffices B - Post a DISCUSS API thread prior to making changes C - Periodically publish a list of API changes for retrospective consideration by the community Points raise

Re: [DISCUSS] New data type for vector search

I think we need to briefly step back and think about what the syntax means and how it fits into existing syntax.It seems that the dimensionality verbiage assumes we’re logically introducing N vector fields, so that each row adopts a value for all of the vector fields or none. But in practice we ar

Re: [DISCUSSION] CEP-38: CQL Management API

Syntactically, if we’re updating settings like compaction throughput, I would prefer to simply update a virtual settings table e.g. UPDATE system.settings SET compaction_throughput = 128 Some operations will no doubt require a stored procedure syntax, but perhaps it would be a good idea to spli

Re: [DISCUSS] Stream Pipelines on hot paths

I think I have already proposed a simple solution to this problem on the thread: if anyone says it’s a hot path (and cannot be persuaded otherwise), it should be treated as such. Saves argument, but permits an easy escape hatch if everyone agrees with minimal discussion. I think this is a good

Re: Testing 4.0 Post-Freeze

+1. > On 9 Jul 2018, at 20:17, Mick Semb Wever wrote: > > >> We have done all this for previous releases and we know it has not worked >> well. So how giving it one more try is going to help here. Can someone >> outline what will change for 4.0 which will make it more successful? > > > I (a

Re: Testing 4.0 Post-Freeze

That’s a peculiar way of looking at it. Committer status is not an absolute right to autonomy over the codebase. It’s an embodiment of trust that you will follow the community's prevailing rules around commit, and that you’re competent to do so. If the community wants to change those rules

Re: Testing 4.0 Post-Freeze

ve said all I need to on this, it's > probably just noise now, so I won't respond any further on this > thread. I don't anticipate having a personal need to commit to a > future 5.0 release before 4.0 is out, so it won't impact me > personally. > > On Tue, Jul 10,

Re: GitHub PR ticket spam

I agree this is a mess. I think we have previously taken the view that JIRA should be the permanent record of discussion, and that as such the git conversation should be duplicated there. However, I think it would be better for JIRA to get a summary of important discussions, by one of the part

Re: GitHub PR ticket spam

Also +1 It might perhaps be nice to (just once) have ASF Bot comment that a GitHub discussion has been replicated to the worklog? In the Arrow example, for instance, it isn’t immediately obvious that there are any worklog comments to look at. Or perhaps we should require committers to summaris

Re: Side Car New Repo vs not

+1 also for separate repo > On 24 Aug 2018, at 01:11, Jeff Jirsa wrote: > > +1 for separate repo > > > -- > Jeff Jirsa > > >> On Aug 23, 2018, at 1:00 PM, sankalp kohli wrote: >> >> Separate repo is in a majority so far. Please reply to this thread with >> your responses. >> >> On Tue, A

Re: Measuring Release Quality

I think it would be great to start getting some high quality info out of JIRA, but I think we need to clean up and standardise how we use it to facilitate this. Take the Component field as an example. This is the current list of options: 4.0 Auth Build Compaction Configuration Core CQL Distr

Re: Measuring Release Quality

re pretty good now). >> – Considering adding a "severity” field to capture the distinction between >> priority and severity. >> ––– >> >> If there’s appetite for spending a little time on this, I’d put effort >> toward it if others are interested; is anyone

Re: Moving tickets out of 4.0 post freeze

I’d like to propose we don’t do Semver. Back when we did this before, there wasn’t any clear distinction between a major and a minor release. They were both infrequent, both big, and were treated as majors for EOL'ing support for older releases. This must surely have been confusing for users,

Re: Moving tickets out of 4.0 post freeze

4.1, I think we > should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our Major>.. versioning of the past never followed semver. > > -Jeremiah > >> On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith >> wrote: >> >> I’d like to propose we

Re: [DISCUSS] changing default token behavior for 4.0

This sounds worthy of a bug report! We should at least document any such inadequacy, and come up with a plan to fix it. It would be great if you could file a ticket with a detailed example of the problem. > On 24 Sep 2018, at 14:57, Tom van der Woerdt > wrote: > > Late comment, but I'll wri

Re: Moving tickets out of 4.0 post freeze

Do we want to manage more versions than we do now? Why don’t we simply align these things to majors, like we’ve typically tried to anyway? I think it’s anyway better to decide on a strategy and find a versioning scheme that matches it, rather than to look for a strategy that matches our current

Implicit Casts for Arithmetic Operators

CASSANDRA-11935 introduced arithmetic operators, and alongside these came implicit casts for their operands. There is a semantic decision to be made, and I think the project would do well to explicitly raise this kind of question for wider input before release, since the project is bound by the

Re: Implicit Casts for Arithmetic Operators

master/src/ee/common/NValue.hpp#L2213 > <https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L2213> > https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L3764 > <https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L3764>

Re: Implicit Casts for Arithmetic Operators

them. The > change in the column types of results sets actually sounds worse if we want > to also improve aggregrations. Many applications won't notice if the client > library abstracts that away, but I think there are still cases where people > would notice the type changing. >

Re: Implicit Casts for Arithmetic Operators

As far as I can tell we reached a relatively strong consensus that we should implement lossless casts by default? Does anyone have anything more to add? Looking at the emails, everyone who participated and expressed a preference was in favour of the “Postgres approach” of upcasting to decimal f

Re: Implicit Casts for Arithmetic Operators

LECT round(2.65) * round(1) returns double 3 >> >> So as we're going to have silly values in any case, why pretend something >> else? Also, exact calculations are slow if we crunch large amount of >> numbers. I guess I slightly deviated towards Postgres' implemention

Re: Implicit Casts for Arithmetic Operators

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

Re: CASSANDRA-13241 lower default chunk_length_in_kb

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 ar

Re: CASSANDRA-13241 lower default chunk_length_in_kb

igh 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

Re: CASSANDRA-13241 lower default chunk_length_in_kb

Shall we move this discussion to a separate thread? I agree it needs to be had, but this will definitely derail this discussion. To respond only to the relevant portion for this thread: > changing years-old defaults I don’t see how age is relevant? This isn’t some ‘battle hardened’ feature w

Re: CASSANDRA-13241 lower default chunk_length_in_kb

I’m +1 change of default. I think Jeff was -1 on that though. > On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: > > Hi, > > To summarize who we have heard from so far > > WRT to changing just the default: > > +1: > Jon Haddadd > Ben Bromhead > Alain Rodriguez > Sankalp Kohli (not explicit)

Re: CASSANDRA-13241 lower default chunk_length_in_kb

nd -0.5 respectively. > > Ariel > > On Tue, Oct 23, 2018, at 11:50 AM, Benedict Elliott Smith wrote: >> I’m +1 change of default. I think Jeff was -1 on that though. >> >> >>> On 23 Oct 2018, at 16:46, Ariel Weisberg wrote: >>> >>> Hi,

Re: CASSANDRA-13241 lower default chunk_length_in_kb

pen-source code-base that's this old, I've learned that it pays to > be very, very cautious. > > On Tue, Oct 23, 2018 at 3:33 PM Jeff Jirsa wrote: > >> My objection (-0.5) is based on freeze not in code complexity >> >> >> >> -- >> Jeff

Re: Proposed changes to CircleCI testing workflow

Just want to say +1, and thanks for taking the time to do this. This all sounds great. (And completely supersedes what I hoped to achieve with CASSANDRA-14648) > On 26 Oct 2018, at 15:49, Stefan Podkowinski wrote: > > I'd like to give you a quick update on the work that has been done > latel

Re: Implicit Casts for Arithmetic Operators

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 examples). >> &

Re: Implicit Casts for Arithmetic Operators

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 >>

Re: Implicit Casts for Arithmetic Operators

d it. > On 21 Nov 2018, at 21:08, Sylvain Lebresne wrote: > > 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 o

Re: Implicit Casts for Arithmetic Operators

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 >>

Re: Implicit Casts for Arithmetic Operators

find the decision pretty hard to make. > > On Thu, Nov 22, 2018 at 11:51 AM Benedict Elliott Smith <mailto:bened...@apache.org>> > wrote: > >> We’re not presently voting*; we’re only discussing, whether we should base >> our behaviour on a widely agreed u

Re: Implicit Casts for Arithmetic Operators

Yes. > On 22 Nov 2018, at 11:32, Benjamin Lerer wrote: > > Then I would be interested in knowing `where we should be`. If the answer > is `ANSI SQL92` then my question is: Why? Simply for the sake of following > a standard? > > > On Thu, Nov 22, 2018 at 12:19 P

Re: Implicit Casts for Arithmetic Operators

have a common point of reference. > On 22 Nov 2018, at 11:42, Benjamin Lerer wrote: > > Sorry, following a standard for the sake of following a standard does not > make sense to me. > > On Thu, Nov 22, 2018 at 12:33 PM Benedict Elliott Smith > wrote: > >> Yes. &g

Re: Implicit Casts for Arithmetic Operators

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

Re: Request to review feature-freeze proposed tickets

> I assume it's obvious to everyone that this should be taken on a > case-by-case basis. There's at least 2 that were in that list (one of which > Marcus bumped off PA) that are potentially big and hairy changes that would > disrupt in-flight testing cycles. Agreed. I’d prefer we aim to be as per

Re: Implicit Casts for Arithmetic Operators

suggested a toggle to permit users to continue with present-day semantics should they choose. Surely this resolves your concerns, unless you think this is intractable? > On 22 Nov 2018, at 12:13, Benedict Elliott Smith wrote: > > This is why I said the decision is ideological. We fund

Re: Implicit Casts for Arithmetic Operators

y agree > the release quality is an important aspect as well for instance, but > my point is that it should _all_ be factored in. > > Currently, we have very little information on how bad 3) and 4) are. So my > current personal opinion is that 1) does justify looking into this

JIRA Workflow Proposals

We’ve concluded our efforts to produce a proposal for changes to the JIRA workflow, and they can be found here: https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals I hope there will be broa

Re: JIRA Workflow Proposals

things >>> wrong) (current proposal is a +1 on "do things right", though I'd argue >>> against it being *easy*) >>> 2. Asking from the users what they can provide about their experience >>> and issues and no more >>> >>> Phi

Re: JIRA Workflow Proposals

people towards more complete and accurate data entry >>>> 4. our ability as a project to measure release quality over time and >>>> identify when Cassandra is ready for (or due a) release. >>>> >>>> The proposal in its current form makes c

Re: JIRA Workflow Proposals

es and no more >> >> Philosophically, are we trying to make it easier for people that are paid >> FT to work on C*, are we trying to make things easier for *users* of C*, >> both, neither? Who are we targeting here w/these project changes and what >> of their issues / p

Re: JIRA Workflow Proposals

The idea is for users to create a ticket without any field requirements. >> Contributors should liaise with the user to understand the problem, and >> transition it to Open. > > Shit, my bad, totally missed / didn't grok that. That makes a lot more > sense. > >

Re: JIRA Workflow Proposals

_think_ several of your concerns are addressed by the new Triage state. >>>> The idea is for users to create a ticket without any field requirements. >>>> Contributors should liaise with the user to understand the problem, and >>>> transition it to Open. >

Re: JIRA Workflow Proposals

:02, Benedict Elliott Smith wrote: > > Do we maintain a list of prior rejects? Revisit any that have increased in > usage since last? > > Probably we’re bike shedding this one thing too closely. I would be happy > with removing it, periodically cleaning it, or leaving

Re: JIRA Workflow Proposals

sal. "Workflow > and bug tracker hygiene” can be a thankless endeavor; I want to make sure > this one’s not. Thank you both! > > If we’re nearing consensus on “keeping labels, and considering them for > promotion to components periodically,” are there other items we nee

Re: JIRA Workflow Proposals

Sorry, 4. Is inconsistent. First instance should be. > - 4. Priorities: Keep ‘High' priority > On 4 Dec 2018, at 19:12, 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)

Re: JIRA Workflow Proposals

oritisation. Wish is a priority to make room for the Wish ticket type we are removing, and for those occasional requests that come in that have no realistic timeline for being addressed. > > And with that, my poll results: > 1:A > 2:+1 > 3:+1 > 4:Don't mind > 5:Don'

Re: JIRA Workflow Proposals

e of this field is very patchy, and of not great utility IMO. Perhaps others have an opinion? > As for workflow changes, I don't have a real opinion on that yet and > like to give this some more thoughts. But the suggested review status > changes are something I'd definitely

Re: JIRA Workflow Proposals

> >> 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 >> > > 1:

Re: JIRA Workflow Proposals

Dec 2018, at 08:16, Sylvain Lebresne wrote: >> >> 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 > <mailto:bened...@apache.org>> >> wrote: >> >>> Thanks for t

Re: JIRA Workflow Proposals

ect list, we will probably not make it mandatory. Here we’re trying to gauge an ideal end state - some things may need revisiting if JIRA does not play ball, though that should not affect many items. > > Ariel > > On Tue, Dec 4, 2018, at 2:12 PM, Benedict Elliott Smith wrote: >&

Re: JIRA Workflow Proposals

5 groups feature impact and platform. It's platform I think is less useful? I > am +1 on feature impacts as we have impact on things like CCM and drivers > that we need to keep track of and I do forget them at times. > > Ariel > > On Fri, Dec 7, 2018, at 1:17 PM, Benedict E

Re: JIRA Workflow Proposals

The “Impact” field idea sounds like a good potential follow-up discussion. I’d prefer not to complicate this process when we’re seemingly nearing consensus, particularly as I’m not personally sure what form such a field would take. But it would be a relatively small modification, if you want t

Re: JIRA Workflow Proposals

so high > value? I don't populate it myself usually I put it in the description or the > subject without thinking. > > It seems like the purpose of a field is to make it indexable and possibly > structured. How often do we search or require structure on this field? >

Re: JIRA Workflow Proposals

, 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

Re: JIRA Workflow Proposals

10, 2018, at 6:14 PM, Murukesh Mohanan >> 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: JIRA Workflow Proposals

>> 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 >>> wrote: >>> >>> On Tue, 11 Dec 2018 at 10:51, Benedict

Re: JIRA Workflow Proposals

#x27;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

Re: JIRA Workflow Proposals

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 >>> >>>

Re: Revisit the proposal to use github PR

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

Re: cassandra-stress HexStrings generator

Yes, I’m pretty sure you understood correctly (I wrote most of this, but it’s been a long time so I cannot remember much for certain). It should be implemented like the Strings generator. It looks like both HexStrings and HexBytes are incorrect, and have been for a long time. > On 12 Dec 20

Re: cassandra-stress HexStrings generator

I’m honestly not sure. The code has changed since I last worked on it, which was years ago. I suspect the profile mode has entirely supplanted the prior modes, and that these older modes supported the HexStrings generator. Perhaps somebody else can help answer this question. > On 13 Dec 2018

Re: Revisit the proposal to use github PR

nce 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 d

[VOTE] Change Jira Workflow

I propose these changes * to the Jira Workflow for the project. The vote will be open for 72 hours**. I am, of course, +1. * With the addendum of the mailing list discussion

Re: [VOTE] Change Jira Workflow

t; On Mon, Dec 17, 2018, at 10: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

Component Migration

Following the vote for JIRA workflow changes, I have introduced the new Components and migrated any that were relatively easy*. I have retained the old Component values with the prefix Legacy/. I have also introduced the proposed Feature field into Component for now, until we can establish if

[JIRA Epic] Removing Contributor Role

In discussing this aspect of the change with ASF Infra, Gavin McDonald asked for a reconsideration. Firstly, he was concerned about Jira struggling under the load of auto-populating 12 user names. He suggested waiting until they have migrated users to LDAP later this year. Given Jira’s ge

Re: Regarding CASSANDRA-14227

The project is primarily pushing towards a higher quality 4.0 release, so I am unaware of anybody considering this bug. There’s a strong argument to be made for this to be fixed in 4.0, since it ideally requires a major version bump. I can’t promise anybody will prioritise this over their othe

Jira Workflow Changes Beta

Hi, The workflow changes are largely up to try out here: https://issues-test.apache.org/jira/browse/CASSANDRA I’d appreciate some beta testing, to make sure I haven’t made any errors in the transitions (I’ve done some, but a few more would be useful). There were a lot of changes, and Jira is

Re: [VOTE] Release Apache Cassandra 3.0.18

CASSANDRA-14812 should probably land in this release, given that it is a critical bug, has been patch available for a while, and is relatively simple. That said, we are sorely due a release. But if we go ahead without it, we should follow up soon after. > On 3 Feb 2019, at 00:32, Michael Shul

Re: [VOTE] Release Apache Cassandra 3.11.4

+1 > On 6 Feb 2019, at 08:01, Tommy Stendahl wrote: > > +1 (non-binding) > > /Tommy > > On lör, 2019-02-02 at 18:31 -0600, Michael Shuler wrote: > > I propose the following artifacts for release as 3.11.4. > > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193 > Git: > https://gitbox.apache.org/

Re: [VOTE] Release Apache Cassandra 3.0.18

+1 > On 6 Feb 2019, at 08:01, Tommy Stendahl wrote: > > +1 (non-binding) > > /Tommy > > On lör, 2019-02-02 at 18:32 -0600, Michael Shuler wrote: > > I propose the following artifacts for release as 3.0.18. > > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e > Git: > https://gitbox.apache.org/

Re: [VOTE] Release Apache Cassandra 2.2.14

+1 > On 6 Feb 2019, at 05:09, Jeff Jirsa wrote: > > +1 > > On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler > wrote: > >> I propose the following artifacts for release as 2.2.14. >> >> sha1: af91658353ba601fc8cd08627e8d36bac62e936a >> Git: >> >> https://gitbox.apache.org/repos/asf?p=cassandra.

Re: [VOTE] Release Apache Cassandra 2.1.21

+1, and also see no point in EOL; if we have failed to back port something important, we should rectify it. > On 6 Feb 2019, at 05:09, Jeff Jirsa wrote: > > +1 (to the release, I see no reason to force this to be EOL; leaving the > branch open has zero cost, and if a serious enough patch comes

Re: Related to large partition and row out of order

This sounds like something you should report upstream as a bug to DataStax. I’m unaware of any bugs in Cassandra mainline that cause this behaviour, but if you can reproduce the creation of this partitions in 3.11.2, we can help to diagnose the cause. But without source code it would be a fool’

Jira Workflow Changes

The new workflow is now live on Jira. Please let me know ASAP of any bugs or issues you find with it. I had to replicate the changes manually, and I may well have missed something. > On 23 Jan 2019, at 14:12, Benedict Elliott Smith wrote: > > Hi, > > The workflow changes ar

Re: [jira] [Updated] (CASSANDRA-14096) Cassandra 3.11.1 Repair Causes Out of Memory

We can, but we will need to arrange another vote, since we explicitly discussed this and voted in favour of lifting any limitation on anonymous users (FWIW, I remain in favour of limiting anonymous users) > On 19 Mar 2019, at 13:35, Joshua McKenzie wrote: > >

Re: [jira] [Updated] (CASSANDRA-14096) Cassandra 3.11.1 Repair Causes Out of Memory

Hmm. Actually, did we? I’m conflating anonymous with logged-in. > On 19 Mar 2019, at 13:43, Benedict Elliott Smith wrote: > > We can, but we will need to arrange another vote, since we explicitly > discussed this and voted in favour of lifting any limitation on anonymous > u

Re: [jira] [Updated] (CASSANDRA-14096) Cassandra 3.11.1 Repair Causes Out of Memory

did not. > On 19 Mar 2019, at 13:45, Joshua McKenzie wrote: > > I don't recall a vote about anonymous users having transition rights. This > topic irritates me enough that I'm pretty sure I'd go full-on campaign mode > against it. :) > > On Tue, Mar 19, 20

Jira: Author Field

A couple of people have recently raised the possibility of an Author field in JIRA, that permits multiple authors (much like we now support multiple reviewers). Unfortunately this can never be quite as clean as Reviewers, as Assignee is a core Jira field and cannot be replaced entirely by Autho

Re: Jira: Author Field

st curious. > > > On Mon, Apr 8, 2019 at 8:55 AM Benedict Elliott Smith > wrote: > >> A couple of people have recently raised the possibility of an Author field >> in JIRA, that permits multiple authors (much like we now support multiple >> reviewers). >> >

Re: Stabilising Internode Messaging in 4.0

Appreciate everyone's input. It sounds like there's broad agreement that the fixes need to make it into 4.0, which I'm really pleased to see. The question seems to be moving towards scope and timing. TL;DR: This patch is probably the most efficient route to a stable 4.0. The patch is already re

Re: Stabilising Internode Messaging in 4.0

I don’t have a lot to add to Josh’s contribution, except that I’d like to really hammer home that many people were a party to 8099, and as a project we learned a great deal from the experience. It’s a very complex topic, that does not lend itself to simple comparisons, but I think anyone who pa

Re: TLP tools for stress testing and building test clusters in AWS

+1 I’m also just as excited to see some standardised workloads and test bed. At the moment we’re benefiting from some large contributors doing their own proprietary performance testing, which is super valuable and something we’ve lacked before. But I’m also keen to see some more representativ

Re: Stabilising Internode Messaging in 4.0

I would once again exhort everyone making these kinds of comment to actually read the code, and to comment on Jira. Preferably with a justification by reference to the code for how or why it would improve the patch. As far as a design document is concerned, it’s very unclear what is being requ

Re: Stabilising Internode Messaging in 4.0

d others have worked for). > Everything we want to do: better testing, better review, better code, is > made easier with better design review, better discussion, and more > digestible patches among many of the other things suggested in this thread. > > Jordan > > On Fri, Apr 12,

Re: Jira: Author Field

t;> for after-the-fact research to determine who wrote a thing to reach out >> to >>> them for context? If the latter, does a change in JIRA metadata give us >>> more context than good git commit message hygiene (i.e. list all authors >> on >>> commit msg)

Jira Updates

Some exciting news from the Jira changes (maybe). We’re done! We’ve even achieved the stretch goals. Does anyone have any further suggestions from the new workflow, after having tried it out for a bit? Speak up while we have the easy capability to make changes! - Somebody has proposed making

Re: TLP tools for stress testing and building test clusters in AWS

end, which should be your evening, could work? >>>>> >>>>> I can set up a Zoom conference to get everyone acquainted. We can >>>>> record and post it for any who can't make it. >>>>> >>>>> I'm thinking Tuesday,

Re: Multi-column relations not allowed on partition key/s

Hi Abhishek, Sorry for the slow response. I would assume the main reason is simply that nobody has implemented the functionality. However, there might be some ideological opposition as well. This query is impossible to implement as efficiently on the server as it is on the client. It shou

Jira Suggestion

How would people feel about introducing a field for the (git) commit SHA, to be required on (Jira) commit? The norm is that we comment the SHA, but given this is the norm perhaps we should codify it instead, while we have the chance? It would also make it easier to find. --

Re: Jira Suggestion

gt; >> Please >> >> -- >> Jeff Jirsa >> >> >>> On May 14, 2019, at 7:53 AM, Benedict Elliott Smith >>> wrote: >>> >>> How would people feel about introducing a field for the (git) commit SHA, >>> to be required on

Re: Jira Suggestion

> > On Wed, May 15, 2019 at 3:39 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 14 May 2019, at 20:10, Benedict Elliott Smith >> wrote: >>> >>> It will be possible to insert n/a. It will simply be a text field - >> Jira doesn’t know

Re: Jira Suggestion

d > understood what you were saying, and then bounced down the thread; that's > completely on me and in no way a phrasing error on your part. > > You are 100% correct and are supporting my (apparently multiple) bad > habits. +1 again! > > On Wed, May 15, 2019 at 9:19 AM

Re: Time for a new 3.0/3.11 release?

It would be nice to have time to get CASSANDRA-14812 in, as it was also (consciously) missed from the last release, and struggled to find a reviewer since. Mick kindly found time to take a look while I was away. It’s a bit rough to force affected users to wait another lengthy release cycle for

Re: Isn't there a workable cassandra java source for developing as other big data system?

3.11.3 compiles just fine, I have just corroborated. Sir Jeff is in fact a Cassandra developer, so please feel free to engage with his question, which was designed to help diagnose your problem. > On 16 Jul 2019, at 14:54, Nimbus Lin wrote: > > To Sir Jeff: > your method of "ant realcl

Re: Google Season of Docs 2019 for Apache Cassandra

So, I think we need to figure out if anybody is actually willing to put in the time to help and mentor these contributors, since the last person to reach out was roundly ignored. Who volunteered the project for this? I think they need to step up and get involved. Right now, I don't feel comfo

  1   2   3   4   >