►
From YouTube: 2022-05-23 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
A
Okay,
let's,
let's
jump
into
that,
thank
you
for
joining.
We
have
still
some
people
recovering
or
flying
back
from
kubecon.
Okay,
let's
go
over
the
agenda
specification,
no
updates
on
the
main
part
of
the
specification.
We
will
be
having
our
usual
release
by
the
start
of
june.
A
A
Okay,
moving
forward
logs
things
quiet
this
week,
proto
new
release
with
logs
declared
stable
is
out
fantastic.
C
Yep
I'm
here
we
released
0.0.3
of
the
contrib
repo
and
we're
working
towards
our
beta.
We
have
a
board
with
all
of
our
card
for
better
tickets.
A
Nice
thanks
so
much
for
that,
okay
java,
an
update,
okay!
Thank
you
on
the
java
instrumentation.
I
saw
no
notes,
but
I
saw
that
six
days
ago
1.14
was
released.
So
that's
that's
pretty
good.
That
includes
metrics.
If
I
remember
correctly:
okay,
javascript.
D
So
let
me
yeah,
no
I'm
here.
Sorry,
I
lost
the
window.
We
have
one
pr,
that's
the
the
multi-instrument
callbacks.
That's
currently
open
and
is
the
reason
we
have
not
officially
released
the
metrics
rc.
Yet
since
it's
a
breaking
change
for
the
interface.
D
A
E
Yeah
sorry,
yes,
we
made
our
release
with
the
metrics
rc
six
days
ago.
We
have
a
plans
to
get
those
table
in
three
weeks
or
so.
B
Yeah
I
could
take
that
we're
just
working
on
the
metrics
sdk.
Currently
the
alpha
release.
Current
status
is
28
open
21
closed
with
five
down
from
open
and
plus
13
from
last
week.
I
guess
that's
two
weeks
because
we
weren't
here
last
week,
yeah
making
progress
there,
it's
slow
but
steady.
I
guess
is
thank
you.
A
Okay,
I
guess
I
can
read
that
open
telemetry
one
1.4
release
last
week,
which
contains
alpha
milestone
rays
for
metrics,
which
is
great
and
locks
sdk
implementation
to
be
specs
compliant.
Probably
that
needs
some
review
or
something
metrics
rc
milestone.
It's
mentioned
here
with
release
candidate,
milestone
and
tentative
tuning.
A
Okay
looks
very
sweet,
ruby
country,
repos
is
still
ongoing.
A
Okay,
swift,
collector
rust
and
airline;
no
updates.
It
seems,
okay,
community
demo,
application.
Yes,
is
anybody
from
the
group
here.
F
Yeah
I'm
here
so
we
got
the
initial
demo
application
donation
merged
into
the
main
repo
we're
hoping
to
get
that
on
docker
compose
sometime
in
the
next
couple
weeks
and
then
we'll
have
kind
of
zero
complete
and
we're
also
finishing
up
our
architecture
right
now,
so
hopefully,
within
the
next
one
like
week
or
two
we'll
have
that
done
as
well
and
be
able
to
do
some
active
development.
F
A
Thank
you
so
much
for
that
and
finally
you
have.
We
have
a
small
point
about
feedback
from
cube
code
sessions.
I
don't
know
who
was
the
qcon?
What
at
the
point
here,
daniel
ortez,
maybe.
D
Yeah,
I
typed
that
up
just
real
quickly.
I
think
we're
going
to
do
a
more
in-depth
review
of
kubecon,
but
this
is
just
the
the
general
feedback
that
I
got.
I
was
at
the
booth
all
three
days,
so
I
thought
I
would
share
it
with
the
people
here.
D
D
The
the
strongest
feedback
that
I
got
at
the
booth,
though,
is
that
our
documentation
is
inconsistent
between
six,
so
some
of
them
are
are
better
documented
than
others,
and
some
of
them
are
documented
differently
than
others
like.
Sometimes
it's
on
the
website,
and
sometimes
it's
in
the
git
repo
and
for
some
users
that's
a
little
bit
confusing.
I
think
that
probably
comes
as
a
surprise
to
nobody,
but
I
thought
that
I
would
share
it
here.
G
Yeah
we're
we're
doing
some
work
in
the
com,
sig,
there's
some
tech,
writers
and
people
there
now
who
are
gonna
help
improve
the
docs
on
the
website.
It
would
be
great
to
get
more
participation
there.
One
thing
in
particular:
we've
noticed
and
I've
noticed
in
my
own
studies,
what
we
we
need
front
and
center
for
every
language.
Implementation
is
an
installation
guide.
G
If
you
look
at
our
docs
today,
they
they
tend
to
lead
more
with
here's.
What
a
span
is
here's,
how
you
use
the
api
and
they
don't
necessarily
have
here's,
how
you
install
the
sdk
and
configure
it
and
install
the
instrumentation
like
that
stuff,
and
that's
usually
the
first
thing
people
need
to
do
so.
That
would
be
my
request
to
maintainers.
G
It's
maybe
go
review
your
current
docs
and
if
you
don't
have
an
installation
guide,
kind
of
like
front
and
center
consider
just
recapturing
that
information
and
putting
it
in
a
single
place
for
people
to
find.
G
Really
either
I
mean,
ideally,
we
want
to
get
the
stuff
up
on
the
web,
but
I
think
it
will
help
tech
writers
do
it
if
they
have
existing
up-to-date
docs
to
to
refashion.
You
know
what
I
mean.
G
So
I
think
this
stuff
needs
to
be
in
the
repo
as
well.
My
personal
opinion
is
the
best
way
to
do
this
is
to
have
these
docs
in
the
repo
and
then
to
have
the
website
copy
them.
So
when
people
have
the
repo
downloaded,
they've
got
the
docs
that's,
but
if
people
want
to
to
only
put
them
in
one
place,
that's
I
think
we
decided
that's
the
prerogative
of
the
the
different
sigs.
B
That
sounds
good
one
other
thing
is,
there
is
like
a
third
place
where
docs
can
live
and
that's
for,
like
I
know
in
go
specifically,
I
think
it's
the
same
for
like
python,
but
like
yeah,
a
language
specific
repository
of
documentation
for
like.
C
G
Yeah,
I
guess
just
I
would
suggest
yeah
as
as
maintainers
like
language
maintainers,
the
docs
that
are
in
the
place
where,
where
the
devs
are
gonna,
look
right,
so
if
that's
go,
that's
that's
go
docs
different
languages
have
different
defaults,
making
sure
that
there's
something
there,
or
at
least
a
link
from
there
to
to
to
some
other
place
where
they're
put
the
advantage
of
those
kinds
of
documentation
sources
is
their
version.
I
think
that's
the
one
disadvantage
of
the
website.
G
It's
a
little
harder
to
provide
correctly
version
docs
for
the
particular
version
you're
using.
So
wherever
is
most
most
comfy
for
language
maintainers.
To
maintain
those
stocks,
I
would
say:
do
it
just
make
sure
that
the
other
places
we're
putting
docs
a
reference
reference
that
spot
and
we'll
be
working
with
tech,
writers
and
stuff?
So
I
think
there
will
be
people
coming
around
helping
to
kind
of
normalize
this
stuff.
G
I
think
the
the
hardest
part
is
just
making
sure
that
the
information
is
is
up
to
date
and
clearly
laid
out.
If
you
look
at
some
language
repos
today
or
their
webs,
the
web
docs
for
them,
they
just
don't.
Have
they
they
often
have
clear
api
documentation,
but
they
don't
necessarily
have
a
clear
installation
or
getting
started
guide.
It's
usually
it's
sometimes
it's
like
buried
in
in,
like
a
sort
of
tutorial
walk
through
or
something
like
that.
It's
not
just
like
a
clear
like
here's.
G
When
it
doesn't
work,
here's
the
the
troubleshooting
you
can
do
to
to
figure
out
why
it's
not
working,
and
so
I
think,
if
you
get
help
from
the
language
maintainers,
if
they
know
know
those
steps
just
to
get
them
written
down.
It'll
it'll
save
us
some
research
time
in
the
comms
group
figuring
it
out.