Re: [DISCUSS] Requirement to document features before releasing them

I am opposed to this. There’s too much imprecision in the “rule” while simultaneously being much too rigid, and it will be improperly enforced (we already have lots of rule breaking around modifying public APIs, that should have discuss threads and do not, for instance). This kind of arbitrary rule

Re: Python and Go callouts during ant compile/build task

We should separate out any grade discussion. I’m happy to migrate accord to ant if that’s the project preference, but there’s continual discussion to begin modularising Cassandra (at least a little), and a proposal to use grade for the modules - which might be a happy medium for everyone’s competin

Re: Constraint's "not null" alignment with transactions and their simplification

If we have a goal of eventually providing ANSI SQL support one day, we should at least stick to the ANSI SQL standard where applicable for features in the meantime. AFAICT the reason everyone else does this the same is it is part of the standard. So, I am more than happy to stick to the CHECK quali

Re: Constraint's "not null" alignment with transactions and their simplification

such a limitation on users and force them to define every column present in a constraint, or do we break the SQL spec?  If we choose to break the spec, then why allow column names in the search expressions?  Only “this” column is safeOn Apr 14, 2025, at 1:24 PM, Benedict wrote:If we have a g

Re: [DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

We should never download and install software via adhoc scripts without user consent. Was this ever discussed on this mailing list? If not, it’s a clear breach of policy (introducing a new dependency) and a severe one in my opinion, as it seems to introduce a new supply chain attack vector for a

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

+1 This is an obviously good feature for operators that are storage-bound in multi-DC deployments but want to retain their latency characteristics during node maintenance. Log replicas are the right approach. > On 3 May 2025, at 23:42, sc...@paradoxica.net wrote: > > Hey everybody, bumping th

Re: CEP-15 Update

folks have concerns, it's easy to fire up a cluster (I do it constantly) and try it out.I think if we were to do this, out of consideration we should time box the amount of time for an evaluation and unless someone raises an objection, consider lazy consensus achieved.JonOn Thu, Mar 6, 2025 at 12

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

I think another way of saying what Stefan may be getting at is: what does a library give us that an appropriately configured mount dir doesn’t?We don’t want to treat S3 the same as local disk, but this can be achieved easily with config. Is there some other benefit of direct integration? Well defin

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

dtest does this already.  Someone just started asking about IAM for login, it sounds like a similar problem. On Thu, Mar 6, 2025 at 12:53 AM Benedict <bened...@apache.org> wrote:I think another way of saying what Stefan may be getting at is what does a library give us that an appropriately conf

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

memetables + offheap objects modeI disabled compactiona recent nightly build is used for async-profilermy hardware is quite old: on-premise VM, Linux 4.18.0-240.el8.x86_64, OpenJdk-11.0.26+4, Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, 16 coreslink to CPU profile ("codahale" code: 8.65%)-

Re: CEP-15 Update

caveats apply when someone is not using Accord.  Assuming they only apply when the feature flag is enabled, I see no reason not to get this merged into trunk once everyone involved is happy with the state of it.-Jeremiah On Mar 5, 2025 at 12:15:23 PM, Benedict Elliott Smith <bened...@apache.

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

we can anticipate broad user confusion/interest. > > In particular if latency stats are reported higher post-upgrade, we should expect users to interpret this as a performance regression, dedicating significant resources to investigating the change, and expending credibility with stakeholders

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

format and the rest on new format - still merge all Clearspring logsin case all SSTables are on new format - merge DatasketchesI haven't looked at it this way. I'll play with it.On Wed, Mar 12, 2025 at 12:55 PM Benedict Elliott Smith <bened...@apache.org> wrote:Hi Stefan,My reading

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

it is definitely not possible to merge / convert.https://lists.apache.org/thread/8xscy9q0s8rqhsfovj03656zdh29qlnpOn Wed, Mar 12, 2025 at 12:55 PM Benedict Elliott Smith <bened...@apache.org> wrote:Hi Stefan,My reading of this mailing list thread is that they think clearspring is junk (probabl

Re: Inconsistent null handling between WHERE and IF clauses

ull as we might not know it’s > null till we do and LET clause, so null in operation becomes false is my > stance > > Sent from my iPhone > >> On Mar 24, 2025, at 10:46 PM, Benedict wrote: >> >> Modifying the behaviour for IF clauses is a major breaking ch

Re: [VOTE] CEP-46: Finish Transient Replication/Witnesses

+1On 12 May 2025, at 15:45, Josh McKenzie wrote:+1On Mon, May 12, 2025, at 10:41 AM, Jon Haddad wrote:+1On Mon, May 12, 2025 at 7:28 AM Ariel Weisberg wrote:Hi dev@, I would like to start the voting for CEP-46: Finish Transient Replication/Witnesses Proposal: https://cwiki.a

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

10:14 AM, Vivekanand Koya wrote:Sounds great. I would like to refactor the codebase (Trunk 5+) to eliminate unsafe explicit casting with instanceOf. Thanks,VivekanandOn Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith <bened...@apache.org> wrote:Yep, that approach seems more than sufficient

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

I think it doesn’t cost us much to briefly discuss new language features before using them. Lambdas, Streams and var all have problems - and even with the guidance we publish some are still misused. The flow scoping improvement to instanceof seems obviously good though. > On 9 May 2025, at 12:3

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I should add that I’m in favour of this proposal in principle, and support the proposal to utilise Paxos.On 9 May 2025, at 08:21, Benedict Elliott Smith wrote:I’d also like to explore a bit further the isolation guarantees we’re promising with "Strict Consistency Mode” - and the protocol de

Re: [DISCUSS] How we handle JDK support

There are performance differences between JVMs. I agree that bug testing of JVM versions for clients is not very important, but isolating JVM characteristic changes from database characteristic changes is important, for me at least.On 20 May 2025, at 17:47, Jon Haddad wrote:If you're upgrading an

Re: [DISCUSS] How we handle JDK support

In-jvm dtests need to execute an upgrade path on a single jvm, but this is close to always possible on the latest jvm. We haven’t hit any issues that I know of in this respect during any version change, so I don’t think this is a real concern.Some users do care about overlapping JVM compatibility.

Re: [DISCUSS] How we handle JDK support

Perhaps we should consider back porting support for newer Java LTS releases to older C* versions, and suggesting users upgrade JDK first. This way we can have trunk always on the latest LTS, advancing language feature support more quickly. That is, we would have something like N-2: JDK, JDK-

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Depending how long the grid structure takes to build, there is perhaps anyway value in being able to update the snapshot after construction, so that when the repair is performed it is as up to date as possible. But, I don’t think this is trivial? I have some ideas how this might be done but they ar

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

original proposal is incomplete without a better repair story and I’m not sure I’d support the cep if it proceeded as is.On Wed, May 21, 2025, at 12:22 PM, Benedict wrote:Depending how long the grid structure takes to build, there is perhaps anyway value in being able to update the snapshot after

Re: [DISCUSS] How we handle JDK support

needs at any time - we can’t do such breaking changes in a patch release.- Benedict made a great point on performance changes with JDK upgrades - we do not have regular performance testing so probably introducing a new JDK in a patch version will come with a huge warning - test thoroughly and move to

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

treams in hot paths >> >> On 31/5/24 9:48, Benedict wrote: >>> My concept of hot path is simply anything we can expect to be called >>> frequently enough in normal operation that it might show up in a profiler. >>> If it’s a library method then it’s re

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

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

Re: CASSANDRA-13241 lower default chunk_length_in_kb

gree with Sylvain (and I think Benedict) - there’s no compelling reason to > violate the freeze here. We’ve had the wrong default for years - add a note > to the docs that we’ll be changing it in the future, but let’s not violate > the freeze now. > > -- > Jeff Jirsa >

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

riguez > Sankalp Kohli (not explicit) > > -0: > Sylvaine Lebresne > Jeff Jirsa > > Not sure: > Kurt Greaves > Joshua Mckenzie > Benedict Elliot Smith > > WRT to change the representation: > > +1: > There are only conditional +1s at this point >

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

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

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

so far. > > I do disagree however that this adherence to a standard should be decided in > a vacuum. No decision should, this is bad project management in my book > and that is kind of why I want to insist on that point. We should be open > to all > relevant context. We can debat

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

Thanks Jo for the feedback too! I’ll keep my responses brief as there are already a lot of discussions in flight. > On 26 Nov 2018, at 16:24, Joseph Lynch wrote: > > Benedict, > > Thank you for putting this document together, I think something like this > will really impro

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

4 and consider promoting those. Anything < that only shows if people are > specifically looking for it." > > Taking count of occurrence of a label as a proxy for the potential value in > promoting it to something hardened isn't without flaws, but it's also not > aw

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

s covered here: > https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow > > ––– > > I also want to step back and thank Benedict and Kurt for all of their > analysis and information architecture work behind this propo

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

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

Re: JIRA Workflow Proposals

Thanks. I’ll respond inline with the thinking around the original proposal. > On 5 Dec 2018, at 20:26, Stefan Podkowinski wrote: > > Thanks Benedict and everyone involved putting up the proposal! It really > deserves some more feedback and I realize that I'm a bit late for th

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

tip. But at this point I’m happy to pre-emptively call it. > On 6 Dec 2018, at 13:55, Sam Tunnicliffe wrote: > > 1: A > 2: +1 > 3: +1 > 4: +1 > 5: +0 > 6: +1 > > On the question of keeping the contributors-only restriction on moving from > Triage->Open, I te

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

this discussion. > On 9 Dec 2018, at 03:03, Mick Semb Wever wrote: > > > >> Of course, if we remove Priority from the Bug type, I agree with others >> that the top level priority ceases to mean anything, and there probably >> shouldn’t be one. > > > Be

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

%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, B

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/

<    1   2   3   4   5   6   7   8   >