►
From YouTube: 2021-08-17 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
So
it
looks
like
riley
has
a
conflict
today,
so
I
might,
I
might
take
leave
on
running
the
agenda.
That's
all
right.
I
have
a
little
bit
of
a
cold,
so
you'll
have
to
deal
with
a
scratchy
throat.
Josh
hope.
No
one
minds.
A
You
you.
C
A
Oh
god,
that's
that's
called
control
c
from
github
and
then
not
paying
attention
yeah,
I'm
not
I'm
not
100
so,
but
but
I
think
I
think,
we're
okay,
so
right
here,
I
wanted
to
start
with
three
three
of
the
main
to-do's
around
the
metrics
sdk.
I
did
not
add
data
model
related
work
or
histogram-related
work,
so
josh.
If
you
could
follow
that
up.
Let's,
let's
start
talking
about
the
sdk,
let's
time
box
to
about
30
minutes
and
then
we'll
follow
up
with
data
model
related
questions
in
the
last
twenty
five,
okay.
A
So
first
off
there's
three
two
dues:
this
was
mentioned
in
the
other
spec
sig.
We
have
the
exporter
pr.
We
have
the
aggregator
pr
and
we
have
the
exemplar
pr.
So
if
you
haven't
had
a
chance
to
look
at
those,
please
look
at
those.
I
think
the
aggregator
pr
already
has
two
approvals
waiting
for
riley
to
approve
it
before
riley
going.
E
A
Take
a
look
at
it,
riley
already
approved.
Oh
did
he,
okay.
As
of
when
I
looked
at
this
morning,
it
wasn't
approved
yet,
or
I
forgot
to
refresh
one
of
the
two
good,
so
maybe
maybe
we'll
take
care
of
that
one.
I
asked
riley
a
few
view
questions
I
thought
would
be
interesting
to
discuss
here.
Just
so,
people
understand
what
the
implementation
will
look
like.
A
A
So
I
just
wanted
to
call
that
out,
because
that's
the
next
major
shuffle
that's
going
to
be
happening
in
the
java
implementation
and
it's
it's
a
little
gross.
So
I
apologize
to
john
who
will
be
reading
the
code.
A
The
next
thing
was
around
whether
first
view
wins
and
who
overrides-
and
this
is
one
I
wanted
to
talk
through
a
little
bit
so
right
now.
Basically,
we
go
through
the
views
if
they've
they've
been
registered
and
if
someone
say
registers
a
a
view
that
conflicts
with
another
one,
here's
the
example
down
here.
Actually
I'm
not
presenting,
am
I
no
man,
you
gotta
when
I'm
when
I'm
not
feeling?
Well,
you
guys
gotta
call
me
out
on
this
jump
all
right
here
we
go
open
telemetry.
Six
back.
A
Okay.
Well,
that's
good!
That's
good!
So
here,
for
example,
if
we
have
a
counter
called
x,
a
histogram
called
y
and
a
gauge
called
z
right,
the
fact
that
we're
adding
a
view
called
x,
I
think
in
the
python
api.
A
This
is
an
unnamed
view
that
matches
on
instrument
x,
and
so
it
would
create
a
view
called
x.
This
one
matches
on
any
instrument
which
would
then
create
a
view
called
that
instrument
name.
But
since
this
one
exists
right,
counter
x
will
have
something
with
some
aggregation
of
delta,
but
will
not
get
these
attribute
key
kind
of
filtration
happening,
whereas
histogram
y
and
gauge
z
would,
and
what
I
want
to
call
out
here
is
when
you
look
at
this
in
isolation.
It's
fine.
A
One
thing
that
we
have
in
java,
though,
are
we
have
we
have
these
extension
builders
for
the
sdk,
for
users
to
provide
and
there's
an
interesting
component
here
where,
if
I
want
to
glob
match
on
something
to
provide
a
default
say
I
want
to
like
glob
match
on
histograms
and
say
I
want
to
change
all
histograms
to
be
this
thing.
But
I
want
to
allow
users
to
override
specifics.
A
I
think
it's
like
we.
We
can
it's
fine.
I
just
wanted
to
call
out
and
figure
out
if
people
are
still
on
board
with
that
as
the
initial
implementation,
it's
kind
of
an
easy
switch,
but
it
does
have
a
bunch
of
implications
in
java,
around
customization,
endpoints
and
their
override
behavior
and
what
they
can
and
can't
do
any
thoughts
there.
A
A
F
A
F
F
Probably
we
can
avoid
allowing
you
to
have
instrument
regex
for
instrument
selector,
we
can
say
for
custom
views,
you
can
specify
only
one
instrument
and
then
during
initialization
we
can
error
that
you
installed
two
views
with
the
same
name
for
the
same
instrument
or
two
views
with
the
same
name
for
different
instruments
or
whatever
we
want
and
then
default
is
a
different
thing
which
which
we
know
it
has
lower
priority.
And
unless
you
have
a
custom
view,
we
apply
the
default.
A
A
C
F
F
C
H
C
Anymore,
no,
we've
made
it
so
it's
it
is,
it
is
configuration
and
then
static.
The
configuration
is
not
dynamic.
Basically.
A
The
the
thing,
the
thing
that
I'm
kind
of
trying
to
call
out
here,
though,
is,
I
think,
if
we
want
to
allow
a
flexible
view,
registration
method
like
some
of
the
things
I
see
in
java
right,
for
example,
the
java
agent
now
configures
all
summaries
to
be
histograms
in
its
view,
api
as
like
a
default
that
they
added
just
to
to
help
ease
the
migration
as
people
upgrade.
That's
that's
a
feature
that
was
there
that
was
very
useful
to
do
one
of
these
glob
matching
things
somewhere.
A
That's
my
main
concern,
and
so
that's
why
I'm
suggesting
that
we
invert
the
order-
or
we
just
you
know,
make
sure
it's
clear
in
implementation,
that
any
kind
of
user
overrides
need
to
come
first
and
any
kind
of
built-in
defaults
need
to
come
last.
That's
fine,
too!
I
just
wanted
to
validate
make
sure
that
we're
all
aware
of
this
behavior.
A
A
If
you're
going
to
do
that,
you
probably
want
to
put
it
at
the
bottom
of
your
config
just
so
that
you
don't
you
can
override
with
specifics.
That
was
the
one
thing
that
I
didn't
realize:
okay,
let's
move
on
to
john's
question.
C
Yeah
so
we
were
discussing
honorable
was
asking
some
questions
about
the
fact
that
the
up
down
counter
and
the
counter
placed
in
java
have
precisely
the
same
api
and
thought
this
was
a
bit
of
a
smell.
So
I
went
in
this
back
and
saw
that
the
uptown
counter
doesn't
exist
anymore
in
the
spec,
except
that
it,
your
meter,
is
required
to
be
able
to
create
one.
C
A
Api
because
it's
right
hold
on.
A
C
B
C
Under
up
down
counter
creation,
yeah,
like
I
said
it's
under
the
meter
creation,
it's
not
under
the
actual
description
of
the
instruments.
This
is
exactly
what
I
said
so
then
up
down
counter
operations
are
here
right,
but
look
at
the
description
of
the
instruments.
There's
a
section
about
instruments,
and
it
doesn't.
It
is
not
listed
there
section
on
instruments
like
here.
C
F
C
Perhaps
I
I
got
hit
by
github's
weird
show
me
something
really
old,
but
that
comes
up
all
the
time.
I
know
have
you
seen
this
though
github
yeah
show
you
a
cached
version
from
months
ago
without
any
understanding
yeah,
it
does
look
like
it's
there.
Now
and
literally.
I
was
looking
at
it
this
morning
and
it
was
not
there.
C
So
there's
nothing
from
except
the
name
of
the
the
in
java,
the
name
of
the
object
that
actually
distinguishes
that
one
might
or
might
not
allow
adding
negative
values
to
it.
F
Yeah,
so
we
had
this
discussion
if
that
property
should
be
on
on
the
constructor
of
the
object
versus
changing
completely
having
a
different
instrument,
and
the
decision
was
that
for
some
back-ends,
this
difference
is
super
important,
so
that
we
went
with
different
instruments.
Because
of
that
reason
I.
G
F
So
kind
of
you
are
suggesting
on
the
up
down
having
a
decrement.
Maybe
I'm
not
suggesting
that
I'm
saying
that
maybe.
C
A
F
Correct,
I
think,
is
histogram
with
add
or
with
record.
G
We
record
what
what's
happening
here
is
that
we
are
kind
of
being
consistent
in
the
fact
that
we
are
having
the
same
name
for
countering
of
the
encounter
and
a
different
name
for
histogram.
F
B
We've
also
talked
about
how,
if
you
were
going
to
admit
a
synchronous
gauge
instrument,
you
might
use
the
verb
set,
and
the
only
other
discussion
on
this
is
that
prometheus
library
uses
the
verb
observe
where
we
are
using
record
so
observe
and
record
or
close
synonyms.
A
We
do
use
observe
when
we
look
like
a
prometheus,
where
I
should
say
when
we
do
asynchronous
collection.
C
F
I
I'm
trying
to
avoid
sub
I'm
just
considering
ink
and
deck
so
increment
with
one
decrement
with
minus
one
or
because
these
are
very
common
for
counting
number
of
reactive
requests
or
stuff
like
that.
So
then
at
least
that
will
not
have
the
problem
of
sub
with
the
negative
or
sub,
with
the
positive.
E
E
E
It
probably
makes
for
for
easier
code
if
you
don't
have
to
check
if,
if
the
value
that
you
want
to
put
into
the
counter
is
negative
or
positive
before
you
call
add
or
subtract
or
subtract
before
you,
you
called
it.
But
I
don't
know,
maybe
just
add,
isn't
the
right.
The
right
verb
for
an
up-down
counter.
Well,.
G
In
in
a
certain
way,
having
these
kind
of
names
is
redundant
because
the
nature
of
the
operation
is
defined
by
the
instrument
itself,
so
maybe
we
could
just
have
one
name
for
every
instrument.
I
don't
know
like
measure
or
operator
whatever.
C
Things
are
additionally
a
little
bit
more
complex
because,
given
the
requirements
of
the
api
standalone
api
to
not
throw
exceptions,
an
up
down
counter
actually
or
a
counter
needs
to
actually
accept,
be
able
to
accept
negative
numbers
and
at
least
and
then
do
something
with
them-
maybe
ignore,
and
should
the
sdk
ignore
negatives
on
a
counter?
Should
it
accept
them?
What
I
mean,
there's
there's
a
little
bit
of
confusion
there,
because
we're
really
not
supposed
to
throw
exceptions
from
bad
instrumentation
and
how
the
instrument
should
behave
under
those
circumstances.
G
Yeah,
but
that
is
kind
of
an
in
language
dependent
detail,
because
I
think
the
specification
also
says
that
it
it's
okay,
if
open
telemetry
is
executed
in
a
certain
mode
where
exceptions
are
raised.
If
the
intention
is
to
do
some
kind
of
debugging.
G
So
as
long
as
you,
you
can
raise
exceptions
in
the
in
the
api
as
long
as
that's
not
the
default
and
as
long
as
you
have
some
other
way
to
handle
them,
so
it
won't
be
different.
For
this
case,
I
guess.
G
I
mean
yeah,
but
that
that's
a
a
topic
that
I'm
sure
has
affected
other
parts
of
the
of
the
project,
so
we
can
pretty
much
just
say:
follow
the
default
quality
of
optometry.
For
these
situations,
which
I
guess
it
exists.
H
C
Guess
my
point
is,
I
don't
think
it
has
been
specified.
Oh
general
enough
way
for
like
format
these
metric
recordings
about
whether
we
should
ignore
them
or
throw
exceptions
or
try
to
coerce
them
into
something
that
makes
sense.
Or
I
mean
we
have
it.
We
have
a
general
rule
of
don't
throw
exceptions,
don't
break,
don't
break
the
users
out
if
they
do
something
wrong,
but
the
metric
case
seems
slightly
different
than
the
like.
The
tracing
cases,
we've
kind
of
defined.
What
the
default
behavior
should
be
if
people
send
in
that
data.
A
Let's
so
we're
we're
about
at
time,
let's
open
a
bug
on
what
to
do
there
and
address
that
as
part
of
so,
let's
hit
feature
freeze
for
the
sdk
in
terms
of
features,
and
then
that
is
what
I
would
call
polish
as
we
implement
this.
We
can
try
to
figure
out
best,
behavior
and
and
solve
that,
but
let's
open
a
bug
and
track
that
make
sure
that
we
do
it.
John,
would
you
mind
opening
that
bug?
I
can
do
that
yeah.
A
I
think
I
think
that's
going
to
be
super
critical,
going
forward
to
make
sure
we
have
good
error
messages.
The
we
had
a
discussion,
the
javascript
I'll,
just
I'll,
just
open
this
up
as
well
around
here
it
was
on
one
of
the
the
pull
requests
around
error,
messages
for
view
conflicts
and
how
to
show
those
to
users.
A
Just
as
an
open
question,
so
that's
probably
something
we
need
to
look
into
and
make
sure
that
error
message
is
good,
make
sure
as
we
implement
this.
We
have
enough
provenance
of
instruments
and
views
to
understand
where
the
conflicts
are
coming
from
and
give
users
guidance
on
how
to
fix
it,
because
it
it
gets
really
complicated,
really
fast
with
the
current
spec.
A
So
we
should
have
good
error
messages
anyway,
if
it's
okay
with
everybody,
let's
table
that
and
then
I'm
gonna
open
the
floor
for
josh
to
tell
us
about
updates
to
any
of
the
histogram
related
stuff
or
updates
to
sampling
things
that
will
somehow
impact
exemplars
and
specification
here.
B
B
B
It
is
certainly
a
very
small
issue
that
we
are
at
the
point
of
debating
right
now,
but
it
is
also
the
kind
of
thing
that
gets
in
the
way
of
open
source
open
protocols
to
have
these
disagreements.
So
I'd
like
your
help,
if
josh,
maybe
you
want
to
since
you're
presenting
just
click
into
the
this
pr-
and
I
can
you
know-
score
scroll
down.
A
B
So
this
you
know,
if
you
read
through
it,
there
have
been.
I
the
first
take,
was
literally
taking
a
prometheus
draft
and
putting
it
in
there
to
see
what
people
would
say.
The
first
feedback
came
in
as
sort
of
like
this
seems
like
maybe
more
complicated
than
you
want
for
a
transport
protocol.
This
is
maybe
appropriate
for
a
storage
protocol.
B
I
agreed
and
I
did
a
change
and
then
at
this
point
we're
you
know
down
to
debating
something
that
almost
doesn't
matter.
This
is
about
zero
bucket
width.
If
you're
an
exponential
histogram,
the
zero
bucket
has
to
be
special
and
the
question
is:
how
special
is
it?
Does
it
have
a
width?
Does
it
have
a
mass
or
a
density,
and
those
are
the
questions
we're
looking
at
it's
connected
with
whether
we
have
a
greater
than
or
a
less
than
equals
or
the
opposite?
B
You
know
bucket
boundaries,
whether
the
buckets
are
bucket.
Boundaries
are
inclusive
or
not,
and
we've
there's
an
argument
that
that's
irrelevant
in
practice,
and
I
I
I
am
at
the
point
of
not
caring
about
any
of
these
details
anymore.
So
you
can
tell
I'm
a
little
frustrated
and
I
don't
know
what
to
do
about
it.
A
You
think
it's
just
this
inclusiveness
exclusiveness,
that's
the
the
last
hurdle
like
it's
just
this.
B
Well,
the
the
reason
why
this
was
reopened
is
that
I
so
I
mean
I
feel
like
coming
from
open
census.
I
feel
like
coming
from,
I
don't
know
math
books
in
my
my
past,
you
know
maybe
having
an
exclusive
upper
bound
and
an
inclusive,
lower
bound
is
a
little
more
standard,
a
little
or
maybe
more
conventional
in
in
mathematics,
education,
perhaps
but
prometheus
has
an
established
convention
in
its
explicit
histogram
of
using
the
opposite,
so
you
have
an
inclusive
upper
bound
and
exclusive
lower
bound.
B
There
has
been
a
debate
in
the
past
over
this.
This
is
not
the
first
time
in
which
we,
because
we
flipped
our
our
protocol
at
some
point
around
point,
0.5
0.7
and
basically
argued
it
doesn't
really
matter.
The
less
than
versus
less
than
equals
is
not
functional
because
you
never
have
an
exact
value
or
you
know,
our
precision
of
measurement
is
not
so
great
that
we
can
have
exact
numbers
like
that.
So
if
you
accept
that
argument,
then
it
just
sort
of
doesn't
matter.
B
However,
you
know
if
you
read
up
a
little
bit.
What
was
what
was
being
said
is
that
prometheus
asked
for
this
concept
of
a
zero
bucket
width.
The
question
is
whether
you
specify
the
zero
bucket
with
it's.
It's
intended
to
be
optional.
First
of
all,
I
I
don't
really
particularly
care
for
it.
It's
it's
just
that
I
want
to
be
accommodating
for
premier
atheists.
I
do
think
it's
something
we
can
add
later
the
concept.
B
However,
the
reason
why
I
flipped
a
little
bit
on
my
opinions
about
the
inclusive
exclusive
upper
bound
is
that
atmar
pointed
out
a
slight,
in
my
opinion,
slight
advantage
of
of
considering
the
the
way
we
represent
this
zero
bucket
width.
If
the
question
now
is
whether
the
zero
bucket
width
is
being
expressed
as
an
inclusive
or
exclusive
bound,
so
if
you
have
a
protocol
semantics
where
zero
is
your
default
value,
then
having
zero,
the
the
meaningful
inclusive
upper
bound
was
proposed,
and
I
think
that's
sensible.
B
B
But
if
you
do
that,
then
we
are
definitely
sort
of
fixing
this
decision
about
inclusive
exclusive
bounds.
Given
that
I
don't
really
care
about
this
zero
bucket,
it
is
a
concept
that
is
well
defined,
but
not
very
important
to
me.
B
I
sort
of
don't
care
the
reason
why
I
liked
going
with
inclusive
upper
bound.
Is
it
satisfies
prometheus?
It
follows
convention
with
prometheus
and
it
gives
you
the
ability
to
add
this
zero
bucket
later
the
zero
bucket
with
later
as
an
exclusive
as
an
inclusive
upper
bound.
I
keep
getting
this
wrong.
I
hope
that
that's
summarized
it's
pretty
hard
to
explain
this
particular
detail.
B
F
B
Count,
it's
all
it's
a
special
bucket.
It's
neither
positive
nor
negative.
It's
just
the
zero
bucket,
and
what
we're
debating
here
in
this
thread
is
whether
the
zero
bucket
has
a
nominal
width
or
not,
and
it
doesn't
need
to.
If
you
have
a
number
that
is
like
extremely
small,
like
you
know,
two
to
the
negative
100
it
fits
between
zero.
It
has
a
real
bucket
in
our
you
know.
It
can
be
given
a
real
bucket
index
can
be
described
in
our
protocol,
but
it
is
sort
of
you
know.
B
I
think
many
people's
opinions
like
if
you're
recording
a
value
of
2
to
the
negative
100.
You
better
know
what
you're
doing,
because
there
are
a
lot
of
buckets
around
2
to
the
negative
100..
It's
extremely
dense
those
buckets
and
chances
of
your
actually
meaning
it.
When
you,
you
know
like
what
what's
intended
when
you
put
a
really
small
number
in,
should
you
get
zero
or
should
you
actually
create
a
new
range
in
your
histogram?
B
That's
like
all
the
way
down
around
two
to
the
negative
hundred,
which
is
is
questionable
whether
anyone
wants
that
type
of
precision
and
that's
what
this
debate
is
about,
whether
you,
whether
when
you
set
up
your
instrument
for
a
histogram,
whether
you
should
say
values
below
10
to
the
negative
10
or
you
know
something
like
something
extremely
small-
are
considered
zero.
And
so
I
wrote
this
protocol.
B
B
But
we're
following
that
prometheus
convention
saying
that
buckets,
have
inclusive
upper
bounds
and
there's
an
option.
In
my
opinion,
uk
maybe
doesn't
agree,
but
but
I
think
opmah-
and
I
are
on
the
same
page-
is
that
we
can
decide
later
to
add
a
new
field
called
zero
tolerance.
It
will
be
the
largest
value,
inclusive
that
falls
into
the
zero
bucket,
at
which
point
you
can
then
create
a
special
bucket
from
zero
to
your
inclusive
upper
bound,
which
would
be
an
optional
field
that
optional
field
is
not
set.
B
A
B
That's
right,
I
I
think
it
can
be
implicit.
That's
that's
that's
what
most
people
would
assume.
I
think,
but
then,
in
this
it's
sort
of
a
prometheus
has
created
this
concern
that
that,
if
you,
you
might
want
to
know-
and
I-
and
I
don't
quite
know
why
you
might
want
to
know-
and
what
was
said
up
further
up
in
that
review
thread
was
if
we
are
going
to
agree
to
a
field
such
as
zero
tolerance,
we've
got
to
really
pin
down
what
you
do
with
it
when
we're
processing
it.
B
So
if
I'm
merging
two
histograms
with
different
zero
tolerances,
what
do
I
do
and
that's
why?
I
think
we
should
leave
it
out
for
now
and
I
think
it
makes
sense
to
follow
prometheus
convention
just
there's
no
reason
to
try
and
change
the
inclusive
exclusive
property
that
I
can
see
just
because
our
math
books
taught
us
to
think
inclusive,
lower
bound
for
whatever
reason
prometheus
went.
The
other
reason
the
other
way,
and
I
don't
want
to
try
and
change
their
minds.
B
It'd
be
really
useful
if
a
few
people
who
have
heard
this
could
get
in
there
and
and
just
sort
of
like
try
and
help
us
close
it
out.
I
think
it
does
seem
like
there's
a
disagreement
and
you
know
take
a
side
and
stop
telling
you
which
side
to
take
but
take
a
side.
It'll
help
us.
B
And
I
don't
so
so
you
you
handed
me
the
floor
and
asked
me
to
talk
about
anything
histogram
or
sampling
related.
I
don't
think
I
have
anything
that's
worth
discussing
here
in
the
sampling
context
right
now,
there's
a
lot
going
on
and
then
I'm
going
to
go
to
a
w3c
meeting
later
today
to
talk
about
that.
A
B
F
F
B
An
interesting
idea,
it's
kind
of
genius,
though
again
I
like
it,
will
you
say
that
in
the
thread
please.
B
B
This
is
322.,
but
I
don't.
A
F
B
F
A
B
Plan
was
to
take
that
histogram
in
the
collector
and
try
to
implement
statsd
receiver,
which
would
generate
the
histogram.
And
then
then
we
can
look
at
the
code
and
see
what
we
really
care
about,
because
I
think
that
a
lot
of
the
existing
processors
and
exporters
are
not
going
to
know
how
to
handle
this
right
away.
They're
going
to
want
to
have
a
utility
to
con
convert
either
way,
essentially
and
and
that's
probably
going
to
have
to
be
implemented.
A
B
Yeah,
well,
I
was
thinking
about
it
and
I
know
that
georg
has
demonstrated
some
go
code
that
from
from
omar's
prototype-
and
I
was
gonna-
take
that
so
that
was
helpful.
I
sort
of
feel
like
the
task
is
not
involving
a
lot
of
histogram
or
science.
It's
really
learning
the
collector
code
base,
which
I
think
it's
on
us
to
do,
and
I
and
I'm
sort
of
gearing
up
to
to
be
able
to
sort
of
stand
behind
it.
B
But
if
anyone
else
wants
to
like
really
get
involved
in
writing
histogram
code
for
this
collector,
it's
going
to
be
a
lot
of
work
and
maybe
contact
me
and
we
can
try
and
break
it
up.
But
it's
like,
I
spent
all
yesterday
or
all
day,
but
a
long
time
learning
how
to
build
the
proto-generated
files
and
modifying
the
gen
p
data
stuff.
So
I
have
modified
gen,
p
data
and
so
like
next
step
would
be
to
start
making
making
conversions
and
so
on.
Anyway.
D
B
Thanks
everyone,
please
update
those
that
histogram
thread.
If
you
have
opinions,
I
love
the
idea
of
not
having
account
at
all
one
less
field.
That
requires
a
few
people
to
think
about.
It.
A
Awesome,
well,
I
don't
have
anything
else.
I
think
just
a
reminder
to
please
take
a
look
at
the
exporter
specification
as
well,
and
then
we'll
take
a
second
glance
now
that
I
think
aggregator
has
enough
approvals.
We
converge
that
one
right,
because
I
think
post
that
export
respect
there'll
be
a
pool
exporter
spec
coming
from
riley,
so
we
should
expect
that
soon
and
hopefully
we
get
the
sdk
to
the
point
where
people
are
implementing.
A
I
think
next
meeting
I'd
like
to
hear
a
status
on
implementation
for
voc.
If
anyone
can
do
that,
so
awesome
see
y'all.