►
From YouTube: 2022-04-21 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
Okay,
well,
let's
wait
for
four
minutes
for
our
folks
to
join
in
a
minute
in
the
meantime,
inside
yourselves
to
the
attendees
list,
I'm
gonna
paste
it
here
in
the
chat.
B
And
if
you
have
issues
topics
you
want
to
express,
please
haven't
we
agenda
as
well.
B
Oh
by
the
way,
congratulations
for
your
new
approval.
A
Why
do
I
just
out
of
curiosity,
I
mean
I
just
saw
that
yesterday
she
can't
just
started
the
release
process
for
1.11.1,
so
I'm
not
aware
of
I
mean
how
the
release
process
works.
So
is
there
any
documentation
where
I
mean
what
are
the
steps
we
need
to
follow
to
release
the
new
version.
B
B
Yeah
all
right,
I
guess
we
should
begin.
We
have
a
topic
that
says
metrics
world
review
later.
Did
you
add
that
I
think.
C
So
already,
but
that's
it's
pretty
much
your
next
topic,
so
maybe
we
should
leave
that
at
the
end.
B
All
right,
yeah
well,
my
topic
was
pretty
much
it's
not
to
review
the
board,
but
to
let
you
know
about
the
issues
that
I
took.
I
took
a
look
on
all
the
metrics
issues
that
we
had
in
the
backlog,
and
I
have
some
that
I
would
like
to
discuss
with
you
so
yeah.
We
can
do
it
at
the
end
if
you
prefer.
C
C
B
C
C
C
I
think
that's
what
it
was
and
it
it
does
seem
like
an
aggressive
timeline,
but
we
are
going
to
be
trying
our
best
and
it's.
This
is
something
that
we
want
to
do
anyways
as
early
as
possible,
so
having
a
actual
timeline
will
encourage
us
to
do
so.
C
The
other
languages
have
already
had
some
sort
of
rc
release
or
stable
release
planned
out.
Um.Net
released
their
metrics
stable
last
week
friday,
and
I
believe
java
is
on
the
same
boat
as
us,
except
they
already
have
an
rc
release
out.
So
we
want
to
be
doing
something
similar.
C
Diego
has
graciously
offered
up
his
time
to
lead
this
effort.
He
will
be
fully
on
the
metrics
work
if
I'm
not
mistaken,
right,
diego
correct,
yes
right,
and
so
he
he
will
be.
You
know
trying
to
spearhead
this
effort
and
obviously
the
rest
of
us
will
be
contributing
and
helping
out
as
well,
but
we
also
brought
down
a
bunch
of
steps
that
we
need
to
do.
I
don't
know
if
you
capture
that
anywhere
diego
besides
that
powerpoint,
oh
no.
C
I
have
that
in
the
powerpoint.
Only
okay
could
you
just
like
copy
and
paste
it
in
the
meeting
notes,
maybe
yeah
like
label
that
as
like
our
plan
or
we
can
like
even
create
an
issue
for
it
up
to
you,
but
anyways.
B
Yeah,
in
fact,
that
sounds
better
I'll,
create
an
issue
with
those
tasks
that
you
can
check
out.
C
Sure
yeah
sounds
good
anyways,
yes,
so
that
is
our
plan
for
that.
Does
anybody
have
any
questions
about
this.
C
Okay,
so
there
were,
there
was
a
lot
of
discussion
regarding,
like
you
know
what
what
does?
What
does
a
stable
release
mean
and
things
of
that
nature
we
want
to?
C
I
have
the
similar
definition
that
we
did
for
the
tracing
release
as
well,
so
you
know
be
be
spec
compliant
and
follow
everything
that's
marked
as
stable
in
the
specs.
We
should
be
fully
implemented.
I
think
the
one
caveat
that
we
did
talk
about
was
the
prometheus
exporter.
C
C
So
all
of
this
would
be
outlined
in
the
the
issue
that
diego
will
be
creating,
so
yeah
just
feel
free
to
jump
in
if
anyone
has
any
questions
yeah,
so
that's
that
for
the
announcements
so
aaron
and
diego
have
recently
added
a
bunch
of
tasks
and
issues.
I
don't
think
they're
necessarily
added
to
the
board,
but
they
do
exist
that
pertain
to
things
that
we
get
for
our
c1
and
yeah,
so
they're
they're
all.
C
C
D
C
D
Sure
it
should
be
pretty
easy.
I
think
I
think
almost
anybody
could
figure
it
out.
B
B
By
the
way,
I
I
am
using
that
label
10rc
one
for
everything
that
is
in
the
board.
At
the
same
time,
everything
in
this
world
is
what
we
want
for
stable
release,
so
both
of
them
are
redundant
tickets,
though.
C
Got
it
okay,
cool.
C
C
There
was
kind
of
like
a
annoyance
that
came
up
in
which
a
lot
of
our
versions
needed
to
be
like
bumped
up
in
terms
of
dependencies,
and
we
found
that,
like
there's,
actually
no
way
to
kind
of
attract
that
a
component
relies
on
another
component
that
if,
if
there's
like
a
new
feature
during
the
dev
dev
process,
so
this
would
have
issues
if,
like
anyone
wanted
to,
you
know
check
out
our
you
know
our
main
branch
and
like
test
out
dev
versions
as
well,
and
I
believe,
similarly
in
certain
pr's,
it's
kind
of
confusing
and
impossible
to
set
correct
dependencies
because
we
can't
bump
them
because
technically
the
new
releases
aren't
out
yet.
C
But
we
want
to
depend
on
the
the
dev
version,
but
also
not
the
previous
version.
So
originally
we
had
a
we
appended
a
dev
to
our
ver,
our
versions
that
were
in
development.
C
The
reason
that
we
kind
of
took
this
out-
I
think
alex-
can
also
attest
to
this.
But
it
was
quite
annoying
to
switch
back
and
forth
as
well
during
release
processes
as
well
as
it
was
easy
for
us
to
miss,
miss
things,
and
so
I
think
we
we
chose
to
once
tracing
became
stable.
I
think
we
chose
to
remove
these
dev
versions
because
it
was
like
a
calculated
like
we
assumed
that
there
weren't
many
gonna
be
many
dependency
bump
changes.
C
However,
now
that
like
we
have
metrics
and
logs
in
the
same
branch
as
our
release
branch,
that
is
no
longer
the
case,
so
every
single
time
we
have
new
metrics
changes,
components
that
depend
on
the
sdk
will
need
to
have
their
versions
updated.
So
that's
pretty
much
like
the
idea
behind
this
we're
probably
like
a
good
plan.
We'll
probably
we
have
to
reintroduce
back
to
dev
versions,
update
the
release
scripts
again,
at
least
for
until
until
metrics
and
logs
both
become
stable
and
then
maybe
we
can
consider
removing
these.
C
I
think
that's
the
general
plan.
Does
anybody
have
any
comments
about
this
or
concerns.
C
I
guess
notably
alex
because
he
and
I
were
the
ones
who
took
this
out
in
the
first
place
so.
E
I
I
do
not
have
any
comments
I
I
feel
like.
If,
if
it's
valuable,
then
we
should
bring
it
back
and
it
sounds
like
in
the
current.
E
C
Oops
anyways
I'll
do
that
later:
cool
yeah.
That
sounds
good
if
yeah.
If
no
one
has
any
other
comments,
we'll
probably
just
go
ahead
with
this,
then
to
avoid
the
future
annoyance.
B
Okay,
so
do
you
want
to
to
go
through
the
stuff
that
we
have
in
the
board
that
you
gotta
take
a
look
at
because
that's
the
case?
Okay,
there
is
one
particular
here
that
I
want
to
discuss.
I
think,
is
that
one
data
from
identical
instruments
must
be
aggregated.
B
So,
okay,
you
can
scroll
down.
Please
yeah,
okay,
okay,
let's
take
a
look
at
the
vr
that
should
fix
it
and.
B
I
think
it's
unfortunate,
but
it's
since
we
we
want
that
check
to
be
the
api.
It's
a
yeah
a
little
bit
yeah.
I
totally
agree
it
should
be
in
the
api,
so
yeah,
if
you
want,
if
you
have
that
in
the
api,
then
we
kind
of
need
to
duplicate
things,
because
we
need
to
set
between
the
api
to
check
the
instrumentation
and
then
the
dictionary
in
the
sdk
to
make
sure
that
we
are
returning
the
same
instrument.
Instance.
C
We
able
to
hold
the
instrument
in
the
api
as
well.
No,
we
don't
do
that
in
the
api.
B
C
B
I
mean
we
could,
I
guess.
C
B
The
instrument
id.
B
To
be
added
to
a
dictionary,
no,
no,
no,
this
just
won't
work.
No.
The
problem
is
that
in
the
api,
we
don't
instantiate
the
the
instruments
in
the
abstract
classes
of
the
api
yeah.
B
Yeah
yeah,
so
so
yeah,
it's
it
even
we
will
need
to
do
that
in
the.
B
Yeah,
it's
yeah,
I'm
not
I'm
not
sure
we
will
be
able
to
do
that
in
one
single
data
structure.
D
Checkford,
this
is.
D
Yeah
is
it
duplicate
instruments
or
instruments
with
the
same
name
and
different
name,
name
type
unit,
description
yeah.
So
so
I
think
those
cases
are
fine.
The
case
that
doesn't
work
is
when
it's
the
same
name
but
different
instruments
in
the
same
meter.
That's
the
one
that
was
the
semantic
error
in
the
spec
right
yeah.
D
B
B
Yeah,
it's
I,
I
don't
think
it's
a
it's
a
big
deal.
We
have
some
duplication
of
instrument
ids
because
we
have
them
in
a
set
and
we
also
have
them
as
keys
in
a
dictionary.
D
Yeah,
I
think
the
other
thing
is.
We
need
to
suppress
the
so
the
api
warns
if
you
have,
if
you
create
the
semantic
error
right,
yeah,
yes,
but
we
need
to
suppress
that
if
there's
a
view
that
correctly,
yes.
B
B
Yeah,
if
you
later,
can
you
search
for
fix
me
yeah?
It
should
be.
B
You're
right
yeah
there
exactly
so
yeah.
That's
why
I
split
that
check
so
that
it
now
returns
the
result
and
then,
when
we
implement
that
with
use,
we
can
use
that
information
to
suppress
the
warning.
So
that's
why
we
are
not
now
warning
layer.
D
Okay,
I
mean
yeah,
I
think
it's
fine
to
to
just
duplicate
the
stuff.
For
now,
maybe
we
can
find
a
clever
way
to
reuse
it.
It's
not
too
ugly.
Yeah.
B
All
right
so
yeah.
If
anyone
else
can
please
take
a
look
at
that
vr
and
leave
a
review.
B
Now
there
is
a
second
issue
that
I
would
like
to
discuss,
particularly
with
aaron.
Can
you
take
a
look
at
the
workplace?
It
will
be.
B
E
B
Yeah,
please
open
the
pr
that
should
fix.
Please
correct,
so
yeah
scroll
down,
please,
okay,
yeah
scroll
down
scroll
down.
Okay,
that's
okay!
That's
the
reply!
I
got
from
our
okay,
so
aaron.
I
think
that
I
partially
agree
with
your
last
comment.
B
B
B
So
I
agree
that
there
will
be
a
conflict,
but
there
won't
be
three
matches
only
two
of
them.
D
Wait
so
so
the
first
view
the
first
instrument
there's
just
going
to
be
a
default
view
right,
correct
yeah,
which
will
be
foo
so
you'll
have
three:
oh
okay,
the
same
name,
foo
and
same
type
counter
and
all
the
other
identifying
properties.
B
Okay!
No,
yes!
Yes,
that's!
Okay,
okay,
yeah,
okay!
So
for
this
pr
I
added
a
new
test
case.
Can
you
please
let
him
go
to
the
code
that
shows
that
we
detect
that
conflict
where
we
have
a
pretty
much
two
view
instrument
match
objects
with
the
same
name,
and
we
raise
a
warning.
B
I
think
yeah
that
one
gives
me
much
collision.
So
I
pretty
much
did
the
same
as
the
example
that
you
had.
So
I
put
the
two
instruments
and
made
them
match
with
instrument
name
and
two
views
with
the
same
name:
that's
lined
to
71
and
272.,
and
then
I
made
sure
that
we
erase
a
warning.
D
Yeah,
are
you
checking,
I
think,
I'll,
have
to
look
through
the
the
code?
Yes,.
B
B
To
take
a
look
and
also
take
a
look
at
the
test
case,
this
one
we
use
when
match
collision.
Please
do
so
we're
sure
that
we
are
making
sure
that
implemented.
D
D
So
there's
like
two
things
in
the
spec
and
I
just
want
to
make
sure
that
we're
on
the
same
page,
the
first
one
says:
if
applying
the
view
results
in
conflicting
metric
identities,
implementation
should
apply
the
view
in
a
middle
warning
and
then
it
won't
sorry
sorry
apply
the
universal
measurement
middleware
and
procedure
yeah.
So
that's
the
case
that
we
were
just
discussing
right.
D
The
second
one
is
the
semantic
error.
So
this
is
if
everything
is
the
same,
except
for
description.
D
So,
for
instance,
I
think
there's
there's
like
some
weird
edge
cases
here.
So,
for
instance,
if
you
have
two
histograms
with
different
bucketing
schemes,
they
that's
not
considered
identifying.
D
Like
aggregation,
etcetera,
then
yeah
what's
up,
are
you
sure
unit?
Because.
D
So
there
was
a
there
was
a
separate
thing
that
said
that
if
you
have
all
the
same
stuff
in
different
unit,
you
might
be
able
to
change
the
units
of
one
of
them,
but
I
think
that's
definitely
out
of
scope
for
the
for
the
ga,
okay.
D
What
is
your
question
here?
I'm
just
trying
to
clarify
it.
We
need
to
make
sure
that
that
so
that's
the
case
where
they're,
what's
the
wording,
conflicting
metric
identities.
The
second
case
is
the
semantic
error
which
was
it
gives
an
example.
Few
sets
an
asynchronous
instrument
to
use
explicit
bucket,
so
that's
like
a
misconfiguration
of
the
instrument
and
then
the
other
semantic
error
that's
mentioned
in
the
I
think
it's
mentioned
in
the
data
model,
is
when
you
have
multiple
metric
identities,
for
a
given
name
with
the
same
resource
and
scope,
attributes
boy.
B
C
C
I
see
you
you're
able
to
prevent
this
as
well
with
the
same
pr.
D
In
this
case,
you
drop
the
view.
B
Yeah,
what
what
I
think
later
means
is
that
if
I
implemented
that
in
the
same
pr-
and
I
did.
B
D
C
A
B
This
is
the
round
here.
I
am
I'm
pretty
much
just
comparing
the
name
of
the
viewers
by
nudge
to
another
viewers,
man
match
name
and
if
both
of
them
are
the
same,
then
I
raise
a
warning.
C
B
That's
that's
my
idea.
Actually,
I
think
I
recommend
it.
The
reason
why
I
do
that
is
because
the
key
is
an
instrument
and
the
value
is
a
sequence
of
various
mid-match
projects.
B
D
D
B
Yeah
yeah
the
views,
mid-match
name,
is
the
name
of
the
view.
If
the
view
has
a
name
or
the
name
of
the
instrument.
B
Okay
yeah,
it
is
you,
take
a
look
at
the
met,
tweak
reader
storage
code,
where
the
instrument
match
is
created.
C
C
I'm
just
looking
at
the
the
class
definition
of
vms
rematch
be
just
views
from
a
match.
Yeah.
I
don't.
I
don't
know.
D
So
it's
like
a
computed
thing
here
right,
so
it
it
would
use
the
instrument
if
the
view
doesn't
name.
Okay,
no.
B
C
Yeah
no
worries
I'll
just
preliminary
check
great
yeah,
it's
for
the
description
right.
Oh
sorry,
the
name,
the
view
name
or
instrument
name
and
also
the
view
description
or
instrument
description.
I
see
cool
cool
cool
yeah.
I
knew
that
was
somewhere.
C
B
Yeah,
when,
when
the
metric
is
pretty
much
sent
to
the
exporter,
that
that
will
identify
metrics
stream
is
the
combination
of
of
that
right.
The
the
type
the
unit
description,
the
variation
temporality.
B
B
Okay,
something
else
aaron,
I
think
you
opened.
B
Yeah,
I
think
erin
opened
an
issue.
Okay,
take
a
look
at
the
issues,
the
the
list
of
issues.
D
Is
it
the
one
about
that
you
already
had
a
different
issue
open
for.
C
That
was
the
yeah
the
metric
reader
temporality
config
yeah
yeah.
I
think
aaron
already
closed
that
you
closed
it.
B
B
D
I
didn't
read
the
for
the
second
part,
but
yeah.
That's
the
part
of
the
spec.
The
metric
reader
must
interrogative
points.
D
B
Okay,
because
I
am
suggesting
that
this
issue
can
be
closed,
because
I
think
we
have
that
already
implemented.
C
Okay,
so
I
think
we
pass
in
metric
temporality
or
prefer
temporality
to
the
metric
reader
and
yeah.
It's
passed
down
to
the
view
instrument.
D
Imagination,
that's
not
what
this
is
saying.
This
is
saying
that
each
instrument
should
the
metric
reader
can
say
what
temporality
it
wants
for
the
instrument.
D
And
then
in
the
actual
sdk
dock,
just
set
it
to
mark
down
it'll,
be
easier
to
read,
I
think
or
the
sorry
I
meant
I
I
meant
in
the
diff,
so
you
can
just
see
the
diffs.
How
do
you
do
that.
D
B
D
B
Okay,
so
the
what
I
understand
is
regarding
the
the
aggregation
right
is
that
the
aggregation,
the
default
aggregation,
the
depends
on
instrument
on
the
instrument
kind.
We
already
have
implemented
that
because
we
map
the
default
aggregation
depending
on
the
instrument
class
right.
This
is.
B
Okay,
yes,
but
this
is
the
the
the
part
that
I
that
I
mentioned
in
that
in
in
that
pier
the
sphere
more
or
less
okay,
okay,
yeah.
What
I
my
point
in
that
vr
is
that
we
in
somehow
I
guess
we
could
pass
the
the
aggregation
to
the
consume
measurement
method.
B
But
the
aggregation
is
also
something
that
you
can
configure
in
a
view,
and
if
we
do
this,
then
we
will
end
up
being
able
to
make
that
configuration
in
two
different
ways
and
then
the
user
will
pretty
much.
B
B
C
We
don't
set
the
temporarily
based
off
the
instrument
kind
we
just
like
pass
in
whatever
temporary
the
user
wants
right.
I
don't
think
that's
a
function
of
instrument
kind
though,
but
you
know
how
we
have
a
mapping
of
each
instrument
class
to
a
aggregation
right
yeah.
I
think
it's
essentially
the
same
thing.
That
map
like
every
instrument
class
to
a
default
temporality.
D
Right,
yes,
that's
if
you
search
in
this
in
this
pr
for
lambda,
there's
a
python
like
code
sample
they
added.
So
this
is
what
they're
saying
when
you
instantiate
the
periodic
metric
reader
or
when
you
add
it,
you
can
specify,
for
instance,
a
lambda
which
takes
in
instrument
kind
and
returns
the
temporality.
B
All
right,
so
what
these
here
feel
like
it?
Okay,
so
so
let
me
see
so
what
we
will
do
for
this
pr
is
pretty
much
passing
a
dictionary
in
the
metric
reader
that
maps
the
instrument
kinds
to
a
particular
temporality
and
then
another
dictionary
that
will
not
instrument
kind
to
to
connect
to
aggregations.
B
B
No,
no,
okay!
So
sorry,
it's
what
I
mean
is:
let's
imagine
that
we
have
to
implement
this
right
so
and
what
I
think
we
have
to
do
is
to
make
it
possible
that
we
put
in
the
in
the
metric
reader
a
way
of
defining
the
aggregation
temporality
and
the
aggregate
and
the
the
aggregation
for
different
instrument
kinds.
C
Wait
wait.
Can
we
not
talk
about
aggregation?
First,
I
have
a
issue
with
that
which
is
related
to
what
you're
talking
about.
Can
we
just
focus
on
the
temporality
for
now?
Okay,
fine.
B
So
so
yeah
is,
is
that
is
that,
where
we
wanted
to
pass
a
mapping
there
between
instrument,
kind
and
temporalities,
I
think.
B
B
C
B
Okay,
in
theory,
we
should
be
doing
the
same
with
with
aggregation.
C
B
D
B
D
B
So
what
what
I
understand
from
what
you
say
is
that,
with
that
mapping
or
whatever
that
we
pass
to
the
metric
reader,
we
can
change
the
default
aggregation
of
the
instruments,
so
it
will
be
pretty
much
just
like
now.
They
have
a
different
default
aggregation
and
if
a
view
comes
then
that
you
should
have
yeah.
D
B
E
B
A
B
C
D
To
call
it
there's
also,
I
believe
the
default
was
also
changed
here,
oh
really
for
aggregation,
but
I'm
not
sure.
So
let
me
go
back
we'll
step
back.
The
big
picture
here
is,
you
know
the
big
picture
is
that
each
instrument
has
like
an
inherent
temporality
based
on
the
calling
convention.
We
know
that
async
instruments
are
seeing
cumulatives
right.
The
idea
here
is
to
not
have
to
store
state
to
do
temporality
conversion
in
the
sdk,
if
not
needed.
So
that's
sort
of
the
whole
point
here
right.
D
It's
that
you
may
want
to
have
mixed
temporality
as
the
default
or
mixed
temporality
for
the
instrument,
so
the
async
instruments
would
be
cumulative
and
synchronous
ones
would
be
delta.
For
instance,
I
don't,
I
actually
don't
think
it
changes
the
default.
You'll
have
to
look
through
this
pr,
but
that's
sort
of
the
big
picture
here.
C
Let's
see
so
right
now
for
our
temp
rally,
conversions,
we
store
state.
D
C
B
Okay,
okay,
but
just
to
make
sure
that
I
don't
implement
everything.
So
what
we're
going
to
do
is
implement
a
way
into
different
pr's,
pass
default
to
change
the
default
aggregation
and
to
the
change
the
default
temporality
for.
C
Each
instrument
kind
yeah,
so
so
this
this
pr
at
add
a
optional
parameter
into
the
metric
reader,
whether
you
can
accept
a
function
or
a
dictionary,
some
sort
of
mapping,
as
well
as
add
a
internal
like
instrument
kind
to
temporality
mapping
to
use
as
a
default.
C
If
someone
doesn't
pass
this
in,
that's
it,
I
believe,
and
then
the
second
one
is
do
the
same
thing
for
aggregation,
but
we
already
have
the
default
aggregation
mapping,
so
you
use
that
if
they
don't
pass
in
aggregation,
okay,
the
thing
that
aaron-
and
I
were
talking
about
just
now
was-
was
like
in
the
future
like.
If,
if
this
goes
in,
then
we
can
do
some
optimization
with
the
convert.
Temporality
function,
okay,
yeah,
because
we
have
an
automatically
assumed
temporality
for
base
yeah.
C
Okay,
all
right,
diego
sound
good.
C
Okay,
cool
all
right,
any
other
issues.
B
B
Yeah,
in
fact,
well
not
there,
but
I
took
a
look
at
the
issues
that
we
had
in
the
backlog
and
there
are
some
issues
that
I
would
like
to
discuss
with
you.
D
D
So
we're
at
like
past
the
10
minute
mark.
Should
we
see
if
anybody
else
has
any
topics?
I
know
there's
nothing
in
the
agenda.
Anything
else.
C
Yeah,
so
I
guess
no
other
topics,
so
you
go.
I
guess
you
have
the
floor.
Okay,
I'll
need
to
share
wait
so
aaron
are
we.
Are
we
reopening
this
pr
sorry,
this
issue.
B
All
right,
diego
go
ahead.
Okay,
real!
B
Oh,
thank
you,
okay,
see
so
yeah.
I
took
a
look
at
the
metrics
backlog.
These
are
the
issues
that
I
would
like
to
discuss
with
you
so
that
we
know
if
we
want
to
include
them
in
the
still
release
or
not
okay.
How
about
this.
C
I
believe
we
only
need
yep
see
yeah.
B
Yeah,
I
agree
all
right,
json
coding
of
prometheus.
You
recently
mentioned
that
we
should
the
prometheus
would
be
good
to
have,
and
I
guess
this
will
also
matter.
E
D
D
E
E
Probably,
I
think,
there's
actually
a
pr
open
for
this
right.
If
you.
B
D
B
Yeah,
it
is
someone.
C
So
should
we
should
we,
okay,
I
guess
we're
like
for
the
future
like,
should
we
base
off
of
should
we
base
off
what
is
necessary
of
stable,
based
off
of
like
convenience
or
like
what
is
actually
important?
I
guess
this.
It
just
so
happens
that
this
issue
was
easy
and
someone
has
a
pr
up
already
but
like
like
what,
if
what,
if
they
don't
come
back,
you
know
like
what,
if
they
block
us
from
releasing
right
like
is
this
something
that
we
need
for
the
stable
release.
E
C
B
Okay,
all
right,
then
next
one.
This
is
something
that
discussed.
I
asked
about
this
in
the
metrics
channel
and
the
java
guys
do
have
a
force
flash
in
the
metrics
exporters.
B
Sorry
the
ventricular
reader.
I
think
it
should
be
pretty
easy
to
add
the
force
flush
there,
but
it
is
true
that
it
is
not
in
the
spec.
D
B
Now
you
have
this
one,
this
is
I
labeled
it
that's
relevant
for
the
release
that
I
will
check
with
you
yeah,
but.
D
D
I
think
this
one's
important
enough
that
it
would
make
prometheus
hard
to
use
or
or
not
ideal
to
use.
So
I
think
it's
something
we
want
to
do.
B
B
I
just
want
to
make
sure
that
it
is
that
all
the
documentation
that
that
you
consider
to
that,
we
need
to
add,
because
I
think
you
also
want
to
add
condition
to
the
api
is
tracked
so.
E
E
Like
is
there
a,
I
mean
I
I've
been
going
through
the
documentation
and
ensuring
that
all
the
methods
that
are
part
of
the
docs
are
contain
documentation.
I
think
I
think
the
issue
will
be
complete
when
there
aren't
any
more
either
methods
or
classes
that
aren't
documented
cool,
all
right,
which.
B
Okay
or
alex
feel
free
to
pretty
much
close
that
issue
once
that
you
reach
that
point
yep
for
sure
sure
right.
Those
were
the
issues
that
I
found
in
the
backlog
next
test
for
me
will
be
reviewing
all
the
interfaces
just
last
announcement.
B
There
are
two
massive
pr's
that
I
opened
yesterday
that
yeah
this
that
will
make
metric
symbols
private
in
the
api
and
the
sdk,
don't
be
scared,
which
is
huge,
because
we
are
moving
the
symbols
from
being
imported
directly
to
being
imported
only
in
the
init
modules,
as
with
discuss
with
error
so
that
we
don't
have
public
stuff
that
we
don't
want
imported,
please
take
a
look,
should
be
big
buddy
is
it
for
you,
nice.
I
like.
E
C
Nice
cool-
I
guess
that's
time
so
we'll
see
everyone
next
week.
Thank
you.