Re: [VOTE] Release Apache Cassandra 2.1.11

Regrettably, this does look like a possible problem. The test writes out an unpopulated SegmentedFile.Builder, i.e. that has no boundaries, which should not really happen in a live system (and is required for any problem to occur). However it looks like we do write out such an unpopulated set of bo

Re: Modifying Cassandra's threadpool queues

The SEPWorker manages its own count of available items that have been enqueued (but not yet dequeued), so it dequeues knowing there should be an item available; if there is not, your queue is swallowing them, either temporarily or permanently. So, in all likelihood (as you suggest), you simply hav

Re: Low compactionthroughput blocks reads?

Yep, definitely a bug. Introduced by CASSANDRA-9240 (me; mea culpa). I've filed a JIRA for you: CASSANDRA-11301 On 3 March 2016 at 14:10, horschi wrote: > Hi, > > I just found another one. Its basically the same, but I'll post it anyway: > > Thread 84311: (state = BLOCKED) > - java.lang.Thread

Re: COMPACT STORAGE in 4.0?

Compact storage should really have been named "not wasteful storage" - now everything is "not wasteful storage" so it's void of meaning. This is true without constraint. You do not need to limit yourself to a single non-PK column; you can have many and it will remain as or more efficient than "comp

Re: COMPACT STORAGE in 4.0?

As Jeremiah indicates, it's 3.0+ only. The docs should definitely reflect this On Mon, 11 Apr 2016 at 16:21, Jack Krupansky wrote: > Thanks, Benedict. Is this only true as of 3.x (new storage engine), or was > the equivalent efficiency also true with 2.x? > > It would b

Re: NewBie Question

For newcomers that ( https://github.com/apache/cassandra/blob/cassandra-3.0.0/guide_8099.md) is probably a bad document to point them to, as it will no doubt confuse them - the naming, behaviour and format descriptions are all now partially incorrect. It was, by its own admission, intended only fo

[VOTE] Release Apache Cassandra 3.8

I think -1 lacks a little clarity when responding to a block of prose with multiple clauses, suggestions and no single proposition requiring a yes/no answer. As fun as it is to type -1. On Thursday, 28 July 2016, Jake Luciani > wrote: > -1 > > On Thu, Jul 28, 2016 at 2:19 PM, Aleksey Yeschenko

Re: A proposal to move away from Jira-centric development

By this definition the Cassandra project is already compliant? There's a commits@ mailing list that behaves just as you describe. I'd personally like to see some reform with how these things work, but mostly because commits@ is rarely going to be subscribed to by anybody who isn't working full tim

Re: A proposal to move away from Jira-centric development

Unfortunately when rulebooks are consulted to shape this kind of discussion, their ambiguity begins to show. What does it mean for something "to happen" on a mailing list? It must be a loose interpretation, because clearly many things do not "happen" on the mailing list, such as all of the code d

Re: A proposal to move away from Jira-centric development

> -Original Message- > > From: Eric Stevens [mailto:migh...@gmail.com] > > Sent: Tuesday, August 16, 2016 06:10 > > To: dev@cassandra.apache.org > > Subject: Re: A proposal to move away from Jira-centric development > > > > I agree with Benedict that w

Re: A proposal to move away from Jira-centric development

become Datastax employees. > Not always of course, but a common pattern. It only makes sense for > Datastax to hire people who are interested in and capable of developing > Apache Cassandra. But the truth is a whole lot less sinister than the > inference. > > --dave > [not associa

Re: A proposal to move away from Jira-centric development

misinterpretation, as well as correcting the inevitable misinterpretations that happen anyway. But that's a major side track we shouldn't deviate down. On 16 August 2016 at 20:28, Eric Evans wrote: > On Tue, Aug 16, 2016 at 1:34 PM, Benedict Elliott Smith > wrote: > > This topic

Re: A proposal to move away from Jira-centric development

tain their life and sanity. On 16 August 2016 at 20:49, Eric Evans wrote: > On Tue, Aug 16, 2016 at 2:38 PM, Benedict Elliott Smith > wrote: > > I think all complex, nuanced and especially emotive topics are > challenging > > to discuss over textual media, due to th

Re: Proposal - 3.5.1

It's worth noting more clearly that 3.5 is an arbitrary point in time. All 3.X releases < 3.6 are affected. If we backport to 3.5, it seems like 3.1 and 3.3 should get the same treatment. I do recall commitments to backport critical fixes, but exactly what the bar is was never well defined. I a

Re: Proposal - 3.5.1

I agree tick-tock is a failure. But for two reasons IMO: 1) Ultimately, the users are the real testers and it takes a while for a release to percolate into the wild for feedback. The reality is that a release doesn't have its tires properly kicked for at least three months after it's cut. So if

Re: Proposal - 3.5.1

t; > The problem for me is going back to the old way doesn't sound great. > > There > > > are parts of tick-tock I really like, > > > for example, the cadence and limited scope per release. > > > > > > I know at the summit there were a lot of ideas

Re: Proposal - 3.5.1

Yes, agreed. I'm advocating a different cadence, not a random cadence. On Thursday, 15 September 2016, Tyler Hobbs wrote: > On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith < > bened...@apache.org > > wrote: > > > Feature releases don't have to b

Re: Use of posix_fadvise

... and continuing in the fashion of behaviours one might like to disabuse people of, no code link is provided. On 18 October 2016 at 16:28, Michael Kjellman wrote: > We use posix_fadvise in a bunch of places, and in stereotypical Cassandra > fashion no comments were provided. > > There is a c

Re: Use of posix_fadvise

This is what JIRA is for. It seems to date back to CASSANDRA-1470, where the default became immediately evicting newly compacted files. This results in cold reads for *hot* data after compaction, so CASSANDRA-6916 permitted evicting the *old* data instead, while guaranteeing >= the same amount of

Re: Use of posix_fadvise

and read thru a billion tickets to maybe understand why > something was done. Clearly thru the conversations on this topic I've had > on IRC and the responses so far on this email thread it's not/still not > obvious. > > best, > kjellman > > On Oct 18, 2016, at 10:0

Re: Moderation

Wow, that was quite the aggressive email. The thing is, it very much looks like the only reason you care about this delay is because Kellabyte is making the ASF board look bad on twitter. If it weren't the case, it seems unlikely such a "slow" 12hr response would receive board notice, let alone ir

Re: Moderation

:57, Chris Mattmann wrote: > > > On 2016-11-04 09:51 (-0700), Benedict Elliott Smith > wrote: > > Wow, that was quite the aggressive email. The thing is, it very much > looks > > like the only reason you care about this delay is because Kellabyte is > > making the ASF bo

Re: DataStax role in Cassandra and the ASF

ear ago), some other > did hurt users running cassandra for long time (ie. discontinuation of > thrift). Especially second decission was seen by outsiders, who do not > desire billion writes per second, as marketing driven. This led to people > looking and finding alternatives using comp

Re: DataStax role in Cassandra and the ASF

ubation phase, so the PMC > should understand how the project should be run, its not the boards job to > fix it directly. Did the board act unreasonably? I don't think so. Did some > heated discussions take place? Undoubtedly. > > > > On Sat, Nov 5, 2016 at 12:28 AM, Benedict

DataStax role in Cassandra and the ASF

inside your > project, we don’t pass judgement. To make us care you must have your > community speak with one voice. Demonstrate that you have consensus around > your opinions. Then, and only then, will the membership - the people who > vote for the board and hold them accountable – accept

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

Hi Ed, I would like to try and clear up what I perceive to be some misunderstandings. Aleksey is relating that for *complex* tickets there are desperately few people with the expertise necessary to review them. In some cases it can amount to several weeks' work, possibly requiring multiple peopl

Re: DataStax role in Cassandra and the ASF

aStax did a lot for Cassandra, but the public perception nowadays > seems to be that DataStax donated Cassandra to the ASF. This is not true. > It was created and contributed by Facebook > https://wiki.apache.org/incubator/Cassandramany years before DataStax was > even founded > > >

Re: DataStax role in Cassandra and the ASF

ic. So this is nothing which just > boiled up the last month - this really got pointed out amicably by the > board for a LONG time before _finally_ they took actions! > > > LieGrue, > strub > > > On Saturday, 5 November 2016, 14:42, Benedict Elliott Smith < > bened...@apa

Re: DataStax role in Cassandra and the ASF

Thanks Jeff, that was very well put. I would quibble on one point, though: the ship has never sailed on topics of community. How the board acts towards the PMC and companies in the community matters a great deal for continuing relations, as well as for other projects. The question is: did the bo

Re: Moderation

In summary: you claim to be someone with years of experience at the forefront of an organisation that conducts all of its business primarily over email. In that time you have not learned to express yourself over email in a manner that is not incendiary to those reading it, nor offensive to the int

Re: Review of Cassandra actions

Jim, I would love it if you could take the time to explain how arrived at a diagnosis of trolling. Aleksey made a well written, cogent and on-topic criticism of your ongoing behaviour, as well as a reasoned rebuttal of your absurd claim that your power is inherent to *you*, not your position (I d

Re: Moderation

eplying > to your messages anymore, at least on list. > > > On Nov 6, 2016, at 11:19 AM, Benedict Elliott Smith > wrote: > > > > In summary: you claim to be someone with years of experience at the > forefront of an organisation that conducts all of its business prim

Re: Review of Cassandra actions

what you consider well-written, cogent, > on-topic and reasoned, then I fear that any further discussion > is really worthless. > > o+o > > > On Nov 6, 2016, at 11:24 AM, Benedict Elliott Smith > wrote: > > > > Jim, > > > > I would love it if y

Re: Review of Cassandra actions

Hi Mark, Thanks, that was a calm and diplomatic email. recognise where they might need to apologise I will start the ball rolling here, as I have not always been generous in my interpretations of others' actions, and have certainly contributed to escalation. But I wonder if you would also help

Re: Proposal to retroactively mark materialized views experimental

This link is a helpful segway to another problem with MVs and defaults - the default behavioural unsafety we opt for by not writing through the batch log, opening far more windows for data inconsistency than the algorithm otherwise permits. Without a way to detect or repair these inconsistencie

Re: Proposal to retroactively mark materialized views experimental

While many users may apparently be using MVs successfully, the problem is how few (if any) know what guarantees they are getting. Since we aren’t even absolutely certain ourselves, it cannot be many. Most of the shortcomings we are aware of are complicated, concern failure scenarios and aren’t

Re: Proposal to retroactively mark materialized views experimental

dig in and understand the specifics of > any other features. So yes, I would prefer my bank to use MV’s as they are > today over rolling their own, and getting it even more wrong. > > Now, even given all that, if we want to warn users of the pit falls of using > MV’s, then lets

Re: Proposal to retroactively mark materialized views experimental

So, as the author of one of the disasters you mention (early re-open), I would prefer to learn from the mistake and not repeat it. Unfortunately we seem to be in the habit of repeating it, and that feature was a lot *lot* simpler. Let’s not kid ourselves: MVs are by far and away the most compli

Re: Proposal to retroactively mark materialized views experimental

ification and user > experience of features post-release sends a good message to said users; if > we all agreed unanimously that these features were this failure-prone and > high-risk, it would be more appropriate to make that change however that's > obviously not the case here. >

Re: Proposal to retroactively mark materialized views experimental

Can't we promote these behavioural flags to keyspace properties (with suitable permissions to edit necessary)? I agree that enabling/disabling features shouldn't require a rolling restart, and nor should switching their consistency safety level. I think this would be the most suitable equivalen

Re: Proposal to retroactively mark materialized views experimental

Kurt, we seem to be talking past each other. While I am concerned about implementation bugs - which I am certain still exist - I have not at any point raised this issue. My concerns have consistently been more fundamental - the basic properties of a theoretically bug-free MV are simultaneously

Re: duration based config settings

I'm strongly in favour of it; it's always bugged me, and I hadn't realised it might be contentious to implement. I'd be in favour of never retiring the _ms format though - it's almost free, there's no backward compatibility problems, and it's fairly intuitive so long as we're consistent about it.

Re: Getting partition min/max timestamp

We already store the minimum timestamp in the EncodingStats of each partition, to support more efficient encoding of atom timestamps. This just isn't exposed beyond UnfilteredRowIterator, though it probably could be. Storing the max alongside would still require justification, though its cost wou

Re: Getting partition min/max timestamp

(Obviously, not to detract from the points that Jon and Jeremiah make, i.e. that if TTLs or tombstones are involved the metadata we have, or can add, is going to be worthless in most cases anyway) On 14 January 2018 at 16:11, Benedict Elliott Smith wrote: > We already store the mini

Re: Getting partition min/max timestamp

a sizes, it's likely such a patch would be accepted. On 14 January 2018 at 20:33, arhel...@gmail.com wrote: > First of all, thx for all the ideas. > > Benedict ElIiott Smith, in code comments I found a notice that data in > EncodingStats can be wrong, not sure that its good idea

Re: Coordinator Write Metrics per CF

For the record, I'm not certain there *is* a great deal of value in this. The read latency metrics are expected to vary a great deal, since the entire IO subsystem is involved. Writes, however, go straight to a memtable. They only block on IO if we exceed our commit log flush bandwidth for an ex

Re: Coordinator Write Metrics per CF

Sorry, I guess I'm tired. I thought this was discussing local write latency. I'm surprised we have that and not coordinator write latency. Please do ignore me, I'm not sure why I got involved! On 13 February 2018 at 21:48, Benedict Elliott Smith wrote: > For the record, I&#

Re: Use of OpOrder in memtable

If you look closely, there can be multiple memtables extant at once. While all "new" writes are routed to the latest memtable, there may still be writes that have begun but not yet completed. The memtable cannot be flushed until any stragglers have completed, and some stragglers *may* still need

Re: Use of OpOrder in memtable

nd timestamp comparison etc.) > > -Original Message- > From: Benedict Elliott Smith [mailto:bened...@apache.org] > Sent: Tuesday, February 13, 2018 2:25 PM > To: dev@cassandra.apache.org > Subject: Re: Use of OpOrder in memtable > > If you look closely, there can be

Re: [DISCUSS] The way we log

at 12:35, Mick Semb Wever wrote: > > reply below… > > > On Thu, 30 May 2024 at 14:34, Štefan Miklošovič <mailto:stefan.mikloso...@gmail.com>> wrote: >> I see the feedback is overall positive. I will merge that and I will improve >> the documentation

Re: [DISCUSS] The way we log

t;>> reply below… >>> >>> >>> On Thu, 30 May 2024 at 14:34, Štefan Miklošovič >>> mailto:stefan.mikloso...@gmail.com>> wrote: >>>> I see the feedback is overall positive. I will merge that and I will >>>> improve the documen

Re: [jira] [Commented] (CASSANDRA-6746) Reads have a slow ramp up in speed

.org/jira/browse/CASSANDRA-6746 > > Project: Cassandra > > Issue Type: Bug > > Components: Core > >Reporter: Ryan McGuire > >Assignee: Benedict > > Labels: performance > > Fix For: 2.1 beta2 > >

Performance Tickets

It's only been six months since the last performance drive, and 2.1 is now around the corner. But I'm hoping we can push performance even further for 3.0. With that in mind, I've picked out what I think are the nearest term wins to focus on. - CASSANDRA-7039: DirectByteBuffer compatible LZ4 met

Re: Performance Tickets

and%20project%20%3D%20CASSANDRA%20AND%20status!%3Dresolved > > Benedict, you might want to un-assign from yourself anything you're > not working on in the near future in case anyone else wants to grab > one. > > On Tue, Apr 15, 2014 at 3:28 PM, Benedict Elliott Smith > wrote:

Re: Performance Tickets

> > - CASSANDRA-5220: Repair improvements when using vnodes That definitely deserves a "performance" tag. Yuki, are you looking at this or should we unassign in case somebody else wants to jump in? On 15 April 2014 14:59, Michael Shuler wrote: > On 04/15/2014 08:28 A

Re: CQL unit tests vs dtests

+1 unit tests On 21 May 2014 02:36, "Jake Luciani" wrote: > I think having cql unit tests is certainly a good idea. It doesn't replace > dtests but makes it easier to have better coverage locally. > > > On Tue, May 20, 2014 at 7:10 PM, Tyler Hobbs wrote: > > > Sylvain and I have been having a d

Re: CMS GC / fragmentation / memtables etc

Graham, This is largely fixed in 2.1 with the introduction of partially off-heap memtables - the slabs reside off-heap, so do not cause any GC issues. As it happens the changes would also permit us to recycle on-heap slabs reasonable easily as well, so feel free to file a ticket for that, althoug

Re: [jira] [Assigned] (CASSANDRA-7120) Bad paging state returned for prepared statements for last page

We need to add 7245 to that list. I'll try to get to it tomorrow. On 21 May 2014 17:40, Tyler Hobbs (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/CASSANDRA-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Tyler Hobbs reassigned CASSANDRA-7120: > ---

Re: CQL unit tests vs dtests

I would for defining the cql tests in a way that permits them being run as both dtests and unit tests. But since we're on python for dtests that could be troublesome. On 22 May 2014 17:03, Jeremiah D Jordan wrote: > The only thing I worry about here is that the unit tests don't come into > the

Re: CMS GC / fragmentation / memtables etc

en shelved for the moment. On 15 Jun 2014 10:53, "graham sanderson" wrote: > Hi Benedict, > > So I had a look at the code, and as you say it looked pretty easy to > recycle on heap slabs… there is already RACE_ALLOCATED which keeps a > strongly referenced pool, however

Re: CMS GC / fragmentation / memtables etc

answerable from memtable, and write amplification is reduced accordingly, improving write throughput. On 15 Jun 2014 13:32, "graham sanderson" wrote: > Hi Benedict, > > Ah, my mistake, I had assumed that since the memory backing the off heap > ByteBuffer Regions was freed on dis

Re: CMS GC / fragmentation / memtables etc

ou will be able to tune accordingly if your data is consistent. On Sun, Jun 15, 2014 at 11:52 PM, graham sanderson wrote: > Hi Benedict thanks once again for your explanations (hopefully these are > my last questions!)… I just read > https://issues.apache.org/jira/browse/CASSANDRA-6694

Re: 2.1 rc3?

Pretty sure we got this head of the hydra. Question is if any more will spring up in its place. On Wed, Jul 2, 2014 at 7:28 PM, Jonathan Ellis wrote: > https://issues.apache.org/jira/browse/CASSANDRA-7465 is a pretty big > one, I'd like to get some more testing with the fix before rolling > -fi

Re: 2.1 rc3?

gt; wrote: > > Also putting my 2 cents in for more testing/another release. > > > >> On Jul 5, 2014, at 4:31 PM, "Jason Brown" wrote: > >> > >> +1 on more testing. TBH, I was a little scared when I found #7465 as it > was > >> rathe

Re: Hinted Handoff/Atomic Updates & SnapTree replacement with BTree

This discussion is probably better had on JIRA, but I favour an asynchronous approach permitting only one modifying thread access to the structure at a time, with each competing modification simply chaining their to-be-merged state to a pending-list, which is repaired at read time if it isn't merge

Re: [VOTE] Release Apache Cassandra 2.1.0-rc6

I'd prefer to patch CASSANDRA-7743 first. On Wed, Aug 13, 2014 at 10:47 PM, Brandon Williams wrote: > +1 > On Aug 13, 2014 7:33 AM, "Sylvain Lebresne" wrote: > > > I propose the following artifacts for release as 2.1.0-rc6. As it is > "just > > a > > RC", we'll keep the vote to a short 24h. >

Re: Assigning tickets

Done On Fri, Sep 5, 2014 at 4:34 PM, Jay Patel wrote: > Hi Folks, > > Seems like I'm not able to assign this tix to myself. Can anyone help to > assign to me? These all are actually related but I opened as separate just > to track. > > CASSANDRA-7882

Re: [VOTE] Release Apache Cassandra 2.1.0

I've just commited 7519, which would be nice (but not essential) to include in 2.1.0, since it has breaking changes to the stress API Also, not sure if this is just me missing something obvious, and is probably minor to fix, but ant fails to compile on org.apache.cassandra.hadoop.cql3.LimitedLocal

Re: [contrib] Idea/ Reduced I/O and CPU cost for GET ops

Hi Mark, This specific heuristic is unlikely to be applied, as (if I've understood it correctly) it has a very narrow window of utility to only those updates that hit *exactly* the same clustering columns (cql rows) *and *data columns, and is not trivial to maintain (either cpu- or memory-wise). H

Re: [VOTE] Release Apache Cassandra 2.1.0

Fair enough (and yes, it did) On Mon, Sep 8, 2014 at 2:40 PM, Sylvain Lebresne wrote: > On Sep 7, 2014 4:41 PM, "Benedict Elliott Smith" < > belliottsm...@datastax.com> > wrote: > > > > I've just commited 7519, which would be nice (but not essentia

Re: Use of System.exit() calls

There are some places we are unlikely to drop using System.exit(), such as when we detect a dangerous application state (e.g. OOM) However in config (e.g. DatabaseDescriptor) it's just because we haven't considered it worth our time to do anything more involved. Feel free to file a ticket and post

Re: Conditional Update Code?

It's quite possible support could be added to evaluate a UDF as part of the condition check. The code you're looking for are implementors of CASRequest.appliesTo(), in CQL3CasRequest and CassandraServer.ThriftCASRequest It seems like https://issues.apache.org/jira/browse/CASSANDRA-8488 would offer

Re: [discuss] Modernization of Cassandra build system

I think the problem is everyone currently contributing is comfortable with ant, and as much as it is imperfect, it isn't clear maven is going to be better. Having the requisite maven functionality linked under the hood doesn't seem particularly preferable to the inverse. The status quo has the bonu

Re: [discuss] Modernization of Cassandra build system

d to it, so it's not needed to make something > more flexible, even if it could facilite external contribution. > > > > 2015-03-31 23:42 GMT+02:00 Benedict Elliott Smith < > belliottsm...@datastax.com>: > > > I think the problem is everyone currently contributing i

Re: March 2015 QA retrospective

he ticket so that these scenarios are amongst those explicitly considered when we address it, but I expect the scope of that ticket to be very broad, and probably introduce its own entire class of subtickets. > Thanks, > Ariel > > On Fri, Apr 10, 2015 at 8:04 AM, Benedict Elliott Smi

Re: Download source release / binary files in source release

> When I did download the the 3.11.10 release [2], I can see that it contained > compiled binary files (jars), which I don't think is in line with ASF release > policy. Could you clarify why you think this is incompatible with ASF policy? AFAICT the policy only stipulates that binary releases _

Re: Download source release / binary files in source release

> I suggest you read the whole thread. The outcome was that it's OK to put jars > in version control but not in a source release. There was no outcome AFAICT? There was a suggestion that was explicitly caveated as only a suggestion that required formal approval by VP Legal, which does not seem

Re: Download source release / binary files in source release

> Because a source release could not contain compiled code Again, I don't see this stated explicitly. Perhaps the guidance should be clarified if this is the intention? On 27/03/2021, 01:59, "Justin Mclean" wrote: Hi, > Could you clarify why you think this is incompatible with ASF po

Re: Download source release / binary files in source release

> Including Category B binaries in a source release is mentioned in ASF policy > here [1]. Sorry to keep banging the same drum, but I read this before our earlier emails, and if this is the intended meaning it needs to be rewritten. I also doubt this was the intended meaning of the original aut

Re: Download source release / binary files in source release

Hi Justin, You are probably right, but as far as I am aware you are not an official source of ASF policy on this matter. The official policy pages do not stipulate this, so I would appreciate if you could get them updated to accord more clearly your beliefs before the project makes the necessar

Re: Download source release / binary files in source release

> I guess you are asking for something official from VP Legal Affairs or the > ASF board? If so I can make that happen. I would prefer the official policy pages to be updated to have a clear statement on this, so this problem can be solved in perpetuity. > IMO it does, the project can choose to

Re: Download source release / binary files in source release

I thought you had indicated you were anyway raising this with the board? Either way, I don't personally see any issue with delaying the vote by a week or so if it will bring some official clarity to this issue, now it has been raised. How quickly can we expect to see changes reflected in the off

Re: Download source release / binary files in source release

> This is not a retrospective change just a clarification on what should be > self evident. This is a non-sequitur surely? Can something that is self-evident need clarifying? Or do you suppose it is self-evident to all besides the feeble intellects of this community? I think a self-evident pol

Re: [DISCUSS] Releases after 4.0

+1 On 29/03/2021, 21:16, "Ben Bromhead" wrote: +1 good sensible suggestion. On Tue, Mar 30, 2021 at 7:37 AM Ekaterina Dimitrova wrote: > I also like the latest suggestion, +1, thank you > > On Mon, 29 Mar 2021 at 14:16, Yifan Cai wrote: > > > +1 > > >

Re: Download source release / binary files in source release

> I think the situation is a little more seriously that you may realise, I > suggest you look at what actions the board has taken in similar situations in > the past I thought you had already indicated the likely remedy: the removal of non-compliant releases? I’m puzzled by your desire f

Re: Download source release / binary files in source release

As I'm sure you're aware, only a couple of people in the community are able to follow or participate in board discussions without being expressly included. On 30/03/2021, 09:51, "Justin Mclean" wrote: Hi, JFYI I've started a discussion about this on the board list [1]. Note that that

Re: Download source release / binary files in source release

There is no legal reason; this was disavowed on LEGAL-288. The ostensible reason is that Roy Fielding, who filed the papers of incorporation, interprets the charter to require this. I don't think, however, anybody has challenged this interpretation of the charter. I certainly do not interpret it

Re: [DISCUSS] Releases after 4.0

> it would make sense to put that information on a *Roadmap* page That makes sense to me, and I'm looking forward to agreeing a roadmap. I think it will be nice for the project to start properly looking to the future again. On 01/04/2021, 14:06, "Benjamin Lerer" wrote: Thanks everybody.

Re: [DISCUSSION] Next release roadmap

nts and instance replacements get safer and >> faster. Schema changes can be made atomic, enabling users to execute DDL >> rapidly without waiting for convergence. Operations like expansions and >> shrinks become easier to automate with less care and feeding. >&g

Re: [DISCUSSION] Attracting new contributors

I think that all of the bootcamps we ran in the past produced precisely zero new contributors. I wonder if it would be more impactful to produce slightly more permanent content, such as step-by-step guides to producing a simple patch for some subsystem. Perhaps if people want to, a recording co

Re: [DISCUSSION] Attracting new contributors

t;problem" to have enough committers to look at it over a (preferably) shorter period of time and make that feedback loop shorter. That's it. You might have the best guides and whatever but if a dust settles at it no guide will make it happen. On Tue, 27 Apr 20

Re: [DISCUSSION] Attracting new contributors

; > > > > > I believe Paolo started with the project through a contributor boot > > > camp. > > > > > Also if I remember correctly some of the ones that were done were > > > > internal > > > > > at DataStax and it helped

Re: [DISCUSSION] Attracting new contributors

lost doing, or easy to misunderstand. I'm definitely open to improving the terminology, but we did bike shed this all only a year or so ago I think? On 27/04/2021, 16:20, "Paulo Motta" wrote: Thanks for bringing the definitions and historical context Benedict. Agreed

Re: [DISCUSSION] Attracting new contributors

bring it on its own thread later so we don't go too far away from the original, and more important, topic which is how to attract and retain new contributors to the project. Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith < bened...@apache.org> escreveu:

Re: [DISCUSSION] Attracting new contributors

ormal. - Ultra-Violence - Hard. - Nightmare - Very Hard. - On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith wrote: > Perhaps we could replace both Complexity and Difficulty with e.g. > Experience? > > Newcomer > Learner

Re: [DISCUSSION] Update complexity levels

e it's very simple and unambiguous, while providing a lot of value to new contributors to find out suitable tasks to work on. Em ter., 27 de abr. de 2021 às 15:23, Patrick McFadin escreveu: > I have to admit, I like those Duke Nukem levels way more than I should. I > g

Re: [DISCUSSION] Attracting new contributors

I think there are two main hurdles, one is restoring contributor interest in mentoring, and the other is finding newcomers that actually want to stick around. These are perhaps two sides of the same coin, though. An ugly truth is that it isn't very enjoyable or rewarding to help newcomers when t

Re: [DISCUSSION] Attracting new contributors

board to help to track newcomers contributions: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463&quickFilter=2088 Apparently Brandon is cheating to appear as a newcomer but we will solve that. He should be at the Nightmare level ;-) Le mer. 28 avr. 2021 à

Re: [DISCUSSION] Attracting new contributors

Thanks Aleksei, Some of these are great points, but to respond specifically to the checkstyle suggestion: I hope to kick off some (minor) discussion around codestyle soon to modernise our guide, however I would personally prefer that code style enforcement remains relatively light touch. Some o

Re: [DISCUSS] Semantic versioning after 4.0

+1 to semver, shippable trunk, feature flags, and better documentation about feature support and compatibility edges - we should have a single page with a table of version x feature, with a summary and links to detailed explanations of everything important a user should be aware of. I didn't re

<    2   3   4   5   6   7   8   >