Re: Apache Cassandra Blog is now live

[Jeff Beck]

I submitted a patch for the feed to that ticket it also seemed like we
needed bundler to ensure we always use the same gems.

On Thu, Aug 9, 2018 at 2:44 AM Jacques-Henri Berthemet <
jacques-henri.berthe...@genesys.com> wrote:

> Hi Scott,
>
> Here is the ticket: https://issues.apache.org/jira/browse/CASSANDRA-14631
>
> Regards,
> --
> Jacques-Henri Berthemet
>
> -Original Message-
> From: Scott Andreas 
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: dev@cassandra.apache.org
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: https://github.com/jekyll/jekyll-feed
>
> 
> From: Jacques-Henri Berthemet 
> Sent: Wednesday, August 8, 2018 1:32:23 AM
> To: dev@cassandra.apache.org
> Subject: RE: Apache Cassandra Blog is now live
>
> It is possible to setup RSS on the blog? Should I create a Jira about that?
>
> --
> Jacques-Henri Berthemet
>
> -Original Message-
> From: Mick Semb Wever 
> Sent: Wednesday, August 08, 2018 8:17 AM
> To: dev@cassandra.apache.org
> Subject: Re: Apache Cassandra Blog is now live
>
>
> > We are also interested in contributing to the blog, what's the process?
>
>
> Dikang,
> it's part of the website,
> https://svn.apache.org/repos/asf/cassandra/site/src/README
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: NGCC 2018?

[Jeff Beck]

I am an organizer with a conference (GR8Conf US) here in Minneapolis I
would be happy to assist with organizing and we also have recording
equipment to support up to 3 tracks. We operate under a non profit already
if we need a legal entity.

If it is the bay area I we can't help much with space but we have contacts
here if there is any desire to have it in the midwest.

Jeff

On Mon, Jul 23, 2018 at 4:25 PM Ben Bromhead  wrote:

> The year has gotten away from us a little bit, but now is as good a time as
> any to put out a general call for interest in an NGCC this year.
>
> Last year Gary and Eric did an awesome job organizing it in San Antonio.
> This year it might be a good idea to do it in another city?
>
> We at Instaclustr are happy to sponsor/organize/run it, but ultimately this
> is a community event and we only want to do it if there is a strong desire
> to attend from the community and it meets the wider needs.
>
> Here are a few thoughts we have had in no particular order:
>
>- I was thinking it might be worth doing it in SF/Bay Area around the
>dates of distributed data day (14th of September) as I know a number of
>folks will be in town for it.
>- Typically NGCC has focused on being a single day, single track
>conference with scheduled sessions and an unconference set of ad-hoc
> talks
>at the end. It may make sense to change this up given the pending freeze
>(maybe make this more like a commit/review fest)? Or keep it in the same
>format but focus on the 4.0 work at hand.
>- Any community members who want to get involved again in the more
>organizational side of it (Gary, Eric)?
>- Any other sponsors (doesn't have to be monetary, can be space,
>resource etc) who want to get involved?
>
> If folks are generally happy with the end approach we'll post details as
> soon as possible (given its July right now)!
>
> Ben
>
>
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692 <(650)%20284-9692>
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>

Re: Roadmap for 4.0

[Jeff Beck]

If you are going to make 4 bigger as long as we call out that 3.11.x (or
whatever) will keep getting patches for stability only that's all that's
needed. We haven't gone to 3.x releases many places yet as we wait for a
release that will be stable longer. Knowing 4 is going to be bigger I
wouldn't want to see more feature releases in 3.x

I wouldn't want to greatly slow features down if they require a major
release and 5 is too far off.

Jeff

On Mon, Apr 9, 2018, 4:05 PM Josh McKenzie  wrote:

> >
> > If they're not close to finished now why even consider them for the 4.0
> > release?
>
> Merging in major features at the end of a release cycle is not the path to
> stability, imo.
>
> On Mon, Apr 9, 2018 at 4:56 PM, Jonathan Haddad  wrote:
>
> > There's always more stuff to try to shoehorn in.  We've done big releases
> > with all the things, it never was stable.  We tried the opposite end of
> the
> > spectrum, release every month, that really wasn't great either.
> Personally
> > I'd be OK with stopping new features by the end of this month and aiming
> to
> > release a stable 4.0 when we agree we would be comfortable dogfooding it
> in
> > production at our own companies (in a few months), and aim for 4.1 (or
> 5.0
> > I don't want to bikeshed the version) for pluggable storage and transient
> > replicas.  If they're not close to finished now why even consider them
> for
> > the 4.0 release?  They're so core they should be merged into trunk at the
> > beginning of the cycle for the follow up release in order to get as much
> > exposure as possible.
> >
> > Jon
> >
> > On Mon, Apr 9, 2018 at 1:46 PM Nate McCall  wrote:
> >
> > > > I'd like to see pluggable storage and transient replica tickets land,
> > for
> > > > starters.
> > >
> > > I think both those features are, frankly, necessary for our future. On
> > > the other hand, they both have the following risks:
> > > 1. core behavioral changes
> > > 2. require changing a (relatively) large surface area of code
> > >
> > > We can aim to de-risk 4.0 by focusing on what we have now which is
> > > solid repair and NIO internode (maybe we move the 4.0 branch timeline
> > > up?), aiming for a 4.1 following soon-ish.
> > >
> > > Or we can go in eyes open and agree on a larger footprint 4.0.
> > >
> > > I'm on the fence, tbh (can't emphasize enough how big both those
> > > features will be). I just want everyone to know what we are getting
> > > into and that we are potentially impacting our goals of "stable" ==
> > > "exciting."
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: Repair scheduling tools

[Jeff Beck]

I personally would rather see improvements to reaper and supporting reaper
so the repair tool improvements aren't tied to Cassandra releases. If we
get to a place where the repair tools are stable then figuring out how to
bundle for the best install makes sense to me.

If we add things that will support reaper other repair solutions could also
take advantage.

Jeff

On Thu, Apr 5, 2018, 11:05 PM kurt greaves  wrote:

> Vnodes is related and because we made it a default lots of people are using
> it. Repairing a cluster with vnodes is a catastrophe (even a small one is
> often problematic), but we have to deal with it if we build in repair
> scheduling.
>
> Repair scheduling is very important and we should definitely include it
> with C* (sidecar long term makes most sense to me but only if we looked at
> moving other background ops to the sidecar), but I'm positive it's not
> going to work well with vnodes in their current state. Having said that, it
> should still support scheduling repairs on vnode clusters, but the
> vnode+repair problem should be fixed separately (and probably with more
> attention than we've given it) because it's a major issue.
>
> FWIW I know of 256 vnode clusters with > 100 nodes, yet I'd be surprised if
> any of them are currently successfully repairing.
>
> On 6 April 2018 at 03:03, Nate McCall  wrote:
>
> > I think a take away here is that we can't assume a level of operation
> > maturity will coincide automatically with scale. To make our core
> > features robust, we have to account for less-experienced users.
> >
> > A lot of folks on this thread have *really* strong ops and OpsViz
> > stories. Let's not forget that most of our users don't.
> > ((Un)fortunately, as a consulting firm, we tend to see the worst of
> > this).
> >
> > On Fri, Apr 6, 2018 at 2:52 PM, Jonathan Haddad 
> wrote:
> > > Off the top of my head I can remember clusters with 600 or 700 nodes
> with
> > > 256 tokens.
> > >
> > > Not the best situation, but it’s real. 256 has been the default for
> > better
> > > or worse.
> > >
> > > On Thu, Apr 5, 2018 at 7:41 PM Joseph Lynch 
> > wrote:
> > >
> > >> >
> > >> > We see this in larger clusters regularly. Usually folks have just
> > >> > 'grown into it' because it was the default.
> > >> >
> > >>
> > >> I could understand a few dozen nodes with 256 vnodes, but hundreds is
> > >> surprising. I have a whitepaper draft lying around showing how vnodes
> > >> decrease availability in large clusters by orders of magnitude, I'll
> > polish
> > >> it up and send it out to the list when I get a second.
> > >>
> > >> In the meantime, sorry for de-railing a conversation about repair
> > >> scheduling to talk about vnodes, let's chat about that in a different
> > >> thread :-)
> > >>
> > >> -Joey
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

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

[Jeff Beck]

I run the local Cassandra User Group and I would love to help get the
community more involved.  I would propose holding a night to add patches to
Cassandra some will be simple things like making sure some asserts have
proper messages with them etc, but some may be slightly larger. The goal
being to just get people used to the process, to help make this a success
it would be great if we could have support on getting the patches we submit
at least looked at briefly in 1 month. That timeframe allows us to talk
about it at the next meetup and show people their contributions even small
ones are valued.

Before we did this night I would probably dig through some tickets and get
an example list going and any feedback notes on making the process easier
would be great.

Generally if there is anything you need from the meetups ask I know I will
do my best to get the local group to support things.

Jeff

On Fri, Nov 4, 2016 at 6:08 PM Aleksey Yeschenko  wrote:

Dunno. A sneaky correctness or data corruption bug. A performance
regression. Or something that can take a node/cluster down.

Of course no process is bullet-proof. The purpose of review is to minimise
the odds of such a thing happening.

I’m sure users running Cassandra in production would prefer actual proper
reviews to non-review +1s.

-- 
AY

On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com)
wrote:

I feel that is really standing up on a soap box. What would be the worst
thing that happens here

Re: Moderation

[Jeff Beck]

Is there an easy place to get up to speed on all the ASF terms? Infra
Karma, apmail, etc... I feel behind on understanding what is being talked
about here.

Jeff

On Fri, Nov 4, 2016 at 12:31 PM Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> Thank you Chris.
>
> I have just replied to her email myself.
>
> Sent from my iPhone
>
> > On Nov 4, 2016, at 10:24 AM, Chris Mattmann  wrote:
> >
> > I'm sorry that you feel I'm promoting the arguing. The point of this
> thread was a simple request - moderate the email. I suspected that there
> weren't enough moderators but didn't spend the time to check. Honestly this
> is the Apache Cassandra PMC's job to maintain a healthy set of moderators,
> ideally in diverse timezones. Some may not feel 12 hours is a long time. I
> can only provide answers from most of the other Apache communities I
> participate in (Tika, Nutch, OODT, Hadoop, Solr/Lucene, Incubator, etc.)
> and in those communities, that *is* a long time. That said, this was also
> elevated because I saw someone with real questions asking them on Twitter
> and not on ASF lists pertaining to the projects (Yes there was also
> denigrating statements about both DataStax and ASF in there too). So,
> regarding that, the grown up thing to do (and honestly the "Apache" thing
> to do) is to bring the conversation on list, and talk, rather than sound
> off in 25+ different mediums.
> >
> > Now we've added a least one more moderator, which will help the root of
> the problem. And Kelly's email is on list. I will try and reply with my
> knowledge as a concerned ASF member first, and Board Member second. It
> would be great for the Apache Cassandra PMC and community to reply as well.
> >
> > Cheers,
> > Chris
> >
> >
> >> On 2016-11-04 10:14 (-0700), Michael Kjellman <
> mkjell...@internalcircle.com> wrote:
> >> @Chris: instead of promoting the arguing going on on this thread could
> you please help lead by example and reply to Kelly's questions in her
> email? Thanks.
> >>
> >> I don't enjoy watching a community I care about continue to explode in
> front of my eyes â~¹ï¸
> >>
> >> best,
> >> kjellman
> >>
> >> Sent from my iPhone
> >>
> >>> On Nov 4, 2016, at 10:10 AM, Chris Mattmann 
> wrote:
> >>>
> >>> I have apmail karma and can add moderators.
> >>>
> >>> Jason I can add you - please confirm you would like to be added. Did
> you file the ticket - if so point me to it. If you haven't yet, no worries
> I can still add you. Let me know. Thanks.
> >>>
>  On 2016-11-04 09:54 (-0700), Jason Brown 
> wrote:
>  Gary,
> 
>  I've just started looking into the moderator component due to this
> thread;
>  I admit I did not know about it before (my fault). Yes, I would like
> to be
>  added. Apparently, I need to file an INFRA ticket (as per
>  https://www.apache.org/dev/committers.html#mailing-list-moderators),
> which
>  I will do in the next few minutes.
> 
>  -Jason
> 
> > On Fri, Nov 4, 2016 at 9:51 AM, Gary Dusbabek 
> wrote:
> >
> > I'm beginning to wonder if I'm the only one with moderator privs.
> Any other
> > committer/PMCs interested?
> >
> > Sorry, it's a chore to begin with and I've been traveling this week.
> >
> > Gary.
> >
> > On Fri, Nov 4, 2016 at 3:47 PM, Chris Mattmann 
> > wrote:
> >
> >> Hi Folks,
> >>
> >> Kelly Sommers sent a message to dev@cassandra and I'm trying to
> figure
> >> out if it's in moderation.
> >>
> >> Can the moderators speak up?
> >>
> >> Cheers,
> >> Chris
> >>
> >>
> >
> 
> >>
>

Re: Low hanging fruit crew

[Jeff Beck]

Would it make sense to allow people submitting the patch to flag things as
LHF or small tasks? If it doesn't look like it is simple enough the team
could remove the label but it may help get feedback to patches more
quickly, even something saying accepted for review would be nice.

Personally if a ticket sits for a few weeks I have no idea what next steps
I should take to keep it moving forward. We may want to document what a
person submitting a patch should do next and if it is documented we should
add a link on
http://cassandra.apache.org/doc/latest/development/patches.html

Jeff


PS: My example is https://issues.apache.org/jira/browse/CASSANDRA-12633

On Wed, Oct 19, 2016 at 12:21 PM Edward Capriolo 
wrote:

> Also no one has said anything to the effect of 'we want to rubber stamp
> reviews' so that ...evil reason. Many of us are coders by trade and
> understand why that is bad.
>
> On Wednesday, October 19, 2016, Edward Capriolo 
> wrote:
>
> > I realize that test passing a small tests and trivial reviews will not
> > catch all issues. I am  not attempting to trivialize the review process.
> >
> > Both deep and shallow bugs exist. The deep bugs, I am not convinced that
> > even an expert looking at the contribution for N days can account for a
> > majority of them.
> >
> > The shallow ones may appear shallow and may be deep, but given that a bug
> > already exists an attempt to fix it usually does not arrive at something
> > worse.
> >
> > Many of these issues boil down to simple, seeemingly clear fixes. Some
> are
> > just basic metric addition. Many have no interaction for weeks.
> >
> >
> > On Wednesday, October 19, 2016, Jeff Jirsa  > > wrote:
> >
> >> Let’s not get too far in the theoretical weeds. The email thread really
> >> focused on low hanging tickets – tickets that need review, but
> definitely
> >> not 8099 level reviews:
> >>
> >> 1) There’s a lot of low hanging tickets that would benefit from outside
> >> contributors as their first-patch in Cassandra (like
> >> https://issues.apache.org/jira/browse/CASSANDRA-12541 ,
> >> https://issues.apache.org/jira/browse/CASSANDRA-12776 )
> >> 2) Some of these patches already exist and just need to be reviewed and
> >> eventually committed.
> >>
> >> Folks like Ed and Kurt have been really active in Jira lately, and there
> >> aren’t a ton of people currently reviewing/committing – that’s part of
> OSS
> >> life, but the less friction that exists getting those patches reviewed
> and
> >> committed, the more people will be willing to contribute in the future,
> and
> >> the better off the project will be.
> >>
> >>
> >> On 10/19/16, 9:14 AM, "Jeremy Hanna" 
> wrote:
> >>
> >> >And just to be clear, I think everyone would welcome more testing for
> >> both regressions of new code correctness.  I think everyone would
> >> appreciate the time savings around more automation.  That should give
> more
> >> time for a thoughtful review - which is likely what new contributors
> really
> >> need to get familiar with different parts of the codebase.  These LHF
> >> reviews won’t be like the code reviews of the vnode or the 8099 ticket
> >> obviously, so it won’t be a huge burden.  But it has some very tangible
> >> benefits imo, as has been said.
> >> >
> >> >> On Oct 19, 2016, at 11:08 AM, Jonathan Ellis 
> >> wrote:
> >> >>
> >> >> I specifically used the phrase "problems that the test would not" to
> >> show I
> >> >> am talking about more than mechanical correctness.  Even if the tests
> >> are
> >> >> perfect (and as Jeremiah points out, how will you know that without
> >> reading
> >> >> the code?), you can still pass tests with bad code.  And is expecting
> >> >> perfect tests really realistic for multithreaded code?
> >> >>
> >> >> But besides correctness, reviews should deal with
> >> >>
> >> >> 1. Efficiency.  Is there a quadratic loop that will blow up when the
> >> number
> >> >> of nodes in a cluster gets large?  Is there a linear amount of memory
> >> used
> >> >> that will cause problems when a partition gets large?  These are not
> >> >> theoretical problems.
> >> >>
> >> >> 2. Maintainability.  Is this the simplest way to accomplish your
> >> goals?  Is
> >> >> there a method in SSTableReader that would make your life easier if
> you
> >> >> refactored it a bit instead of reinventing it?  Does this reduce
> >> technical
> >> >> debt or add to it?
> >> >>
> >> >> 3. "Bus factor."  If only the author understands the code and all
> >> anyone
> >> >> else knows is that tests pass, the project will quickly be in bad
> >> shape.
> >> >> Review should ensure that at least one other person understand the
> >> code,
> >> >> what it does, and why, at a level that s/he could fix bugs later in
> it
> >> if
> >> >> necessary.
> >> >>
> >> >> On Wed, Oct 19, 2016 at 10:52 AM, 

Re: Github pull requests

[Jeff Beck]

I would love to be able to send PRs, there have a been a few minor
improvements I wanted to submit that are sitting in local branches for me
for when I have time to really learn how to submit a patch where PRs are
much more approachable now.

Jeff

On Fri, Aug 26, 2016 at 11:11 AM Aleksey Yeschenko 
wrote:

> Mark, I, for one, will be happy with the level of GitHub integration that
> Spark has, formal or otherwise.
>
> As it stands right now, none of the committers/PMC members have any
> control over Cassandra Github mirror.
>
> Which, among other things, means that we cannot even close the erroneously
> opened PRs ourselves,
> they just accumulate unless the PR authors is kind enough to close them.
> That’s really frustrating.
>
> --
> AY
>
> On 26 August 2016 at 17:07:29, Mark Thomas (ma...@apache.org) wrote:
>
> On 26/08/2016 16:33, Jonathan Ellis wrote:
> > Hi all,
> >
> > Historically we've insisted that people go through the process of
> creating
> > a Jira issue and attaching a patch or linking a branch to demonstrate
> > intent-to-contribute and to make sure we have a unified record of changes
> > in Jira.
> >
> > But I understand that other Apache projects are now recognizing a github
> > pull request as intent-to-contribute [1] and some are even making github
> > the official repo, with an Apache mirror, rather than the other way
> > around. (Maybe this is required to accept pull requests, I am not sure.)
> >
> > Should we revisit our policy here?
>
> At the moment, the ASF Git repo is always the master, with GitHub as a
> mirror. That allows push requests to be made via GitHub.
>
> Infra is exploring options for giving PMCs greater control over GitHub
> config (including allowing GitHub to be the master with a golden copy
> held at the ASF) but that is a work in progress.
>
> As far as intent to contribute goes, there does appear to be a trend
> that the newer a project is to the ASF, the more formal the project
> makes process around recording intent to contribute. (The same can be
> said for other processes as well like Jira config.)
>
> It is worth noting that all the ASF requires is that there is an intent
> to contribute. Anything that can be reasonably read that way is fine.
> Many PMCs happily accept patches sent to the dev list (although they may
> ask them to be attached to issues more so they don't get forgotten than
> anything else). Pull requests are certainly acceptable.
>
> My personal recommendation is don't put more formal process in place
> than you actually need. Social controls are a lot more flexible than
> technical ones and generally have a much lower overhead.
>
> Mark
>
> >
> > [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is%3Aclosed
>
>