►
From YouTube: 2022-08-18 meeting
Description
Instrumentation: Messaging
A
B
B
A
B
B
It
looks
like
it's
gonna
be
a
pretty
short
meeting,
so
we
probably
just
jump
into
it.
To
start
it
off.
Take
a
look
at
the
metrics
sdk
progress
for
the
alpha
release,
doing
pretty
good
this
number's
down
to
81
from
like
86
just
because
we
have
a
lot
in
the
pipeline,
so
yeah.
I
definitely
wanted
to
spend
a
little
bit
of
time
here
just
to
see.
If
we
try
to
clear
this
out,
we
have
a
lot
in
progress
and
I
think
there's
a
lot
of
reviews
that
are
needed.
B
This
is
the
pr
here.
I
think
it's
got
one
review.
I
guess
technically
it
it's
a
documentation
pr,
but
I
was
waiting
on
another
review
before
I
merged
this.
So
that's
up.
If
you
have
the
time
to
to
review
that,
I
think
that's
good,
the
next
one
for
the
open
source
or
the
otlp
metrics
exporter
there's
a
pr.
I
have
out
for
the
exporter
itself.
This
is
at
the
high
level
of
the
otlp
metrics
level.
B
B
Next
we
have
the
ad
async
instruments
and
providers
pr
this
has
had.
I
guess
just
me,
one
review
so
far.
It
doesn't
look
like
aaron.
I
don't
know
if
you've
had
time
to
look
at
this
okay,
so
it's
still
a
work
in
progress,
but
it
could
definitely
use
some
more
eyes.
This
again
is
a
really
important
one.
It's
tied
to
the
async
instrument
stub,
which
could
go
here
as
well,
and
I
think
the
callback
handling
to
aaron
right
yeah.
B
Yeah
move
those
over.
I
think
the
only
one
left
then
would
be
this,
but
these
are
important,
because
this
is
the
thing
that
starts
to
unblock
the
front
of
the
ingest
of
setup
of
the
metrics,
which
then
unblocks
all
the
example
codes
and
the
usage
of
the
sdk.
So
these
are.
This
is
a
good
one
to
get
some
eyes
on.
B
If
you
have
time
next
up
is
open
census
work,
david
ashford
is
on
so
yeah
he's
been
doing
great
work
at
the
specification
level
as
well
as
here,
because
I
think
go
might
be
one
of
the
few
places
that
open
census
is
kind
of
bridge,
but
it's
a
it's
an
important
one,
and
so
there's
a
metrics
translation
library.
Here
I
think
this
is
actually
well
it's
only
three
hours
old,
so
it's
ready
to
merge
with
based
on
the
current
reviews.
Dave.
A
Nope,
just
that
it's
or
sure
I'll
have
something
it's
not
a
complete
bridge,
given
that
we're
still
discussing
sort
of
where
it's
going
to
fit.
This
is
just
the
like:
translate
a
list
of
open
census,
metrics
to
a
list
of
open,
telemetry
metrics,
since
we'll
probably
need
that
piece
and
it's
informal.
So
you
know.
B
Yeah
absolutely
yeah:
this
is
it's
pretty
straightforward
if
you've
already
reviewed
a
translation
pr
which
I'm
sure
you
have
this
is
shouldn't
be
too
much,
then
the
only
thing
next
would
be
the
reintroduction
again.
This
is
another
really
straightforward.
One
diff
is
your
friend
here.
Dave
is
just
adding
back
the
tracing
portion
of
open
census
that
was
removed.
So
I
don't
think
this
is
too
controversial
either
right,
david.
B
Yeah
yeah
exactly
yeah
okay,
so
that
is
everything
in
progress
so
yeah.
Definitely
these
two
are
pretty
straightforward
pr's.
This
is
a
pretty
high
priority
pr.
This
is
blocking
other
otlpx
work
and
then
this
is
documentation.
So
if
you
have
some
time,
reviews
would
be
really
welcomed
to
help
progress.
The
metrics
sdk
at
this
point
that
makes
sense
looking
forward
to
what
we
have
to
do
afterwards.
There's
still
another
one,
more
documentation,
package
or
issue,
looks
pretty
straightforward.
We
have
a
taker
for
the
prometheus
exporter
code.
A
B
C
A
B
Cool
okay,
then
up
is
the
syncs
synchronous
instrument
stubs,
which
I'm
guessing
is,
is
follow
on
to
this.
So
we
need
to
get
this
through
the
the
async
one.
First,
it
does
let
the
groundwork
of
some
overlap.
I
know
this
is
kind
of
the
open
census
bridge
one.
This
is,
I
don't
know
if
david
want
to
talk
a
little
bit,
but
I
know
it
follows:
there's
some
specification
issues
yeah.
We
need
some
sort
of
way
for
another
thing
to
provide
metrics
to
readers.
B
Currently,
we
hide
all
of
the
registration
methodology
and
the
producer
functionality
of
the
metrics
sdk
and
the
census
bridge
is
going
to
need
a
way
to
transmit
those
metrics.
So
if
you
haven't
taken
a
look
at
the
specification
issue
linked
here
as
well,
it's
worth
getting
some
eyes
on
that.
I
think,
is
a
good
idea.
A
Yep,
that
would
also
be
appreciated,
and
please
don't
review
this
proof
of
concept.
This
is
just
for
me
to
play
around,
but
yeah
yeah,
but
if
you're
curious
what
it
might
look
like
and
go
or
actually
now
that
the
spec
pr
has
changed,
this
is
no
longer
what
it
would
look
like
and
go
so
I'll,
probably
update
this
soon.
B
B
C
It
just
doesn't
function
without
it,
which
kind
of
forces
us
to
change
our
linting
workflow
to
run
on
go
119.,
and
I
want
to
make
sure
that
everyone
is
okay
with
that,
especially
since
go
119
introduces
changes
to
gofund,
which
are
going
to
basically
require
that
anyone
developing
in
this
repo
now
develop
on
119.,
and
I
think
we
also
are
going
to
have
to
do
the
same
thing
in
the
core
repo
goldenseal.
There
is
currently
has
a
dependency
on
a
pseudo
version.
B
I
personally
would
welcome
the
upgrade
across
the
board
to
119
I'm
using
119
on
my
local
system
and
currently
trying
to
run
the
ci
system
with
go
119
based
on
our
current
going
ci
like
went
set
up
it
it
panics
and
like
there's
some
really
bad
issues.
I
think
mostly
around
like
go
simple
and
other
things
that
were
blocked
on
trying
to
support
generics
and
go
118..
So
if
we
can
update
that,
I
think
and
then
try
to
unify
and
go
119..
I
would
appreciate
it
but
yeah.
B
C
A
B
B
B
Well,
cool,
I
guess
that's
no
news
is
good
news.
Then
I
guess
we
can
end
it
here
then
definitely
a
short
meeting
thanks
everyone
for
joining
appreciate
it
all.
If
you
have
time
I'll,
let
you
get
back
to
going
to
those
reviews,
but
otherwise
see
y'all
next
week
same
place
same
time
very
seriously.
Bye,
rome.