Re: [VOTE] Development Approach for Apache Cassandra Management process

> > It is important we make progress as we have been discussing this since > April!! The discussion was making progress. Just because you want things to happen faster is no reason to force an early vote. On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli wrote: > Also my vote is same as Jeff. d bu

Re: [VOTE] Development Approach for Apache Cassandra Management process

should vote? Why was the thread dead for months and > someone comes back with a contribution and then people starts talking? > > I would have happily waited for few more days!! > > > > On Wed, Sep 12, 2018 at 2:09 PM Joshua McKenzie > wrote: > > > > > > >

Re: [VOTE] Development Approach for Apache Cassandra Management process

> Also discussion thread is ongoing from April and not last 4 days. If enough > people think it is rushed, we can always revote. > > On Wed, Sep 12, 2018 at 2:24 PM Joshua McKenzie > wrote: > > > That was four days ago, and I have a newborn at home. Not a lot of time > for

Re: Measuring Release Quality

I've spent a good bit of time thinking about the above and bounced off both different ways to measure quality and progress as well as trying to influence community behavior on this topic. My advice: start small and simple (KISS, YAGNI, all that). Get metrics for pass/fail on utest/dtest/flakiness o

Moving tickets out of 4.0 post freeze

We have quite a few tickets still flagged for 4.0 that aren't in keeping with the idea that the code is frozen: https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20(fixversion%20%3D%204.0%20OR%20fixversion%20%3D%204.0.0)%20and%20resolution%20%3D%20unresolved%20and%20type%2

Re: CASSANDRA-13241 lower default chunk_length_in_kb

> > The predominant phrased used in that thread was 'feature freeze'. At the risk of hijacking this thread, when are we going to transition from "no new features, change whatever else you want including refactoring and changing years-old defaults" to "ok, we think we have something that's stable,

Re: CASSANDRA-13241 lower default chunk_length_in_kb

gt; > >>>> To summarize who we have heard from so far > >>>> > >>>> WRT to changing just the default: > >>>> > >>>> +1: > >>>> Jon Haddadd > >>>> Ben Bromhead > >>>> Alain

Re: CASSANDRA-13241 lower default chunk_length_in_kb

ilitate a collective decision. > > > > > > > > On 24 Oct 2018, at 16:27, Joshua McKenzie wrote: > > > > | The risk from such a patch is very low > > If I had a nickel for every time I've heard that... ;) > > > > I'm neutral on the default

Re: Request to review feature-freeze proposed tickets

> If those tickets were sitting in patch available state prior to the freeze they *should* get in. 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 ch

Re: Request to review feature-freeze proposed tickets

Strong +1 on prioritizing community engagement 1st and caution second, though still prioritizing it. I think the right metric for us to calibrate around is that "disrupt in-flight testing cycles", i.e. if changes cause significant rework for people that have already begun testing 4.0, probably ok t

Re: JIRA Workflow Proposals

1) Removal of labels: one of the strengths of the current model is flexibility for groupings of concepts to arise from a user-perspective (lhf, etc). Calcifying the label concepts into components, categories, etc. is a strict loss of functionality for users to express and categorize their concerns

Re: JIRA Workflow Proposals

d have few fields mandatory like platform, > version, etc. We want to put less burden on someone creating a ticket but I > feel these are required for opening bugs. > > > > 2. What is the flow when a non committer does the first pass of review? > > > > > > > &

Re: JIRA Workflow Proposals

n active process to promote good hygiene. > > But who said our state of mind isn’t also important :) > > This isn’t something I’ll fight hard for, though, I can see it’s at least > partially a preference for cleanliness. Interested to see what others > think. > > > On 26

Re: JIRA Workflow Proposals

like a fine outcome. > > >>> > > >>> – On Sankalp’s question of issue reporter / new contributor burden: I > > >> actually think the pruning of fields on the “new issue form” makes > > >> reporting issues easier and ensures that information we

Re: [VOTE] Change Jira Workflow

+1 On Tue, Dec 18, 2018 at 7:30 AM Aleksey Yeshchenko wrote: > Sure, +1 > > > On 18 Dec 2018, at 09:42, Joseph Lynch wrote: > > > > +1 non-binding > > > > On Tue, Dec 18, 2018 at 1:15 AM Sylvain Lebresne > wrote: > > > >> +1 > >> -- > >> Sylvain > >> > >> > >> On Tue, Dec 18, 2018 at 9:34 AM O

Re: Warn about SASI usage and allow to disable them

+1 on config change, +1 on disabling, and so long as the comments make the limitations and risks extremely clear, I'm fine w/out the client warning. On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña wrote: > I mean disabling the creation of new SASI indices with CREATE INDEX > statement, the ex

Re: Commit-log structure changes - versions

You'll probably see the bulk of changes in CommitLogReader.java:CommitLogFormat . I tried to limit the dependencies on any internals of the CommitL

Re: Audit logging to tables.

One of the things we've run into historically, on a *lot* of axes, is that "just put it in C*" for various functionality looks great from a user and usability perspective, and proves to be something of a nightmare from an admin / cluster behavior perspective. i.e. - cluster suffering so you're wri

Re: Audit logging to tables.

entries. > > > > Dinesh > > > > > On Feb 28, 2019, at 6:41 AM, Joshua McKenzie > > wrote: > > > > > > One of the things we've run into historically, on a *lot* of axes, is > > that > > > "just put it in C*" for vario

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

; > (FWIW, I remain in favour of limiting anonymous users) > > > > > >> On 19 Mar 2019, at 13:35, Joshua McKenzie wrote: > >> > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >

Re: Jira: Author Field

What problem are we trying to solve w/this proposed change? Is the thinking for live querying of things in progress, or is the thinking 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 th

Re: Jira: Author Field

, allows to more accurately reflect on the ticket > who contributed in what capacity. > > > On 8 Apr 2019, at 14:01, Joshua McKenzie wrote: > > > > What problem are we trying to solve w/this proposed change? > > > > Is the thinking for live querying of things

Re: Stabilising Internode Messaging in 4.0

As one of the two people that re-wrote all our unit tests to try and help Sylvain get 8099 out the door, I think it's inaccurate to compare the scope and potential stability impact of this work to the truly sweeping work that went into 8099 (not to downplay the scope and extent of this work here).

Re: Stabilising Internode Messaging in 4.0

> > a couple of people (even if I know them personally, > consider them friends and are both among the best engineers i've ever > met) going off in a room and producing something in isolation is more > or less a giant "f*k you" to the open source process and our community > as a whole. Two enginee

Re: Jira Updates

I have no useful feedback on the changes (haven't had a chance to test them, probably won't soon) - just wanted to say thanks for taking point on this Benedict. On Tue, Apr 16, 2019 at 6:23 AM Benedict Elliott Smith wrote: > Some exciting news from the Jira changes (maybe). > > We’re done! We’v

Re: Jira Suggestion

+1 here, though I also liked it when people made it an href in comments so my lazy ass busy and efficient self could click it. =/ 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

Re: Jira Suggestion

again! On Wed, May 15, 2019 at 9:19 AM Benedict Elliott Smith wrote: > I should clarify that by “cleanly formatted link to GitHub” I meant > supporting exactly this. > > > On 15 May 2019, at 14:17, Joshua McKenzie wrote: > > > > +1 here, though I also liked it when pe

Re: Running 4.0 (trunk) on Windows

> > there is no plan from Cassandra Devs to normally support Windows in > Cassandra 4.0 I was the dev kind of single-handedly making it work on Windows; it was good up through the 3.X line but I didn't maintain it past that point to 4.0+ and don't have plans to. Reason being: the WSL approach 100

Re: Review ApacheCon Cassandra track submissions

1) How about we have entire PMC vote on talks? 2) We need to do t-shirts. :) Do we need corporate sponsorship for that (i.e. $$)? I can look into that if so. On Tue, May 21, 2019 at 12:28 AM Nate McCall wrote: > Hi Folks, > As you probably know, the ApacheCon NA CFP recently closed. We received

Re: Review ApacheCon Cassandra track submissions

Re-reading that, I realize I probably need to clarify: 1) Entire PMC *+ anyone else who wants to volunteer* vote on talks. Not just PMC. On Tue, May 21, 2019 at 8:48 AM Joshua McKenzie wrote: > 1) How about we have entire PMC vote on talks? > 2) We need to do t-shirts. :) Do we need cor

Re: Review ApacheCon Cassandra track submissions

e ASFs review system > for which you need an ASF account. (If someone had commit access on another > project and wanted to participate , I’d be cool with that). > > On Tuesday, May 21, 2019, Joshua McKenzie wrote: > > > Re-reading that, I realize I probably need to clarify: > >

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

> > The unofficial rule is to not upgrade to prod till .10 is cut. FWIW, I believe it's historically .6. Which is still not a great look for the project. There's a ton of work going into testing 4.0 already. While I intuitively and anecdotally (from the people I've backchanneled with) believe th

Re: [DISCUSS] Moving chats to ASF's Slack instance

+1 to switching over. One less comms client + history + searchability is enough to get my vote easy. On Tue, May 28, 2019 at 5:52 PM Jonathan Ellis wrote: > I agree. This lowers the barrier to entry for new participants. Slack is > probably two orders of magnitude more commonly used now than i

Re: [VOTE] remove the old wiki

Before I vote, do we have something analogous to this: https://wiki.apache.org/cassandra/ArchitectureInternals In the new wiki / docs? Looks like it's a stub: https://cassandra.apache.org/doc/latest/architecture/overview.html Having an architectural overview landing page would be critical before s

Re: [VOTE] remove the old wiki

Is there any other good info we should gather and include in the wiki / docs? Thinking of our bootcamp material a bunch of us put together back in the day (link: https://www.slideshare.net/joshmckenzie) Might be helpful to identify a backlog of stuff we'd like to collect and integrate and have pe

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

has been a lot of progress here, but I’ve let perfect > > be the enemy of the good in getting updates out. I’ll complete that pass > > later this week. > > > > Cheers, > > > > — Scott > > > > > On May 28, 2019, at 10:48 AM, Dinesh Joshi wrot

Re: Apache Cassandra Virtual meetings

The one thing we need to keep in mind is the "If it didn't happen on a mailing list, it didn't happen " philosophy of apache projects. Shouldn't constrain us too much as the nuance is: *"Discussions and plan proposals often happen at events, in chats (Slack, IRC,

Re: 4.0 alpha before apachecon?

> > dynamic snitch improvements, fixing token counts > they're small enough By what axis of measurement out of curiosity? Risk to re-test and validate a final artifact? Do we have a more clear understanding of what testing has taken place across the community? The last I saw, our documented t

Re: Stability of MaterializedView in 3.11.x | 4.0

> > so we need to start migration from MVs to manual query base table ? Arguably, the other alternative to server-side denormalization is to do the denormalization client-side which comes with the same axes of costs and complexity, just with more of each. Jeff's spot on when he discusses the ris

Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process

All too often, a work-invalidating insight hits late in a cycle while people are talking about something and significant work has been done on the invalidated proposal. A CEP up front with engagement from a bunch of parties may very well help surface those design implications sooner, but we also ha

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

> > >>>>> final stages of the release on gathering feedback from users + > >> > > >>> developers > >> > > >>>>> to validate tooling and automation; compatibility with less > >> > > >>> commonly-used > >> >

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

; decision-making on the project. I think codifying the rules of the project > would help as a starting point, but also simply recognising that > participation in decision-making is costly, and that proposers should > understand that they need to work to lower the cost of decision-making o

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

> a committer). Lazy consensus appears to have been intended to operate > primarily for code modifications (given the examples and caveats), and > seems problematic for larger decisions, particularly procedural ones. > > These are all further reasons to codify our project governance, as

Re: time for a release?

+1 from me. On Fri, Oct 4, 2019 at 4:47 PM DuyHai Doan wrote: > +1 too (non binding) > > On Fri, Oct 4, 2019 at 10:33 PM Scott Andreas > wrote: > > > > +1nb for me for the 3.x releases. > > > > The user-facing issues resolved in 2.2 are slimmer and relatively minor > (just 15225, 15050, 15045,

Re: [VOTE-2] Apache Cassandra Release Lifecycle

+1 Don't have comment rights on the confluence article (or am too dense to figure out _how_ to leave a comment). There's some stringency surrounding clean CI + no flaky tests that I think bear further discussion; for what it's worth I'm 100% in support of having hard gatekeeping so quality doesn't

Re: [VOTE-2] Apache Cassandra Release Lifecycle

It probably warrants a separate discussion about how we version. Also, robust +1 to what you said here bes and haddad ;) On Tue, Oct 8, 2019 at 5:31 PM Jon Haddad wrote: > This has definitely been a confusing topic in the past, I completely agree > Benedict. Glad you brought this up. > > I'm

Re: Protocol-impacting (internode and client) changes for 4.0

> > each one of them is extremely low risk, which means that any validation > effort that has already happened won't have to be re-done +1 On Wed, Oct 9, 2019 at 1:46 PM Jon Haddad wrote: > Seems reasonable, especially since we're in alpha mode. > > On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshc

Re: Improving our frequency of (patch) releases, and letting committers make releases

Might make sense to split the difference and have a loose reactive policy of "consider / discuss a potential release when any of the following are hit": 1. something critical is merged (data loss fix, cluster down fix, etc) 2. there are changes to the branch 3. it's been weeks since the

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

+1 On Thu, Oct 24, 2019 at 4:19 PM Dinesh Joshi wrote: > +1 > > Dinesh > > > On Oct 24, 2019, at 10:26 AM, Michael Shuler > wrote: > > > > I propose the following artifacts for release as 4.0-alpha2. > > > > sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55 > > Git: > https://gitbox.apache.org/rep

Re: [VOTE] Release Apache Cassandra 3.11.5

+1 On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote: > +1 > > > On Fri, Oct 25, 2019 at 6:26 AM Michael Shuler > wrote: > > > I propose the following artifacts for release as 3.11.5. > > > > sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7 > > Git: > > > > > https://gitbox.apache.org/repos/asf?p

Re: [VOTE] Release Apache Cassandra 2.2.15

+1 On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote: > +1 > > > On Fri, Oct 25, 2019 at 6:25 AM Michael Shuler > wrote: > > > I propose the following artifacts for release as 2.2.15. > > > > sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086 > > Git: > > > > > https://gitbox.apache.org/repos/asf?p

Re: [VOTE] Release Apache Cassandra 3.0.19

+1 On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote: > +1 > > > On Fri, Oct 25, 2019 at 6:31 AM Michael Shuler > wrote: > > > I propose the following artifacts for release as 3.0.19. > > > > sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0 > > Git: > > > > > https://gitbox.apache.org/repos/asf?p

Re: putting the alphas on the website downloads section

Is there an opportunity to consider a separate "upcoming release testing" type page with downloads to alpha releases? Sounds like, as per letter of the law, we wouldn't that on the official project page but getting something going where we can have project-wide "test out this alpha" or where indivi

Re: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

+1 On Mon, Nov 4, 2019 at 3:55 PM Ben Bromhead wrote: > +1 > > On Mon, Nov 4, 2019 at 10:56 AM Vinay Chella > wrote: > > > +1 > > > > -Vinay Chella > > > > On Sat, Nov 2, 2019 at 5:09 PM Jeff Carpenter > > > wrote: > > > > > FYI the audio of the session with Ben Bromhead / Scott Andreas is > >

Re: CommitLogReaderTest

Hey Angelo. Here's my suspicion - only had a brief time to poke at this this morning but it might help you bottom out on this. In short: I think the logic in the test is flawed, and that the Assert.assertEquals check should instead do a >= check against total mutations read from midpoint. The test

Re: Cassandra CI Status

Thanks for taking this on Mick. We had roughly 7 jenkins slaves DS had donated languish I'm looking into (came up on slack yesterday morning) so hopefully we'll have some more resources back in the pool soon. One other thing we've seen repeatedly over the years is startlingly low-hanging-fruit of

Offering some project management services

Hey all, I've recently had some cycles free up I can dedicate to the open-source project. My intuition is that I can add the most value right now by engaging in some simple project management type work (help get assignees and reviewers for things critical path for 4.0, help stimulate and facilitat

Re: Cassandra CI Status

> > On my 16gb quad i7 laptop dtests take 4-5 hours Hm. This is actually faster than I'd have expected so that's a positive for my Friday :). Makes me wonder how things would behave on one of the new threadrippers w/PCIe-4. And yes, I'm looking for excuses to get one of those. On Fri, Jan 10, 20

Re: Offering some project management services

k that is > necessary for 4.0, and is executing on it as quickly as resources allow. > > > On 10/01/2020, 16:18, "Joshua McKenzie" wrote: > > Hey all, > > I've recently had some cycles free up I can dedicate to the open-source > project

Re: Offering some project management services

If I gave the impression I was advocating for just plopping tickets on people as assignees that was a significant miscommunication on my part. My mental model is to go back to the Jirsa approach of a pulsed status update with a list of open unassigned tickets and call for volunteers on the dev lis

Re: Offering some project management services

re there aren’t any critical bug reports around that > slipped through past triage attempts. > > > > > On Jan 10, 2020, at 8:18 AM, Joshua McKenzie > wrote: > > > > Hey all, > > > > I've recently had some cycles free up I can dedicate to the open-sou

Cassandra 4.0 Dev Work Status

Hello and welcome to our kickoff email about the 4.0 release work status. Structure and contents are fluid; if you'd like to see, or not see, something, please reply and let me know as my goal is purely to help meet the needs of our dev community here. My initial thinking is to send this out weekly

Re: Cassandra 4.0 Dev Work Status

Apparently the formatting on this got straight borked. I may try sending subsequent emails from my personal gmail instead of my @apache address to see if that keeps the rich-text formatting. Sorry for the ugliness. ;) On Tue, Jan 14, 2020 at 10:27 AM Joshua McKenzie wrote: > Hello and welc

Re: Cassandra 4.0 Dev Work Status

Historically I believe we used the ".x" nomenclature to indicate general release we wanted things in (4.x, 3.11.x, 3.6.x, etc), and then upon merge update the FixVersion to reflect which release it actually went in. Is that still a thing, and whether a thing or not, is the current appropriate usage

Re: Cassandra CI Status

> > - parallelise dtests (because 12 hours is wild) That's one word for it. :) We used to ad hoc take a crack at sorting the individual test times by longest and taking top-N and seeing if there was LHF to shave off that. Being on a flight atm, not having that data handy right now, and that not

Re: [DISCUSS] Switch to using GitHub pull requests?

> > I am reacting to what I currently see > happening in the project; tests fail as the norm and this is kinda seen as > expected, even though it goes against the policies as I understand it. After over half a decade seeing us all continue to struggle with this problem, I've come around to the sch

Re: Update defaults for 4.0?

> > I'm unable to create an epic in the project - not sure if that has to do > with project permissions. Could someone create an epic and link these > tickets as subtasks? Just realized I can no longer create epics anymore (or the "new" JIRA UI is just so obtuse I can't figure it out. I give it

Re: Cassandra CI Status

> > an entry in the progress report? That'd be slick. I've had some people pinging me on slack asking about the easiest way to get involved with the project and ramp up, and I think refactoring and cleaning up a dtest or two would be another vector for people to get their feet wet. I like it! On

Re: [DISCUSS] Switch to using GitHub pull requests?

g and gating commits > >> Every release there’s a thread on testing and gating commits > >> > >> People are the common factor every time. Nobody wants to avoid > merging their patch because someone broke a test elsewhere. > >> > &

Re: [DISCUSS] Switch to using GitHub pull requests?

gt; IMO, we should email dev@ if there are failing runs for trunk, and there > should be a rotating role amongst the contributors to figure out who broke > it, and poke them to fix it (or to just fix it, if easy). > > > On 24/01/2020, 14:57, "Joshua McKenzie" wrote: >

4.0 release status progress report, 2020/1/30

Got a 4.0 progress update for everyone: First off, the 4.0 board can be found at https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355. The broad view: We have a total of 95 tickets open for 4.0 releases: https://issues.apache.org/jira/issues/?filter=12347896 One report I often fin

Re: 4.0 release status progress report, 2020/1/30

> > I opened an infra ticket this morning Well that was quick (it's done). I'll be setting up that test epic today. On Thu, Jan 30, 2020 at 11:46 AM Joshua McKenzie wrote: > Got a 4.0 progress update for everyone: > > First off, the 4.0 board can be found at > ht

Testing out JIRA as replacement for cwiki tracking of 4.0 quality testing

>From my 4.0 status progress email earlier today, we still have quite a few testing initiatives that are lacking Shepherds or tracking tickets in JIRA: [Areas needing Shepherds] - 6 ... [Areas needing tracking tickets] - 11 ... I went ahead and tried out the format of creating an epic in JIRA as

Re: [VOTE] Release Apache Cassandra 4.0-alpha3

+1 On Thu, Jan 30, 2020 at 4:31 PM Brandon Williams wrote: > +1 > > On Thu, Jan 30, 2020 at 1:47 PM Mick Semb Wever wrote: > > > > Proposing the test build of Cassandra 4.0-alpha3 for release. > > > > sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29 > > Git: > https://gitbox.apache.org/repos/asf?

Re: [Discuss] num_tokens default in Cassandra 4.0

> > We should be using the default value that benefits the most people, rather > than an arbitrary compromise. I'd caution we're talking about the default value *we believe* will benefit the most people according to our respective understandings of C* usage. Most clusters don't shrink, they stay

Re: Testing out JIRA as replacement for cwiki tracking of 4.0 quality testing

> > what we really need is > some dedicated PM time going forward. Is that something you think you can > help resource from your side? Not a ton, but I think enough yes. (Also, thanks for all the efforts exploring this either way!!) Happy to help. On Sun, Feb 2, 2020 at 2:46 PM Nate McCall wro

Re: Testing out JIRA as replacement for cwiki tracking of 4.0 quality testing

>From the people that have modified this page in the past, what are your thoughts? Good for me to pull the rest into JIRA and we redirect from the wiki? +joey lynch +scott andreas +sumanth pasupuleti +marcus eriksson +romain hardouin On Mon, Feb 3, 2020 at 8:57 AM Joshua McKenzie wrote: >

Re: Do we need Javadoc in binary distribution? Was: [RELEASE] Apache Cassandra 4.0-alpha3 released

+1 to removing javadoc from the distro from me. On Sat, Feb 8, 2020 at 9:24 AM Michael Shuler wrote: > I like this idea for keeping binary deployment size down. I'm not sure > how to handle it for the tarballs, but we could certainly split the docs > out of the debian and rpm packages to add > c

2/10/2020 4.0 status update

2/10/2020: Today's 4.0 status update: The 4.0 board can be found at https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355. The broad view: We have a total of 95 tickets open for 4.0 releases (No change from 11 days ago, though 5 are cwiki migration tests): https://issues.apache.org/

Re: [Discuss] num_tokens default in Cassandra 4.0

> > Discussions here and on slack have brought up a number of important > concerns. Sounds like we're letting the perfect be the enemy of the good. Is anyone arguing that 256 is a better default than 16? Or is the fear that going to 16 now would make a default change in, say, 5.0 more painful? O

Re: Testing out JIRA as replacement for cwiki tracking of 4.0 quality testing

JIRA approach? Thanks. ~Josh On Mon, Feb 3, 2020 at 3:39 PM Joshua McKenzie wrote: > From the people that have modified this page in the past, what are your > thoughts? Good for me to pull the rest into JIRA and we redirect from the > wiki? > +joey lynch > +scott andreas >

20200303 4.0 Status Update

Hello project! Time (well, one day late. Sorry. =/) for our weekly check-in, and I'm up this week. Link to JIRA board: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA We've had 4 tickets open in the past week: https://issues.apache.org/jira/secure/RapidBo

Re: [proposal] Introduce AssertJ in test framework

Strong +1 here. Many of you know I'm a C# / LINQ junkie though. ;) On Tue, Mar 10, 2020 at 3:55 PM DuyHai Doan wrote: > Definitely +1 > > Coding in Java every day, I can't write test without assertJ. Once you get > to know assertJ, it's impossible to go back to basic assertions of JUnit > that f

Re: Sidecar meeting notes from 2020-03-10

One thing that I wasn't aware of is we have an official JIRA for it now as mentioned in the notes: https://issues.apache.org/jira/projects/CASSANDRASC/issues/CASSANDRASC-1?filter=allopenissues Was talking to someone else earlier today on a different topic about the merits of JIRA vs. using github

20200324 4.0 status update

Hello project - I'm up this week. Jordan, Jon, and I figure we should just send these updates out on Tuesdays since it seems to keep happening that way anyway; Mondays are hard. Link to the JIRA board: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA [Open

Re: CircleCI config change?

Am I understanding correctly - this isn't disabling tests, just changing when they're triggered (i.e. automatic to manual)? So, for instance, smaller interim commits don't trigger a CI run and thus costs? On Tue, Mar 24, 2020 at 3:34 PM David Capwell wrote: > > > > I want to change it so it cou

Re: CircleCI config change?

> > You could push to the repository that triggers CI less frequently? For the paranoid among us or those that work on a variety of machines over time, this does represent a sub-optimal arrangement. On Tue, Mar 24, 2020 at 4:38 PM Benedict Elliott Smith wrote: > You could push to the reposito

Re: CircleCI config change?

e able to have working version > on > > > > every commit merged to master, and possibly even block merging in > case > > > > tests don't pass. It'd be great to hear more about why this could be > > > > helpful. > > > &

Idea: Marking required scope for 4.0 GA vs. optional

As we're under a feature freeze but not code freeze, there are quite reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look like nice to haves for the release but wouldn't necessarily block cutting GA. I think there would be value in us flagging tickets that are required for 4.0 to

Re: Idea: Marking required scope for 4.0 GA vs. optional

identify > unknown issues that haven't yet been filed – but those items can be tagged > as release blockers as they're identified. 👍 > > > From: Joshua McKenzie > Sent: Saturday, March 28, 2020 7:14 AM > To: dev@cassandra.apache.org > Subject: Idea: Ma

Re: Idea: Marking required scope for 4.0 GA vs. optional

FWIW, I don't care what we go with as long as we can differentiate tickets that are optional for the rel vs. tickets that are blockers and filter the JIRA board on them so people know where they should focus their effort. The rest of it's just paint colors to me. On Sun, Mar 29, 2020 at 9:24 AM M

Re: Idea: Marking required scope for 4.0 GA vs. optional

Regardless of how we indicate optional vs. required for rel, are there strong opinions on who should set that metadata on tickets? Reporter? Assignee? One person? A group of people? On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie wrote: > FWIW, I don't care what we go with as long a

Re: Idea: Marking required scope for 4.0 GA vs. optional

; > What I'm used to is having two buckets for a release: tickets in the > > > release (if not complete they are blockers), and triage. How this is > done > > > isn't important but I do feel it's important to have both. > > > > > > Ri

Re: Idea: Marking required scope for 4.0 GA vs. optional

My PoV re: perf: if it's a regression or something that makes a new feature just Not Work, mark it as bug. All else mark improvement and can go in in patch rel. On Tue, Mar 31, 2020 at 9:17 PM Jake Luciani wrote: > > I see what you mean, I guess my personal line is: does this work worse than > t

Re: server side describe

This looks like a feature that'd potentially invalidate some testing that's been done and we've been feature frozen for over a year and a half. Also: scope creep. My PoV is we hold off. If we get into a cadence of more frequent releases we'll have it soon enough. On Wed, Apr 1, 2020 at 3:03 PM w

Re: server side describe

One thing probably worth thinking about: we're a mostly irascible lot to begin with and there's a global pandemic and Human Race Lockdown. I don't know about the rest of you but I'm starting from a pretty not-chill place these days; trying to be mindful of that. So for this: if we require a protoc

Re: server side describe

This isn't a hill to die on or something to binding -1 for me personally. In a vacuum this merge is totally fine. The problem for me comes in if a merge like this is one of 10, or 50, or 100 things that are innocuous in isolation. IMO as long as we make sure this is the only cut we do to ourselves

Re: server side describe

> > Someone once said: In my opinion, sniping like this doesn't help us move the conversation forward. Please reach out to other contributors who's behavior you have concerns with separately. On Fri, Apr 3, 2020 at 12:23 PM Joshua McKenzie wrote: > This isn't a hill t

Re: Cassandra CI Status – 2020-04-06

I spoke with Mick offline about this a bit but wanted to relay it here for posterity: ** Why are cdc and compression unit tests run separately? > In the case of cdc, I erred on the side of caution in impl assuming that most people would not be using it so any degradation in performance for the non

Re: Keeping test-only changes out of CHANGES.txt

+1 On Wed, Apr 8, 2020 at 12:26 PM Sam Tunnicliffe wrote: > +1 > > > On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > > > Can we agree on keeping such test changes out of CHANGES.txt ? > > > > We already don't put entries into CHANGES.txt if it is not a change > > from any previous release.

  1   2   3   4   5   >