►
From YouTube: 2021-06-21 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
B
Sorry,
it
was
muted,
hello,
hello,
good
start
of
the
week.
Please
add
yourself
to
the
agendas
usually
and
let's
start
in
one
or
two.
B
B
Okay,
let's
start
thanks
for
joining
as
previously
mentioned.
Okay,
let's
go
over
the
agenda.
First
of
all,
the
specification
just
for
your
information
there
there's
a
new
pair
of
new
groups.
The
instrumentation
one
is
in
theory,
already
started
or
it's
bootstrapping
is
death
young
on
the
call
death.
Are
you
around.
C
B
B
The
second
one
is
that
we
will
be
starting
most
likely
the
sampling
see
like
trying
to
restart.
You
know
this
effort,
so
this
is
for
you
to
know
if
you're
interested,
please
stay
in
the
loop.
Okay,
next
metrics.
B
B
Now,
okay,
without
logs
something
happening
there.
B
G
So
I'm
just
back
from
my
vacation,
but
from
what
I
see
the
version
22
for
sdk
has
been
released,
which
is
compatible
with
version
1.
of
the
api,
the
contrib
from
what
I
see
hasn't
been
released.
So
I
guess
we
should
probably
focus
on
releasing
the
contrib,
so
it's
compatible
with
the
latest
api
and
sdk.
B
A
Yeah
I
can
share
so.
Basically,
the
only
thing
which
is
happening
is
the
matrix
sdk
work
in
the
repo,
mostly
trying
to
help
with
the
spec
work,
where
we
are
now
prototyping
a
view.
Api.
Sorry,
the
view
in
the
sdk
that's
the
most
important
update,
which
is
happening
in
the
repo
but
parallelly
the
dotnet
team,
where
the
apa
would
be
part
of
they
have
already
released
the
first
preview
version,
which
contains
the
open,
elementary
compatible
or
open
elementary
matrix
api.
A
So
the
entire
sdk
which
open
telemetry
ships
from
our
repo
will
be
just
built
on
top
of
whatever
is
provided
by
the
dot
net
team.
So
this
is
a
first
update.
I
still
think
it
has
like
some
instruments
which
are
part
of
the
auto
spec,
but
not
yet
included
in
the
dot
net
team,
because
they
are
still
waiting
to
get
a
like
better
stability
guarantee
on
the
epa
before
adding
it
into
the
dot
net.
So
yeah,
that's
pretty
much.
It.
H
Go
yeah.
I
can
give
an
update
if
anthony's
right
on
we
had
a.
We
successfully
made
a
release
candidate
last
week,
the
first
one
for
the
wanna
stable,
stable
release,
which
is
really
exciting,
pretty
pretty
stoked
about
that,
and
now
we're
working
towards
the
actual
1o
1.00
release.
I
Yeah,
so
we
did
had
a
second
release
candidate
last
week
on
friday,
so
we
are
more
close,
closer
to
the
stable
free
series
and
we
are
working
on
the
microstone
for
onenote
group.
So
probably
we'll
be
publishing
it
this
week
and
there
is
a
ask
from
us
for
we
need,
I
think,
for
short
term.
We
need
some
basal
experts,
so
basically
open
telemetry,
c,
plus
plus
supports
builds
using
both
bazel
and
c
make.
I
I
So
I
think
it's
good
if
somebody
can
really
help
us
for
short
term
is
the
build
part,
not
the
specs
or
implementation.
But
if
somebody
has
expertise
on
bazel,
I
think
it
would
be
definitely
good
for
us
so
yeah.
That's
that's.
I
B
Okay,
I
will,
I
will
ask
around
see
if
there's
somebody
here
so
please
everybody
do
that
in
your
own
companies
as
well.
That
can
be
tricky.
Yes,.
B
Okay,
ruby,
you
guys
have
something
or
no
major
updates
for
now.
B
C
Her
a
quick
update
did
you
want
to
give
I'm
here,
go
ahead.
Go
ahead.
You
started
go
ahead,
okay,
sure
so
tigran
and
robin-
and
I
you
know
we're
working
on
this
and
right
now
we're
tracking.
So
we
had
some
discussions
about.
You
know
what
needs
to
be
done
to
complete
a
complete
tracing
stability
for
core
collector,
and
we
have
you
know
three
phases
in
the
backlog
that
we've
identified
and
have
been
working
towards
phase.
C
One
is
almost
complete
that
will
mark
the
stability
of
the
core
collector.
There
are
three
items
still
in
flight,
big
items,
but
nonetheless
you
know
there
are
three
clearly
defined,
and
what
we
have
also
discussed
is
that
we
will
move
in
order
to
achieve
core
stability
and
tigran.
You
know,
please
feel
free
to
also
clarify
further.
In
order
to
achieve
core
stability,
we
will
move
any
of
the.
C
You
know,
components
that
are
still
being
evaluated,
such
as
processors,
and
you
know
some
redesigned
work
that
needs
to
be
happening
there
to
into
contrib
in
order
to
you
know
ensure
that
core
is
stable
and
and
at
the
same
time
publish
very
clearly.
You
know
what
those
stability
guidelines
are
for
core
and
then
continue
to
work
towards
contrib
stability
in
the
next
couple
of
months.
C
So
that's
that's
kind
of
the
game
plan
and
there
are
a
couple
of
issues
I
linked.
You
can
track
the
backlog
as
well
as
the
issue
in
terms
of
what
we
will
be
having
a
clear
list
of
components
that.
C
The
processors
that
we
will
move
to
the
token
trip
and
then
going
from
there
pull
in
anything.
That's
that
stable
thereafter.
Tigran
did
you
want
to
cover
anything
else.
E
C
For
tracing
we're
tracking
phase
one
for
for
phase
two,
this
will
be
contrib
stability,
I'll
I'll,
make
the
descriptions
a
bit
more
clear
and
then
post
you
know
stable
is
really
the
refactoring
such
as
and
and
some
of
the
work
that
needs
to
be
done
thereafter.
B
So
I
guess,
updates
this
week:
okay,
perfect
yeah!
So
then,
let's
move
on
with
the
agenda.
I
put
a
few
items.
Sorry
for
the
excessive
I
put
them.
I
put
their
four
items,
it's
mostly
about
just
trying
to
point
people
into
that
direction
of
you
know
in
the
direction
of
some
specific
items.
The
first
one
is
that
it
was
filled
by
nikita.
B
It's
about
there's,
not
a
clear
list
of
what
otlp
formats
are
supported
by
different
seeds
and
actually
for
that.
I
think
I
I
do
remember
that
we
left
that
in
the
air
before
1.0
and
now
we
we
need
to
take
that
back
and
I
I
don't
think
there
are
yeah
but
you're
here
or
javascript
developers.
I
think
that
for
the
tricky
thing
there
is
that
in
some
six
you
may
default
to
some
specific
one
because
you
have
to
like.
B
I
think
javascript
wanted
to
default
to
json
over
http
right,
for
example,
so
yeah.
We
need
to
gather
some
information
there.
So
just
please
comment
on
that.
I
don't
think
we
can
really
provide
the
fact
to
the
folder.
Sadly-
or
I
don't
know
so,
please
take
a
look
at
that.
I
think
that
most
of
the
six
support
grpc-
that's
that's
my
impression.
B
The
second
one
is
theotep
that
josh
sure
from
google
paul
steff.
He
has
been
there
for
a
few
days
now.
I
see
that
mostly
the
same
people
that
started
the
review.
Are
the
ones
iterating
over
that,
but
it
needs
more
eyes,
especially
because
it
would
affect
the
dsdk
side.
B
So
please
maintainers,
if
you
have
some
free
cycles.
Please
take
a
look
at
this
comment
on
something.
If
you
see
something
that
is
problematic
or
you
think
we
should
push
for
that
harder.
Just
please
leave
a
comment
there
and
finally
go.
The
next
two
items
are
around
instrumentation.
I
don't
think
that
that
is
here
well
too
sad
about
that.
But
the
thing
is
that
we
have.
This
is
a
recurring
problem
between
manual
and
auto
instrumentation
about
how
to
not
instrument
twice
the
same
path.
B
So
please
comment
on
that.
I
think
that's
it's.
I
think
different
languages
have
taken
different
routes
to
solve
this
problem,
but
it's
still
a
problem.
We
need
to
work
on
that.
The
other
one
is
an
instrumentational
instrumentation
that
anurag
put
together
to
try
to
unify,
or
at
least
provide
some
general
guidelines
for
instrumentation.
I
think
that's
very
important,
as
I
said
the
manual
and
now
to
instrumentation
application
problem
and
the
instrumentation
of
tips
filled
by
anurag,
most
likely
will
be
taken.
B
D
Yeah,
so
this
is
a
need
that
we've
recognized
when
talking
with
some
go
projects,
especially
those
that
are
converting
from
open
tracing
which
had
a
span.tracer
method
that
gave
access
to
the
tracer
that
was
used
to
construct
the
span.
D
Users
are
expecting
to
be
able
to
continue
to
use
that
method
and
for
for
a
while,
we
had
a
tracer
method
on
the
span
in
go
that
returned
the
tracer,
but
in
open
telemetry.
The
tracer
is
slightly
different
from
what
it
was
in
open
tracing.
Now
I
think
the
tracer
provider
is
the
more
analogous
concept,
that's
where
the
export
pipeline
is
configured
and
all
of
that,
whereas
the
tracer
includes
instrumentation
library,
information,
schema
version
and
those
things
that
you
don't
want
to
be
taking
from
some
unknown
parent.
D
So
I'm
crafting
a
pr
for
the
spec
right
now
that
will
add
a
tracer
provider
method
to
the
span
to
enable
retrieving
from
the
span,
the
tracer
provider
that
was
used
to
construct
it
and
the
intended
usage
pattern.
There
is
that,
then,
a
user
can
pull
a
span
from
a
context
without
any
previous
configuration
retrieve
the
tracer
provider
create
their
own
tracer
and
then
start
creating
spans.
That
will
be
part
of
that
trace.
D
So
I
just
wanted
to
let
the
this
group
know
that
that
pr
will
be
coming
I'll.
Have
it
in
later
today,
just
cleaning
up
the
language
a
bit
now
and
would
appreciate
eyes
on
that
I'll,
bring
it
up
again
in
the
spec
meeting
tomorrow
as
well.
F
So
I
was
working
with
avida
and
some
of
the
other
php
people
this
week,
one
of
the
main
or
one
of
the
individual
contributors
mentioned
that
we
weren't
following
spec
exactly
for
api
and
sdk
separation.
We
have
them
both
in
our
main
repo
and
that's
more
of
an
idiom
of
php
versus
some
other
languages.
I
know
like
go
and
java.
F
It
makes
a
lot
more
sense
to
have
separated
packages,
so
I'm
planning
on
writing
an
ochep
for
that
this
week,
but
I
wanted
to
follow
up
with
y'all
and
see
if
anybody
just
has
like
a
a
huge,
strong
feeling
about
this.
I'm
sure
nobody
does
but
the
way
the
spec
is
worded.
It
makes
it
sound
like
it's
an
explicit
dependency,
even
though
it
might
not
need
to
be.
D
F
B
B
J
So
we
don't
have
anything
in
place
for
php,
but
I
think
one
of
the
one
of
the
core
concepts
is
that
one
would
always
be
able
to
either
have
a
completely
rewritten
sdk
with
for
for
special
reasons
like
I
don't
know,
having
a
streaming
sdk
that
that
does
everything
synchronously
or
something
like
that
or
just
have
a
fork
for
whatever
reasons
of
the
sdk,
and
I
think
that's
why
the
by
the
api,
the
spec
was
written
in
that
way.
D
D
F
A
good
point,
I
know
that
open
open
census
did
that
in
the
same
package
too,
for
a
phd,
probably
for
the
same
reasons
that
we're
coming
across
this.
This
like
it
would
be.
Very
I'm
saying
I
guess
my
point
is
it'd,
be
very
difficult
to
package
the
api
and
sdk
separately
in
php,
and
we
can
attempt
to
do
it,
but
I'm
just
making
sure
that
before
we
go
down
that
rabbit
hole
that
we
have
a
good
reason
to
do
so.
B
Yeah,
probably
in
the
other
tab,
if
you
list
the
the
exact
technical
details
of
why
it's
a
bad
idea,
and
that
could
be
good,
I
mean
I'm
telling
that
as
a
you
know
like
for
people
who
are
not
familiar
with
php,
and
it
could
be
harder
to
grasp.
D
Cool
no
problem.
Thank
you,
carlos
I'll.
Make
sure
to
include
that
in
my
hotel
is
the
concern
just
the
packaging
of
the
api
and
the
sdk
together.
Or
would
it
be
that
it
would
be
impossible
to
use
the
api
with
another
sdk,
because
I
think
it
might
be
fine
if
they're
packaged
together,
but
you
could
still
use
a
different
sdk
with
the
api.
F
So
I
think
the
answer
to
that
is:
it's
really
like
packaging
in
php,
like
with
separate
inherent
packages,
gets
really
really
difficult
for
lack
of
effort,
I'll
make
sure
that
I
add
all
sorts
of
technical
implementation
details
on
ph
on
the
hotel,
because
I
don't
want
to
bore
people
here,
but
too
long
didn't
read,
it's
boring
it's
annoying
and
difficult.
So
if
we
can't
avoid
it
I'd
like
to,
if
not
I'm
happy
to
do
it.
C
Yeah,
I
think
bob
again
to
your
point
and
anthony
what
you
mentioned.
Is
it
possible
to
ever
use
a
different
sdk
with
the
php
api,
it's
difficult
right
and,
and
I
think
that
all
we
need
to
do
in
the
otap
is
at
least
clearly
itemize
the
use
cases
that
you
know
99
of
the
time
the
same
sdk
obviously
will
be
used,
but
clearly
itemize.
What
happens
if
you
know
there
is
a
different
sdk
that
so,
if
they're
trying
to
use.
B
Perfect,
looking
forward
to
read
that
tip,
thank
you,
okay!
That's
what
agenda
do
you
guys
want
to
discuss
something
else.
C
I
think
carlos
one
of
the
things
I'd
like
to
bring
up
and
again
this
is
just
for
discussion-
is
that
we
should
be
regularly
communicating
an
update.
You
know
as
a
blog
post,
even
if
we
are
just
linking
to
the
maintainer
knows
at
least
once
a
month,
because
I
think
that
you
know
gives
a
lot
of
a
lot
more
understanding
across
all
the
different.
You
know,
folks,
who
are
tracking
the
project,
it's
easier
to
point
folks,
to
do
that.
We
did
that
for
the
metrics
and
the
trace,
you
know
updates.
C
B
C
I
think
I
think
what
has
happened
is
austin
is
out
there's.
My
understanding
is
that
you
know
nobody
is
really
driving
that,
but
at
least
from
an
you
know,
engineering
point
of
view.
If
we
can
communicate
that's
also,
it
doesn't
have
to
be
too
ready
just
pointing
to
you
know.
We
already
have
the
release,
notes
and
everything
that
you
know
are
published.
B
Yeah,
that's
a
good
point,
but
out
of
curiosity
I'm
sorry
I
am
out
of
that
loop.
What
is
the
communications
sick?
The
calls
are
still
happening
or
did
there
are
no
happening.
C
Having
heard
that,
they
weren't
in
in
the
last
couple
of
iterations.
B
I
see
interesting
okay,
I
will
follow
up
what
we
said
since
you
just
said.
You
talked
to
that,
so
I
will
and
then
I
will
follow
over
with
you
so
yeah.
C
And-
and
it's
it's
also
because
you
know
we
are
tracking
towards
incubation,
so
just
an
update,
you
know
on
the
incubation
which
I've
been
working
on
with
our
fellow
dc
members
is
that
we
have
completed
all
the
requirements
for
incubation.
C
You
know
whatever
information
they
had
requested,
as
well
as
the
toc
had
requested
additional
data,
and
we
added
you
know
a
bunch
of
status
updates
to
the
website.
As
you
know,
and
and
so
at
this
point
in
time,
the
doc
will
now
have
an
public
review
com
period,
which
will
be
you
know
open
through
through
some
period
in
july,
and
then
hopefully
all
goes
well,
and
you
know
we
land
into
incubation
soon.