►
From YouTube: 2020-10-13 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).
B
Yeah
usually,
but
this
year
is
kind
of
different
because
of
the
virus.
Oh.
A
B
A
Cool
well
yeah,
welcome
aboard.
I
know
you've
seen
some
of
the
folks
from
amazon,
making
some
pull
requests
around
readme's
and
and
obviously
you
guys
are
very
active
around
the
collect
the
hotel
system
in
general
yeah.
I'm
america
work
over
at
david
oak,
which
is
a
vendor.
B
A
It's
okay,
I
guess!
What's
up
robert
and
then
robert's
over
at
shopify.
A
A
A
Decent
matt,
tyler
benson,
says
hello.
By
the
way,
I
think
you
guys
briefly
overlapped
at
a
previous
job.
Yeah
yeah
tell
him
I
say
hi
as
well.
I
will
I
was
like
oh
yeah
there's
this
guy
I've
been
talking
to
him
a
lot
and
hotel.
I
think
he's
working.
Oh
yeah
yeah,
that's
my
guy,
so
he
thinks
highly
of
you.
So
nice
yeah.
A
Interesting
he
was
living
in
oh
I'm
liking
on
the
name
somewhere
in
japan.
Yes,
I
panned
for
a
while.
I'm
super
unassuming
then
just
would
occasionally
be
like
hey
anyway.
There's
a
touchdown
coming.
I
gotta
go.
A
D
Yeah,
so
it's
five
after
I
feel
like
we
usually
start
at
around
this
time,
and
this
is
looking
like
most
people,
so
I'll
go
ahead
and
keep
doing
the
usual
unless
somebody
tells
me
to
stop-
and
that
is
I'll-
just
kind
of
run
through
the
the
spec
sig.
Try
to
summarize
that
in
a
reasonable
amount
of
time
and
then
we'll
kind
of
move
on
talk
about
talk
about
issues
on
the
ruby
repo
and
our
kind
of
upcoming,
milestone.
D
D
It
so
I
guess
the
biggest
update
kind
of
from
spec
sig
and
also
the
maintainers
sig,
is
that
we're
getting
at
least
close
on
the
spec
side
for
ga,
so
so
yeah.
I
think
people
are
just
getting
like
more
serious
about
that
in
general.
There
are
a
few
issues
to
to
resolve
before
the
spec
is
like
formally
frozen,
but
I
think,
like
the
the
outcome
of
that,
will
be
there's
already
this
compatibility
matrix
on
the
specification.
D
It's
a
matrix
of
some
kind
compliance
matrix,
but
I
think
ultimately,
like
we've
been
kind
of
keeping.
D
I
think
francis
has
been
keeping
us
updated
over
here.
Thank
you,
francis,
but
this
is
generally
like
the
things
we're
supposed
to
have
and
the
things
that
we
actually
have,
but
they're
kind
of
spread.
You
know
across
a
few
different
areas.
I
think
this
is
going
to
become
a
little
bit
more
focused
and
we
might
get
some
sort
of
list
like
this.
For,
for
the
actual
ga
and.
D
I
know
the
that
open,
telemetry
itself
is
kind
of
the
the
I
don't
know
the
the
bodies
of
people
who
do
this
stuff
are
getting
ready
to
make
like
a
a
blog
post,
announcing
ga
at
some
point-
and
I
saw
I
don't
know-
I
think,
there's
a
date
of.
D
So
they're
gearing
up
for
a
blog
post
is
it?
Is
it
tldr
and
we'll
probably
have
like
a
little
bit
more
definition
around
what
that
means
for
us.
E
And
for
the
other
is
the:
is
the
announcement
just
going
to
be
around
the
spec,
or
is
it
also
going
to
be
around
like
ga
status,
for
a
number
of
implementations.
D
The
announcement's
going
to
be
around
the
spec,
I
think,
with
the
note
that
implementations
or
that
yeah,
that
the
implementations
will
follow
at
some
later
date.
I
know
they
were
in
the
maintainers
meeting
talking
about
like
it
would
be
great
to
have
like
estimates
of
when
you
think
stuff
will
be
done.
I
think
this
is
yeah.
It
would
be
great,
but
like
probably
not
possible,
for
anybody
to
actually
do,
especially
on
a
project
such
as
this,
but
but
yeah.
D
D
Yeah,
I
think
I
don't
know
all
that
is,
it
is
what
it
is
I
mean
stuff
is
done
when
the
checklist
has
been
checked
and
stuff
is
released
into
the
wild,
so
it's
at
least
nice
to
know
what
we're
working
towards.
E
E
D
This
exact
issue
came
up
in
the
maintainers
meeting
where,
like
things
have
changed,
people
have
filled
this
in
and
it
looks
like
it's
done,
but
now
nobody
knows,
I
think,
that's
still
the
state
and
there
was
kind
of
like
a
there's
at
least
an
ask
that
when
something
does
change
that
the
spec
compliance
matrix
just
gets
reset
on
that
thing,
which
would
be
really
nice
because
it's
hard
there's
just
like
so
much
changing
it's
hard
to
actually
keep
up
with
it
all
and
know
like
what
is
even
on
the
list
and
what
has
already
been
checked
so
enjoying.
E
The
churn
in
the
go
implementation.
D
Yes,
yeah
and
I
think
that
that's
kind
of
the
thing
it's
like
we're,
we're
really
pretty
familiar
with.
What's
going
on
in
ruby,
because
we've
been
paying
attention
everything,
but
for
things
where
you
are
kind
of
like
half
paying
attention-
or
you
know
not
fully
paying
attention
to
like
can
be
a
bit
of
a
nightmare.
D
So
I
think
I
think
people
are
bringing
this
up
like.
I
think,
there's
not
like
an
answer
today,
but
hopefully
hopefully,
when
we
get
this
like
formal
checklist
for
4ga,
we
can
find
some
way
to
to
resolve
this.
I
guess
it
and
that
might
just
be
like
re-going
through
the
checklist
and
yeah
it's
it's
just
a
little
painful
looks
you
kind
of
have
to
like,
as
you
go
through
the
checklist
go
back
through
the
spec
and
be
like.
Has
this
really
changed
and
investigate
the
implementation?
So
we'll
figure
that
out.
D
So
yeah
there
there's
always
this
kind
of
triage
session
to
figure
out
what
things
should
or
should
not
be
be
handled.
D
D
None
of
them
are
really
sticking
out
as
things
that
were
blockers.
I
think
a
lot
of
them
were
just
kind
of
slated
for
could
be
allowed
for
ga
or
maybe
after
ga.
D
Probably
one
of
the
biggest
things
was
talking
about
this
issue
of
the
fact
that
key
value
pairs
on
spans
are
called
attributes
and
they
have
slightly
different
semantics
than
the
things
on
metrics,
which
are
called
labels.
D
And
I
think
we
touched
on
this
last
week
and.
D
It
seems,
like
you
know,
there's
there's
a
reason
for
this.
There's
a
reason
for
this,
mainly
in
metrics
labels.
The
values
are
always
going
to
be
treated
as
strings
by
the
back
ends.
So
it's
way
easier.
If
the
apis
handle
them
as
strings
and
in
you
know,
in
typed
languages
they
usually
have
like
a
type
for
like
attributes.
D
It's
usually
kind
of
like
a
polymorphic
type
that
you
know
allows
the
type
system
to
ensure
that
the
thing
that
you
provided
is
is
the
right
thing
for
you
so
trying
to
reuse
that
between
metrics
and
spans
is
a
bit
challenging,
but
I
think
there
is
a
desire,
because
people,
it's
confusing,
that's
kind
of
the
other
side
of
the
argument.
It's
confusing
to
have
these
different
things
for
different
types.
D
So
there
are
talks
about
trying
to
unify
this,
and
there
are
really
ambitious
talks
about
trying
to
unify
this
before
ga
so
yeah.
I
wish
everybody
luck
in
this
conversation.
If
you
have
opinions,
though,
and
I
feel
like
francis-
you
had
some
really
good
ones
last
week
when
we
discussed
this
and
helped
me
understand
it
a
lot
better.
D
So
if
you
have
the
energy
or
time
to
comment
on
that
feel
free
to,
if
you
have
the
desire.
D
The
one
thing
that
I
did
kind
of
like
is
that
people
were
floating
the
name
tags
as
like
a
new
name
for
everything,
and
I
I
do
kind
of
like
that
name.
It's
it's
concise.
It's
a
lot
easier
to
use
than.
D
On
the
note
of
that
compliance
matrix,
there
is
just
just
this
question:
do
we
want
to
track
api
and
sdk
concerns
separately
or
have
them
together
on
the
same
table?.
D
B
D
C
D
E
But
that
should
make
things
interesting
in
the
c
plus
implementation.
F
B
F
D
D
Yes,
there
was
so
arguably
we
could
go
the
other
way
right
and
have
more
conduct
have
more
context.
Yeah
yeah,
I
mean
I
kind
of
do
like
having
this
as
as
context,
and
I
honestly,
I
think,
we've
kind
of
talked
about
this
before
I
think
the.
D
I
think
the
trend
will
be
to
consolidate
your
contexts
more
over
time
to
where
you
know
for
the
cons
where
yeah
you
probably
get
rid
of
span
and
by
by
doing
that,
we
would
get
rid
of
spam
context
and
you
would
just
be
managing
contexts.
E
F
Yeah
the
same
underlying
concept
and
what
it
means
to
be
a
contractor
what
it
means
to
be
a
spirit.
What
does
it
need
to
be
a
choice
as
long
as
the
underlying
concept
is
consistent
and
you
have
concrete
versions
of
it?
There's
a
compound
names
of
it.
I'm
happy,
I
think
that
will
at
least
cement
the
idea
in
your
hair
and
then,
when
you
see
it
appear,
oh,
they
just
check
the
content.
Oh,
this
is
just
a
span,
knock
it
off.
F
D
No,
I
think
that
makes
sense,
and
I
don't
know
sometimes
these
conversations
can
head
in
weird
directions,
but
I
mean
ultimately,
I
think
we
are
going
to
get
to
this
point
after
we
ga,
where
we're
going
to
have
to
educate
people
on
how
to
use
this,
and
I
think
it
probably
does
become
a
little
bit
more
important
that
we
have
have
ways
to
communicate
this
to
to
users
and
potential
users.
D
D
John
was
just
looking
for
an
opinion
I
gave
one,
and
that
is
that
you
know
the
the
baggage.
Propagator
should
should
be
part
of
the
api
package.
In
my
mind,
it
should
probably
not
be
turned
on
by
default,
but
you
should
be
able
to
turn
it
on
if
you
would
like
to
which
I
think
is
the
same
way.
Trace
contacts
is
working,
and
I
know
there's
a
lot
of
discussions
on
that.
I
honestly
forget
where
it
landed,
but
I
think
that's
where
it
landed
is
that
these
are
part
of
the
api
package.
D
B
D
Yeah,
I
kind
of
covered
this
stuff.
First,
I
think
in
regards
to
the
ga.
The
one
thing
I
didn't
exactly
talk
about
was
like
they
were
thinking
about,
having
like
milestones
for
the
implementations
that
kind
of
came
about
they
weren't
talking
about
like.
D
Having
having
rc's
and
they're
like
oh
yeah,
you
know
this
stuff
doesn't
need
to
go
into
the
first
rc.
It
can
go
into
the
second
rc
and
they
were
talking
about
multiple
rc's
and
that
I
don't
know
that
at
least
inspired
me
to
mention
that
an
rc
should
be
a
code.
D
Complete
piece
of
software
and
subsequent
rcs
should
only
be
bug
fixes
on
that
code,
complete
thing
until
no
more
bugs
are
found,
and
ideally
we
would
use
rc
to
mean
that,
and
if
we
want
to
have
some
milestoney
thing,
it
should
be
something
slightly
different.
We
should
probably
use
some
different
words
just
so
that
we're,
I
don't
know
not
to
like
get
too
much
into
the
details,
but
I
think
ultimately,
the
labels
on
your
software
should
probably
indicate
like
what
the
software
actually
is
just
for
for
clarity
for
potential
users.
D
D
D
D
The
full
discussion,
but
it
was
kind
of
it,
was
around
honeycomb
and
they
have
some
kind
of
functionality
where
they're
able
to
I
don't
know
it
seems
like
it's
almost
like
a
thread:
local
that
gets
a
bunch
of
attributes
that
apply
to
like
the
whole
trace.
So
it's
really
a
slightly
different
thing.
D
A
different
approach
than
open
telemetry
generally
has
taken
with
like
contexts
where,
like
it's
really
easy
to
propagate
stuff
downwards
in
a
trace,
it's
pretty
much
impossible
to
go
the
opposite
direction
and
I
think
that's
kind
of
by
design,
but
I
think
honeycomb
kind
of
has
this
thing
where
you
add
a
bunch
of
attributes
to
a
trace
as
it's
happening
and
then
maybe
those
end
up
on
the
trays
to
end
up
somehow
getting
to
the
tracing
back
end.
D
There's
there
always
ends
up
being
a
lot
of
edge
cases
around
that
which
I
think
is
why
this
is
a
harder
thing
to
do
in
open
telemetry.
It's
like
you
know
in
ruby.
We
could
probably
get
away
with
saying
you
could
stick
all
these
things
on
your
root
span.
But
this
is
not
always
true
and
it's
definitely
not
always.
True
in
all
languages,
sometimes
like
the
root
is
long
gone
by
the
time
you
reach
like
the
end
of
a
trace.
D
So
that
was
some
of
kind
of
the
context
around
this,
but
I
think
it
was
kind
of
getting
into
the
details
of
a
span
processor
like.
Are
these
run
in
orders
or
any
kind
of
order
guarantees
so
that,
if
you
actually
did
want
to
kind
of
add
some
attributes
that
you
could
do
this?
In
maybe
the
first
processors
that
other
processors
could
get
access
to.
C
B
D
D
That's
my
two
cents.
What
you
try
to
do
in
those
is
is
up
to
you
and
any
order
dependent
things
that
you
introduce.
You
do
so
at
your
own
peril,
but
establishing
order
and
saying
that
you
know
these
run
in
consecutive
or
reverse
consecutive.
I
think
that
is
fine.
A
And
just
to
be
clear,
there's
no!
It's
not
it's!
Non-Deterministic
right!
Now,
I'm
confused
on
the
current
behavior
or
or
is
it
just
not
specified.
A
Yeah,
I
think,
there's
a
ton
of
use
cases
you
can
have
where
you
just
want
to
make
sure
you
do
something
first
and
then
you
you,
can
you
don't
have
to
worry
about
it
in
your
downstream
processors?
I
think
the
the
collector's
processors
are
having
ordering,
so
it
would
make
sense.
E
E
Some
of
those
processors
are
being
removed
and
their
functionality
is
being
pushed
into
the
places
they
belong
so
things
that
should
always
be
right
before
the
exporter
are
being
pushed
into
the
exporter.
So
this
is
some
of
the
queuing
stuff
and
then
most
likely
things
that
should
be
right
after
the
receiver,
so
right
at
the
start
of
a
pipeline
will
probably
be
moved
into
the
receiver
just
so
people
don't
have
to
think
so
carefully
about
like.
Where
does
this
stuff
belong?
E
We
had
it
wrong
for
a
long
time
at
shopify,
and
I
went
to
give
a
talk
on
this
like
I
was
co-presenting
a
talk
and
gave
my
presenter
a
copy
of
the
slides,
and
he
said:
are
you
really
doing
it
that
way?
That's
the
wrong
way.
A
Is
there
that's
actually
extremely
relevant
to
something
I'm
working
on
like
earlier
today?
Is
there
an
issue
you
could
link
me
to
because
I'm
like
yeah,
it's
yeah.
I
don't
want
to
hijack
speeding,
but
that's
very
relevant
to
my
interests.
E
Yeah,
I
don't
know
if
there's
an
issue,
I
know
that
the
request
queuing
processor
has
been
deprecated
and
sorry,
I
forget,
what's
called
retry
cueing
process
or
something
like
that
huge
retry,
and
that
functionality
has
been
moved
into
exporters.
I
don't
know
if
there's
anything
about
the
other
end
of
the
pipeline,
yet.
A
D
So
the
last
thing
was
renaming,
possibly
status,
canonical
code
to
just
status
code,
there's
an
issue
and
a
pull
request.
I
think.
D
It
seems
harmless
enough
again,
I
think
just
keeping
track
of
all
these
things
and.
D
F
D
So
yeah,
that
is
the
the
rundown
of
of
the
spec
sig.
I
think
you
know
main
takeaways
is
there
will
probably
be
a
lot
more
definition
around
ga
and
buzz
about
that
in
in
the
coming
weeks.
D
I
think
the
yeah,
the
biggest
kind
of
flag,
is,
what's
what's
going
to
happen
with
attributes
versus
labels
versus
maybe
tags.
That
could
be
interesting.
My
guess,
like
I
don't
know
I,
I
wish
everybody
luck
in
that
discussion,
but
I
feel
like
it's
going
to
become
like
a
a
bike
shed,
but
who
knows
maybe.
D
With
a
looming
ga
and
having
enough
people
by
shedding
the
the
issue,
it
could
get
some
sort
of
reasonable
resolution,
so
I'm
not
I'm
not
gonna
rule
it
out
completely.
I
will
be
silently
hopeful
that
something
positive
comes
of
all
of.
D
D
Concerns
cool,
I
guess
we
can
move
on
and
talk
about
the
ruby,
sig,
so
notable
things.
We
didn't
end
up
cutting
a
release
last
week,
just
because
we
kind
of
had
a
handful
of
bug,
fixes
and
other
improvements
and
we're
a
ways
away
from
our
from
our
current
milestone,
the
v
0
7.
So
I
think
we
just
released
something
called
v07.
D
We
might
want
to
rename
these
things,
yeah
I'll
fix
them,
but
yeah
there's
a
release
and
then
one
of
the
fixes,
a
fix
for
sinatra
instrumentation-
did
not
fix
it
in
all
situations,
so
we
did
push
another
patch
release
of
that
out
as
well,
but
that
was
all
around
having
a
a
nice
kind
of
out-of-the-box
quantized
stand
name
for
for
sasha,
instrumentation,
so
yeah
this.
This
is
still
our
our
next
milestone
or
kind
of
in
progress.
D
Yeah,
I'm
not
sure
if
there's
any
any
questions
people
have
about
it
anything
we
could.
We
should
change
about
this.
A
It's
fine.
I've
still
just
been
really
tied
up
with
some
other
hotel
work,
so
I
should
be
able
to
hopefully
re-prioritize
ruby
soon.
D
Yeah,
that's
fine.
I
I
get
the
impression
that
lots
of
people
are
are
busy
with
things
and
it
happens
to
all
of
us.
So
when
time
allows
these,
these
are
things
worth
working
on.
D
I
recently
did
some
work
in
js
around
b3.
I
did
some
work
in
js
and
on
the
spec
around
that.
So
if
I
get
some
time,
I
was
thinking
about
maybe
working
on
b3
for
ruby,
since
it's
all
fresh
in
my
mind,
I
know
that's
not
in
our
milestone,
but
I
don't
know
if
anyone
would
would
be
upset
if
I
pulled
that
in.
If
I
do
have
time,
I'm
not
making
any
promises,
but.
A
I
think
that's
helpful.
I
know
I
mean
from
a
vendor
perspective.
That's
really
the
only
way
do
the
dog
connects
so
yeah.
It's
a
big
help.
D
Yeah
we're
somewhat
interested
in
that
too.
That's
kind
of
been
our
story
for
like
a
lot
of
people
transitioning
to
hotel.
It's
like
b3
is
like
the
common
denominator
between
a
lot
of
other
tracing
clients,
so.
D
Yeah,
I
think
I
think
everybody
should
do
that
also,
but.
D
We
can
still
work
towards
this
and
see
how
it
goes
if
we
do
start
getting
like
more
bug,
fixes
and
other
things
that
queue
up
in
this
milestone
is
taking
longer
than
we
like.
We
can
always
like
do
what
we
did
last
time
where
we
caught
an
interim
release
and
then.
E
Kind
of
rename
the
milestone,
yeah
I've
shuffled
things
around
and
added
a
milestone
there.
So
I
moved
all
the
darn
issues
to
the
v07
milestone
and
then
closed
it.
So
this
looks
like
we
haven't
done
anything.
D
Excellent
brand
new
fresh
milestone,
clean
slate,
but
yeah.
I
think
that's
also
good.
I
guess
for
people
observing
from
the
outside.
Looking
at
this,
they
should
not
expect
anything
coming
out
in
the
next
week
or
two
probably.
D
Cool
and
then
issues
it
looks
like
our
most
current
one
is
20
days
ago,
so
nothing
new
has
come
in
here.
I
suspect
there
are
new
things
on
on
the
spec,
so.
E
E
A
couple
of
things
on
the
spec
that
we
need
to
track,
but
I
think
they're,
all
pretty
minor
one
thing
I
noticed
because
I
was
going
through
a
lot
of
pain,
updating
from
the
v
0
12
to
v.
0
13.
E
go
implementation,
they
have
rearranged
their
packages
quite
a
bit
and
they
now
have
baggage
and
text
map,
propagator
related
things
on
their
top
level,
hotel
package
so
outside
of
the
api
and
then
the
propagation
package
or
propagator's
package.
What
it
was
called,
that's
gone
away
from
api
now.
E
E
D
Recently,
yeah,
I
think,
there's
definitely
been
a
drive
to
it
seems
like
baggage,
is
a
little
underspecified
at
the
spec
level,
so
there's
definitely
a
drive
to
actually
write
down
what
the
expectations
are,
and
I
think
I
feel
like
we
talked
about
this
a
little
bit
last
week.
I
think
there's
also
there's
yeah,
I
think,
there's
there's
some
interest.
I
guess
in
possibly
changing
how
the
api
works.
D
You
kind
of
there's
a
baggage
manager
and
there's
not
exactly
like
a
baggage
object
per
se
that
you
get
a
handle
on
you
kind
of
interact
with
your
baggage
through
this
manager
and
it
reads
and
writes
baggage
into
a
a
context,
a
context
context
the
full
unified
context
that
we
don't
have
dynamic
confidence.
D
That's
because
it
was
correlation
context
manager,
so
yeah.
I
think
the
opportunity
might
still
be
there,
but
there
was
some
sort
of
desire
to
kind
of
have
like
a
like
a
baggage
struct.
I
guess
that
you
kind
of
deal
with
a
little
more
directly.
D
D
You
need
to
make
some
changes
to
your
baggage,
and
then
you
need
to
get
that
thing
back
into
the
context
somehow.
So
it's
kind
of
like
this
situation,
where
you
you
work
with
the
baggage.
You
do
something
with
it.
Then
you
kind
of
like
commit
the
change
to
some
sort
of
context
that
ends
up
making
it
active.
D
D
So
I
think
it's
just
the
nature
of
how
how
those
how
changing
and
persisting
those
changes
works.
I
guess
I
could
be
wrong
on
all
that,
so
I'm
definitely
open
to
any
like
improvements
there,
but
that
was
kind
of
my
my
thinking
on
where,
where
where
things
were
and
why
some
people
might
be
struck-
and
that
is
just
a
little
odd.
D
But
bringing
that
back
around
like
the
package
organization,
I
think
I'm
not
sure
what's
going
on
in
go,
and
I
don't
know
that
I've
actually
seen
anything
like
at
the
spec
level
and
I
definitely
haven't
seen
those
same
things
happening
in
js,
for
example.
So
I
do
I
do
know
like-
and
this
is
just
kind
of
some
past
knowledge
and
just
questions
that
I
got
from
people
working
on
go.
D
You
know
trace
context,
propagator
and
I
think
the
one
the
one
thing
that
makes
that
probably
not
true
is
the
dynamic
context
that
you're
working
with.
I
think
everything
else
is
probably
pretty
reusable,
but
I
guess
in
go.
D
Maybe
this
is
why
you
can
do
this
and
go
because
the
dynamic
context
is
a
go
context,
and
it's
not
this
thing
that
you
had
to
make
up,
because
your
language
doesn't
have
it,
which
is
what
we
have.
So.
D
I
don't
know
in
that
stream
of
consciousness,
that
might
that
might
be
the
identifying
reason
why
they
can
move
this
stuff
up
to
the
top
level
and
might
be
why
there's
kind
of
a
desire
to
do
that.
Just
to
say
that
these
are
generic
baggage
and
trace
context
packages.
You
don't
have
to
write
these
if
you
want
to
use
them,
at
least
so,
but
it
is
something
I'll
keep
an
eye
out
for
to
see.
If,
if
I'm
missing
the
point-
and
there
is
actually
some
some
other
reason.
E
Yeah
one
of
the
things
I
noticed
is
that
the
way
you
typically
pass
in
your
propagators
like
you
have
it
used
to
be
that
you'd,
say
propagation
inject
http,
because
they
still
have
that
suffix
on
there.
So
you
did
propagation.inject
and
then
you
pass
in
your
context
and
your
propagators
and
the
carrier
as
like
the
three
parameters
right
and
now
they've
gotten
rid
of
that
top
level
kind
of
propagation.inject
thing.
E
Instead,
you
have
to
hold
on
to
the
propagators
and
call
them
yourself
so
or
you
have
to
reach
into
the
global
propagators
and
and
work
through
that.
So
there's
a
few
changes
like
that
I'd.
It
would
be
interesting
to
compare
the
spec
with
their
implementation
and
with
our
implementation.
D
Yeah,
so
I
think
typically,
the
way
you
want
to
interact
with
your
propagators
is
through
the
global
propagation
api.
That's
like
the
this
is
the
way
instrumentation
should
be
doing
that
for
ruby,
anyways
and
I
think
for
most
languages.
That's
like
the
desire.
All
of
the
other
ways
that
you
can
get
at
propagators.
D
You
probably
shouldn't,
but
I
do
know
that
there
has
always
been
a
strong
anti-globalist
camp
coming
out
like
largely
in
go
and
other
places-
and
I
think
you
know,
global
state
gets
a
bad
rap
for
a
lot
of
good
reasons,
but
I
think
there's
also
good
uses
of
of
such
things.
So.
D
If
there's
kind
of
these
two
ways
that
are
pretty
well
established
in
go,
that
would
be
my
guess
as
to
why,
but
but
yeah.
I
think
I
think
the
kind
of
your
your
position
here
is
that
we
should
kind
of
compare
the
spec
to
our
implementation
to
the
goal,
implementation
and
just
make
sure
that
we're
all
doing
the
right
things,
I
think
is,
is
a
good
call
to
action,
and
if
we're
not
doing
the
right
things,
we
should
change
it.
If,
if
stuff
is
unusual
and
go,
maybe
bring
it.
D
E
Open
the
floor
just
going
to
pick
on
robert
for
a
second
is
there
anything
that's
come
up
in
our
htlp
rollout
or.
C
So
I
want
to
see
that
and
just
more
like
generally
like,
I
think
some
other
things
need
to
have
like
the
verbosity
kind
of
adjusted
like
I
have
an
app
that's
using
sidekick
with
the
scheduler
and
the
amount
of
floods
from
the
redis
instrumentation
of
just
like
every
single
ping
like
it's.
It's
just
a
lot
of
noise.
E
E
We
are
striving
to
have
defaults
for
everything,
so
we
just
we
have
this
wrapper
package
like
open,
telemetry,
ruby,
shopify,
that
wraps
open,
telemetry
and
just
wraps
the
configuration
and
provides
a
default
configuration
and
points.
E
People
at
the
right
collector
address
all
this
sort
of
stuff,
but
we
want
the
flexibility
of
overriding
some
of
that
with
environment
variables
and
in
a
lot
of
cases
there
are
environment
variables
already
specified
for
this,
but
the
order
is
wrong
right
in
the
sense
that
the
the
order's
right
from
a
programmer's
perspective
like
a
normal
application,
programmer's
perspective,
but
from
the
perspective
of
people
trying
to
build
this
default
package
and
then
tweak
the
defaults
in
certain
cases,
because
we're
testing
like
a
new
new
path,
it
yeah
it's
a
little
bit
annoying.
E
So
one
of
the
things
I
think
was
like
the
hotel
or
the
otlp
exporter
address
or
endpoint.
I
think
it
was
called.
We
want
to
set
up
our
exporter,
so
it
has
a
hard-coded
collector
address
for
everybody,
but
then
on
an
app
by
app
basis.
We
want
to
be
able
to
override
that
with
an
environment
variable
and
it
makes
sense
to
use
the
existing
environment
variable,
but
our
explicit
thing
overrides
the
environment
variables.
E
So
in
these
cases,
in
our
rapid
package,
we're
actually
having
to
check
for
the
existence
into
the
environment
variable
and
if
it
exists,
then
don't
provide
our
explicit
thing
or
like
override
our
explicit
things.
So
it's
just
a
little
bit
weird.
I
don't
know
what
the
right
fix
is
there
it's
kind
of
annoying
to
have
to
like
stick
a
shopify
prefix
on
all
of
these
things
where
there's
like
already
an
environment
variable,
that's
just
specified
later.
D
It
does
I
kind
of
had
this
discussion.
I
think
like
configuration
is
there.
There
is
a
debate
out
there
and
I
was
having
this
discussion
with
somebody
like,
I
know,
historically,
like
people
really
like,
basically
just
kind
of
like
precedence
of
environment,
variable
versus
encode
configuration
versus
kind
of
like
a
configuration
file.
If
you
have
those
three
sources
and
historically
I
have
known
that
operators
really
like
when
an
environment
variable
takes
precedence,
and
this
can
be
a
very
useful
thing.
D
But
I
was
pointed
towards
like
the
12-factor
manifesto
as
being
the
one
source
of
truth,
and
it
says
that
encode
configuration
is
the
thing
that
will
take
the
highest
precedence
which
makes
sense
and
that
if
you
want
environment
variable
configuration,
you
should
leave
off
the
encode
stuff
and
that's
and
that's
how
you
get
it
or
your
in
code.
Stuff
should
handle
that
case.
For
you,
I
was
swayed
because
there
was
a
manifesto
somebody
could
point
out,
and
I
and
there
wasn't
one
for.
D
Yes,
yes,
I
mean-
and
I
think
that
would
be
fine
like
if,
if
there
are
manifest,
those
people
can
point
at
especially
yeah
people
who
are
using
this
stuff
and
have
good
reasons
behind
it,
because
I
think
they're.
I
think
our
reasons
for
all
of
these.
That
would
be
great,
like
I
think
the
the
biggest
thing
is
just
making
sure
that
we
do
this
in
a
standard
way
across
the
hotel,
like
I'm,
not
super
tied
to
any
of
these
schemes.
E
Yeah,
I
think
our
opinion
is
basically
we
like
different
defaults.
Make
sense
in
production
is
really
what
it
comes
down
to
so
we're
having
to.
I
think
the
way
we're
going
to
have
to
do
things
is.
We
have
to
create
this
wrapper
package
that
sets
a
bunch
of
defaults,
but
we're
going
to
have
to
replicate
the
environment.
Variable
checks
that
are
done
for,
like
the
otlp
exporter,
we'll
have
to
do
that,
but
we'll
have
a
different
default
in
production
from
what's
currently
in
the
spec.
E
D
So
yeah
I
mean
on
this
note,
like
one
thing
that's
been
kind
of
in
the
back
of
my
mind,
especially
as
we
move
towards
ga
like
I
have
been
thinking
about
our
configurator
just
a
little
bit
anyways,
because
I
know,
like
you
know,
dating
back
to
before
that
configuration
was
a
complete
nightmare.
E
D
We
added
that,
and
it
got
a
little
better,
but
we
had
that
a
long
time
ago
and
like
I
feel
like
there
could
be
some
more
improvements
there
to
make
it
a
little
easier
to
set
up
specifically
like
an
export
pipeline
and
and
propagators
so
like
since
you're,
using
this
and
you're
kind
of
wrapping
it
like
any
other
users.
D
C
I
just
remember
when
I
was
working
with
it.
I
found
some
of
it
just
a
little
bit
tricky
and
without
like
having
like
a
concrete
pr
that,
like
showcases,
very
hand
wavy,
but
some
of
it
felt
just
a
little
bit
brittle
because
there's
a
lot
of
like
implicit,
behavior,
you'd
call
something
and
the
side
effect
would
be
creating
something
on
the
side,
and
that
had
to
happen
before
something
else
and
adding
a
new
configuration
option.
C
Just
felt
a
little
bit
sketchy
there
and
that's
more
like
a
criticism
of
like
the
internal
workings
like
the
interface
with
it
seems
fine,
like
it's
pretty
standard
for
most
gems,
that
I've
worked
with
in
the
past.
You
just
have
like
a
configuration
block
and
you
pass
in
some
stuff,
but
I
do
think
like
stuff.
C
That's
coming
coming
up
around
like
setting
having
a
service
name
helper
and
having
what
was
that
with
the
other
recent
one
that
was
added,
but
just
like
an
easier
way
of
like
passing
in
resources
and
like
just
a
simple
thing
like
we
could
have
a
configuration
option
to
add
resource
tags
and
it
doesn't
need
to
accept
an
actual
resource.
Object,
it
could
just
be
like
a
hash
and
we
could
create
the
resource
and
merge
it
for
them,
and
so
I
think,
there's
a
lot
of
like
little
quality
of
life,
things
that
could
happen
there.
E
Yeah,
I
think
the
one
problem
with
that
is
the
semantic
conventions.
It's
really
clunky,
reaching
for
the
keys
in
kind
of
our
semantic
conventions
for
resources.
For
some
of
those,
I
I
feel
like
it
would
be
useful
to
have
helpers
where
you
could
just
call
a
method.
In
the
same
way,
we
have
service
name,
and
you
just
specify
what
the
service
name
is.
Having
helpers
for
some
of
these
other
ones
might
be
good
as
well.
E
Sorry,
deployment
environment
would
be
yeah.
I
would
nominate.
D
Yeah,
so
that's
been
in
the
back
of
my
mind,
I
think
I'm
glad
I
brought
it
up
because
it
seems
like
it's
on
in
the
back
of
everyone
else's
mind
like
yeah.
I
just
want
to
mention
that
that
thing,
I'm
kind
of
halfway,
responsible
or
largely
responsible
for
introducing
it.
It
was
a
huge
improvement
over
what
we
had,
but
I
don't
think
it's
probably
going
to
cut
it
for
ga
and
it
needs
it
needs
a
rev
so
like,
but
I
think
user
feedback
is
going
to
be
what's
going
to
make
that
successful.
D
So
tldr,
I
think
we're
two
minutes
over
I'll
I'll
just
make
an
issue
to
track
this
so
that
we
don't
forget
about
it
and
we
can
like
write
stuff
in
there
for
how
to
improve
it,
but
really
would
be
soliciting
like
ideas.
There
also
cool
sounds
good
great.
All
right.