FWIW, the goal of this field was to help project planning (both going forwards,
and in looking at how we've fared to help project going forwards) more than
contributor assignment. There wasn't any expectation that the correct
complexity would be provided on triage.
I'm not sure how much Jira is likely to be used for this purpose in the coming
year anyway, and the boss level difficulty has yet to be used anywhere in the
project (even on tickets that deserved it), so sure, no objection from me if
we're simplifying.
On 27/04/2021, 19:49, "Paulo Motta" <pauloricard...@gmail.com> wrote:
Branching out the discussion on the complexity levels from the "Attracting
new contributors" thread so we don't mix up the topics in the same thread.
I personally think that the "complexity" field is more an indicator/hint
for inexperienced contributors on whether he will be able to work on a
particular task. Veteran contributors will very likely just ignore this
field and work on whatever they like/need.
For instance, a person that never contributed to the project will look only
into "entry level" tasks. A person who worked on a few "entry level" tasks
will maybe start looking into "intermediate" tasks, but not into "advanced"
tasks. A person who worked on several "intermediate" tasks will become
confident to work on "advanced" tasks.
On the other end of the spectrum, the veteran contributor will not extract
any value from this field since it is able to gauge the complexity of the
task without this and decide which tasks to work on.
So, with that in mind I'm +1 in having this 3 tiered level proposed by
Patrick since 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 <pmcfa...@gmail.com>
escreveu:
> 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
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
