►
From YouTube: 2022-07-28 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
B
Yeah,
it's
been
a
few
weeks.
Damn
are
you
tan,
just
the
back
of
my
neck.
C
Actually,
it's
already
almost
10
past.
Let's
just
get
started:
okay,
cool
as
usual.
Please
add
your
name
to
the
attendees
list
for
this
week,
as
well
as
any
issues
or
prs
that
you
want
to
bring
up
or
talk
about,
they'll
probably
be
expedited
here
at
the
end
of
it,
we'll
probably
go
over
our
metrics
project
to
see
how
our
progress
is
doing
for
that
and
yeah.
That's
pretty
much
it
so.
D
Okay,
so
actually
I
wanted
to
discuss
web
sockets
in
case
of
ascii,
like
you
know,
based
frameworks,
so
I
wanted
to
mainly
discuss
how
are
we
planning
to
handle,
like
you
know,
websocket
type
of
connections
and
like
without
correct
implementation?
I
see
there
are
a
lot
of
like
you
know,
like
you
know,
places
where
the
testings
are
not
done
or,
like
you
know,
some
like
there
are
some
things
which.
D
Feel
so
if
we
want
to
discuss
that
thing
so
should
like
you
know,
is
it
the
right
place
to
I
mean
right
time
to
discuss?
Maybe
after
the
end
of
this.
D
Okay,
so,
for
example,
in
case
of
web
sockets,
I
see
I
mean,
like
you
know,
the
status
quo
code
is,
for
example,
status
quo
is
not
like
you
know,
present
in
web
circuit
type
of
connections.
So
what
we
are
going
to
do
is
actually
directly
like
you
know,
adding
it
adding
200,
like
you
know,
hard
coding,
200
there
and
but
in
like
currently,
I
was
working
on
a
matrix
implementation
in
ascii
based
frameworks,
so
there
there
is
a
like.
I
need
to
calculate
the
time.
Duration.
D
D
Continuous
communication,
so
it
may
could
be
a
lot
of
you
know
in
this
way.
The
way
we
calculate
http
time
duration.
So
that's
also
a
second
thing
which
I
feel
am
I
clear.
I
mean.
C
Yeah,
you
did,
you
did
cut
off
a
little
bit
at
the
end,
but
I
I
think
I
got
the
gist
of
what
you're
saying
yeah.
D
Yeah
sorry
go
ahead,
go
ahead!
Sorry.
D
Okay,
apart
from
that,
I
feel
I
was
like
you
know
so
far,
so
as
I
guess
we
discussed
in
the
last
meeting,
I
was
not
present
in
the
last
meeting,
so
we
discussed
that
we
are
not
going
to
implement
matrixes
for
web
socket,
like
I
know,
that's
what
we
discussed
but
like.
D
I
wanted
to
also
add
some
test
cases
for
that,
like
in
case
of
like
you
know,
websocket
type
of
request,
though
I
wanted
to
test
the
success
of
a
request,
but
I
see
there
are
no
like
you
know,
like
you
know,
test
based,
you
know
setup
for,
like
in
websocket
type
of
community
connection.
I
see
only
an
http.
We
can
only
test
http
with
our
current
setup,
but
not
like
you
know.
Web
socket
connections.
D
D
Yeah,
but
at
a
lot
of
places
one
possible
way
could
be
like
you
know:
we
can
directly
test
whether
the
connection
is,
whether
is
it
an
http
or
not,
and
if
it
is
not
http,
we
can
directly,
like
you
know,
return
the
app
this
response
instead
of
going
creating
presses
and
all,
but
what
we
are
doing
is
we're
actually
creating
some
traces
and
spans
for
web
circuits.
I
think
we
should
also
test
test
web
server
type
of
connections
also,
but
we
are
not
adding
any
tests
for
that.
C
I
believe
we
have
to,
I
think
the
only
thing
we
do
is
we
don't
differentiate,
whether
it's
a
http
or
a
websocket
request
right.
A
A
C
Did
you
have?
Did
you
have
a
question
for
what
angel
was
saying.
C
Answer
please
go
ahead.
D
Okay,
so
should
I
share
my
screen
and,
like
you
know,.
A
D
Yeah,
okay,
so,
for
example,
this
is
like
you
know,
an
ascii
like
you
know,
implementation
for,
like
you
know,
instrumentation,
and
you
see,
we
are
actually
like.
You
know,
differentiating
on
the
basis
of
web
sockets
in
case
of
send
and
receive
caller.
Let
me
let
me
show
you,
okay,
yeah,
for
example.
Here
what
we
are
doing
is
we
are
checking
whether
the
type
of
message
is
an
http
response
or
a
web
socket
dot,
send
and
in
case
of
web.
D
Second,
we
are
actually
sending
status
code
as
200,
and
similarly
there
are
also
in
case
of
receive
also
we
are
like
you
know,
checking
whether
it
is
a
websocket
connection
or
not.
So
we
are
kind
of
like
giving
a
support
for
web
socket,
but
in
case
of
matrices
time,
duration,
all
these
things
are
not
you
know,
will
be
not
fit
in
case
of,
like
you
know,
with
fit
for
web
socket.
D
C
Well,
this
correct
me:
if
I'm
wrong,
if
anyone
else
knows
the
context
of
this,
but.
F
I
can
jump
in
I'm
sure
so
this
I
mentioned
this
in
the
last
meeting
everything
around
the
web
socket.
You
can
keep
it
aside.
It
is
so
some
like
instrumentation
is
there.
We
do
not
know
how
much
does
it
cover
the
real
world
cases
and
then
how
many,
how
much
of
the
you
know
coverage
do
we
have
for
that
so,
and
there
are
a
lot
of
issues
that
are
open
still.
I
know
how
to
handle
that
you
can.
F
The
the
websocket
part
you
can
handle
it
separately
so
for
now
work
it
on
the
like
the
instrumentation
just
make
sure
that
the
work
that
you
are
doing
is
covered
for
the
http
responses.
Only
you
do
not
have
to
worry
about
the
web
sockets
in
the
same
issue,
so
there
I
you
know
shared
the
couple
of
issues
where
we
already
have
the
like
some
ongoing
discussion
on.
How
do
we
want
to
handle
the
websocket?
F
If
we
have
anything
like
all
your
observation,
you
can,
I
know
note
it
down
there
and
then
let's
say
you
want
to
improve
test
or
you
want
to
improve
like
how
it's
handled.
You
can
note
it
there,
but
yeah
the
entire
everything
related
to
web
sockets.
You
can,
you
know,
work
in
a
different.
You
can
send
a
separate
pr.
You
do
not
have
to
include
the
matrix
instrumentation
for
that
right
now.
D
Okay,
okay,
so
for
so
for
now,
I
think,
like
what
from
what
I
got
from
what
I
understood
is
for
now.
I
can
just
simply
check
whether
the
current
request
is
http
or
not,
and
if
it
is
http,
then
I'll,
like
you
know,
add
the
instrument
that
the
mattresses
that
we
are
collecting
and
if
it
is
not,
then
we
will
just
simply
like
you
know,
skip
it.
Is
it
is
it?
What
do
you
mean
yeah.
F
Yeah
do
not
bother
about
the
web
sockets
but
now
like,
if
you
have
proposal
like
if
you
want
to
address
it
in
the
same
issue,
then
you
are
obviously
welcome
like
right,
like
share
how
you
want
to
address
that
in
the
issue.
We
can
discuss
it,
but
it's
an
optional
thing
like
you.
Do
not
have
to
do
that
if
you
want
to
do
it
in
the
same
issue,
share
it,
how
you
want
to
do
it
and
then
we
can
continue
that
discussion.
F
Yeah
so
yeah,
I
was
saying
that
it's
an
optional
for
now,
but
if
you
want
to
add
it
in
the
issue
like
in
the
same
pr,
you
can
do
it
as
well.
D
Also
one
more
thing
just
like
this
last
one
thing
so
like
you
know
for
now,
if,
if,
for
example,
if
I
only
like
an
add
matrices
for
stdp,
I
wanted
to
test
whether
my
current
implementation
of
matrix
works,
fine
for
websocket
type
of
correction
or
not
so,
should
I
add
a
test
for
that
or
like
it
it's
it
is
it's
also
fine
that
I
do
not
test
that
thing
I
mean.
C
So
I
have
a
question
about
that:
I'm,
not
I'm
not
too
familiar
with
web
sockets,
but
wouldn't
what
like
us,
requests
sent
through
a
websocket
be
covered
with
a
different
set
of
semantic
conventions
for
metrics,
like
it
doesn't
fall
under
http
right.
F
So
the
way
the
the
connections
are
handled
like
it's,
not
so
you
you
have
the
in
in
case
of
http,
you
have
the
request
response
model,
but
websocket
they
continue
to
maintain
it
for
longer
times.
I
think,
though,
I
I'm
not
aware,
like
any
semantic
convention
defined
fire
rate,
I'm
not
sure
how
other
languages
that
have
already
implemented
that
yeah
it's
it's
unclear
how
it
should
be
done.
F
C
Right
so
it
doesn't
even
seem
like
metrics
for
websocket
type
scenarios
is
even
defined
that
well
so
right,
like
we
shouldn't
be
bothering
implementing
it
for
those
scenarios
for
any
instrumentations.
F
Like
that's,
not
something
we
do
not
have
to
what
in
right
now,
it
should
be.
C
Right,
so
actually,
actually,
if
you
actually
test
it
for
a
web
socket
scenarios,
and
even
if
you
do
get
them
to
pass
whatever
you
do,
it
could
be
wrong
like
it
could
be
not
what
we
it
could
be.
The
metrics
represent
something
we
don't
want
to
represent
eventually
in
dismantling
conventions.
D
C
I
guess
there's
no
issues.
I
put
up
a
pr
real,
quick.
It's
just
one
of
the
prs
for
the
metric
stable,
relates
to
removing
the
environment,
vendor
variable
usage
for
ulti
lplp,
to
plurality,
preference
for
the
generic
metrics
reader.
The
solution
is
kind
of
hacky,
but
I
don't
see
a
better
way
to
do
it
that
isn't
hacky.
I
actually
have
to
check
for
the
class
name
to
see
if
the
ex
passed
an
exporter
in
the
metrics
reader
is
an
otlp
exporter
or
not.
C
C
So
if
anyone
has
any
other
suggestions
to
do,
it
feel
free
to,
let
me
know
but
yeah
it's
it's
I
I
don't.
I
don't
have
any
other
ideas
right
now.
So.
E
Yeah
I
mean
I
took
a
look
into
his
pr
yesterday
and
thought
about
it
for
a
very,
very
long
time
and
yeah.
I
got
to
pretty
much
the
same
conclusion
that
later
on
that
it's
it's
just
not
possible
to
not
include
a
hacky
solution
here.
If
we
don't
want
to
have
a
dependency
between
the
sdk.
E
Sorry,
if
we
don't
want
to
make
the
sdk
have
a
dependency
on
the
ltlp
exporter
right,
so
so
yeah.
I
think
these
this
will
have
to.
C
Yeah
cool,
if
I
could
get
some
more
reviews
on
it,
it's
pretty
pretty
straightforward.
Actually,
besides
from
the
questionable
solution,
so
yep
any
other
comments
on
this.
B
Cool
I'll
take
a
look
offline,
but
is
there
no
way
for
the
for
for
this
to
be
like
checked,
sorry,
checked
in
the
otlp
exporter
and
then
sent
on
to
the
reader
like
yeah.
E
F
That's
true,
but
like
one
of
the
things
that,
like
one
of
the
ways
that
we
discussed
like
in
the
previous
call,
is
that
we
can
make
the
exporters
implement
the
what
is
their
preferred.
Temporality,
let's
say
otlp
has
like
you
know
it
will
be
based
on
this
env
or
it
will
be
something
that
they
can
use
can
pass
like.
Let's
say
prometheus,
it
will
always
be
cumulative,
so
the
reader
would
use
that
interface
definition
and
then
configure,
like
you
know,
set
this
up.
E
Yeah
that
could
be,
I
don't
know
if
that's
spec
compliant
as
far
as
I
remember,
the
definition
of
preferred
temporality
and
preferred
aggregation
was
something
that
concerned
the
reader,
not
the
exporter.
F
I
I
believe
there
was
a
mention
about
that
leadership.
F
Car
like
later
should
ask
the
exporter
what
its
preferred
temporality
and
then
send
it,
but
I'm
not
confident
right
now
that
it
is
if
it's
still
the
case,
but
I
can
look
it
up
and
see.
E
B
So
I
think
that's
what
I
had
in
mind
and
somebody
correct
me
if
I'm
wrong,
but
this
really
only
applies
to
the
periodic
exporting
metric
reader
right
like
that
one
isn't
coupled
to
the
exporter
interface,
the
push
exporter.
So
like
you,
we
can
add
stuff,
that's
not
in
this
in
the
spec,
necessarily
as
long
as
we're
still
implementing
the
spec
right.
E
C
Yeah,
if,
if
you
can
configure
it
through
environment
variables,.
E
C
Possible
yeah,
but,
like
I
don't
know,
are
we
are
we
are,
are
we
making?
Are
we
introducing
and
increasing
our
api
surface?
Just
because
we
have
this
like?
Would
we
would
we
would
we
implement
that
feature,
the
temporality
preference
and
probably
aggregation
preference
for
exporters?
If
we
didn't
have
to
do
this.
C
C
If
we,
if
we
allow
exporters
to
configure
their
temporality
and
aggregation
preference
right,
then
that's
just
another
thing:
users
can
do
right
through
our
apis
and
also
then
we
have
to
think
about
like
now.
We
can
configure
temporality
in
three
different
places
right
or
actually,
two
or
actually
three
right
views,
readers
and
exporters.
Now
right.
E
Views
no!
No,
because
we
will
be,
we
will
be
moving
the
no.
You
mean
views
readers,
flash
exporters
and
environment
marvels.
C
E
A
C
But
is
it
like,
don't
we
need
to
check
the
temporality
to
know
how
to
like,
like
convert
some
data,
sometimes.
E
E
C
Right
so,
okay,
so
like
does
anyone
else?
Have
any
comments
on
this
because,
like
I,
I
don't
for
see
a
very,
very
strong
reason
to
just
like
make
make
something
temp
like
like
not
as
not
as
great
for
this
small
feature.
E
The
the
only
elegant
solution
that
I
see
is
the
one
that
slick
and
iron
mentioned
about
moving
this
configuration
into
the
exporter
itself,
but.
E
Sorry
adding
it
adding
it
there,
but
even
in
that
case,
we
will
need
to
somehow
figure
out
that
that
exporter
has
that
configuration
and
make
the
reader
extract,
that
configuration
from
the
exporter
and
that
will.
E
Yeah
well,
another
solution
would
be
to
implement
a
subclass
of
the
periodic
exporting
blah
blah
metric
reader
and
putting
that
subclass
in
the
in
the
exporter
package.
E
So
if
someone
want
wants
to
use
the
periodic
for
the
metric
reader
with
the
exporter
that
someone
will
have
to
use
the
the
reader
that
is
provided
in
the
exported
package,.
E
E
And
that
is
a
specific
use
case
for
the
dlp
exporting
metric
here.
So
I
think
that
leanest
way
will
be
for
the
otp
export
metric
hotel
b
exporter
to
provide
it
its
own.
I'm
just.
C
C
C
E
No,
no,
it
won't
be
the
same
thing,
because
in
that
way
you
will
have
both
classes
in
the
same
package,
and
you
can
just
check
that
that
metric
reader
is
not
paired
with
any
other
exporter.
That
is
not
of
that
otlpix
for
a
class
right.
C
E
C
What
does
anyone
else
have
any.
B
Them
all
in
this
base
class
is
not
going
to
scale,
so
you
know
for
to
have
some
way
to
do
this
in,
like
a
not
hardcoded,
more
dynamic
way.
I
think
that
that
is
worth
worthwhile
so
like
and
then
also
to
diego's
point
like
we
don't
have
to
have
a
subclass
of
periodic
exporting
metric
reader,
the
actual
exporter.
B
So
whatever
we
get
for
the
the
environment,
variable
hotel
metric
exporter
that
that
instance
could
provide
a
method
which
just
generates
or
creates
the
metric
reader
based
on
all
of
the
configuration
it
knows
about
right,
just
as
another
alternative,
but.
C
B
C
C
Wait
so
back
to
your
previous
point:
you
foresee
exporter,
specific
environment
variables
and
configuration.
B
Yeah
so,
like
I
think,
the
environment
variable
for
this,
for
this
pr
was
hotel
exporter,
otlp
metrics,
temporality
preference,
like
you
know
what,
if
it's,
what
if
it's
aggregation,
you
know
yeah
well,
also
what,
if
it's
not
otlp?
What,
if
it's,
google
cloud
exporter
license
exporter,
you
know,
etc.
Right.
C
C
E
Now,
what
happens
is
that
even
if
they
can't
be,
we
already
have
a
a
situation
here,
even
if
it's
only
one
and
it's
better,
if
we
don't
put
any
anything
explorer
specific
in
the
sdk.
C
So
what
was
the?
What
was
the
alternative
solution
that
you
suggested
aaron.
B
Yeah,
I
think
so
so
the
alternative
would
be
when
you
load
the
hotel,
metrics
exporter,
whatever
gets
provided
by.
That
has
a
method
that
can
return
the
metric
reader
that
you
need
right.
B
So,
basically,
what
I'm,
what
I'm
suggesting
is
the
otlp
metric
exporter
would
have
a
function,
create
a
metric
reader
that
could
be
used
for
this
sort
of,
like
dynamic
environment.
Variable
based
configuration.
C
Yeah,
but
like
it's,
it's
like
the
user
would
have
to
still
do
different
stuff
right,
yeah.
E
Yeah
but
but
that's
the
same
case,
what
I'm
trying
to
say
is
that
in
the
approach
that
I'm
suggesting
the
the
user
instantiates
this
new
special
metric
reader
class
by
itself
and
in
the
approach
that
aaron
suggests,
they
call
a
specific
function
that
creates
a
metric
reader.
A
pretty
expert
exporting
material
that
is
ready
to
use.
C
F
I
I
would
be
great
if
I
I
I
sort
of
got
it
like
it
will
change
how
we
ask
users
to
you,
know
work
with
these
classes,
so
what
I
was
so
there
is
this
line
in
the
specification
that
says,
metric
exporters
have
always
associated
with
the
metric
reader.
The
aggregation
and
the
temporality
properties
used
by
the
sdk
are
determined
when
the
registering
the
metric
exporter
through
their
associated
metric
reader,
so
open,
telemetry
language
implementation
may
support
automatically
configuring
integrated
to
use
for
an
exporter.
A
C
B
This
is
copied
from.
I
believe
this
is
really
similar
in
the
tracing
spec.
It
just
means
that
you
shouldn't
do
like
you
know
you
should
try
not
to
do
like
batching
re-aggregation,
any
crazy
stuff.
It's
just
supposed
to
be
like
hey,
take
this
data
and
send
it
to
the
the
endpoint
that
we
want.
I
think
that's
what
they're
trying
to
get
out
here.
C
Sure,
but
doesn't
wouldn't
that
also
include,
like
hey,
take
a
look
at
your
preferred
temporality
and
aggregation
configuration
and
modify
your
or
create
a
new
metric
reader
based
off
of
that
like
wouldn't
that
be
included
as
well.
B
C
Wouldn't
when
that,
when
this
minimized
burden
of
implantation
cover
like
configuring,
a
new
metric
reader
as
well
like,
we
wouldn't
want
to
do
that,
it's
adding
more
complexity
to
exporters.
B
Yeah,
I
see
your
point,
I
I
agree.
It's
like
it's
definitely
more
complex.
I
think
if
you,
if
you
want
to
like
really
break
things
apart
and
have
you
know
like
single
responsibility
for
each
component,
I
think
it's
reasonable
that
we
could
come
up
with
like
a
factory
or
something
like
that
that
corresponds
to
the
environment,
variable
hotel,
metrics
exporter,
which
provides
like
a
metric
reader
and
exporter,
or
something
like
that
like
yeah,
we
don't
have
to
add
it
directly
in
that
one
spot.
I
think
the
the
issue
here
is
like
for
tracing.
B
We
have
hotel
traces
exporter
and
there's
only
a
single
interface
and
the
tracer
provider
accepts
that
directly,
whereas
with
metrics
we
have
this
like
pull
and
push.
So
we
have
sort
of
like
a
level
of
indirection
and
two
things
have
to
be
configured
so
we're
trying
to
you
know:
we've
got
to
somehow
make
those
things
fit
together
and.
C
Also
question:
if
we
create
a
different
kind
of
metric
reader
eagle
talking
about
your
solution,
does
that
mean
that
I
cannot
use
multiple
exporters
with
it.
E
C
C
Yeah,
like
I'm,
I'm
still
coming
kind
of
like
taking
a
step
back
and
still
wondering
like
is,
is
this
all?
Is
this
all
worth
it
to
just
cover
that
this
one
scenario
I
could
totally.
A
C
The
argument
like
like
aaron's
point
like
if
there
is
future
exporter
specific
configuration
through
environment
variables,
we
would
definitely
need
a
different
mechanism
than
this
right,
but
that's
defined
by
the
spec.
We
would
definitely
need
it.
C
That
could
be
an
argument
that
I
could
go
for,
but
if
it's
just
to
cover
this
scenario
like
I,
I
don't
think
it's
worth
it.
In
my
opinion,.
E
A
E
C
A
C
E
That
that's
that's
the
the
what
I
I
don't
find
it
consistent.
If
we
are
going
to
say
this
exposure
is
different
from
others,
because
it's
defined
in
the
spec,
then
it's
hard
to
to
argue
against
another
special
consideration
that
we
will
give.
This
exposure,
see
that
that's
where
I
I
find
it
to
be
inconsistent.
C
I
see
what
you're
saying
yeah:
it's
like.
I
guess
it's
just
like
a
matter
of
opinion
like
I
think,
there's
a
limitation
to
what
special
means,
but
I
I
get
what
you're
saying
does
anyone
else
have
any
opinions
based
off
this,
because.
E
Yeah
my
other
opinion,
if
you
can
take
a
look
at
the
implementation
itself,.
C
E
Okay,
basically,
what
we're
doing
in
line
329
is
just
checking
if
the
class
name
contains
otlp
right.
Yes,
and
if
it
does,
then
we
say:
oh
okay,
this
is
a
an
otlp
exporter
and
we
gotta
do
something
special
for
you:
okay,
yes,
okay!
Now
that
is
the
we
could
do
the
same
by
using
this
instance
and
checking
that
the
the
class
of
the
exporter
is
an
otp
metric
exporter.
E
But
if
we
do
that,
then
we
will
need
to
add
the
exporter
as
a
dependency
right,
because
we
will
need
to
import
the
class
from
somewhere
in
blah
blah.
So
this
thing
that
we
are
doing
here
in
line
329
is
doing
pretty
much
that
it's
just
doing
it
in
a
very
obscure
way
by
just
checking
the
the
a
particular
substring
to
be
existing
there.
E
It's
it's
even
vulnerable,
because
I
don't
know.
Maybe
someone
creates
another
exporter
and
names,
it
otlp
special
metric
exporter,
and
that
will
fail
right.
Yeah
absolutely
will
be
there.
E
E
Against
that,
my
point
is
I
I
don't
want
that
to
happen.
I
also
understand
that,
having
that
as
a
dependency
of
the
ack
is
a
bad
thing,
my
point
is
just
that
we
don't
need
for
this
to
happen
again
in
in
another
scenario,
hypothetical
scenarios
suggests
I
think
we
already
have
an
actual
scenario
that
justifies
finding
another
approach
right
now,
this
one.
C
E
E
Yeah,
we
in
theory
could
provide
a
general
purpose
method
to
every
explorer
that
will
be
called
for
by
every
metric
reader
as
well.
B
B
Should
take
the
yeah
into
the
discussion
for
the
pr
yeah
just
because
we're
running
out
of
time?
I
know
we
wanted
to
go
over
the
metrics
forward,
so.
A
E
Okay,
I
edited
the
topic
so
real,
quick.
I
wanted
to
say
thank
you
srikant
and
later
great
progress
on
these
she's
getting
done
right
now.
We
have
all
these
issues
in
progress.
I
have
three
of
them
and
I'm
working
on
them
right
now.
I
expect
to
have
a
pr
today.
I
finally
can
now
understood
the
spec
enough
to
drop
something
now,
so
we
can't,
I
already
approved
your
histogram
timer
context
manager
pr.
The
issue
2756
only
needs
another
approval.
E
So
if
someone
can
please
take
a
look,
it
would
be
great
and
they
wanted
to
ask
this
weekend
about
that
issue.
25
5-0,
the
last
one:
oh
yeah,
no
yeah
that
one
second
are
you?
Are
you
working
on
it.
F
Yeah
I
have
a
draft
player
for
that.
It
will
also
have
some
conflicts
with
what
latin
has
implemented
yeah.
I
can
open
it
like
make
this
ready
for
review
eventually.
Basically,
I
I
worked
on
that.
I
can,
you
know
you
know
clean
it
up
and
then
open
that
reviews.
F
E
Okay,
great,
so
the
pending
issues
we
have
here
are
three
that
are
about
documentation.
E
E
B
Okay,
I
feel
like
this
issue
is
maybe
scoped
a
little
too
big.
So
if
we
could
split
it
up,
I'd
be
happy
to
take
on
some
parts,
but
yeah.
E
Just
considering
awesome,
yeah
yeah
something
else
this
is.
I
opened
this
issue
and
if
I
remember
correctly,
because
I
was
looking
into
the
spec-
and
this
is
a
pretty
pedantic
in
the
sense
that
the.
E
B
Yeah,
I
think
I
mean
I
think
this
is
true
in
some
cases
but
like
obviously
this
is
a
very
error
prone.
You
know,
like
part
of
you,
know
coding
in
general,
so
if
we
could
have
like
maybe
some
sort
of
tests
that
that
try
to
create
races-
and
you
know
if
we
see
any
sort
of
flakiness,
we
would
know
that
there's
you
know
race
conditions
or
or
something
like
that.
So
I
think
maybe
that
was
the
idea
here
was
like
you
know.
B
A
C
Is
there
something
specific
that
you
want
to
split
up?
Maybe
that
would
help
like
diego
knowing
like
how
you
want
to
scope
this.
B
A
C
Yeah,
if
you
guys,
like
maybe
like
split
up
to
split
up
into
issues
that
pertain
to
like
methods,
maybe
I
don't
know
that
could
be
a
possible
way
to
scope.
This
better
yeah.
E
Yeah,
it
just
did
before
that.
We
do
that.
I
wanted
to
ring
up
something
to
our
rotation,
so
this
issue
is
right
now
marked
as
the
one
of
the
python
metrics
issues
that
was
required
for
stable.
E
To
be
honest
with
you,
I
don't
consider
it
to
be
necessary
for
civil
for
two
reasons.
One
of
them
is
that
no
pretty
much,
we
won't
change
anything
in
the
api
to
solve
this
issue.
It's
pretty
much
adding
test
cases
if,
if
we
fix
any,
if
we
end
up
fixing
any
race
conditions,
we
probably
because
we
were
missing
some
locks
somewhere,
and
the
other
thing
is
that
this
pretty
much
applies
to
everything
right
as
we
just
mentioned.
E
So
it's
a
super
long
issue
that
can
just
keep
us
from
getting
stages
are.
C
So
diego,
it's
interesting
that
you
mentioned
that
because
I
feel
like
we're,
actually
missing
a
lot
of
things
besides
from
those
issues
in
the
project
board,
because
we
haven't
really
combed
through
the
spec
compliance
matrix,
which
I
have
only
been
looking
at
recently
and
we're
actually
missing
a
lot
of
these
things
that
other
languages
specifically
java,
who
already
have
a
stable
release
for
metrics,
has
been
following.
C
B
I
think
I
think
duo's
point
is:
we've
implemented
that
to
the
best
of
our
knowledge,
but
it's
just
a
matter
of.
Obviously
we
can't
prove
it
completely,
but
having
attested
some
form
of
like
a
brute
force,
proof
right.
E
B
I
think
I
think
you
raise
a
good
point,
though
late
and
like
maybe
this,
maybe
our
matrix
isn't
that
up
to
date,
maybe
we
should
schedule
some
time
to.
C
Really,
I
think,
that's
a
separate,
separate
problem.
Yeah
like
we
probably
should.
I
could
talk
to
the
stakeholders
that
are
interested
and
set
up
a
meeting
to
actually
go
through
this
spec
and
see
what
we
actually
want
for
metric,
stable
yeah.
C
For
example,
it
does
seem
daunting
like
like
we
don't
have
examples
and
everything,
but
like
even
for
java,
like
the
their
their
exemplars,
are
like
experimental
right
now,
but
they
release
the
metric
stable.
So
you
know
like
what
does
that
mean
right?
So
exactly.
C
C
So
I
think
that's
something
that
the
the
maintainers
and
the
people,
the
the
rest
of
the
members
that
are
interested
invested
in
metrics,
can
decide
as
a
community.
So.
E
E
Okay,
but
I
mean
what
was
he
the
audience
you
expect
only
us
or
somebody
else,
no.
C
E
Okay,
but
you
want
people
from
number
six
to
join
as
well.
C
No,
this
is.
C
Sounds
cool,
sound
good.
All
right
looks
like
we're
out
of
time.
If
there's
anything,
not
anything
else
pressing,
I
will
see
you
guys
next
week,
oh
yeah,
oh.