►
From YouTube: 2022-01-12 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
B
C
B
Maybe
two
things:
there's
there's
just
getting
the
otep
approved,
which
I
feel
like
should
have
been
approved
by
now
and
michael
brought
that
up
in
the
spec
meeting
this
morning
to
request
the
tc
review
this
thing
and
approve
it.
This
is
kind
of
overdue.
At
this
point-
and
I
saw
there
was
a
spec
pr
for
defining
the
http
structure
that
was
proposed
a
while
back,
but
looks
like
it
doesn't
have
any
any
approvals.
Yet.
C
That's
true,
so
that's
something
that
I
would
also
like
to
bring
here.
So
I
currently,
I
do
have
like
a
three
pull
requests
to
open
telemetry
to
like
a
two
different
parts
of
open
telemetry
and
the
kind
of
you
know.
Overall
participation
is
kind
of
low,
so
I
just
wanted
to
understand
what
what
we
can
do
in
terms
of
improve
the
overall
experience
and
how
it
actually
works.
B
Yeah
yeah
this
is
this
is
honestly
a
real
struggle.
We
have
with
the
the
spec
and
oteps
right
now.
B
It
feels
like
the
technical
committee
crew
is,
is
spread
pretty
thin
and
so
they're
kind
of
being
a
bit
of
a
blocker
for
getting
these
things
approved,
and
sometimes
it
can
just
be
hard
to
get
feedback
on
spec
issues,
because
people
just
might
not
feel
like
they
have
an
opinion
or
that
they
are
qualified
to
to
have
an
opinion,
so
they
can
be
a
little
slow
to
to
speak
up.
So
I
don't.
B
I
don't
have
a
great
solution
other
than
bothering
specific
people
and
saying
can
you
please,
you
know,
approve
this
or
tell
me
why
you?
You
won't
approve
this,
but
now
that
I'm
back,
I
will
try
to
help
shut
some
of
that
through,
as
well
as
giving
my
my
approvals
and
comments,
these
things
but
yeah.
It's
unfortunate.
B
Of
of
this
spec
process-
and
I
would
love
it
if
we
could
expand
the
number
of
approvers
for
these
things,
which
is
something
I've
also
been
trying
to
do.
B
Let
me
put
this
conversation
up.
I
had
been
asking
tigran
to
create
a
spec
approvers
group
for
semantic
conventions.
B
B
B
B
So
let
me
have
a
look
and
see
if
this
group
has
been
added
to
anything,
yet
it
doesn't
look
like
they
have,
and
I
think
this
is
also
gated
on
some
work
I
started
and
then,
like
totally
dropped
before
I
went
on
break
around
trying
to
reorganize
the
spec
to
get
all
of
the
semantic
conventions
kind
of
like
they're
sort
of
like
scattered
throughout
the
spec
right
now,
and
trying
to
get
them
grouped
into
their
own
section
in
the
spec.
B
B
To
do
that,
it
would
just
look
a
little
ugly
right
now
so
I'll
take
it
on
my
plate
to
to
reopen
that
pr
and
and
try
to
get
that
actually
completed
this
week
and
I'll
bother
the
technical
committee
to
get
the
people
listed
in
this
current
working
group
team
to
basically
get
this
team
added
as
spec
approvers
for
the
semantic
conventions.
B
We
have
some
people
who
signed
up
for
like
messaging
conventions
and
some
people
for
http,
but
I
just
felt
like
that
would
be
a
little
too
micro
managey
and
it
would
be
great
if,
if
we
could
all
just
kind
of
like
pay
attention
to
all
of
these
convention,
prs
right
now
and
kind
of
help
each
other
out
and
that
should
hopefully
make
this
work
move
faster,
because
it'll
drop
the
number
of
outside
approvals
that
we
need
to
actually
get
the
stuff
pushed
through.
B
I
still
want
to
see
the
tc
review
this
stuff,
but
I
feel
like
what
we
are
saying
is.
We
are
actually
the
group
that
is
bringing
the
expertise
to
the
stuff,
and
so,
if
we're
fine
with
our
work-
and
there
are
no
outside
objections,
then
we
should
just
move
forward
with
it
for
the
time
being.
C
Yeah,
that
sounds
great.
Maybe
maybe
it
can
help
us,
you
know
to
to
move
faster
because
for
the
last
several
months,
my
impression
was
that
we
just
we
are
we're
discussing
some
items
with
just
making
proposals,
but
there
is
no
ability
for
us
to
actually
finalize
them.
B
Yes,
right
now,
we
would
need
people
who
are
on
the
spec
approvers
list
for
those
either
the
overall
approvers
and
then
I
think,
all
of
the
work
we're
currently
doing
for
the
most
part
is
falling
into
like
tracing
conventions.
B
Code
owner's
file,
there
is
basically
the
technical
committee
just
so
people
can
see
this.
B
B
Those
are
the
people
who
we
want
to
be
poking
for
our
spec
approvals.
If
we're
not
getting
any
attention,
you
can
look
at
who
who's
currently
on
those
teams
and
bother
them
on
slack.
B
Yeah-
and
I
will
try
to
to
help
with
that-
it
would
be
great
if
this
was
was
smoother.
It
is
something
we're
trying
to
work
on
as
a
group,
but
we're
just
the
reality
is
with
like
getting
the
collector
core
work
in
the
collector
finalize
getting
metrics
pushed
out
and
and
logs
there's
just
just
actually
quite
a
bit
of
work
that
is
going
into
the
spec.
That's
like
asking
people's
attention
that
that
needs
real
review
and
not
just
you
know,
a
rubber
stamp,
and
so
people
are
genuinely
spread
thin
right
now.
B
So
so
I
do
apologize
for
the
experience,
but
that's
that
is
why-
and
my
hope
is,
that
when
kind
of
metrics
moves
out
of
the
way
and
hopefully
logs
that
that
it
will
get
a
bit
better
but
yeah,
this
is
a
consistent,
consistent
issue
that
we
have
right
now.
C
All
right
so
yeah
one
one
topic
that
I
also
wanted
to
discuss
with
regards
to
the
like
a
prior
previous
work
that
I
was
doing
related
to
retries
and
redirects
in
the
spawn
structure
for
those.
C
C
We
also
have
implementation
or
actually
prototype
done
by
ludmilla
in
december,
actually
in
november,
for
java,
but
from
this
perspective,
java.net
looks
similar
so
internally,
here
in
microsoft,
we
were
also
it's
like
thinking
that
it
might
be
beneficial
to
have
implementations
of
this
proposal
for
python
and
javascript
and
car.
Responding
is
the
case,
and
I
wanted
to
confirm
that
it
actually
will
be
enough
for
us
to
say
that
we
are
actually
cover
all
the
like
cases
that
we
wanted
to
cover.
So
that's
something
just
wanted
to
agree
from
the
from
like.
B
Yes,
that's
that's
totally
totally
sufficient.
Having
like
three
languages
is
sufficient,
I
would
say
for
for
getting
this
discovered
four
is
even
better.
B
I'm
not
super
duper
worried
for
most
of
honestly
for
like
this,
this
kind
of
work
that
we're
doing,
because
it's
about
modeling
kind
of
like
protocols
and
things
like
that,
and
there
isn't
like
a
huge
amount
of
variation
between
languages
on
this
stuff
compared
to
things
like
the
tracing,
spec
and
stuff,
where
actually
the
language
runtimes
work
quite
differently
from
each
other.
So
when
you
say
you
know
context,
propagations
can
work
this
way.
You
really
have
to
try
that
out
in
a
bunch
of
languages
to
make
sure
it
is
feasible.
B
So
three
languages
for
for
this
work
is
totally
feasible.
I
actually
kind
of
suspect
where
we
will
run
into
gotchas,
like
subtle.
Gotchas
with
this
stuff
is
not
actually
between
languages,
but
between
instrumentation
packages.
B
You
know
what
I
mean,
because,
like
probably
where
we
will
get
frustrated
is
the
way
in
which
all
of
these
various
instrumentation
packages
expose
hooks
and
allow
you
to
hook
into
them.
You
know
and
that's
a
case
where
it's
it
will
probably
be
more
frustrating
in
the
more
non-dynamic
languages
right
with
a
language
like
java,
there's
always
a
way
to
kind
of
go
around.
B
B
So
I
suspect,
honestly,
that's
where
we're
gonna
see
see
difficulty
we'll
be
in
like
languages
where
there
isn't
a
good
monkey
patching
solution
and
we're
kind
of
beholden
to
the
wide
range
of
approaches
to
implementing
these.
These
things.
C
Yeah,
that
sounds
reasonable,
but,
like
we
also
mentioned
that
we
need
to
have
implementation
at
least
for
three
languages,
but
is
there
any
like
a
definition
for
this
exact
three
languages.
B
No,
no
we're
just
in
general,
with
with
oteps
and
spec
changes,
trying
to
make
sure
that
things
have
been
prototyped.
You
know
at
least
three
times.
I
would
say
we
don't.
We
don't
currently
have
a
hard
rule
for
this,
because
some
changes
are
are
bigger
than
others,
but,
generally
speaking,
like
three,
three
prototypes
is
sufficient.
B
But
I
guess
the
thing
I'm
I'm
commenting
on
is
like
generally,
when
we've
been
thinking
about
this
we've
been
thinking
about
it
in
terms
of
building
core
features
like
the
tracing
system
and
the
metric
system,
and
when
we
think
about
trying
to
put
something
into
the
spec
for
those
things,
it's
the
differences
in
languages
that
come
up
when
it
comes
to
like
what
would
a
good
api
look
like
because
it's
kind
of
like
api
design
and
actually
what
we're
doing
here
in
the
instrumentation
group,
I'm
just
noting,
is
like
actually
a
little
bit
different
and
I'm.
B
I
don't
know
that
we're
we're
going
to
run
into
problems
where
it's
like.
Oh
it's.
We
can't
do
this
in
javascript,
because
something
about
the
javascript
language
is
preventing
us
from
modeling
in
http
retries
in
an
http
request.
I
just
I
just
predict.
We
won't
have
any
problems
as
far
as
like
the
language
and
language
api
designs
are
concerned,
actually,
where
we'll
probably
run
into
problems
is
like
we're
trying
to
model
retries
in
go,
and
this,
like
http
library,
doesn't
actually
like.
B
Let
me
hook
in
in
a
way
where
I
can
get
at
those
things
and
put
them
on
the
span
that
I
want
to
put
them
on,
or
it's
actually
really
difficult.
I
have
to
retain
references
in
a
way.
That's
this
tricky
or
something.
So
I
don't
I'm
not
I'm
just
predicting
that
actually,
where
we
might
run
into
problems,
might
be
somewhere
different
than
where
we've
been
running
into
them
in
the
past.
So
I
think
that's
maybe
a
thing
to
be
aware
of.
B
I
don't
know
that
we
need
to
slow
down
what
we're
doing,
but
maybe
just
I'm
trying
to
think
of
what
languages
besides
go
where
this
is
like
the
nastiest.
Maybe
it's
just
go.
Maybe
it's
just
goes
problem.
C
Should
be
like
a
go
language
be
like
required
in
this
list,
so
currently
what
I'm?
What
I'm?
Actually,
what
is
possible
for
me
to
to
push
is
to,
in
addition
to
the
net
implementation,
is
to
have
also
python
and
javascript
yeah.
Unfortunately,
there
is
no
go
currently,
but
just
for
this
particular
change
that
I'm
proposing
for
retries
and
redirects
yeah.
I
just
wanted
to
confirm
upfront
that
these
three
implementations
will
be
just
sufficient.
I.
B
I
personally
think
three
is
fine
for
now,
let's
just
go
with
three
it
I
would.
I
think
I
maybe
want
to
flag
that
if
it
is
possible
to
do
some
of
the
prototyping
and
go
that
might
be
good
for
us,
because
that's
an
example
of
a
language
where
we
can't
use
any
monkey
patching,
but
maybe
the
other
way
of
thinking
about
it
is
just
noting
if
we're
if
this
is
like
forcing
us
to
do
monkey
patching
or
write
things
in
an
awkward
fashion
in
other
languages.
B
But
if
I
I
don't
want
to
block
work
by
saying
it
has
to
be
done
at
go
if
you've
got
something
in
javascript
and
python,
that's
great
just
we
just
want
to
make
sure
we're
we're
looking
at
it
in
a
language
that
doesn't
have
the
kind
of
dynamical
approach
that
we
take
the
instrumentation
in
java
and
net.
I
guess
that's
the
thing
and
we
don't
tend
to
do
that
stuff
as
much
in
python
and
js.
So
so
I
think
those
are
fine
languages
to
to
check.
B
Group
we
should
make
a
note
to
like
try
this
stuff
out
and
go
with
those
it
might
be
really
annoying,
but
that
might
just
be
go's
problem
that
you
just
can't,
unfortunately,
cannot
get
as
much
data
out
of
some
of
those
packages.
B
How
hard
is
it
to
like
hold
on
to
the
kind
of
context
that
you
need
to
do
this?
That's
like
a
thing,
I'm
curious
about
that
language,
because
that's
javascript's
place
where
we
we
struggle
with
that
stuff,
because
there's
no
one,
there's
no
one
great
answer
for
context
propagation
in
that
language.
So,
if
you
can,
if
you
can
make
it
work
there,
that's
good.
It's
also
like
the
browser
is
a
place
where
the
stuff
is
kind
of
baked
in
in
a
funny
way.
B
C
C
But
yeah
in
this
regard,
another
question
that
probably
I
had
to
underwrap
was
about
aws
sdk.
So
I
got
a
comment
on
the
pull
request.
That
must.
It
is
a
strong
word
here,
because
it's
not
really
possible
to
to
create
spam
per
physical
request
and
aws
is
the
game.
So
I
reckon
maybe
maybe
you
can
elaborate
more
about
this.
Just
like
what
is
the
blocker
there.
A
C
A
C
Yeah,
that's
that's.
What
would
be
the
context
propagation
right
so
like
you
cannot?
You
cannot
store
it
within
the
the
request,
since
it's
already
kind
of
yeah
exactly
considered
immutable,
but
will
be
possible
to
have
some
data
structure
like
ambient
context
context
as
a
part
of
the
like
a
flowing
with
with
the
with
the
with
this
request
object.
So
you
can
have
you
can
use
this
as
a
storage.
B
B
B
Like
here's
our
problem,
it's
not
just
aws,
though
it's
like
actually
any
situation
where
you
have
some
kind
of
like
signed
request
that
involve
hashing
all
the
headers
or
something
like
that,
and
you
can't
you
cannot
change
any
of
them
on
the
retries,
because
that
I
mean
like
oauth
and
other
things,
like
kind
of
come
to
mind.
It's
like
just
random
things
that
will
pop
up
in
that
situation.
B
C
That's
a
really
good
point
so
like
in
this
regards.
It
would
be
enough
for
me
just
to
change
moss
to
shoot,
saying
that,
like
we
want
to
like
make
our
best
efforts
and
it's
not
really
possible,
then
well,
basically,
it's
not
supported.
C
That's
a
good
idea,
that's
a
good!
Let
me
glorify
this.
B
Yeah,
you
might
want
to
include
this
example
in
the
spec
language
as
well.
So
people
understand
why
it's
a
should.
B
B
B
B
A
look
at
instrumentation
apis
and
languages
that
are
not
java.
B
So
that's
like
a
shout
out.
I
don't
know
if
there's
anyone
at
microsoft
would
be
willing
to
to
have
a
look
at
the
what's
already
been
going
on
in
javascript
and
and
also
maybe
python
around
instrumentation
apis.
Just
because
you
know
it
sounds
like
stuff
is
getting
very,
very
stable
and
finalized
in
java.
You
know-
and
I
really
want
to
support
them,
shipping
it,
but
I
also
would
love
this
stuff
to
get
into
the
spec
and
like
that.
B
So
the
fact
that
we're
not
we're
not
prototyping
this
in
other
languages,
I
think,
is-
is
kind
of
holding
that
effort
back
a
little
bit
at
this
point.
B
So
I
don't
know
if
there's
people
at
microsoft,
who
might
might
have
cycles
to
be
able
to
poke
it
poke
at
that
issue.
C
Well,
I
I
I
can
mention
this
one
when
I
will
be
interacting
this
week
with
with
these
people.
Maybe
we
can
can
you
know,
ask
them
to
participate
next
time.
So
awesome.
B
Yeah-
and
I
think
you
know
the
core
maintainers
of
python
and
js,
I
think-
are
happy
to
like
help
and
kind
of
review
that
stuff,
but
again,
like
I
think,
they're
a
little
too
busy
to
to
have
cycles
to
like
actually
do
the
prototyping
work.
But
but
I
do
think
they'll
review
efforts
in
a.
A
C
Well,
yeah,
I
do
have
one
one
request,
maybe
so,
last
time
with
james
from
atlassian,
we
were
discussing
that
we
have
several
items
currently
open
for
http
spec
to
actually
to
make
it
finalized.
So
redrys
and
redirects
is
one
of
them,
but
we
do
have
several.
We
have
two
more
and
the
request
here
will
be
to
maybe,
if
other
people
can
help
covering
these
additional
items,
it
will
be
great.
So
we
can
move.
B
Faster
free,
do
you
do
you
have
a?
Let
me
see
if
we
have
a
list
of
these.
Hopefully
these
are
tagged
properly,
so
we
can
actually
have
a
look
at
them.
B
Burp,
burp
nope.
Do
you
mind
if
you
have
them
handy?
Do
you
mind
pasting,
like
the
list
into
the
meeting,
notes,
yep,
sure
sure.
B
Okay,
great
I'll
I'll,
take
a
look
at
those
this
week
and
see
if
I
can
help
approve
them
myself
and
see
if
I
can
help
get
other
eyes
on
them,
because
yeah
the
time.
B
Well,
good,
seeing
y'all
excited
to
be
back.