I have to admit, I like those Duke Nukem levels way more than I should. I
guess when you choose "Damn I'm Good" you get the boss fight to end all
boss fights. "Benedict has been assigned as a reviewer..." o.O

But seriously folks. :D

I would advocate for a simple tiering system.

Entry Level
Intermediate
Advanced

Clearly defined buckets which not only make it easier for the person
looking at the Jiras, it also makes it easier for whoever is creating or
triaging the issue. Also, 3 is a magic number.

Patrick

On Tue, Apr 27, 2021 at 10:16 AM Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Quake has it like
>
> - I Can Win
> - Bring It On
> - Hurt Me Plenty
> - Hardcore
> - Nightmare!
>
> On Tue, 27 Apr 2021 at 19:02, Benedict Elliott Smith
> <bened...@apache.org> wrote:
> >
> > I think Duke Nuke'em would be more apt
> >
> > - Piece of Cake
> > - Let's Rock
> > - Come Get Some
> > - Damn I'm Good
> >
> > On 27/04/2021, 17:57, "Patrick McFadin" <pmcfa...@gmail.com> wrote:
> >
> >     Could always go with Doom difficulty levels:
> >
> >
> >        - I'm Too Young to Die - Easy.
> >        - Hurt Me Plenty - Normal.
> >        - Ultra-Violence - Hard.
> >        - Nightmare - Very Hard.
> >        -
> >
> >
> >     On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith <
> bened...@apache.org>
> >     wrote:
> >
> >     > Perhaps we could replace both Complexity and Difficulty with e.g.
> >     > Experience?
> >     >
> >     > Newcomer
> >     > Learner
> >     > Contributor
> >     > Experienced
> >     > Veteran
> >     >
> >     > I'm not sure I like it. I don't really like segregating the
> community into
> >     > buckets like this. But it is perhaps more intuitive than
> complexity, while
> >     > encoding a more objective concept of difficulty.
> >     >
> >     >
> >     > On 27/04/2021, 17:33, "Paulo Motta" <pauloricard...@gmail.com>
> wrote:
> >     >
> >     >     I (wrongly) assumed this proposal would be fairly
> uncontroversial so I
> >     >     brought up within this related thread but given there is some
> >     > divergence, I
> >     >     retract the suggestion for now and will 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:
> >     >
> >     >     > What you are describing to me are difficulty levels, whereas
> this
> >     > field
> >     >     > tries to measure complexity. The difference is that while
> both are
> >     >     > subjective, difficulty is relatively more so. This may lead
> people to
> >     >     > assign difficulty based on their own perception (which is
> very
> >     > subjective),
> >     >     > rather than the scope of the problem (which is still
> subjective, but
> >     > less
> >     >     > so).
> >     >     >
> >     >     > We can bike-shed the names or the definitions all we like,
> but we
> >     > need
> >     >     > some separate text to elaborate the intended meaning, else
> we'll all
> >     > mean
> >     >     > and encode different things.
> >     >     >
> >     >     > I also don't personally think Hard or Very Hard are
> descriptive. By
> >     >     > comparison, Byzantine is a word that not only crops up in
> distributed
> >     >     > systems to mean involving many parties (i.e. in this case
> many
> >     > subsystems),
> >     >     > but is widely used in English to mean "intricately involved"
> with
> >     >     > connotations of labyrinthine, i.e. easy to get 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" <
> pauloricard...@gmail.com>
> >     > wrote:
> >     >     >
> >     >     >     Thanks for bringing the definitions and historical
> context
> >     > Benedict.
> >     >     > Agreed
> >     >     >     to not attach difficulties to time to complete a task.
> >     >     >
> >     >     >     The fact that the complexity types need explanation or
> reading
> >     >     >     documentation is precisely the issue I’m trying to solve
> by
> >     > using more
> >     >     >     straightforward and unambiguous terms (as much as
> possible).
> >     >     >
> >     >     >     So I propose the following levels instead.
> >     >     >     - Beginner (current LHF for people who have never
> submitted a
> >     > patch
> >     >     > (ie.
> >     >     >     trivial doc changes or minor test fixes))
> >     >     >     - Easy (current LHF for people who have submitted at
> least a
> >     > couple of
> >     >     >     patches (ie. add parameter to existing tool))
> >     >     >     - Intermediate (current normal)
> >     >     >     - Hard (current Challenging)
> >     >     >     - Very Hard (current Byzantine)
> >     >     >
> >     >     >     Please let me know what you think.
> >     >     >
> >     >     >     Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott
> Smith <
> >     >     >     bened...@apache.org> escreveu:
> >     >     >
> >     >     >     > If you're wondering, they're documented:
> >     >     >     >
> >     >     >
> >     >
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >     >     >     >
> >     >     >     > Impossible was introduced to take the place of "pony"
> - which
> >     > was
> >     >     >     > genuinely deployed on occasion, but I agree it's
> redundant as
> >     > nobody
> >     >     >     > proposes things like that anymore.
> >     >     >     >
> >     >     >     > Challenging and Byzantine are useful distinctions IMO,
> but I'm
> >     > open
> >     >     > to
> >     >     >     > relabelling them. Levels of difficulty do not cleanly
> map to
> >     > time
> >     >     > involved,
> >     >     >     > however.
> >     >     >     >
> >     >     >     > The project literally never used Easy in the past, but
> perhaps
> >     > you
> >     >     > can
> >     >     >     > bring about the necessary change to do so.
> >     >     >     >
> >     >     >     >
> >     >     >     > On 27/04/2021, 15:32, "Paulo Motta" <
> pauloricard...@gmail.com
> >     > >
> >     >     > wrote:
> >     >     >     >
> >     >     >     >     Since this is a related topic, I'd like to open a
> small
> >     >     > parenthesis to
> >     >     >     >     throw out a proposal for improving the semantics
> of our
> >     > JIRA
> >     >     >     > "complexity"
> >     >     >     >     field, which currently has the following levels:
> >     >     >     >     * Low Hanging Fruit (overall easy tasks for new or
> existing
> >     >     >     > contributors)
> >     >     >     >     * Normal (? this is the most misleading one since
> it
> >     > currently
> >     >     > ranges
> >     >     >     > from
> >     >     >     >     very simple tasks to nearly complex tasks)
> >     >     >     >     * Challenging
> >     >     >     >     * Byzantine (the difference between challenging,
> byzantine
> >     > and
> >     >     >     > impossible
> >     >     >     >     tasks is blurry/unclear to me)
> >     >     >     >     * Impossible (not clear to me what's the purpose of
> >     > filling a
> >     >     > task
> >     >     >     > that is
> >     >     >     >     impossible to do? I think we can just close the
> ticket as
> >     > invalid
> >     >     >     > during
> >     >     >     >     triage without setting complexity.)
> >     >     >     >
> >     >     >     >     I propose the following levels instead:
> >     >     >     >     * Low Hanging Fruit (I think we should even rename
> this to
> >     >     > "Beginner",
> >     >     >     >     since the LHF term is not very well known by
> outsiders and
> >     >     > non-native
> >     >     >     >     English speakers) : easy tasks for who never
> contributed
> >     > to the
> >     >     >     > project.
> >     >     >     >     * Easy : easy tasks for those who have some basic
> >     > familiarity
> >     >     > with the
> >     >     >     >     project (contributed at least 2-5 LHF).
> >     >     >     >     * Intermediate : tasks with intermediate
> complexity, can
> >     > be done
> >     >     > in
> >     >     >     > under a
> >     >     >     >     month.
> >     >     >     >     * Challenging : multi-month effort task.
> >     >     >     >     (no need for byzantine and impossible complexity
> levels
> >     > since
> >     >     > they
> >     >     >     > don't
> >     >     >     >     add any value)
> >     >     >     >
> >     >     >     >     If you prefer I can open a new thread with this
> proposal
> >     > so we
> >     >     > can
> >     >     >     > focus on
> >     >     >     >     initiatives to attract contributors - but I think
> having
> >     > clear
> >     >     >     > guidelines
> >     >     >     >     on the meaning of task's complexities will help to
> better
> >     >     > delineate
> >     >     >     > what
> >     >     >     >     tasks are suitable for new contributors.
> >     >     >     >
> >     >     >     >     Em ter., 27 de abr. de 2021 às 11:25, Joshua
> McKenzie <
> >     >     >     > jmcken...@apache.org>
> >     >     >     >     escreveu:
> >     >     >     >
> >     >     >     >     > Updating the boot camp material for 4.0 and
> having it
> >     >     > integrated in
> >     >     >     > with
> >     >     >     >     > the official docs (
> >     >     >     > https://cassandra.apache.org/doc/latest/development/)
> >     >     >     >     > would likely be a valuable, if expensive,
> exercise.
> >     >     >     >     >
> >     >     >     >     > Think this is the slideshare link from the 2014
> boot
> >     > camp;
> >     >     > could
> >     >     >     > build off
> >     >     >     >     > this as the bones are still the same.
> >     >     >     >     > https://www.slideshare.net/joshmckenzie/
> >     >     >     >     >
> >     >     >     >     > On Tue, Apr 27, 2021 at 10:08 AM Paulo Motta <
> >     >     >     > pauloricard...@gmail.com>
> >     >     >     >     > wrote:
> >     >     >     >     >
> >     >     >     >     > > Bootcamp is a great effort, but I think in
> terms of
> >     > priority
> >     >     >     > ensuring
> >     >     >     >     > that
> >     >     >     >     > > LHF tickets are properly described (well
> scoped, good
> >     > ticket
> >     >     >     > description
> >     >     >     >     > > etc) and given proper attention and mentorship
> to
> >     > ensure it
> >     >     > goes
> >     >     >     > through
> >     >     >     >     > > the finish line is a great first step and will
> >     > significantly
> >     >     >     > reduce the
> >     >     >     >     > > barrier to contribution. Once we have this
> initial
> >     > pipeline
> >     >     > working
> >     >     >     >     > > smoothly, I think promoting a bootcamp would
> be a great
> >     >     > second
> >     >     >     > step,
> >     >     >     >     > since
> >     >     >     >     > > the bootcamp can be much more efficient if the
> >     > participants
> >     >     > have
> >     >     >     > already
> >     >     >     >     > > some basic level of familiarity with the
> project and
> >     > can
> >     >     > start
> >     >     >     > working
> >     >     >     >     > on a
> >     >     >     >     > > bit more involved tasks ("Easy" complexity)
> tasks.
> >     >     >     >     > >
> >     >     >     >     > > Em ter., 27 de abr. de 2021 às 10:50, Benjamin
> Lerer <
> >     >     >     > b.le...@gmail.com>
> >     >     >     >     > > escreveu:
> >     >     >     >     > >
> >     >     >     >     > > > >
> >     >     >     >     > > > > It really boils down just to a simple
> "problem" to
> >     > have
> >     >     > enough
> >     >     >     >     > > > > committers to look at it over a
> (preferably)
> >     > shorter
> >     >     > period of
> >     >     >     > time
> >     >     >     >     > > > > and make that feedback loop shorter.
> >     >     >     >     > > > >
> >     >     >     >     > > >
> >     >     >     >     > > > The review delay is a clear issue. A part of
> the
> >     > problem
> >     >     > is that
> >     >     >     > most
> >     >     >     >     > > > committers are pretty busy (or that there
> are not
> >     > enough
> >     >     >     > committers,
> >     >     >     >     > > > depending how you look at it) but another
> part of the
> >     >     > problem is
> >     >     >     > that
> >     >     >     >     > we
> >     >     >     >     > > do
> >     >     >     >     > > > not have a good visibility on what is
> currently
> >     > going on
> >     >     > with new
> >     >     >     >     > > > contributors. By having a clear view of which
> >     > newcomers'
> >     >     > tickets
> >     >     >     > are
> >     >     >     >     > > stuck
> >     >     >     >     > > > we could also act in a more efficient way.
> We are
> >     > currently
> >     >     >     > doing some
> >     >     >     >     > > > experimentations with Berenguer to have a
> way of
> >     > tracking
> >     >     > those
> >     >     >     > things.
> >     >     >     >     > > >
> >     >     >     >     > > > Once 4.0 is out of the door, I believe that
> some of
> >     > us
> >     >     > should
> >     >     >     > also
> >     >     >     >     > have a
> >     >     >     >     > > > bit more time to help out with newcomers'
> >     >     > reviews/mentoring.
> >     >     >     >     > > >
> >     >     >     >     > > > +1, I had a few minor patches before but the
> bootcamp
> >     >     > definitely
> >     >     >     > helped
> >     >     >     >     > > me
> >     >     >     >     > > > > ramp up on the project faster and I found
> the
> >     > recorded
> >     >     >     > material very
> >     >     >     >     > > > useful
> >     >     >     >     > > > > during project onboarding (some of it is
> still
> >     > available
> >     >     > on
> >     >     >     > Youtube).
> >     >     >     >     > > > >
> >     >     >     >     > > >
> >     >     >     >     > > > People have different levels of experience
> and they
> >     > will
> >     >     > probably
> >     >     >     >     > > approach
> >     >     >     >     > > > the project in a different way but if a
> bootcamp can
> >     > help
> >     >     > to have
> >     >     >     >     > another
> >     >     >     >     > > > Paulo, I am willing to do it. ;-)
> >     >     >     >     > > > Of course in this pandemic world the best we
> can
> >     > probably
> >     >     > offer
> >     >     >     > for the
> >     >     >     >     > > > moment is some virtual bootcamp.
> >     >     >     >     > > >
> >     >     >     >     > > > Le mar. 27 avr. 2021 à 15:34, Paulo Motta <
> >     >     >     > pauloricard...@gmail.com> a
> >     >     >     >     > > > écrit :
> >     >     >     >     > > >
> >     >     >     >     > > > > +1, I had a few minor patches before but
> the
> >     > bootcamp
> >     >     >     > definitely
> >     >     >     >     > helped
> >     >     >     >     > > > me
> >     >     >     >     > > > > ramp up on the project faster and I found
> the
> >     > recorded
> >     >     >     > material very
> >     >     >     >     > > > useful
> >     >     >     >     > > > > during project onboarding (some of it is
> still
> >     > available
> >     >     > on
> >     >     >     > Youtube).
> >     >     >     >     > > > >
> >     >     >     >     > > > > I think it would be beneficial to
> collocate a
> >     > bootcamp
> >     >     > for new
> >     >     >     >     > > > contributors
> >     >     >     >     > > > > together with an annual event such as NGCC
> or
> >     >     >     > Apachecon/Cassandra
> >     >     >     >     > > Summit
> >     >     >     >     > > > > and also record some of the sessions so
> they're
> >     >     > available for
> >     >     >     > a wider
> >     >     >     >     > > > > audience after the fact.
> >     >     >     >     > > > >
> >     >     >     >     > > > > Em ter., 27 de abr. de 2021 às 10:20,
> Jeremy Hanna
> >     > <
> >     >     >     >     > > > > jeremy.hanna1...@gmail.com> escreveu:
> >     >     >     >     > > > >
> >     >     >     >     > > > > > 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 some people get
> >     > familiar
> >     >     > with the
> >     >     >     > project
> >     >     >     >     > > who
> >     >     >     >     > > > > > still contribute today.
> >     >     >     >     > > > > >
> >     >     >     >     > > > > > Also this would be short recorded
> introductions
> >     > so they
> >     >     >     > could be
> >     >     >     >     > > around
> >     >     >     >     > > > > > for viewing and with auto translate on
> Google for
> >     >     > different
> >     >     >     >     > languages
> >     >     >     >     > > > > such
> >     >     >     >     > > > > > as Japanese and Mandarin.
> >     >     >     >     > > > > >
> >     >     >     >     > > > > > I do like the idea of a periodic chat. I
> just
> >     > thought
> >     >     > some
> >     >     >     > recorded
> >     >     >     >     > > > > > introductions would help with some of
> the more
> >     > common
> >     >     > things
> >     >     >     > like
> >     >     >     >     > > “this
> >     >     >     >     > > > > is
> >     >     >     >     > > > > > how the read path works from end to end”.
> >     >     >     >     > > > > >
> >     >     >     >     > > > > > > On Apr 27, 2021, at 10:14 PM, Benedict
> Elliott
> >     > Smith
> >     >     > <
> >     >     >     >     > > > > > bened...@apache.org> wrote:
> >     >     >     >     > > > > > >
> >     >     >     >     > > > > > > 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
> >     >     >     > could be
> >     >     >     >     > > > > created
> >     >     >     >     > > > > > of going through that guide as well.
> >     >     >     >     > > > > > >
> >     >     >     >     > > > > > > That said, if there are new
> contributors
> >     > actively
> >     >     > trying to
> >     >     >     >     > > > > participate,
> >     >     >     >     > > > > > organising a periodic group chat to talk
> through
> >     > one
> >     >     > of the
> >     >     >     > issues
> >     >     >     >     > > that
> >     >     >     >     > > > > > they may be working on together as a
> group with
> >     > an
> >     >     > active
> >     >     >     >     > contributor
> >     >     >     >     > > > > might
> >     >     >     >     > > > > > make sense, and be more targeted in
> focus?
> >     >     >     >     > > > > > >
> >     >     >     >     > > > > > >
> >     >     >     >     > > > > > > On 27/04/2021, 12:45, "Manish G" <
> >     >     >     > manish.c.ghildi...@gmail.com>
> >     >     >     >     > > > > wrote:
> >     >     >     >     > > > > > >
> >     >     >     >     > > > > > >    Contributor bootcamps can really
> help new
> >     > people
> >     >     > like
> >     >     >     > me.
> >     >     >     >     > > > > > >
> >     >     >     >     > > > > > >>    On Tue, Apr 27, 2021, 5:08 PM
> Jeremy Hanna
> >     > <
> >     >     >     >     > > > > > jeremy.hanna1...@gmail.com>
> >     >     >     >     > > > > > >>    wrote:
> >     >     >     >     > > > > > >>
> >     >     >     >     > > > > > >> One thing we've done in the past is
> >     > contributor
> >     >     > bootcamps
> >     >     >     > along
> >     >     >     >     > > with
> >     >     >     >     > > > > the
> >     >     >     >     > > > > > >> the new contributor guide and the LHF
> >     > complexity
> >     >     > tickets.
> >     >     >     >     > > > > > Unfortunately, I
> >     >     >     >     > > > > > >> don't know that the contributor
> bootcamps
> >     > were ever
> >     >     >     > recorded.
> >     >     >     >     > > > > > >> Presentations were done to introduce
> people
> >     > to the
> >     >     >     > codebase
> >     >     >     >     > > > generally
> >     >     >     >     > > > > (I
> >     >     >     >     > > > > > >> think Gary did this at one point) as
> well as
> >     >     > specific
> >     >     >     > parts of
> >     >     >     >     > the
> >     >     >     >     > > > > > >> codebase, such as compaction.  What
> if we
> >     > broke up
> >     >     > the
> >     >     >     > codebase
> >     >     >     >     > > into
> >     >     >     >     > > > > > >> categories and people could volunteer
> to do a
> >     > short
> >     >     >     > introduction
> >     >     >     >     > > to
> >     >     >     >     > > > > that
> >     >     >     >     > > > > > >> part of the codebase in the form of a
> video
> >     >     > screenshare.
> >     >     >     > I
> >     >     >     >     > don't
> >     >     >     >     > > > > think
> >     >     >     >     > > > > > >> this would take the place of mentoring
> >     > someone, but
> >     >     > if we
> >     >     >     > had
> >     >     >     >     > > > > > introductions
> >     >     >     >     > > > > > >> to different parts of the codebase, I
> think
> >     > it would
> >     >     >     > lower the
> >     >     >     >     > bar
> >     >     >     >     > > > for
> >     >     >     >     > > > > > >> interested contributors and scale the
> existing
> >     >     > group more
> >     >     >     >     > easily.
> >     >     >     >     > > > > > Besides
> >     >     >     >     > > > > > >> the codebase itself, we could also
> introduce
> >     > things
> >     >     > like
> >     >     >     > CI
> >     >     >     >     > > > practices
> >     >     >     >     > > > > or
> >     >     >     >     > > > > > >> testing or documentation.
> >     >     >     >     > > > > > >>
> >     >     >     >     > > > > > >>>> On Apr 24, 2021, at 12:49 AM,
> Benjamin
> >     > Lerer <
> >     >     >     >     > ble...@apache.org
> >     >     >     >     > > >
> >     >     >     >     > > > > > wrote:
> >     >     >     >     > > > > > >>>
> >     >     >     >     > > > > > >>> Hi Everybody,The Apache Cassandra
> project
> >     > always
> >     >     > had some
> >     >     >     >     > issues
> >     >     >     >     > > to
> >     >     >     >     > > > > > >>> attract and retain new contributors.
> I think
> >     > it
> >     >     > would be
> >     >     >     > great
> >     >     >     >     > to
> >     >     >     >     > > > > > change
> >     >     >     >     > > > > > >>> this.According to the "How to
> Attract New
> >     >     > Contributors"
> >     >     >     > blog
> >     >     >     >     > > post (
> >     >     >     >     > > > > > >>>
> >     >     >     >
> https://www.redhat.com/en/blog/how-attract-new-contributors)
> >     >     >     >     > > > having
> >     >     >     >     > > > > a
> >     >     >     >     > > > > > >> good
> >     >     >     >     > > > > > >>> onboarding process is a critical
> part. How to
> >     >     > contribute
> >     >     >     > should
> >     >     >     >     > > be
> >     >     >     >     > > > > > >> obvious
> >     >     >     >     > > > > > >>> and contributing should be as easy as
> >     > possible for
> >     >     > all
> >     >     >     > the
> >     >     >     >     > > > different
> >     >     >     >     > > > > > >> types
> >     >     >     >     > > > > > >>> of contributions: code,
> documentation,
> >     > web-site or
> >     >     > help
> >     >     >     > with
> >     >     >     >     > our
> >     >     >     >     > > CI
> >     >     >     >     > > > > > >>> infrastructure.I would love to hear
> about
> >     > your
> >     >     > ideas on
> >     >     >     > how we
> >     >     >     >     > > can
> >     >     >     >     > > > > > >> improve
> >     >     >     >     > > > > > >>> things.If you are new in the
> community, do
> >     > not
> >     >     > hesitate
> >     >     >     > to
> >     >     >     >     > share
> >     >     >     >     > > > your
> >     >     >     >     > > > > > >>> experience and your suggestions on
> what we
> >     > can do
> >     >     > to
> >     >     >     > make it
> >     >     >     >     > > easier
> >     >     >     >     > > > > for
> >     >     >     >     > > > > > >> you
> >     >     >     >     > > > > > >>> to contribute.
> >     >     >     >     > > > > > >>
> >     >     >     >     > > > > > >>
> >     >     >     >     > > > > > >>
> >     >     >     >     > > >
> >     >     >     >
> >     >
> ---------------------------------------------------------------------
> >     >     >     >     > > > > > >> 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
> >     >     >     >     > > > > > >
> >     >     >     >     > > > > >
> >     >     >     >     > > > > >
> >     >     >     >     >
> >     >     >
> ---------------------------------------------------------------------
> >     >     >     >     > > > > > 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
> >     >     >     >
> >     >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> ---------------------------------------------------------------------
> >     >     > 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
> >     >
> >     >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Reply via email to