►
From YouTube: 2021-04-19 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
All
right,
let's
get
started,
welcome
everybody
to
our
weekly
maintainers
call
if
you're
new
here
welcome
if
you're
returning,
you
know
the
deal
so
we'll
get
started
with
the
sig
check-in,
starting
with
the
specification.
B
Yeah
hello,
we
did
release
1.0,
that's
when
say,
there's
an
important
point
regarding
trace
provider.
Tracer
provider
get
tracer
getting
new
value,
so
yeah.
This
is
something
probably
we
will
have
to
revert.
Probably
this
is
not
something
we
can
discuss
here,
but
we
will
be
discussing
this
tomorrow.
So
please
come
and
join
us
tomorrow
to
discuss
this.
A
A
All
right
I'll
keep
going
on
javascript
sdk
released
0.19
before
the
1.00
rc0
this
week.
Api
feedback
on
100
rc0
has
been
positive
so
far,
carlos
is
reviewing
the
api
for
correctness.
Excellent.
C
C
It's
just
some
people
don't
want
to
go
through
a
major
version
change,
so
it's
easier
for
them
to
continue
with
the
same
upgrade
path
and
then
once
they're
using
the
code,
it's
easier
to
swap
everything
all.
At
the
same
time,.
D
Riley,
there's
no
no
major
update
we're
still
making
the
beta
1.1.
Okay.
A
Go
working
towards
a
release
candidate,
11
items
to
do
six
in
progress,
254
done
nice
c,
plus
plus
sdk
multiprocessor
support
is
in
review,
api
baggage
support
and
review,
and
the
exporter
to
jager
and
thrift.
Udp
are
all
in
review.
Release
candidate
is
planned
for
the
end
of
may
need
to
revisit
this
still
looking
for
c,
plus
plus
developers
chatted
about
that
last
week,
and
the
milestones
are
tracked
on
the
sheet.
Excellent
ruby
is
working
towards
a
release
candidate
still-
and
that's
tracked
here.
A
Swift
spec
review,
if
by
carlos
is
done
and
corrections
were
added
for
main
components.
Main
limitation
is
low.
Usage
would
like
to
release
a
what
public
1.0
beta
wow,
that's
fast,
with
some
publicity
to
attract
users.
Fantastic,
that's,
amazingly,
quick
progress.
E
Yeah
we
would
like
to
I
don't
know
how
we
could,
how
the
pentametric
community
could
help
with
that
publicity,
because
we
are
really
very
limited
in
the
number
of
users
yeah.
So
we
know
some
of
the
areas
are
very
well
tested
and
working,
but
some
others
are
really
in
low
usage
and
we
wouldn't
like
to
go
with
an
rc
without
usage
and
don't
don't
know,
what's
the
best,
the
best
way
for
for
that
to
be
done
so.
A
A
Of
three
ways
just
immediately
off
top
of
my
head:
the
first
is
the
open,
telemetry
blog
that
we
have
like
you,
can
draft
a
blog
post.
I
I
can
just
approve
it
and
it'll
show
up
as
posted
by
you
with
a
blog
post,
saying,
hey
we're
approaching
beta
for
for
swift.
If
you're
interested
in
trying
it
out,
you
can
try
it
out.
I
think
that
would
that
would
help
if,
like
there
might
even
be
vendors
who
contribute
to
this
project.
I
don't
even
know
that
it's
available.
A
The
next
is
along
with
a
blog
post.
Certainly
the
open
symmetry
twitter
account
would
tweet
about
your
blog
post.
Finally,
I
think
kubecon
eu
is
coming
up.
I
haven't
been
super
attached
to
it,
but
we
can
also
chat
with
some
open
telemetry
speakers.
I
assume
there
are
some
open
telemetry
talks
happening.
Keep
going
to
you
to
have
them
mention
this
in
their
talks.
E
A
Thanks
all
right
so,
but
for
the
blog
posts
like
just
draft
something
up
or
if
you
want
just
send
me
a
message
and
I
can
definitely
assist
drafting
it
up
and
and
once
you
or
you
and
I
come
up
with
a
draft,
then
I
can
have
that
post.
This
was
published
by
you
on
the
official
blog
okay,
great
thanks
excellent.
I
I.
A
Okay,
great
yeah,
so
just
yeah,
let
me
know
just
send
me
an
im
on
slack
and
and
we
can
get
the
process
going
from
there
once
you've.
A
draft
great
all
right
next
is
collector.
Do
we
have
any
updates
on
the
collector.
F
G
Remaining
just
a
wild
guess,
you
might
be
in
the
template
instead
of
the
actual
notes,
but
maybe
not.
A
F
H
Yeah
so
main
thing
is
we're
working
on
upgrading
the
libraries
and
then
we'll
be
able
to
release
the
1.0,
but
we
are
also
in
need
of
an
airline
contrib
repo.
So
if
there's
someone
on
this
call
that
can
make
that
that
would
be.
That
would
be
great
thanks.
A
A
All
right
and
tristan
looks
like
you're
still
up.
H
Yeah,
hopefully
I
can
describe
this
really
quick,
I'm
holding
a
cranky
baby
who
might
be
quiet
long
enough,
the
so
yeah
I
had
some
concerns
when
I
was
looking
over
documentation
as
I'm
writing.
Erlang
documentation.
H
H
I'm
fairly
sure
I've
heard
automatic
even
be
used
to
apply
to
implicit
context,
propagation,
like
with
thread
locals,
and
so
it's
a
mixture
of
it
can
be
difficult
to
discuss
across
languages
or
people
who
might
be
reading
documentation
for
one
language
and
then
trying
to
apply
that
to
others
that
might
not
have
as
much
documentation.
H
So
I
guess
I
want
to
clarify
the
meaning
of
these
terms
with
everybody
and
then
it'll,
you
know
get
them
updated.
If
there's
any
differences
that
need
to
be
changed,
things
that
differences
in
how
they're
used
in
other
language
documentation
as
well
as
getting
deciding
if
the
term
implicit
or
automatic,
should
be
used
for
like
context
propagation,
with
a
thread.
Local.
A
It's
a
really
good
question.
I've
actually
caught
myself
doing
this
before
right,
because
we
we
particularly
look
like
java
right
we've
got
the
the
built-in
instrumentations
you
can
use
with
the
sdk
and
then
you've
got
the
the
actual
like
java
sort
of
agent
thing
that
can
automatically
instrument
a
jvm
application.
I
don't
think
as
a
project
that
we've,
as
you
point
out,
that
we've
been
we've
gone
and
built
the
right
nomenclature
for
this
yeah.
H
Yeah
it's
well.
No,
I'm
not
sure
it's
tuba,
I
mean
it
seems
to
imply
things
that
aren't
you
know
like
middlewares
things
that
aren't
code,
that
you
explicitly
say.
Okay,
this
http
server
uses
this
instrumentation.
Somebody
else
wrote,
but
are
things
that
you
simply
say
include
this
instrumentation
library
that
then
goes
and
figures
out
stuff
that
you're
using
versus
telling
something
that
hey
I'm
using
an
http
server.
H
Add
instrumentation.
I
think
that's
a
good
distinction.
I
I
don't
know
that
library
instrumentation
is
a
good,
is
very
descriptive
for
what
the
other
ones
are
like
what
the
middleware
type
ones
are,
but
I
think
automatic
being
magic
stuff
that
hooks
in,
for
you
is
fairly
descriptive.
I
D
I
Happens
magically
without
the
user
having
to
do
anything
library,
instrumentation,
you
have
to
wire
in
the
library
instrumentation
yourself.
If
you
want
to
use
it,
so
that's
for
java,
that's
how
we
tend
to
refer
to
it
and
hopefully
there's
a
comment
about
using
agent.
Well,
that
is
the
java
language
for
doing
bytecode.
Instrumentation
is
a
java
agent,
so
that
I
mean
that's
kind
of
what
we
don't
want
to
not
use
that,
because
that's
what
everyone
in
the
java
world
will
know.
H
I
D
Yeah,
so
my
understanding
is,
we
have
a
clear
definition
in
the
glossary
about
the
automatic,
instrumentation
and
instrumentation
library
and
the
act
of
using
instrumentation
library
doing
some
configuration
in
the
isdk.
That
action
was
not
clearly
defined,
but
I
guess
it's
probably
fine.
So
I
think
automatic
instrumentation
has
a
clear
definition.
It
means
some
byte
code
or
whatever
magic.
You
don't
use
any
sdk.
Instrumentation
library
is
a
collection
like
that's
already
specced
out
and
library.
Instrumentation
is
something
that
seems
a
little
bit
scary
to
me.
D
I
I
G
I
H
I
H
Yeah,
so
I
think
yeah
they're
yeah
it
might.
I
yeah.
I
don't
know
what
term
we'd
use
for
if
you
include
a
middleware
or
a
automatic
instrumentation
that
causes
the
http
client
to
propagate.
Without
you
writing
any
code.
Is
that
explicit
or
implicit
that
might
be
automatic
propagation?
So
might
be
a
good
term
too,
to
use.
A
H
No
well
yeah
posing
the
question
of
the
other
non-in
process,
propagation.
That
is
say,
you
include
a
library,
instrumentation
or
an
automatic
instrumentation
that
causes
your
http
client
to
automatically
propagate
context
across
processes.
Is
that
should
that
be
termed
automatic
propagation
in
the
glossary
or
something
else
or
just
propagation?.
D
So
my
suggestion,
like
at
least
what
in
donna
there
seems
to
be
a
very
good
documentation
and
people
like
it.
What
what
I've
seen
is
whenever
we
refer
to
some
terminology,
we
look
up
the
open,
telemetry
spike
and
make
sure
the
terminology
we
use
link
to
the
spec.
So
we
always
link
to
the
spec
and
we
we
don't
mention
or
invent
some
terminology
there,
and
if
this
is
something
we
need
we'll
put
the
full
description
unless
it's
clearly
specced
out
in
the
spec
report,.
I
D
Sometimes
it
means
you
just
like
like
spend
like
10
additional
words,
but
but
it's
much
better
than
mention
some
maintainers
are
familiar
with
and
all
the
others
were
struggling
with.
It
avoids
confusion,
keeps
it
consistent,
yeah,
agreed
and
also
one
example.
I
I
I
think
in
the
like
the
examples.
Initially,
we
will
call
that
samples
and
we
decided
samples
could
be
hard
when
people
try
to
search
sampling
like
samples
sample
out
or
sampled.
So
we
decided
that
all
the
examples
should
use
example
instead
of
sample
and-
and
that
seems
to
help
a
lot.
H
No,
I
think
that's
good,
except
just
the
I
mean
I
might
get
around
to
it.
Glossary
I
think,
needs
updating
for
propagation
and
yeah.
H
The
the
mention
of
examples
is
a
good
point
of,
maybe
even
in
the
glossary
I
don't
know,
but
I
know
it's
been
very
useful
in
the
spec
that
we
have
examples
for
a
lot
of
things
now
they're
in
go,
but
I
think
that's
worked
out,
but
so,
if
you
say
like
instrumentation,
a
library
instrumentation
showing
a
little
example
of
how
that
would
be
something
in
go
where
you
specifically
say
wraps
the
http
server
in
this,
this
instrumentation
library
automatic,
and
then
you
have
an
example
of
the
java
agent
or
something
it
could
be
useful.
H
A
Awesome:
okay,
next
topic:
riley
metrics,
api
and
sdk
release
plan.
D
Okay,
so
this
is
a
like
a
topic
brought
out
by
john
watson
and
the
the
ask
is
like
here:
the
matrix
spec
will
try
to
have
a
experimental
release
by
end
of
may.
That
means
beginning
from
june,
we
expect
majority
of
the
language
6
to
start
working
on
the
implementation.
So
number
one
ask
is
for
every
maintainer,
please
plan
this
accordingly
and
you
can
check
the
metrics
timeline.
There's
a
link.
The
second
one
is
different.
D
D
So,
based
on,
like
last
week
like
like
talking
with
multiple
folks
in
the
meeting,
I
I
think
java
and
go
would
most
likely
prefer
to
have
a
migration
path,
so
they
probably
will
have
a
paved
path
for
the
user
to
eventually
move
from
the
current
api
to
the
new
api,
without
like
directly
like
remove
all
the
apis
or
do
some
like
major
changes.
So
for
c,
plus,
plus
and
dot
net,
the
matrix
api
was
not
widely
adopted,
although
it
has
been
there
for
a
long
time.
D
D
So
the
ask
here
is:
if
certain
languages
like
python,
they
already
have
the
matrix
api.
They
need
to
think
about
either
the
align
with
go
and
java,
or
they
align
with
the
plus
plus
or
download,
instead
of
trying
to
invent
yet
a
different
approach,
because
we
want
the
entire
open
climate
across
language
to
be
as
consistent
as
possible.
D
So
this
is
the
ask
like
maintainers,
please,
plan
for
the
upcoming
metrics
work
and
also
try
to
sync
with
either
the
go
java
approach.
If
you
want
to
have
a
paved
path
or
you
take
a
breaking
change,
similar,
like
c
plus
plus
and
don't
add,
and
for
languages
who
don't
have
any
matrix
api
sdk
information
today,
this
shouldn't
be
an
issue
but
like
in
this
way,
probably
follow.
What
c,
plus
plus
is
doing
will
be
good
enough,
and
the
last
update
is
if
certain
languages
would
want
to
leverage
the
medium
post
to
communicate.
D
Hey
like
we're
going
to
make
the
certain
changes
and
here's
our
timeline.
I
expect
to
have
a
matrix
update
by
end
of
may.
Just
to
tell
people
hey
like
this.
Is
the
update
on
the
metrics
back
we're
getting
experimental
ones,
so,
please
expect
like
different
languages,
will
release
some
preview
version
and
please
try
it
and
give
the
feedback,
and
when
are
we
going
to
have
stable
release?
So
in
this
way,
if,
like
java
or
go
want
to
have
a
broader
communication,
we
can
use
this
to
have
a
one
single
communication.