►
From YouTube: 2022-01-14 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).
A
A
A
I
mean
this
is
this
is
just
recreating
the
old.
You
know
the
old
thing
that
you
had
to
do
when
you
were
in
physical
offices,
where
you'd
have
to
go
from
one
meeting
room
to
another
to
try
and
find
a
meeting.
That's
all.
This
is
that's
a
feature.
A
C
Everybody
to
another
edition
of
the
legendary
python
cig,
as
always,
please
add
your
names
to
the
attendees
list-
will
be
beginning
in
one
minute.
If
you
have
any.
B
C
A
C
Yes,
I
guess
we
can
begin
now
topics
we
have
this
topic.
Yes,
your
commenter,
you
already
have
here
all
right.
Yes,
I
think
this
was
discussed.
D
Yeah
we
discussed
it
last
week.
Yes,
so
I
think
like
10
had
some
question
for
me
or
something
like
sikhan
basically
pulled
me
up.
E
B
Yeah
right,
so
I
wasn't
here
for
the
when
this
is
talked
about.
I
I
don't
know
exactly
what
this
is
like.
What
the
ask
is.
You
could
just
like
summarize
what
you're
trying
to
do
and
like
what
you
want.
What
you
need
from
us
that'd
be
great.
D
Yeah
so
like
sql
commenter
was
donated
by
google,
I
think
around
september
of
last
year,
so
currently
it
recites
in
a
separate
repository
outside
of
open
telemetry
country
or
outside
open,
telemetry
sdk.
D
And
so
there
are
few
tasks
like
we
are
renaming
the
packages
and
everything
verifying
things
are
working,
so
we
are
planning
to
release
it
from
the
independent
repo
first
to
make
it
work
and
like
for
that.
We
need
token
from
open
telemetry,
because
I
think
it
has
to
be
deployed
in
one
of
the
open
like
using
the
open,
telemetry
wi-fi
account.
D
Yeah
yeah,
there
are
basically
it's
in
two
places
like
initially
it
existed
in
google
cloud,
sql
connector
after
the
donation.
We
have
migrated
the
report
to
open
telemetry,
sql
commenter.
B
A
D
That
open,
telemetry,
okay,
so
the
plan
as
of
now
is
like
first
have
a
release
version
from
here
and
maybe
make
that
google
cloud
and
cloud
one
as
a
no
maintenance,
because
currently
it's
residing
in
two
places
and
if
issues
happen,
we
have
to
do
changes
in
both
the
places
till
one
is
like
completely
like
independent
or
it
is
working
so
open,
telemetry,
sequel,
commenter.
It
could
be
done
like
fully
migrated
when
we
have
some
release
from
here.
B
Okay,
all
right
yeah,
thanks
thanks
for
that,
so
I
was,
I
was
just
wondering
like
I
haven't,
taken
a
look
at
the
actual
meat
of
the
code
or
anything
of
the
migration
I
was
wondering
like
like.
Is
this
itself
just
a
another
instrumentation
like?
B
D
I
think
we
would
require
a
specialized
token
so
that,
like
we
as
the
maintainers
cannot
deploy,
I
think,
other
open
telemetry
instruments,
and
I
think
that
was
the
first
thing
we
discussed.
D
For
that,
we
need
to
create
a
project
like
someone
from
python
contributed
mesh
to
deploy
from
sql
commander
so
that
we
can
create
a
project
on
sql
commander
and
keep
that
particular
access
to
the
new
token.
B
B
I
see
I
I
believe
we
like.
We
have
a
process
to
that
that
publishes
packages
for
us
right,
like
no
one
person
has
access
to
that
like
it's
it,
it's
a
like
like
not
not
a
single
person
like
signs
into
the
open,
telemetry
account
or
something.
F
Sorry,
maybe
I
can
help
clarify
a
little
bit.
This
is
like
already
donated
to
open
telemetry
right,
so
this
opens
elementary
school
commenter.
Repo
is
a
separate
repo
in
the
open,
cylindry
org.
Already
we're
like
in
the
process
of
migrating
it
from
the
google
repo
to
this
opensource.
One
and
there's
been
like
some
changes
and
we
just
want
to
be
able
to
release
whatever's
there.
F
There
might
be
like
plans
to
move
it
to
contrib
at
a
later
point
is
my
understanding.
It's
not
really
decided
yet,
but
in
the
meantime
we
just
want
to
cut
a
release
right.
So
oh.
B
F
Yeah,
the
best
thing
would
be
to
do
it
under
the
open.
Telemetry
wi-fi
account
right,
that's
that's
all
we
want
to
do.
I
think
so.
The
easiest
way
to
do
that
is
with
or
like
the
safest
way
to
do.
That
is
with
the
pipe
tokens
which
give
you
scoped
access
to
a
single
package
to
publish,
but
you
have
to
first
publish
the
package
once
to
be
able
to
get
tokens
is
what
alex
told
us
last
week.
G
This
one's
repeating
so
I
see
the
comment
has
mentioned.
This
is
the
supported,
django
and
some
other
forum
for
python.
Does
it
make
sense
to
maybe
implement
these
as
part
of
the
existing
generation?
C
G
I'll
I'll
try
to
speak
louder.
E
G
Yeah,
that's
what
I
was
asking
if
that's
viable,
so
I
I
see
like
you
mentioned,
django,
flask
and
sql
coming
so
and
psychopathy
too
so
we'll
have
this
means
we'll
have
four
computing
or,
like
other
four
instrumentations
for
the
same
frameworks,
and
we
already
have
instrumentations
for
these
frameworks.
So
it
might
be
confusing
for
users
which
packages
to
install
and
which
packages
contain
which
features.
So
would
it
make
sense
to
like
put
that
code
and
host
that
code
in
the
existing
instrumentations.
E
That's
that's
that's
the
thing
that
not
decided
yet
like.
Ideally,
everyone
agrees
that
it's
better.
The
code
is
moved
to
the
contribute
contributor
for
each
one
like
for
the
java
and
the
js
python.
It's
not
decided
yet.
So
what
what
I
know
from
like
discussing
them
is
once
they
release
this,
and
then
they
duplicate
the
google
cloud.
E
Eventually
they
the
specification,
they
they'll
make
a
request
to
the
specification
team
and
then
once
it's
approved,
and
then
each
each
of
these
packages
get
merged
to
the
contributor.
D
Yes,
it's
more
like
the
first
version
of
it
like
for
people
to
at
least
test
it
out,
see
itself
tanya,
because
the
thing
is
it's
like
four
languages
and
everyone
is
to
agree
on
the
stakes.
The
specs
team
has
to
agree
on
the
specs,
mostly
so,
after
that
only
we
can
have
like
move
it
into
each
of
these
different
languages.
F
Yeah
late
in
just
to
clarify
on
that
there's,
basically
a
propagation
format
for
sql
commenter.
It's
you
can
think
of
it
almost
as
like
a
way
to
inject
trace
context
into
a
sql
query
right
and
there's
like
a
bit
of
a
specification
for
that
and
as
you
imagine
it's
it's
also
coupled
to
the
instrumentation,
and
it's
also
coupled
to
like
the
source
of
the
trace
context.
So
there's.
F
So
I
think
I
think
these
are
all
good
points.
There's
like
an
open
issue
already
to
try
to
hammer
some
of
these
details
out.
There's
like
some
complicating
factors
also
like,
I
believe,
there's
also
open
census.
Instrumentation,
like
you,
can
pull
the
trace
context
from
open
census
or
up
in
telemetry,
depending
on
what's
available.
F
So
it's
almost
like
a
cross
product
between
open
senses,
open
telemetry
and
then
each
instrumentation
and
it
also
sort
of
depends
on
like,
like
there's
an
action
controller,
there's
a
bunch
of
different
parameters
which
can
come
in
besides
just
stuff
in
your
typical
trace
context.
So
I
think
the
first
step
is
just
publishing
it
under
open
telemetry.
Since
it's
been
donated
to
the
open
telemetry
project,
and
then
we
can
like
we're,
really
happy
to
have
all
those
discussions.
B
What
would
like
until
we
decide
whether
or
not
to
put
in
contrib
or
not
like
what
does
the
like
support
story?
Look
like?
B
Is
this
exposed
to
customers
anywhere
like?
Is
it
supposed
to
be
already
used.
D
B
D
F
F
Yeah
that
that's
already
so
there
is
like
now
an
open,
telemetry,
school
commenter
group
with
maintainers
approvers,
etc,
like
there's
a
whole
separate
repo,
where
issues
can
be
open
and
stuff
like
that,
literally,
the
only
connection
to
the
python
sig
is
just
going
to
be
that
we
use
the
same
pi
pi
token.
For
now,
that's.
A
I
think
we
talked
about
this
at
the
last
week.
Sorry
I
I
stepped
up
for
a
couple
minutes
here,
but
last
night
we
talked
about
getting
the
package
published.
So
someone
who
has
access
to
the
open,
telemetry
tokens
will
publish
the
initial
package
and
then
create
a
sub
token
or
whatever,
just
for
specifically
for
this
package
until
it
gets
moved
into
the
repository.
F
B
I
actually
don't
have
access,
I
think
alex
is
the
only
one
who
does
right
now.
F
Cool
then
I
guess
from
the
sql
commenter
side,
all
we're
gonna
need
is
like
wheel
and
source
tarball
to
do
a
release
right
setting
so
like
to.
Whenever
we're
ready
to
do
the
release
from
the
sql
commenter
side.
For
the
first
release,
we
need
to
actually
one
of
the
one
of
either
layton
or
whoever
has
the
credentials
needs
to
upload
to
the
initial
upload
and
then,
after
that,
we
can
get
the
token
back,
but
so
for
the
first
release,
I
think
we're
gonna
need,
like
you
know
the
release
artifacts.
F
F
D
Aware
of
the
terminology
terminologies,
but
are
you
like?
Do
you
mean
to
say
like
that
workflows
and
all
these
things
get
get
workflows
and
all.
F
No,
no,
just
like
literally
just
like
build
artifacts
for
the
first
release.
B
B
B
Okay,
so
I
didn't
want
to
take
up
too
much
more
time.
Actually
yeah
yeah
we'll
we'll
talk
about
offline.
We
we
should
move
on.
Does
anybody
else
have
any
other
questions.
C
C
B
C
Next
week,
all
right:
okay,
if
we
can
reply
next
week
right.
C
Okay,
thank
you,
yeah
all
right
in
the
case
prs
well,.
C
That
you
are,
and
leaving
for
your
reviews
and
addressing
these
issues,
what
these
comments
that
you
just
started
here
aren't
just
a
question
mentioned:
that
we
need
to
import
a
synchronous.
F
F
C
And
yeah
stricken:
okay!
Yes,
I
see
this.
I
think
that
what
you
want
here
is
to
be
to
use
the
same
order
that
we
use
in
the
api
right.
E
C
Okay,
yeah
I'll
do
that
as
well
and
regarding
returning
instruments
well
I'll.
I
think
we
can
leave
it
like
that.
So
for
the
moment,
I
don't
see
any
harmony,
recording
an
instrument
in
a
synchronous.
B
E
No,
I
mean
what
do
you
expect
the
user
to
do
with
that,
like
in
synchronous
they
have
they,
they
do
the
like
recording
values.
I
am
adding
counters
right,
but
with
the
async
ones,
they
they
don't
really
do
much.
C
H
E
Yes,
so
the
measurement
consumer
here
will
call
it
periodically
and
then
collects
the
the
measurements,
but
they
they
cannot.
They
don't
do
anything
with
the
with
the
written
value.
C
C
Well,
we
can
change
that
as
aaron
mentioned,
because
no,
we
will
also
need
to
change
it
in
the
api,
but
I
mean
we
can
also
do
that
problem
so
yeah.
What
do
you
think.
F
I
think
it's
an
interesting
idea,
maybe
maybe
we
can
open
an
issue
for
it
and
revisit.
I
think
yeah
like
like
the
observable
instruments,
don't
really
have
any
methods
on
them
to
do
anything
with,
so
I
totally
see
where
you're
coming
from.
I
do
wonder
if
we
returned
if
we
started
returning,
none
and
later
on,
you
know
like
the
spec
changed,
we
have
to
start
returning,
something
it
shouldn't
be
a
breaking
change,
I
guess
but
yeah
I
don't
know
like
like.
B
C
All
right,
I
guess
we
can
create
an
issue
out
of
this
conversation,
all
right.
B
C
All
right
all
right!
Well,
thank
you,
everybody
for
your
reviews,
I'll
be
addressing
this
today
and
hopefully
we
can
get
the
merged
and
I'll
be
continuing
with
the
next
issue
in
the
list,
all
right,
okay
issues.
Here
we
have
this
one.
I
think
it's
alex.
C
Right,
well,
it's
more
than
informative.
I
think
it's.
It
is
wrong
to
name
a
class
default
because
default
is
not
an
intrinsic
attribute
of
the
class.
What
I'm
trying
to
say
is
that
the
default
class
that
is
used
may
change
and
if,
in
the
future,
that
class
is
no
longer
the
default,
then
we
will
have
a
class
name
default.
That's
not
the
default.
C
What
describes
this
class
is
the
fact
that
it
is
a
no
op
class
that
is
intrinsic
to
that
class.
So
no
up
is
it's
it's
the
right
name
in
my
opinion.
Now
the
here's.
Here's
a
comment
from
sprikken.
C
C
It
is,
it
is
no,
no,
no
or
the
spec
says
this.
Nevertheless,
the.
C
The
the
problem
is
that
default
implies
something
that
I
mean
it's
not
guaranteed
to
be
always
like
that
specific
class
may
not
be
default,
always
okay,
we
have
here,
we
should
say
identity,
so
no
makes
sense
to
me
or.
C
Okay,
now
there
is
another
point
I
want
to
mention,
but
maybe
after
we
we
discussed
this,
so
we
can
maybe
have
a.
E
C
Right
something
else
that
I've
been
thinking
is
that
we've
made
this
private,
but
I'm
not
sure
it
makes
sense
to
have
a
private
class
that
is
exposed
in
a
public.
That's
limited
like
that.
Introvert.
C
C
I
I
don't
know
if
this
makes
much
sense
right,
I
think
we're
exposing
a
private
class.
On
the
other
hand,
why
are
we
making
this
private?
What
is
the
motivation
to
make
this
private
in
the
first
place.
A
C
B
C
So
yeah
what
we
have
pretty
much
the
no
up
classes
are
like
the
api
implementation,
internal
implementation
right.
It's
like
the
api
sdk,
because
the
the
api
would
have
an
abstract
class
for
tracer
providers
and
also
a
concrete
class.
That
would
be
the
know
of
visor.
B
C
E
I
had
one
question
here
I
mean
if
they're,
not
if
they're,
not
public,
they
don't
really
have
to
add
any
deprecation
right.
I
I
expect
nobody
to
use
this.
The
default
support.
F
F
C
E
B
Yeah,
I
think
what
aaron
is
saying
is
like
if,
if
we
don't
deprecate
it
like,
like
the
existence
of
this
being
in
this
and
like
the
setup
file
and
like
being
used
for
auto
instrumentation
shouldn't
be
like
the
indicator
for
like
a
breaking
change.
It
would
be
like.
If
someone
were
to
explicitly
use
default,
tracer
provider,
then
that's
the
only
case.
It
would
be
a
breaking
change.
B
So
since
it's
private-
and
I
don't
expect
anyone
to
do
that-
I
think
secant
is
saying
like
there's
no
point
of
having
to
add
deprecated
well
well,
it
also
makes
sense
yeah.
B
We
we
don't
deprecate
private
things
yeah,
but
I'm
just
saying
like
it's
it's
just
because
it's
being
used
as
an
entry
point
right
now,
like
the
entry
point
name
itself
like
is,
is
it
would
be
a
breaking
change
if
we
change
that,
but
the
fact
that
we
just
used
specifically
default
tracer
as
the
implementation
for
usage
of
this
entry
point
doesn't
mean
we
can't
change
it
and
it
not
be
a
breaking
change.
Okay,
yes,.
C
No,
no.
What
I'm
trying
to
say
is
that
the
the
ideal
thing
will
be
that
if
someone
uses
the
default
tracer
provider
entry
point,
they
get
a
warning
saying
we're
gonna.
This
is
deprecated.
Don't
use
this
anymore.
B
C
Yes,
I'm
trying
to
say
that
the
this
is
private
right.
This,
the
the
class
is
private,
but
the
entry
point
is
public,
let's
say
so,
if
in
the
future,
if
if
what
we're
trying
to
do
is
to
get
rid
of
this,
we
the
thing
that
we
need
to
mark
as
dupricated,
so
that
the
user
gets
a
warning.
Is
the
public
thing
this
one.
B
C
No,
I
don't
think
that's.
That's
that's
a
good
idea,
because
the
the
default
racer
provider
entry
point
is
is
is
now
is
pointing
to
something
named,
no
up
tracer
provided
so,
for
example,
here
we
have
contours
context,
vars
context
and
it
points
to
context
bars
same
here
phrase
context:
it
points
to
trace
content.
A
C
What
I
suggest
is
that
we
make
a
new
entry
point:
name
no
op
tracer
provider,
because
at
the
end,
whatever
is
default
should
not
be
decided
by
the
name
of
the
entry
point.
But
by
then
the
normal
configuration
mechanisms
like
environment
variables
or
whatever
it
is
see.
What
I
mean.
B
B
Okay,
so
so
aaron
away,
like
oh
sorry,
always
alex
like
if
this
is
such
a
simple
thing
like.
Are
we
okay
with
what
diego
is
proposing
like?
So
we
could
just
move
on.
C
B
C
Okay,
no
more
comments.
I
guess
look
to
the
next
pr
here,
no
issue
here,
so
so
dogs
changes
to
split
out
of
my
expectations.
Mutation,
okay,
here
is
the
issue.
B
Yep,
so
this
guy,
he
went
through
all
of
our
docs
and,
like
kind
of
like
basically
he's
just
trying
to
like
suck
make
specific
sections
that
will
be
important.
I.
B
Be
an
okay
change,
it
makes
sense
to
me.
I
just
wanted
to
see
what
you
guys
thought.
I
liked
the
issue.
You
guys
can
take
a
look
at
it.
It
does
like.
What's
it
called
like
bring
light
to
a
lot
of
like
common
problems
that.
B
And
user
have
so
it
might,
you
know,
like
lower.
You
know,
supportability
cases
and
stuff
like
that.
B
Oh
it's
hard
to
say
no
to
someone
who
wants
to
help
with
the
communication
right
yeah,
that's
pretty
great!
Actually,.
B
Well,
especially
the
faq
sections,
it's
I
feel
like
we
can
put
a
lot
of
like
common
use
cases
there
like
repeated
questions
that
people
have.
So
I
think
it's
good.
F
F
Go
okay,
just
one
quick
question
so
they're
mostly
proposing
changing
the
navigation
right
and
adding
new
stuff
right.
F
C
All
right
great
well,
if
someone
else
has
any
comments,
I'm
sure
then
I
don't
hear
but
but
yeah.
I
guess
we
can
pretty
much
tell
character
and
p
to.
C
Perfect:
okay,
last
one
we
have
open
roadmap
for
bringing
the
existing
http
semantic
conventions
for
tracing
to
an
initial
stable,
oh
yeah,.
B
I
added
this
okay
yeah,
so
basically
yeah
I
was
talking
to
dennis
yesterday.
He
has
been
kind
of
like
leading
the
effort
to
try
to
push
the
http
semantic
conventions
to
the
first
1.0,
and
I
think
this
would
be
really
good
and
he
kind
of
needs,
like
our
help,
from
both
python
node
and
ghost
side,
actually
pretty
much
every
language.
Actually,
the
the
outline,
the
main
topics,
the
outline
and
the
oteps,
the
the
four
things
are,
the
ones
that
are
in
scope
for
1.0.
B
So
if
anyone's
interested
in
those
changes
on
what
he's
being
proposed,
I
think
this
is
this
would
be
really
good
in.
You
know,
actually
pushing
us
to
completion
and
then
and
then
we'll
have
a
bunch
of
other
topics
specifically
for
python
like
oh.
How
do
we
do
this
for
instrumentations?
Like
you
know?
What
does
that
mean
for
our
like
stability
for
instrumentation
packages,
but
we
can
deal
with
that
after,
but
it
is
something
to
keep
in
mind
of
oh.
C
Okay,
should
should
should
an
issue
be
open
in
a
repo.
B
C
All
right:
well,
that's
it!
For
today
anyone
else
comments,
questions,
suggestions,.
B
Okay
right
project,
yeah
yeah,
oh
diego,
I
think
you
also
have
a
the
the
bucket
histogram
pr
open.
I
think
aaron
also
yeah.
C
Comments
on
that,
you
want
to
talk
about
that.
C
Sorry:
okay,
yes,.
C
Okay!
Yes,
I
quickly
saw
this
comment.
I
have
not
responded
yet,
but
I
think
that
this
will
not
make
any
change
to
the
speed
up
because
ordered
here
is
not
being
used
to
in
the
searching
of
the
bucket.
C
F
So,
first
of
all,
it's
like
key
key
on
account.
F
Okay,
I
mean:
can
we
just
agree
like
generally
that
the
array,
the
array
would
be
probably
faster
than
like
a
dictionary
wrapping
the
integers?
If
we
already
have
the
index
right.
F
C
Yeah,
but
I
am
okay,
I
can
I
can
do
the
experiment
and
if
it's
faster,
you
can
make
the
change
the
the
only
thing
that
I'm
saying
is
that
before
we
were
going
through
all
the
keys
of
the
dictionary
in
a
sequential
manner,
and
now
we
are
using
binary
search
through
the
the
keys
and
we
are
only
using
the
dictionary
to
insert
the
values.
F
F
Okay,
maybe
maybe,
let's
put
aside
the
performance
thing
since
we
don't,
since
we
don't,
even
you
know
like
no
we'd-
have
to
actually
test
it.
If
you
want,
we
can
do
this
in
a
separate
pr.
I
just
think
it
would
be
a
simpler
representation
because
the
like
this
is
basically
exactly
what's
in
the
protobuf
right,
so
you
have
bucket
counts
and
explicit
bounds,
and
you
don't
need
you
don't
like
need
the
dictionary
at
all
right.
C
F
So
that
that
would
be
the
lower
bound
right,
not
the
bucket
number
like
if
they
want
to
know.
What's
in
the
like,
you
can
make
the
opposite
argument
right
like
if
they
want
to
know
what's
in
the
fifth
bucket,
they
could
just
say
boundaries
of
five
and
like
regardless,
that's
not
exposed
in
the
api
right.
C
A
F
Move
the
change-
I
just
think
this
is
like
a
more
simple
at
least
to
me.
It's
a
little
bit
easier
to
think
about,
given
the
the
format
that
we
exported
all
right.
Okay,.
C
F
C
C
Okay,
all
right
all
right,
more
comments.
C
Here-
okay,
all
right,
so
in
progress
I
don't
know
later.
Do
you
want
to
check
something
specifically
here.
F
Yeah
yeah,
so
maybe
we
can,
like
you
know.
Whoever
has
time
to
work
on
metric
stuff.
It
looks
like
we've
already
got
some
assigned
to
layton
myself,
treycon
alex
and
diego
right.
F
Okay,
do
we
have
any
like
like
do
you?
Do
you
all
think
you
can
work
on
it
this
week
or
what's
yeah
like?
Maybe
we
can
kind
of
do
like
a
stand
up.
C
Oh,
okay,
okay,
oh
cool,
okay,
all
right
I'll
go!
First!
If
you
don't
mind,
yes,
I'm
right
now,
working
on
the
last
comments
of
the
ad
measurement
consumer
pr,
they
are
not
big.
I
think
I
can
get
them
ready
today.
Hopefully,
if
everything
is
fine,
we
can
get
that
merged
today.
After
that,
I
kind
of
need
to
take
a
look
into
the
the
list
of
issues
to
select
the
next
thing
I'm
gonna
do.
F
F
B
Cool
yeah,
at
least
they
give
you
the
little
drop
down
thing
on
the
right.
You
do
add
it
to
the
project.
That's
pretty
cool
yeah.
C
F
Cool
anything
else,
do
you?
Oh,
no,
no,
all
right
cool
I'll,
just
go
next.
If
you
go
go
down
in
the
assign
column,
I
think
I
gave
myself
if
you
just
scroll
scroll
down
yeah
that
one.
So
I
gave
myself
my
default
measurement
consumer,
which
I
think
is
synchronous
measurement
consumer
now,
so
I'm
basically
just
going
to
put
in
some
of
the
code
and
the
and
add
tests
from
the
prototype
pr
and
that
one's
blocked
by
the
by
diego's
pr.
But
I
think
that
one
should
go
in
hopefully
really
soon.
F
So
that's
what
I'm
gonna
do
and
then
probably
all
I
can
get
to
this
week
all
right.
C
E
I
I
can
share
mine,
so
I
have
a
draft
pia
for
periodic
metric
reader.
I
was
waiting
on
the
measurement
consumer
pull
request,
hopefully
once
that
gets
much
I'll
make
it
up
and
make
it
open
for
the
reviews
and-
and
I
can
pick
up
any
new
to
that
I'll-
take
a
look
at
the
open
tickets
and
then
pick
up
pick
something.
E
Yes,
once
your
measurement
consumer
pr
gets
merged
I'll
make
the
changes
necessary
changes
and
open
it
up
for
the
reviews.
C
All
right,
perfect
great
what
else.
F
F
Just
wanna
like
or
comment
yeah,
I
can
try
it.
I
can
try
basically
there's
like
kind
of
undefined
behavior,
whether
or
not
you
would
return
the
same
meter
instance
or
a
new
meter,
and
that
affects
whether
you
get
a
new
instrument
or
the
same
instrument
right.
I
think
in
java.
What
they're
doing
is
they
keep
a
registry
of
the
meters
by
name
and
then
they
return
the
same
one
repeatedly,
I
kind
of
feel
like
that's
the
easiest
thing,
because
then.
B
It's
just
a
bit
different
right
now,
because
we
have
like,
like
proxies
and
stuff
too
so
we
gotta
keep
track
of
all
that.
But
the
principle
is
the
same.
A
Yeah,
I'm
working
on
the
other
exporter,
I'm
planning
on
adding
support
for
one
of
the
one
of
the
metric
types.
So
I'll
probably
just
start
with
some,
because
it
seems
like
an
easy
one
and
then
get
that
kind
of
push
through
and
then
add
the
other
types
of
separate
pr's
just
to
make
it
quicker
for
reviews
all
right.
C
E
C
C
All
right
we're
out
of
time.
Thank
you
very
much,
and
I
guess
we'll
see
you
next
week.