►
From YouTube: 2021-10-04 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
so
we'll
start
today
with
the
usual
sig
check
in
and
then
we'll
move
on
to
the
agenda
topics.
I
think
we
have
a
fairly
big
agenda
today.
A
A
I
don't
know
if
carlos
or
riley
or
anyone
you
want
to
add
anything
here.
Should
we
keep
going.
C
A
Perfect,
no
updates
for
logs
and
updates
for
php
no
significant
updates
for
java.
Any
updates
for
java
instrumentation.
A
Okay,
we'll
keep
going
javascript
1.0
for
trace,
sdk
was
released
last
week.
Congratulations,
metrics
work
is
gaining
some
steam
and
the
otlp
exported
penadon
experimental
metrics
package
work
is
ongoing
to
split
the
trace
part
out.
I
understood
I
noticed
that
I
was
curious
about
it.
Cool
python
started
work
on
the
error,
handling
compliance
and
they've
continued
to
work
on
the
metrics
implementation,
dot
net,
actively
working
on
implementing
metric
views
to
be
released
as
part
of
beta
1
this
week,
that's
pretty
exciting
delayed
from
last
week.
A
That's
okay,
adding
experimental
support
for
the
otlp
block
exporter
go
1.0.1
was
released
on
friday
with
a
contrib
release
to
follow
today,
we'll
release
more
1.0.0
detectors
and
propagators.
A
D
Sure,
basically,
the
users
are
trying
to
construct
that
environment
variable
in
places
where
they
don't
have
access
to
a
scripting
language
and
just
smashing
them
together,
which
ends
with
two
commas
together
and
currently
we
reject
the
value
if
there
are
any
empty
values
in
the
set
once
we
split
it
on
commas,
so
they're
going
to
look
at
other
languages,
see
what
they're
doing
and
if
other
languages
are
also
doing
the
same,
they
may
want
to
create
a
spec
issue
to
allow
for
more
lenience
in
having
empty
values.
There.
A
New
contributors
are
also
welcome,
planning
for
the
1.0,
sorry
1.1.0
beta
1
for
tracing,
so
spec
changes
between
1.0.0
and
v,
1.7.0
hotel,
cbp,
contrib,
fluid
exporter
for
logs
and
tracing
is
under
review
cool
event.
Tracing
for
windows
exporter
for
logs
is
also
under
review.
A
I
remember
working
on
this
as
an
intern,
ruby
interested
in
how
the
release
announcement
should
be
done
and
if
it
can
be
done
with
any
other
ga
releases.
Let's
talk
about
that
now.
Do
we
have
any
of
the
ruby
folks
on
the
call.
A
Yeah,
so
you're
certainly
welcome
to
write
a
blog
post
on
the
open,
telemetry,
medium
post
or
medium
blog.
The
way
that
works
is
you
write
a
draft
you
submit
the
draft
to
the
blog
and
then
anyone
who
has
access
myself
and
ted-
and
I
think
a
few
others
who
has
admin
access
to
the
blog
can
approve
it
for
final
publishing.
It'll
show
up
under
your
name
on
on
the
blog.
It's
a
good
question
about.
A
If
there's
any
other
recent
ga
releases
that
we
want
to
include
in
this,
I
think
we
already
did
one
around
the
collector
and
metrics
alita
authored
that
have
we
had
one
around.
I
think
we
had
one
also
like
catching
up
on
a
few
of
the
sdks
like
go,
but
I
don't
know
if
we've
had
any
that
mentioned
javascript.
So
perhaps
we
could
do
ruby
and
javascript
together.
A
Okay
seems
reasonable
to
me,
I
mean
so
definitely
chat
with
like
daniel
or
or
some
of
the
folks
on
the
the
javascript
sig,
and
I
think
the
timing
works
out
well,
cool,
all
right,
no
updates
for
swift
or
the
collector,
and
then
erlang
needed
someone
on
the
tc
to
review
sign
off
on
ga.
So
if
carlos
or
someone
else
on
the
tc
who
wants
to
take
point.
A
C
Yeah
me
neither,
but
we
should
certainly
bring
it
up
tomorrow.
No.
A
G
Maybe
just
pairing
with
a
an
erlang
maintainer
or
someone
to
like
walk
through
it.
A
E
A
B
The
summary
of
it
this
was
discussed
in
the
past.
I
guess
we
decided
that
grpc
is
the
right
default,
but
I
think
we
have
new
evidence
here,
which,
which
probably
means
that
we
we
can't
say
that
http
is
the
only
default
for
all
languages,
because
some
released
sdks,
which
are
declared
stable,
already
use
grpc
as
the
default,
and
that
would
be
a
breaking
change.
B
F
Speaking
from
a
company
that
has
a
php
shop
that
has
been
adopting
go
is
grpc
is
unbelievably
language
or
language.
Differentiating
a
php
is
has
a
very
difficult
jrpc
implementation.
Any
I
guess
the
right
way
to
say
is
any
language
that
google
uses
has
a
great
grpc
implementation,
because
they
have
a
vested
interest
in
that,
and
I'm
sure
that
there
are
other
companies
that
have
the
same
thing.
G
I
would
also
recommend
even
for
languages
that
have
grpc
as
their
default
to
to
make
sure
they
also
include
an
http
implementation
and,
and
vice
versa,
just
to
allow
users
a
way
to
get
around
dependency
conflicts.
We
see
this
more
consistently
with
grpc,
where
the
version
we
want
to
use,
regardless
what
version
that
is,
creates
dependency
conflict
with
something
else.
The
end
user
is
using
so
making
sure
there's
a
an
alternate
implementation
available
just
so
they
can
get
around
this
dependency.
Conflicts
is
really
important,
agreed.
A
Als
also,
if
languages
were
just
going
to
support
one,
we
could
end
up
in
a
world
where
half
our
languages
only
support,
grpc
and
half
the
other.
Half
of
them
only
do
htp
for
otp,
and
that
would
be
bad
yeah
you'd
have
components
that
I
mean
you
have
the
collector
being
the
only
thing
that
could
that
could
really
bridge
that
gap,
and
I
don't
think
that's
ideal.
F
A
Yeah,
it's
a
real
pain
yeah,
so
I
agree
I
mean
they
should
support
both
even
if
one
ends
up
being
a
lot
better
than
the
other
and
which
I
think
tgrind
is
basically
what
you're
saying
like
like
a
few
weeks
ago
on
this
call
we
said:
grpc
should
be
the
default
in
almost
all
cases,
unless
it's
untenable
and
I
think
what
you're
saying
is,
we
should
reduce
that
to
just
say
any
distribute
any
any
open,
telemetry
component
that
uses
otlp
should
support
both
http
and
grpc,
but
we
as
maintainers-
and
I
mean
we'll-
have
to
run
through
the
spec
group.
A
H
B
A
Perfect
I'll
put
that
in
bold.
While
I
do
that
carlos
do
you
want
to
start
up
the
next
topic.
A
I
Yeah,
that's
correct!
That's
good!
Sorry,
yeah!
Sorry,
what's
important,
my
connection,
yeah!
I
think
this
is
kind
of
straightforward.
He
mentioned
that
changing
the
actual
value.
Now
from
what
we
have
could
probably
be
creating
a
lot
of
pain,
but
at
least
we
should
create
we
could.
We
would
have
a
suggestion
there
as
a
good
starting
point,
and
I
would
like
to
know
about
maintainers.
Please
take
a
look
at
that.
What
he
proposes.
It's
relatively
simple,
not
very
political.
I
think
so.
You
have
an
opinion.
I
A
All
right,
let's
note
that
here
no
objections
on
the
call,
but
please
respond
to
the
issue.
If
you
have
an
opinion
of
this
okay,
I
think
this
was
already
answered,
but
otlp
in
javascript
sdk
appears,
if
you're
experimental.
I
think
dan
or
armand
just
already
mentioned
that
this
is
because
it
was
one
package
included,
metrics
and
tracing
and
you're
trying
to
split
that
apart.
I
And
yeah
and
sorry
for
being
latest
as
well.
For
this
point
but
yeah,
I
think
that
this
is
something
that
was
on
the
words
for
a
long
time,
and
I
talked
to
tigran
like
two
or
three
times
about
what
needs
to
happen
next,
so
I
will
be
working
on
this
for
the
next
weeks
to
make
it
stable.
So,
okay,
yeah
just
for
your
information,
we
have
a
developer
working
on
uses
a
prototype,
just
some
other
validation
java
json
exporter.
I
B
So
there
is
also
otlp
json
implementation
in
the
collector.
If
you
want
to
have
a
look
as
a
reference,
the
receiver
and
the
exporter,
so
it
is
implemented
in
the
collector.
It's
just
not
declared
stable,
but
it
does
work.
I
B
A
Okay,
next
up
is
ouch.
Ouch
is
doing
some
research
about
how
we
can
make
open
telemetry
even
easier
to
adopt,
and
I
think
he
wanted
to
bring
that
up
here
so
ouch.
If
you're
here.
K
Yeah
absolutely
awesome,
hey
everyone,
so
yeah.
I
think
I
think
we've
made
some
great
progress
over
the
past
couple
of
weeks,
just
looking
at
the
progress
we're
making
on
the
language,
instrumentation
agents,
as
well
as
the
collector,
achieving
the
tracing
stability
milestone.
So
I,
but
I
did
want
to
also
take
this
opportunity
to
step
back
and
if
we
can
all
really
reflect
upon,
how
can
we
really
improve
the
getting
started
experience?
K
I
think
if
we
have
any
kind
of
any
kind
of
inputs
and
feedback
about
what
are
the
concerns
being
voiced
by
the
community
on
cncs,
slack
or
other
channels
of
communication
right,
I
wanted
to
actually
just
reach
out
on
this
call,
as
well
as
maybe
get
some
opinion
from
all
of
you
about.
Is
there
a
better
way
to
collect
this
kind
of
a
feedback
from
maybe
different
sigs
or
any
other
channels
of
communication?
I
thought
this
would
be
a
great
chance
to
discuss
this
more.
F
F
It's
really
cool
because
it
gives
you
the
ability
to
have
the
end
user,
look
at
the
implementation
of
your
language
and
then
follow
through
with
where
their
missteps,
like
not
miss
steps
but
like
where
their
disconnects
are,
and
that
might
be
really
nice
to
get
for
your
like
for
your
language
to
if
you're,
just
worried
about
your
particular
language,
and
that
being
said
with,
like
a
larger
viewpoint,
I
think
that
there
might
be
like,
like
a
slight
disconnect
between
and
like
potential
end
users
of
open
telemetry
and
this
group
of
people.
F
We
all
have
such
a
very
strong
vested
interest
in
under,
like
knowing
how
the
specification
works
and
how
it
works
for
our
respective
languages,
blah
blah,
and
I
think
that
it
may
be
prudent
at
some
point
in
the
future
to
have
like
an
open
telemetry.
In
plain
english
document
that
lives
somewhere
so
that
an
end
user,
that's
really
interested
in
starting
to
use
open,
telemetry
can
say
like.
Oh,
this
is
a
span.
This
is
a
link.
This
is
a
xyz.
F
I
think
that
it
would
be
really
nice
if
we
just
had
like
a
plain
english
dictionary
somewhere,
so
that
end
users
could
really
understand
how
to
use
open
telemetry
a
little
bit
better.
I
think
that
communication
might
be
helpful
for
everybody,
but
especially
for
a
group
of
people
that
want
to
start
using
our
observability
libraries,
but,
like
you
know,
can't
have
a
little
bit
of
a
disconnect
between
what
that
looks
like
in
pr
in
theory
and
what
it
looks
like
in
practice.
K
Yeah,
absolutely,
I
agree,
I
think,
just
starting
from
the
basics
something
that
kind
of
explains
to
people
about
what
each
of
them
are
each
of
the
components
and
I
think
something
more
basic
like
you
miss
discuss,
so
I
think
that'll
be
great,
and
if
you
can
share
that
user
research
form
for
sure,
I
think
that'll
be
very
helpful
as
well.
F
Sure
I'll,
oh
yeah,
I
have
an
example
from
when
we
did
it
in
php
I'll
share
it
I'll
share
it
in
the
open,
telemetry
maintainer
slack
room.
G
Yeah,
I
can
say
one
thing
we
noticed
consistently
is
just
the
more
help
we
can
give
people
on
the
installation
phase
instructions
for
installing
open
telemetry.
G
That's
that's,
usually
the
place
where
people
get
hung
up
the
most
being
able
to
not
just
install
the
sdk,
but
also
all
of
the
instrumentation,
and
then
checking
that
it's
correct.
I
would
love.
G
I
feel
like
we're,
stretched
too
thin
to
do
it
right
now,
but
after
metrics
and
like
this
instrumentation
work
is
off
our
plate.
I
would
love
to
start
like
a
diagnostics,
sig
yeah.
G
About
in
the
past,
I
think
ted
right
yeah.
That
is
a
thing.
That's
that's
still
on
my
mind,
but
that's
for
it.
So
the
getting
started
experience
is
kind
of
two
parts
one
do
I
have
enough
instructions
to
like
just
get
everything
done
normally,
and
you
know
feel
confident
that
I've
installed
all
the
pieces.
I
need
to
install
and
I
think
we
could
do
that
now
and
then
the
other
part
is
if
I
feel
like
I've
gone
through
all
of
those
steps,
but
things
still
aren't
working.
G
What
is
the
diagnostics
routine
that
I
run
to
track
down?
Where
context
might
be
broken?
Am
I
exporting
data
correctly?
Did
it
get
to
the
collector
correctly
and
then
from
the
collector
onwards,
is
where
the
problem
is
stuff
stuff
like
that,
so
it
would
be
great
if
people
do
have
ideas
on
that
front,
definitely
write
them
down
somewhere,
because
I
think
it's
something
we
should
do
at
some
point.
K
Yeah,
I
think
that's
that's,
really
valuable
I
do
intend
to.
Maybe
I
will
tag
in
a
particular
document
to
this
particular
point.
If
anybody
feels
free
feel
free
to
add
in
any
more
inputs,
I
think
a
couple
of
them
have
already
come
up
right
now,
but
as
well
as
any
other
related
to
the
diagnostic
sig
or
even
general.
I'll.
Add
that
here
as
well,
yeah
yeah
cool.
G
Yeah,
this
came
up
from
the
the
python
sig.
I
thought
it
would
be
worthwhile
to
to
raise
it
with
the
maintainers
there.
F
G
A
question
of
you
know:
we
have
broad
rules
around
saying
that
the
api
should
not
throw
exceptions
and
muck
up
the
user's
code,
which
is
very
important,
but
we
don't
actually
have
a
lot
of
details
in
the
spec
both
around,
for
example,
what
what
are
the
the
boundaries
of
saying
we
shouldn't
throw
exceptions,
for
example,
if
they
call
a
method
that
doesn't
exist,
should
that
throw
an
exception,
the
way
it
normally
would
in
a
language
just
to
give
an
extreme
case,
and
then
the
other
thing
we
don't
really
have
a
lot
of
inspect
is
what
to
actually
do
in
the
face
of
of
bad
input.
G
We
generally
say
it
should
get.
You
know
piped
to
some
centralized.
You
know
logging
or
exception
reporting
facility,
but
there
aren't
a
lot
of
details
specifically
for
objects
for
method
calls
that
return
an
object.
What
should
be
done
so,
for
example,
if
someone
tries
to
start
a
span
and
gives
garbage
input
into
the
start
span
call,
should
we
return
a
no
op
span?
Should
we
return
a
functional
span
with
some
kind
of
default
values
that
say
the
span
was
created
an
error,
etc,
etc.
G
So
I
just
wanted
to
highlight:
that's
it's
a
place
where
we
don't
actually
have
a
lot
of
stuff
in
the
spec,
but
probably
different
working
groups
are
actually
doing
something
here,
and
so
it
would
just
be
helpful
to
know
what
what
everyone
is
currently
doing
in
this
regard.
G
Yes,
yeah
totally
what
what
what
stuff
should
the
api
layer
be
handling,
for
example,
and
what
stuff
should
the
sdk
layer
be
handling?
There's
also
some
like
edge
cases.
G
We
discovered
around
like,
for
example,
providers
right
like
there's,
there's
some
poor
small
portion
of
the
api
package
that
doesn't
call
down
to
the
sdk,
because
it's
its
own
self-contained
mechanism
for
registering
the
sdk
and
for
the
the
rest
of
the
stuff
you
can
say
well,
the
sdk
should
should
catch
what
exceptions
is
going
to
catch
and
pipe
them
to
some
facility,
but
for
that
chunk
of
the
api,
where
it
doesn't
call
into
the
sdk.
What
should
that
thing
do.
L
L
L
L
That
could
be
different
like
we
could
decide
that
that
it's
okay,
that
it
throws
exceptions
in
that
case
or
we
could
decide
that
it's
okay,
that
it
does
log
to
some
something.
So
we
just.
I
think
it's
just
important
to
keep
those
two
cases
in
mind,
because
the
api
is
going
to
be
embedded
in
libraries
and
the
user
may
not
have
any
interest
in
actually
using
open
telemetry
at
all,
but
they
may
be
using
that
library
that
has
open,
telemetry
api
usages
inside
it
and
we
cannot
break
their.
M
G
I
think
another
way
of
phrasing
it
is
the
the
no
op
sdk
may
swallow
more
errors
than
the
production
sdk.
I
think
it's
what
john
said
like
there
might
actually
be
slightly
different
rules,
for
you
know
what
like
the
no
op
sdk,
should
swallow.
Basically
everything
because,
like
john
was
saying
like
you,
don't
want
instrumentation,
you
have
no
control
over
blowing
your
stuff
up
when
you're
not
using
open
telemetry,
but
maybe
there
are
some
extreme
cases.
There
are
some
cases
where
you
would
say.
E
Yeah,
I
really
like
that
on
a
bad
input
to
starting
a
span
returning
a
no-op
span,
we
had
been
just
using
an
atom.
That
means
nothing
happened
and
that
and
then
we
have
to
accept
that
everywhere,
a
spans
accepted
which
has
been
fine
but
the
yeah.
E
I
didn't
even
think
about
the
no
op
thing
which
makes
me
think
there
really
should
be
some
good
more
going
through
the
the
spec
again
and
picking
out
these
points
where
something
is
returned
and
saying
what
do
we
do
when
the
input
is
bad
and
having
that
across
all
the
implementations,
but
also
like
in
the
main
spec
there's
stuff
about
performance
and
error
handling
in
general?
I
started
on
and
this
might
be
good
for
each
language.
E
I
started
on
in
the
earling
repo
principles
document
that
will
have
stuff
like
never
crash,
especially
because
it
goes
against
much
of
the
coding
style
for
earlying
people
that
we
have
to
accept
every
input
and
do
nothing
if
something
comes
in
when
we're
used
to
just
crashing
and
no
longer
can
crash,
because
the
point
is
to
never
have
this
affect
the
user
code.
So
a
principles
document
might
be
useful
for
each
repo,
so
users
coming
in
to
work
developers
coming
in
to
work
on
it
where
things
in
the
project
are
coming
from.
G
G
So
this
is
just
an
area
where
maybe
the
first
step
would
just
be
to
to
understand
what
everybody
is
currently
doing
in
these
situations
and
maybe
see
if
we
could
normalize
some
of
that
and
yeah
write
these
guidelines
down,
because
this
is
an
area
where
it's
a
little
confusing,
and
I
think
our
explanation-
it's
it's
helpful
for
us
to
actually
explain
why
we're
doing
it,
because
it
is
a
little
odd
in
some
cases.
A
Okay,
ted,
I
think
probably
the
best
form
for
this
going
forward
is
going
to
be
the
spec
sig.
I'm
guessing.
G
Yeah
yeah
I'll
bring
it
up,
bring
it
up
there
again,
but
yeah
maybe
start
a
doc
for
for
six
to
just
write
down
what
their
current
behavior
is.
Yep.