►
From YouTube: 2022-03-22 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
I
see
your
screen.
Isn't
it
I'll
add
that
contra
ratio
for
naming
that,
like
just
suggestions
thing
as
well,
I
think
michael
already
responded,
but
if
you
also
open
their
trip
for.
A
Okay,
so
we
can
start
by
writing
your
name
to
the
td
list,
so
we'll
go
over
the
first
update,
which
is
the
release
update.
So
we
didn't
do
the
rc3s
also
today.
So
I
need
to
look
at
the
pr
from
last
week
which
I
didn't
have
fixed.
So
so
we
need
to
do
a
rc3
thing.
We
was
playing.
We
were
trying
to
do
it
like
late
last
week,
but
that
didn't
happen.
So
let's
try
to
do
it
today
or
like
as
soon
as
we
are
done
with
the
fpr's.
A
The
other
update
is
the
matrix.
Sdk
is
now
marked
as
mixer
stability
with
most
of
the
parts
which
dotnet
has
implementations
are
already
marked
as
stable,
so
views
provider
reader
exporter.
So
all
those
parts
are
stable,
so
that
means
like
we
are
no
longer
blocked
by
the
step
to
release
a
1.2
stable.
So
we
need
to
like
now
like
make
sure
like
we
have
everything
covered,
because
we
are
about
to
do
1.2.
A
So
we
need
to
do
like
some
more
review
just
to
make
sure
that
there
are
no
like
loose
ends
or
really
important
to
those.
So
what
I
I
would
do
is
like
I,
then
has
a
pr,
so
we
quickly
go
over
it
today.
Let's
see
if
we
can
merge
that-
and
there
are
at
least
one
or
maybe
two
peers
about
the
status
thing,
so
we
decided
like
last
week
or
maybe
the
week
before,
that
we'll
include
the
status
fix
as
well
in
the
1.2
release.
A
So
we'll
wait
for
like
this
is
almost
ready.
I
like
left
some
minor
comments,
but
this
one-
and
I
think
this
is
the
one
we
sell
yeah.
These
two
are
the
really
critical
things
we
really
need
for
1.1.
Everything
else
seems
nice
to
how
I
mean
it
should
not
block
1.1
release.
Anything
related
to
prometheus
is
already
not
in
the
scope,
because
this
would
anyway
be
a
separate
milestone,
so
the
stable
release
of
prometheus.
A
B
A
So
next,
one
week
like
once,
we
merge
this
important
psh
we
consider
required
for
1.2.
We
probably
need
to
face
the
entire
like
prs.
We
don't
really
want
to
take
anything.
You
know
last
minute,
at
least
for
three
four
days
just
while
we
are
like
anything
which
is
required
for
like
like
addressing
box
or
something
in
matrix,
we
can
take,
but
everything
else
we
can
like
put
a
post
after
we
do
the
rc3.
A
So
that
will
give
us
at
least
one
week
of
no
activity,
so
that
will
give
us
some
time
to
hear
from
customers
as
well.
A
So
that's
the
only
update,
so
I
think
we
can
go
through
this
issue
and
then
come
back
and
look
at
the
pr
formula
and
also
the
pr
award
status.
Since
we
are
about
to
merge
it.
It
makes
sense
too,
okay
yeah.
So
this
is
a
matrix
packets.
Unfortunately,
the
the
main
readme
is
not
yet
updated.
Yeah,
maybe
you'll
ask
rightly
or
someone
to
send
a
pr
to
clarify
that
oops.
A
Sorry,
I
intended
to
open
the
sd
card,
so
it
is
mixed,
but
all
the
things
which
dot
net
currently
has
implementation.
They
are
all
stable,
so
yeah
sdk
is
mixer,
provider
is
stable,
so
everything
below
here
is
from
the
provider,
application
drop
or
aggregation.
This
is
up
to
the
area.
Stable
attribute
limits
is
stable,
example.
Is
we
surface
the
top
netness
of
today
does
not
have
it.
So
we
are
not
affected
by
that
matrix.
Reader
and
exporter
are
also
unstable.
B
A
Just
confirming
here,
the
exporters
themselves
were
already
stable,
like
from
december,
so,
except
from
here
so
from
this
is
experimental,
but
the
thing
which
we
mostly
care
about
here.
This
is
already
okay,
okay,
so
think
we
are
like
unload
from
clearly
it's
just
now
on
ourselves
to
make
sure
like
we
do
like
review
the
code,
make
sure
there
is
no
accidental
public
api
or
any
important
box.
So,
okay,
let's
start
with
the
agenda
item.
A
Yeah,
so
there
is
this:
like
we're
already,
there's
an
all
going
on
ongoing
effort
for
to
rename
all
the
instrumentation
packages
and
all
the
other
packages
and
contract
people.
Can
you
give
a
quick
update
like
how?
How
are
we
done
with
that?
Or
is
this
the
last
one,
or
do
we
start
now,
so
we
still
have
mass
transit
left
and
okay
and
all
the
amazon
aws
related
ones
we
haven't
touched
at
all,
and
I
don't
think
prashanth
has
responded
to
that
issue.
A
Yet:
okay,
mass
transit,
there's
a
pr
out
for
that
and
I've
added
the
component
owner
for
it.
They
haven't
responded
yet
okay.
So
what
about
this
one?
Is
it
a
package
or
is
it
just
an
internal
thing?
Yeah?
This
is
just
like
an
internal
helper
library,
okay,
not
part
of
the
shipping
thing.
B
A
That's
what
I
think
that
is
blanchard
michael
blanchard,
just
yeah,
but
this
basically
means
like
all
the
maintainers
are
the
owners.
So,
okay,
okay,
I
think
we
put
a
title-
maybe
maybe
somewhere
here
we
mentioned
that.
Where
do
we
find
that
if
it's
not
there,
we
can
oh
yeah
this.
You
know
interesting.
I
thought
like
it
was
clearly
mentioned
like
who
is
the
owner
that
maybe
has
it.
A
Maybe
let's
look
at
cordoners,
and
that
is
because
now
we
use
that
other
workflow.
A
A
Mass
transit
and
then
the
yeah,
so
mass
transit
do
have
an
honor
yeah.
Let's
wait
for
hearing
from
them
for
like
one
more
day
and
then
we
can
choose
to
do
it,
because
this
never
had
a
stable
release
where
we
should
be
fine
there
for
aws
yeah.
We
need
to
get
an
explicit
acknowledgement
from
the
owners
and
for
slab
driver.
There
is
like
I
was
running
into
some
issues
when
I
tried
to
rename
the
folder
everything
yeah,
but,
like
we've
done
with
the
release
right
there,
you
can't
see
that
yeah.
D
A
Okay
and
like
for
some
reason,
though,
the
unit
test
started
failing
when
I
changed
the
removed
contract
from
the
place
part
of
the
public
ap,
okay,
and
that's
where
we
have
an
issue
tracking
yeah.
We
do
have
an
issue
with
tracking
that,
but
we'll
see
if
someone
from
google
wants
to
fix
it
yeah.
A
There
were
like
some
issues
even
before
related
to
that,
and
it
looks
like
no
one
from
google
wanted
to
work
on
it
because
they
effectively
put
a
statement
saying
that
this
is
not
owned
by
google
and
not
supported
by
google.
So
just
like,
as
of
today,
it's
just
a
random
contribution.
A
Somewhere,
like
yeah,
I
think,
george
from
google
added
this
thing
saying
that
this
is
not
officially
supported
so
yeah,
it's
okay
to
leave
with
that
for
now,
because
it's
still
not
stable,
since
we
have
an
issue
covering
that
we
should
be
fine.
So
all
we
need
to
decide
is
the
name
for
this
package
right,
yeah
and
extensions
together:
okay,
okay
and
what
the
current
name
is
contract.preview.
So
when
we
remove
the
word
contributor,
just
becomes
open
elementary
dot
preview
yeah.
So
in
that
issue,
like.
B
I
had
suggested
extensions
or
preview,
and
I
think
michael
blanch
also
said
that
any
suggestions
for
the
people
package-
yeah-
let's
open
that
okay
or
do
we-
want
to
rename
it
to
something
else.
Like
extensions.
A
A
Second
again
with
the
word
preview
and
then
like,
there
is
a
third
thing
like
that
you
get
package.
You'll
also
tell
that.
Okay,
this
is
not
a
stable
thing,
so
it's
little
bit
of
duplicate
information,
but
that
aside,
I
don't
so
what's
wrong
with
just
open
elementary
dot
preview.
A
Probably
there's
nothing
wrong
with
it,
but
I
feel
like
open
elementary
preview
sounds
a
little
like
no
like.
We
are
confident
that
this
is
like
this
is
open
to
elementary
preview
package
like
this
is
what
open
telemetry
is
going
to
be,
at
least
that's
what
I
felt
when
I
like
say.
So.
That's
why
the
word
extensions
are
yeah.
A
E
Then
yeah
just
for
a
little
history.
The
main
thing
in
there
is
the
activity
log
attaching
thing
right,
so
we
thought
when
we
built
this,
there
was
a
strong
probability
that
it
would
end
up
as
part
of
the
spec.
E
F
A
So
if
we
use
the
word
open
elementary
dot,
extensions
and
name
the
package
as
unstable
all
the
time,
that
would
also
convey
the
message,
because
it's
not
part
of
the
core
thing-
it's
part
of
extensions
right
now.
Eventually
it
could
be
move,
but
that's
not
a
breaking
change
anymore.
It's
additive
change
to
the
main
sdk
and
this
package
itself
can
be
always
remaining
in
the
like
non-stable
nougat
versioning,
so
that
could
also
indicate
that
this
may
or
may
not
happen.
E
E
Your
assembly
sort
of
thing
you
can
put
a
type
forward
and
then
anybody
that's
compiling,
just
gets
directed
to
the
new
thing.
That's
kind
of
how
runtime
is
able
to
move
things
in
different
assemblies
internally,
so
we
could
piggyback
on
that.
If
it
was
open,
telemetry.extensions
it
lived
in
there
and
then
we
wanted
to
move
it
to
the
main
repo.
I
think
we
could
do
it
transparently,
non-breaking.
A
B
Yeah
and
for
sdk
extensions.
What
remotes,
okay,
auto
configure
metric
incubator.
A
A
Okay
yeah,
so
maybe
let's
stick
with
the
name
which
we
has
proposed
here,
so
extension
stop.
A
A
I
don't
feel
strongly
yeah
the
only
reason
why
I
wanted
to
avoid
that
word:
preview.
It's
kind
of
duplicating,
because
the
package
names
are
all
not
stable,
so
kind
of
indicate
that
okay,
this
is
an
unstable
thing,
but
no
opinion
here,
but
maybe
like
alan
like,
if
you
want
to
throw
some
peanut
here.
C
A
I
mean
that
is
the
right.
English
word
right,
like
we
are
incubating
things
for
potentially
considering
to
be
part
of
the
main
thing,
but
if
the
failed
they'll
they'll
remain
and
thrown
away
from
the
incubation,
so
if
they
graduate,
then
they
become
the.
So
that
word
is
like
technically
correct.
They
believe.
A
Now
that
you
brought
the
word
experimental,
it
sounds
equally
good
for
me:
telemetry
dot,
yeah
even
incubation
sounds
good
to
me,
but
either
way
like
we
can.
We
don't
need
to
like
spend
too
much
time
because
it's
still
going
to
be
non-stable
package,
at
least
for
the
near
term.
So
if
we
come
up
with
any
better
name,
we
would
have
the
opportunity
to
rename
it
again
so
I'll
paste.
My
suggestion
here,
like
others,
can
also
paste
the
solution
I'll
be
doing.
A
A
So
I
just
think
I
should
even
please
share
some
comments,
so
we'll
pick
some
name
by
end
of
this
week,
but
even
if
you
don't
like
it,
we
still
have
opportunity
to
change
it
in
the
future.
As
long
as
it's
not
stable.
A
A
But
we
can
simply
use
the
1.2
milestone
to
indicate
the
things
which
we
really
need
for
1.0.
This
is
probably
needed.
This
is
definitely
needed.
This
is
definitely
needed.
Everything
else
prometheus
is
not
required
as
we
covered
earlier.
This
is
nice
to
have
not
really
blocking
it,
because
we
were
like
31.1
this
one.
We
can
really
differ
to
the
next
one.
This
one
is
instrumentation.
This
is
also
instrumentation.
A
This
is
adding
new
test,
so
no
harm
matching
it.
This
is,
I
think,
it's
already
approved,
so
probably
okay
too
much.
So
let's
look
at
these
three
because
they
are
blocking
the
1.2
release.
So
let
me
start
from
this
one,
and
so
again,
can
you
walk
us
through
this
again?
I
know
you
did
it
like
like
two
weeks
back,
but
since
then
it
did
did
change
so
maybe
just
for
everyone's
sake.
You
can
do
a
quick
recap
of
what.
What
is
the
thing
which
you
are
trying
to
achieve.
C
Yeah,
so
the
gist
of
this
one
was,
is
it's
a
basically
a
fix
of
my
initial
attempt
at
this,
and
that
went
out
with
the
last
release,
specifically
for
some
use
cases
with
views.
So
the
whole
idea
is
that
when
an
instrument
is
registered,
you
know
meter
dot,
create
whatever
counter
histogram.
C
A
C
Right
so
now
views
so
that
that's
like
the
simple
case
right
where
say,
like
no
view
is,
is
in
play
then,
when
that
second
second
instrument
is
registered
now
we
just
basically
map
it
to
the
same
underlying
metric
that
we
created
with
the
first
instrument.
So
both
those
instruments
are
operational.
That's
that's
that's
what
happened
with
the
my
first
attempt
or
my
rc2
yeah,
that
was.
C
Right
views
are
a
little
bit
more
complex,
so
the
the
thing
with
views
is
that
whenever
a
view
is
specified
or
configured
with
the
meter
provider,
it
any
instruments
that
mapped.
That
view
should
result
in
a
metric
stream.
C
A
an
additional
metric
stream
from
that
instrument
where
it
gets
complicated,
is
like,
if
you
have
a
two
instruments
that
are
distinct,
maybe
in
some
way
that
map
to
the
same
view
they
by
like
some
of
the
things
beyond
just
name
and
description,
and
so
on,
like
for
instance,
views
you
can
configure
the
tags
to
filter
by
or
histogram
bounds,.
C
If
a
single
instrument,
identity
maps
to
two
different
configurations
for
say,
like
histogram
bounds,
that
with
this
pr
results
in
two
separate
metrics
streams,
which
is
how
views
are
supposed
to
work
that
wasn't
happening
prior
to
this
pr.
D
C
A
So,
even
if
even
if
that
means
emitting
a
duplicate
stream
in
terms
of
name
and
other
things,
like
name,
everything
would
be
same,
but
the
individual
metric
points
may
have
like
different
aggregation
thing.
Okay,.
C
We
still
admit
a
warning
mike
from
when,
when
that
happens,
because
yeah
these
duplicate
streams,
basically
the
sp.
The
specification
has
some
verbiage
that
says,
like
hey,
you
know
consumers
of
these
metrics,
if
you
get,
if
you
get
a
metric
with
the
same
identity,
effectively
a
name
description
units
all
that
it's
up
to
the
consumer,
well,
to
decide
what
to
do
it,
it
can
drop
one
of
the
streams
if
it
desires.
A
Exporter,
which
we
currently
able
to
ship
the
console
doesn't
care
in
memory,
probably
doesn't
care.
The
otlp
will
not
have
this
issue
or
will
otp
also
see
the
dual
streams
with
the
same
name,
everything
would
it
complain
or
would
it
have
any?
I
know
that
prometheus
has
this
issue.
If
you
like
send
two
streams,
then
the
scraper
would
complain.
A
Something
would
fail,
but
does
otlp
has
any
issues.
If
we
send
like
two
streams,
I
guess
not,
but
is
there
anything
which
we
need
to
handle
in
the
otlp
site.
C
As
well
from
the
standpoint
of
our
exporter,
no
it's
it's
the
downstream
consumer
that
that
might
care,
but
ultimately
like
well
like
from
an
otlp
perspective
that
would
be,
like
you
know,
an
open,
telemetry
collector
or
something
like
that
or
some
back-end
vendor
that
supports
otlp.
C
And
it's
basically,
though,
that's
what
the
specification
is
speaking
to
it's
like
hey,
you
know
like
you,
can
send
this
be
an
otlp
exporter.
It
shouldn't
complain
right
it
should
it
should
pass
it
through,
but
the
back
end
that
you're
sending
that
to
yes,
they
should
do
the
merging
or
whatever
they
want
or
merging,
dropping
whatever
it
is
that
they
decide.
You
know
like
okay,.
A
A
Think
like
is
there
any
specific
point
which
you
want
to
like
go
over,
or
can
we
just
trust
everyone
to
look
at
it
and
offer
some
reviews,
or
anything
in
particular,
which
you
think
might
be
like
controversial.
C
A
C
C
A
Quickly
open
one
part
for
this
effect,
where
it
talks
about
the
instrument,
duplication,
just
to
make
sure
like
yeah,
for
the
others
who
are
in
the
call
as
well.
They
may
also
get
so
is
it
in
the
sdk
or
if
you
duplicate
now,.
C
Api
and
and
the
sdk,
and
I
forget
what,
where
the
words.
A
Api
is
required
to
create
valid
instruments,
and
data
model
includes
recommendation
on
how
to
treat
it
must
aggregate
from
that
identical
instruments
in
its
export.
It
should
assist
the
user
by
reporting.
Okay,
when
potential
error
is
conflict,
arranges
between
two
at
non-identical
metric
instances
having
the
same
name
configured
view.
So
this
is
basically
like
how
we
should
log
the
message
so
that
user
can
click.
It
view
selector
view
recipe
should
be
printed.
We
are
not
doing
it,
but
that's
really
like
a
should
think.
Not
a
must
thing.
A
A
So
this
really
means
what
we
are.
What
we
are
doing
in
this
pr
being
proposed
is
matching
the
spec.
A
So
here
the
definition
of
identity.
We
are
expanding
the
definition
of
identity
to
include
the
view
configure
things
as
well
right,
like
the
tag
keys
and
the
histogram
bonds.
A
That's
right
uh-huh,
so
I
think
maybe
maybe
I
have
a
small
consensual.
So
it
says
let
me
quickly
go
through
it
so
name
same
name,
identical.
D
C
Mean
the
united,
so
in
here
you're
not
to
find
like
like
a
a
thing
that
says.
Part
of
the
identifying
thing
is:
is
the
tags
or
the
histogram
bounds
that
that
that
requires
kind
of
like
an
interpretation
of
the
view,
api.
A
Yeah,
because
I
can
see
like
this
is
about
api
level
thing
and
it
cannot
really
talk
about
views
or
anything.
Okay,
then
it's
like
we
are
kind
of
like
extending
the
instrument
identity
to
include
the
things
from
the
view,
and
is
it
correct
that
it's
not
explicitly
stated
in
the
stack
to
do
so
right?
It's
not
like
explicitly
stated
that
view
should
be
included
in
the
activity
right.
A
We
are
kind
of
interpreting
it
to
be
that
way,
based
on
the
based
on
the
view
existing
spec,
we
are
kind
of
interpreting
that
if
the
user
is
using
a
view
to
take
a
instrument
and
produce
two
identical
streams,
identical
in
every
sense
but
like
some
histogram
bound
is
different,
so
in
that
case
we
have
to
produce
two
different
stream.
We
cannot
merge
them
together,
so
we
have
to
produce
different
streams,
so
that's
not
explicitly
listed,
but.
C
We
didn't
need
to
consider
the
the
intersection
of
that
and
and
how
it
interoperated
with
views,
because
we
were
just
dropping
it
so
like
if
you
created
two
identical
instruments
via
say,
like
a
view
that
would
have
resulted
in
an
error
in
before,
and
we
would
have
effectively
dropped
the
the
recording
of
of
thing
values
from
one
of
the
instruments
right
so
that
that's
the
whole
thing
that
the
the
api
spec
is
trying
to
to
resolve.
A
You
have
to,
I
totally
get
your
point.
I
mean
I
was
just
trying
to
see
like
whether
there
was
an
explicit
mention,
or
is
it
more
like
an
implicit
thing
that
we
are
expecting,
because
I
was
thinking
if,
if
views
not
only
allow
you
to
change
the
histogram
once
like
in
the
future
like
in.net
or
in
the
spec,
it's
already
there
like
aggregation
can
also
be
used.
So
I
can
say,
like
there
is
a
counter
and
I
define
two
views.
A
One
says:
take
it
default,
do
a
counter,
then
another
v
on
the
same
instrument
say:
take
it
and
produce
a
histogram
out
of
it.
So
now
we
are
expected
to
produce
two
distinct
streams,
one
with
counter
semantics
and
other
with
histogram
thing.
So
it's
not
explicitly
given
here,
but
I
I
see
that
that's
the
right
thing
to
do
as
well.
A
Okay,
so
if
that's
the
case
like
it
won't
be
attribute
keys
and
the
histogram
bounce,
it
will
be
like
aggregation
also
when
we
start
supporting
it.
Yep.
Okay,
that's
going
to
like
expand
in
the
future,
and
I.
C
Almost
thought
about
adding
aggregation
just
for
now,
because
it
is
on
there
on
the
on
the
metric
stream,
but
I
didn't
it
was
going
to
it
was
going
to
involve
more
refactoring,
and
I
wanted
to
keep
this
pr
totally.
A
Okay,
yeah,
I
think
conceptually.
I
fully
agree
with
you
now
I'll
just
go
and
read
the
fear-
and
this
should
not
be
a
perfect
concern
as
well
right,
because
we
are
only
doing
it
in
the
instrument
creation
time.
This
checking
all
that
happens,
so
it
should
not
affect
anything
in
notepad.
Okay,
so
it
looks
like
we
have
a
good
solution.
So
now
it's
on
others
to
go
and
review
it.
So
I'll
also
review
it
and
try
to
close
it
as
soon
as
possible.
A
Okay,
anyone
else
comments
or
questions
about
this
particular.
This
is
probably
the
like
really
piece
of
thing
blocking
our
release
status
is
nice
to
have,
but
this
is
really
blocking.
So
I
really
encourage
everyone
to
expand
sometime
like
understand
the
application
and
do
a
review.
C
A
We
don't
really
expect
people,
I
mean
users,
to
explicitly.
I
mean
one
common
scenario
which
I
can
think
of
is
like.
If
you
have
this
dimension
explosion
problem
like
then,
let's
say
you
have
two
dimensions:
one
has
like
five
unique
values
and
the
second
one
was
10.
So
by
default
it's
like
5
times.
10
is
the
maximum
number
of
time
series
we
produce.
A
So
that's
50,
but
if
I
configure
a
view
to
take
the
first
dimension,
then
another
view
just
taking
the
second
one,
then
the
maximum
time
series
is
5
plus
10,
as
opposed
to
5
times
50
5
times
10,
and
someone
actually
asked
this
question
to
me
like
two
years
back
when
the
original
view
spec
was
being
written,
it
seemed
like
a
genuine
thing
right,
so
we
I,
I
think
I
blocked
like
some
pr's,
because
this
was
prohibited
and
then
riley
added
it
back.
So
I
know
that
this
is
a
use
case.
A
It's
a
valid
use
case.
I
just
don't
know
how
often
people
would
use
it
and
again
I
don't
know
whether
the
histogram
part
is
very
useful,
like
whether
you
produce
like
two
histogram
stream,
one
with
one
bound
and
another
with
another
one.
That
also
I
mean
it's
legally
allowed.
A
Yeah.
Okay,
we
interesting
like
how,
like
once
we
release
it
to
the
wild
that
we'll
be
interesting,
how
people
use
views
and
come
up
with
interesting
use
cases
which
may
not
have
been
in
the
original
intention
as
well.
A
A
Is
not
very,
I
don't
know
whether
it's
explicitly
saying
anywhere
that
view
can
be
used
to
like
do
this
broadcasting
effect
like
you
take
online
produce
multiple.
It's
like
one
of
the
use
cases
of
the
view,
but
I
think
it's
not
explicitly
mentioned
here.
It
says
you
can
name
I
mean
you
can
decide
which
one
to
drop.
A
So
I
don't
know
whether
people
would
actually
use
it,
but
there
is
nothing
preventing
anyone
from
doing
that.
I.
C
C
A
What
what
I
was
referring
to
was
the
introduction
section
on
view.
It
says,
like
some
of
the
scenarios,
where
some
sums
and
xml
is
not
a
full
list,
but
yeah,
I
don't
really
have
the
energy
to
like
propose
something
to
the
view.
A
Okay,
okay,
so
no
other
comments,
nothing
in
the
agenda
as
well,
so
we
will
go
to
the
next
pr
which
we
decided
was
important.
So
let's
open
this
one.
A
Okay,
so
we
recently
did
a
pr
where
now
console
exporter
is
natively
understanding,
both
the
activity
status
directly
and
if
it's
not
there,
it'll
fall
back
to
the
one
on
the
activity
tags.
So
this
is
borrowing
the
same
idea
to
zip
in
exporter.
A
We
really
want
to
do
the
same
for
other
two
exporters
as
well,
and
we
had
like
two
approaches:
where
we'll
do
it
either
in
in
the
core
sdk,
and
so
that
exporters
doesn't
need
to
worry,
but
then
we
decided
we'll
do
it
in
individual
exporter,
so
it's
like
kind
of
transparent
for
the
users.
So
that's
what
this
pre
so
think
I
mean
I
reviewed
this.
It's
a
bit
tricky
to
review,
because
the
way
our
zipping
exporters
work
like
we
don't
really
enumerate
tags
using
a4h.
We
use
the
allocation
free
tag
enumeration
state.
A
So
it's
a
bit
tricky
to
follow,
but
I
think,
like
there
are
enough
units
to
cover
that
we're
not
breaking
any
any
existing
features.
So
idea
is
if
the
user
is
using
the
new
status
we'll
take
the
status
code
and
description
from
the
new
one,
if
not
we'll
fall
back
so
as
of
today.
If
people
are
still
using
the
old
way,
it
will
just
use
the
you
should
just
use
that
as
the
fallback
mechanism,
so
it's
considered
not
if
they
can
change.
A
So,
if
someone
migrates
to
using
the
new
api,
then
starting
this
version
onwards,
the
official
exporters
will
just
respect
that.
So
that's
all
the
like
somebody,
so
maybe
routine
you
do
you
want
to
like
ask
anything
in
general,
or
do
you
think
it's
just
like
waiting
for
review?
I
will
be
uploading
it
very
shortly.
I
had
left
like
a
couple
of
minor
comments,
but
like
nothing
seems
to
be
broken,
so
really
encourage
others.
D
So
for
people
who
want
to
review,
I
would
suggest
to
start
with
the
part
0..
So
that's
an
example
of
the
idea
of
console
exporter.
I
paint
the
link
in
the
chat
in
the
zoom
chat
yeah
in
the
description
of
that
pr.
There
are
like
examples
and
the
output
of,
like
all
the
cases
after
the
change
of
populating
the
activity,
the
native
activity
status,
so
basically
yeah.
We
can
go
through
the
oh,
the
use
cases
in
the
description
and.
A
This
is
the
primary
case
where
we
are
looking
for
status
in
the
activity
directly
if
it's
not
there,
we'll
fall
back
to
status,
code
and
status
description,
and
these
are
already
populated
from
somewhere
else.
So
maybe
it's
good
to
just
look
at
the
whole
file.
D
Yeah,
so
the
one
corner
case
is
that
native
activity
will
take
precedence
over
activity
tax
if,
in
rare
cases,
there
are
conflicting
status,
for
example,
in
the
native
activity
status,
it's
reporting
okay,
but
in
the
activity
text
it's
reporting
arrow,
so
the
output
will
be
only
putting
the
activity
status,
activity
status
status,
so
yeah.
A
Okay
and
that's
the
right
thing
to
do,
because
if
the
user
is
setting
status
on
activity
on
the
native
way,
that
should
take
the
preference
this
other
one
is
anyway,
was
a
temporary
workaround
yeah.
So
that's
what
it's
very
easy
to
understand
if,
like
for
anyone
else
like
just
look
at
the
console
just
to
explain
the
concept,
so
we,
when
we
iterate
to
the
activity
tags,
we
store
the
status
code
and
description
into
like
two
variables
now.
A
This
is
where
we
are
going
to
print
the
status
code
and
description.
So
here
we
prefer
the
native
one,
if
not
we'll
fall
back
to
the
unknown
tag.
So
that's
all
it
is
conceptually,
but
the
exporters
other
than
console
are
doing
the
performance
way
of
right
writing.
So
it's
like
a
little
bit
tricky
to
follow
the
logic.
But,
yes,
you
did
suggested,
go
and
treat
this
pr.
First,
then,
it's
more
easier.
D
I
have
a
quick
question,
so
vishwash
was
working
on
this
change
before
and
by
chatting
with
him.
I
understand
that,
probably
eventually
we
wonder
like
remove
the
support
for
activity
tax
like
yeah.
Remove
that
support,
so
I'm
just
wondering
do
we
have
a
planner
of
when
would
we
like
remove
the
support
before.
A
We
can
the
only
thing
we
can
do
is
mark
that
extension
method
in
the
open
elementary
api
as
a
absolute
thing.
We
cannot
remove
it
unless
we
ship
two
dot
or
version,
so
it
will
remain
there
forever.
I
mean
until
we
reach
200,
so
the
only
thing
we
can
do
is
mark
it
as
obsolete.
So
just
like
a
warning
to
the
user
saying
that
okay,
I'm
using
something
absolute
so
in
the
absolute
warning
message
we'll
tell
that
okay,
please
go
and
use
the
activity
dot
status
directly.
A
So
it's
not
really
like
required
to
do
it
right
away,
but
maybe
like
once
all
this
exporter
changes
have
done.
We
can
do
a
small
pr
making
absolute
warning,
because
that
way
like
people
are
when
they
start
using
1.2,
they
immediately
get
a
compeller
warning,
saying
that
oh
okay,
it
says
I
mean
if
they
are
using.
If
they
were
using
it,
then
they'll
get
a
computer
warning
and
then
they
can
like
switch
to
the
new
status
and
since
exporters
are
already
covering
it,
they
would
be
unaffected
yeah.
A
There
is
like
this
thing
like
anyone
who
is
writing
their
own
exporter,
so
I
think
there
are
like
few
companies
who
have
their
own
exporter,
so
they
would
be
affected
if
that
exporters
don't
make
the
change.
So,
as
I
mentioned
like,
I
have
an
action
item
on
me
to
modify
the
writing
your
exporter
doc.
A
To
indicate
of
this
thing-
and
I
also
know
inside
microsoft,
we
have
our
own
exporter,
so
we
are
aware
of
it.
Helping
dyna
trace.
Folks,
that's
the
only
company
I
know
and
honeycomb
so
I'll,
just
like
do
mention
that
they
want
to
be
potentially
making
similar
changes
for
their
as
well.
I
mean
assuming
they
are
still
doing
something
with
the
status.
So
maybe
they
are
not
treating
the
auto
status
quotas
specially
anymore.
Maybe
they
are
just
treating
it.
A
I
don't
know
so
I'll
just
tag
them,
because
that's
only
two
exporters
I
know
which
is
written
like
custom,
so
there
could
be
more
but
yeah.
We
cannot
do
much
other
than
documenting
it
in
the
change.
Change.
No
change!
Look.
A
So
I
will
make
sure
like
we'll
review
and
get
this
at
least
zip
in
one
today
if
we
can
get
the
other
ones,
that
would
be
nice
to
include
it
in
rc3
so
that
we
can
truly
do
no
code
changes
between
rc3
and
stable.
A
But
if
you
think
that,
like
this
is
going
to
take
another
damage,
okay,
dude,
like
wait
for
another
day
like
we
can
like
delay
the
rc3
for
one
more
day
to
get
the
eager
and
otp
as
well.
So
we
can
try
to
see
if
we
can
help
each
other
and
make
it
happen,
because,
ideally
we
don't
want
to
be
like
releasing
like
I
mean
we
don't
want
to
be
like
merging
more
chord
changes
after
the
last
rc.
That's
the
ideal
state.
A
It
should
be
exactly
the
same
with
such
the
final
stable
one,
but
if
there's
a
need
we
have
to,
of
course
do
it.
So,
let's
try
to
see
if
we
can
get
other
exporters
I'll
also
help
this
week
today
and
tomorrow,
then
we
can
make
sure,
like
all
the
exporters,
are
called
okay.
Any
comments
on
this
one
or
questions.
B
B
Or
let's
see.
A
Okay,
this
has
some
approval,
so
mozzarella.
Can
you
quickly
summarize?
What
did
we
change
here?
One
second.
G
Sorry
I
was
unused.
Can
you
hear
me
yeah
yeah,
yeah
yeah?
So
initially
we
made
a
change
in
the
in
memory
exporter
to
do
just
a
type
check
if
it
was
being
initialized
as
a
metric
exporter.
It
had
just
an
extra
if
statement
and
boot
cars
advised
split
it
into
a
separate
class.
So
now
there's
a
new
class
in
memory
metric
in
sporter.
G
G
The
generic
in
memory
exporter
that
way
it's
able
to
reuse
the
logic
in
the
generic
exporter
and
just
has
this
one
extra
clear
statement.
So
it
saves
the
type
check
and
the
if
loop
in
the
hotpath.
A
B
A
Okay,
I
I
mean,
can
you
remind
me,
like
I,
totally
lost
strike
of
the
this
interest?
We
are
like
trying
to
solve
something
else
right:
okay,
we
basically
documented
that,
but
there
is
no
they're
not
like
really
fixing
anything
in
the
memory
explorer.
We
are
just
documenting
that.
As
soon
as
the
control
returns
returns
from
the
exporter,
you
can
no
longer
assume
anything
about
the
state.
So
that
statement
is
the
critical
thing
the
clearing
part.
Can
you
help
me
refresh
my
memory?
So
why
are
we
clearing
it
again?
A
Sorry
if
it
was
already
asked
yeah.
So
what
what
was
the
reasoning
behind.
G
Yeah
so
before
this
we
would
just
continuously
export
the
same
metrics.
Every
every
export
would
just
export
the
exact
same
metrics,
and
so
the
user
collection
that
exported
collection
would
just
have
duplicate
of
the
metrics,
and
anyone
who
was
operating
in
that
metric
would
either
do
a
manual
clear
themselves
in
their
controlling
code,
or
they.
A
A
Okay,
okay,
actually
we
do
it
before
calling
the
underlying
export,
and
this
would
call
the
base
exporter,
which
would
add
the
batch
into
the
order.
Okay,
I'm
still
thinking
like
what
what
implication
does
it
have
anyone
else
like
on
comments?
I
totally
understand
the
other
part.
I
am
still
like,
like
redigesting
this
part.
I
know
we
discussed
a
little
bit
in
the
past,
but
okay,
we
are
trying
to.
A
A
G
Because
it
doesn't
there's
no
value
in
preserving
the
formerly
exported
metrics
yeah,
because
it's
anyway
overturned.
A
By
the
interface
right
now,
I'm
now
only
debating
with
you
like:
do
we
have
to
do
it
in
the
merry
exporter,
or
do
we
just
document
user
say
go
and
do
it
yourself,
because
what
we
are
going
to
export
is
basically
duplicate
of
what
we
gave
in
the
last
cycle.
So
if
you
want
your
collections
to
like
in
there
keep
it
near
example,
says
make
sure
you
clear
it.
E
So
in
theory,
if
you
wanted
to
model
some
kind
of
test
where
you
wanted
to
look
at
both,
you
know
runs
the
first
batch,
the
second
batch
you
have
that
ability
today.
If
you
want
to
clear
it,
you
also
have
that
ability.
So
to
me
it
kind
of
feels
like
we
should
leave
it
up
to
the
user,
but
it
is
sort
of
a
surprising
behavior
and
very
different
than
you
know
how
activity.
A
B
Let
me
start
one
here,
clearing
some
connection
given
to
us
by
the
user.
Once
again,
this
prevents.
C
I
think
part
of
the
part
of
the
weird
thing
about
this
is
that
we
so
I've
looked
at
the
java
in
memory
exporter
and
basically
when
it
puts
the
stuff
out
to
the
collection,
which
also
is
something
that
the
the
user
controls.
Actually.
No,
that
may
not
be
true,
but
besides
that
the
things
that
get
exported
are
an
immutable
copy
of
of
the
metric,
but
the
difference
here.
The
unique
thing
with
us
is
that
it's
it's
immutable
under
the
underlying
thing
is
mutable
right.
C
You
might
understand
that
understanding
that
correctly
so
like
when
we,
when
we
add
things
to
the
a
second
export
happens,
the
same
reference
to
the
underlying
memory
is
is
added,
which
is,
I
would
agree,
doesn't
make
sense,
but
if
we
wanted
to
preserve,
then
I
think
it
would
be
best
to
pursue
something
where
we
would
keep
the
the
previous
export
immutable.
E
C
A
G
From
from
what
I
remember,
there's
no
obvious
way
to
do
a
deep
copy
of
the
metric
object
itself.
I
described
a
couple
different
options
like
how
you
would
normally
do
a
deep
copy,
the
memory
stream,
xml,
serialized,
json,
serialized,
reflection,
based
and
there's
like
blockers
or
concerns
with
every
approach.
Okay,
we
also
look.
D
G
G
Whoever's
consuming
it
don't
have
to
know
to
do
this
extra
thing
like
to
copy
the
metric
point.
Whenever
working
with
the
metric.
G
Point
is
a
struct,
but
it
contains
some
classes.
So
you
can
you
do
like
a
member-wise
clone
of
the
struck.
You
just
get
reference
to
those
same
classes,
specifically
histogram
bucket,
so
histogram
bucket
was
the
biggest
one
where
you
could
clone
your
metric
point.
But
then
all
your
clones
would
have
the
same
bucket.
A
And
that
could
get
affect
me
that
could
be
change
underneath
even
you're,
not
literally
copying
it.
It's
just
right,
so
maybe
like
one
other
thing
is
like.
I
think,
like
the
only
place
where
we
would
expect
the
memory
exporters
are
used
are
in
like
unit
test
like
not
not
really
like
production
level
systems.
A
Would
we
be
okay
to
undo
this
change
like
the
clearing
part
budget
now
and
had
this
documentation
and
like
if
there
is
any
pushback
on
that
later,
we
can
still
tweak
it
as
long
as
we
document
that
this
is
a
reason
why
we
are.
If
we
we
are
choosing
not
to
clear
it.
A
Would
that
be
a?
I
mean
it's
more
like
a
compromise
to
does
anyone
have
objections
if
you
go
that
route,
basically
like
just
reward
this
change,
which
is
doing
the
clearing
part,
but
make
it
a
make
it
still
the
responsibility
of
the
user
to
clear
it
because
they
own
the
collection,
so
they
are
responsible
for
it.
But
we
just
put
a
warning
saying
that
if
you
are
using
in
memory
exporter
after
every
collection,
we
are
going
to
give
you
the
same
thing
over
and
over.
A
A
All
of
the
unit
tests
which
are
using
in
memory
exporter
end
up
clearing
it
right.
So,
basically,
any
practical
usage
of
in
memory
exporter
involves
clearing
it
before
asserting
making
any
assertions
of
the
contents
inside
and
also
like
it's
different
for
metrics,
because
with
traces
and
logs
it's
a
different
activity
and
different
log.
So
you
can
keep
sending
it
to
the
list.
But
here
it's
the
same
thing
that
we
are
looking
at
we're
just
looking
at
different
snapshots
of
the
same
metric
and
method.
Yeah,
so
I
mean
for
consistency
sake.
A
That
would
be
like
one
argument
of
not
clearing
it,
leaving
it
completely
to
the
user
just
by
documenting
that
it's
your
responsibility
to
clear
it,
because
you're
not
really
adding
any
value
by
you're,
not
finding
it
any
useful
to
keep
copies
of
the
same
thing,
because
you
won't
be
able
to
know
what
happened
in
the
previous
one
unless
you
didn't
copy
yourselves,
yeah.
A
Okay,
so
maybe
like
that's
a
reasonable
balance
like
we
can
undo
the
clearing
part
put
the
dot
like
the
the
first
note
which,
where
we
want
about
the
there,
is
no
guarantee
that
the
underlying
state
is
going
to
be
saying.
That
part
is
good.
So,
let's
add
another
warning
to
in
memory
exporter
specifically
saying
that
the
exporter
could
keep
adding
same
things
over
and
over,
and
the
user
is
responsible
for
clearing
the
collection
if
they
choose
to.
G
A
Oh
yeah,
right
you
mean,
I
mean
it's
not
here,
but.
A
Is
passing
I
mean
holding
the
question
yeah?
Okay
here
we
could
say
that
here
yeah,
but
this
is
very
specific
to
metric
right
here.
So
this
is
then
the
right
place
where
you
can
say
that
yeah.
That
would
be
another
place
to
add,
but
it's
okay
to
just
have
it
in
the
in
memory,
because
I
don't
think
we
have
a
readme
for
in
memory.
So
let's
have
a
quick,
peek
yeah.
A
We
have
a
very
basic
thing,
so
maybe
we
can
add
like
this
is
intended
for
like
unit
test
purposes
and
like
I
had
a
subsection
for
matrix
thing
that
you
you're
expected
to
clear
it.
If
you
want
after
every
export.
H
H
A
A
Yeah,
so
so
that,
like
we
don't
change
any
behavior,
we
keep
the
behavior
asses.
We
do
like
two
dog
changes.
One
is
already
done
about
the
morning
the
metric
specific
one.
Now
we
modify
the
in
memory
specific
warning
to
want
the
user
to
clean
yeah
once
you
do
that,
like
do
an
explicit
mention,
so
I
can
go
ahead
and
merge
it.
Okay,
yeah!
So
I
think
that's
the
only
peers
which
we
need
to
cover,
because
those
are
the
things
which
we
really
wanted.
Consider
us
spoking.
A
C
A
remainder,
oh
sorry,
go
ahead
I'll,
just
just
one
other
thought
I
don't
know
you
may
have
mentioned
the
c.
Maybe
I
didn't
fully
understand
it,
but
maybe
in
the
future
an
idea
with
the
in-memory
exporter
is
that
we
could
have
like
an
option
that
allows
people
to
choose
the
the
data
format
that
they
want
to
store
in
memory.
So
today
we're
doing
we're.
C
C
D
C
Different
and
then,
if,
if
we,
if
we
thought
that
that
would
be
a
useful
thing
to
to
expose
in
the
future,
then
I
think
the
this
conversation
around
where
the
clear
should
be.
I
would
argue,
in
that
case
the
clear
actually
doesn't
belong
inside
of
the
exporter
right,
because
that's
that's
probably
what
we
want.
A
Yeah,
that's
I
mean
I
don't
regret
discussing
this,
so
maybe
this
is
a
good
thought.
We
should
explore
yeah
it's
interesting
that
there
is
no
specker
on
it.
So
it's
really
up
to
us
to
decide.
How
do
we
want
to
do
it,
but
yeah?
That's
a
good
thought
like
we
should
maybe
like
once.
The
immediate
pain
is
done.
Like
1.2
release
is
done.
We
should
like
revisit.
How
can
we
make
the
memory
thing
little
bit?
Better
user,
more
user
friendly
yeah
I
mean
for
folks
who
are
asking
like
how
will
unit?
A
Does
we
basically
go
and
look
at
our
unit
tests
and
how
we
are
using
in
memory
exporter
to
because
people
are
like
mostly
asking?
I
am
instrumenting
my
service
with
metrics
and
I
want
to
know
I
did
it
correctly
or
not.
A
So
the
only
solution
for
them
right
now
is
using
the
same
thing
as
what
we
are
doing.
So
if
you
wanted
to
be
like
any
better,
then
yeah,
it
should
be
like
additive
change
to
the
memory
exporter
to
convert
clone
or
change
the
format
to
json
or
any
other.
Okay.
A
All
right,
I
think
we
are
like
slightly
about
time
so
just
a
regard
like
please
go
and
review
this
ps.
I
will
put
this
prs
as
milestone
1.2,
even
though
it's
going
to
be
like
in
the
rc
milestone,
but
1.2
just
to
indicate
that
we
really
need
this
for
1.2.
A
Okay,
thanks
everyone.
I
will,
I
think,
if
I
need
any
help
from
ellen
to
do
the
release
part
two
yeah
like
we
discussed
like
we,
have
a
hiccup
in
the
naming,
so
I
had
to
like
figure
out
the
naming
part
so
I'll
play
with
that,
and
hopefully
we
can
address
that
by
tomorrow
and
do
the
release.
A
Okay
thanks
everyone.
If
there
are
any
other
questions
which
you
think
are
like
blocking
metrics,
please
place
it
in
the
chat,
treat
it
as
highest
priority
because
we
are
like
very
close
to
finally
shipping,
the
1.0
stable,
so
yeah.
Thank
you.
Bye,
see
you!
Everyone
bye,
bye,.