►
From YouTube: 2020-09-29 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
This
is
usually
our
starting
time,
though
I
think
I
think
eric
mentioned
on
getter
that
he's
preoccupied
with
something
else,
and
this
looks
generally
like
the
group
of
people
we
have
so
maybe
we
should
get.
B
Started
yeah
so.
B
C
Oh
hi,
I
just
joined
amazon,
so
yeah,
I
think
I'll,
be
contributing
to
the
open
telemetry
project
in
the
near
future.
Yeah
great
welcome.
Thank
you.
B
Yeah
so
yeah
there
we
go
yeah,
I
suppose.
Maybe
we
can
do
like
some
quick
introductions.
I'm
matt.
I
work
at
lightstep
kind
of
been
been
around
at
this
project
since
pretty
close
to
the.
B
So
yeah
I'll
I'll
kind
of
jump
in
if
anybody
has
like
any
burning
issues
like
feel
free
to
add
these
to
the
agenda,
as
always
like
we
can
talk
about
whatever.
Usually
I
try
to
recap
the
spec
sig
in
a
shorter
time
than
the
spec
sig.
I
usually
do
that,
but
only
narrowly
but
and
then
after
that
we
can
kind
of
start
going
over
the
issues
and
stuff
in
our
repo.
B
So
we
are
still
trying
to
burn
down
towards
ga
ga
for
tracing
right
now
and.
B
Friday,
everything
was
supposed
to
be
wrapped
up
and
there
are
a
couple
of
burning
issues
that
are
preventing
that
from
happening.
B
So
this
first
one
this
first
one
is
tragically,
I
am
a
co-assignee
of-
and
this
is
probably
one
of
like
the
more
controversial
issues,
but
basically
this
kind
of
comes
down
to
the
fact
that-
and
I
think
I
was
talking
talking
about
this
last
week-
I
probably
talked
about
this
in
a
number
of
weeks.
Where,
essentially,
I
don't
know.
B
I've
sometimes
been
labeling.
This,
like
span
slash
context
duality.
It's
kind
of
like
this
weird
divide
that
has
happened
since
otep
66,
where
we
kind
of
have
this
top
level
context
concept,
and
that's
a
newer
thing,
whereas,
like
previously
tracers,
were
very
interested
in
just
spans
and
span
context.
B
So
like,
as
we've
introduced
this
new
top-level
concept,
it
has
muddied
the
apis
a
little
bit
and
one
of
the
things
that
we
often
find
as
a
concrete
example
is
that
there's
tracer
start
span
as
a
method,
and
it
returns
a
span
and
50
of
the
time
you
probably
want
to
span,
so
you
can
like
add
an
event
or
an
attribute
or
something
to
it
and
the
other
half
the
time.
B
You
actually
want
a
context,
because
you
want
to
use
this
to
go
parent,
something
else
or
to
make
it
to
to
activate
it
in
some
some
other
context,
some
other
execution
context.
These
words
get
all
overloaded,
but
but
basically
a
few
things.
B
A
lot
of
things
happened
last
week,
a
ton
of
things
got
merged
in
and
one
thing
I'm
glad
that
you
got
brought
up
as
kind
of
like
a
blocking
thing,
because
languages
have
had
different
ways
of
handling
of
handling
this,
and
I
don't
know
I
kind
of
made
a
comment
here
somewhere
as
to
what
what
we
have
for
ruby.
B
With
some
variations,
but
basically
these
methods,
I
think,
have
been
working
for
us.
We
have
tracer
current
span
and
this
will
extract
a
span
out
of
a
context.
It's
it's
the
current
context.
B
It
will
insert
a
span
into
a
context
that
is
derived
from
some
parent
context,
and
these
have
been
pretty
good
for
us
java,
on
the
other
hand,
has
done
something
else
all
together
where
they
just
have
this
tracing
context,
utils
kind
of
class
with
a
bunch
of
static
methods
on
it
to
kind
of
operate
on
on
a
context-
and
I
think
this
is
the
stuff
that
actually
exists
in
the
spec
today
and
I'm
personally
not
like
a
huge
fan
of
it.
I
think
these
things
belong
on
tracer
to
some
degree.
B
B
So
that
was
mainly
a
lot
of
setup,
I
think
to
say
that
I
think
most
of
these
things
belong
on
tracer.
I
think
one
of
the
things
that
is
coming
up
is
that,
like
right
now,
these
are
on
tracer
instances,
which
I
don't
know.
I
mentioned
this
comment.
Well,
maybe
if
the
current
span
or
inserting
a
span
into
a
context,
doesn't
necessarily
have
to
do
with
an
instance,
we
could
just
make
them
class
methods.
B
I
feel
like
I
want
to
walk
back
that
a
little
bit
and
say
that
at
a
bare
minimum
I
guess
they
could
be
in
both
places,
but
I
think
that
is
one
of
the
concerns
of
this
is
having
multiple
ways
to
do
something,
rather
than
having
like
one
well-defined
way
to
do
it.
B
But
I
feel
like
a
really
good.
Hybrid
approach
would
be
to
just
leave
these
as
tracer
instance
methods
and
just
have
like
a
a
default
tracer
that's
easily
available.
If
you
don't
already
have
a
handle
on
a
tracer,
but
I
realize
that
is
somewhat
ugly
in
that
these
instance
methods.
Don't
still
don't
have
anything
to
do
with
the
state
of
the
instance.
E
So,
that's
actually
sorry
that
that's
actually
a
normal
thing.
I
guess
I
want
to
say
the
tracer
is
largely
expected
to
at
least
like
the
way
it's
expected.
It's
largely
expected
to
forward
most
operations
to
the
tracer
provider
and
the
context
for
two
tracer
instances
that
come
from
the
same
tracer
provider
is
expected
to
be
the
same,
so
sticking
them
on
and
I
stick
them
into
tracer,
as
instance,
methods
seems
perfectly
reasonable.
E
B
Yeah,
I'm
not
sure
if
that
ever
made
it
into
the
spec,
but
this
is
the
thing.
So
this
is
the
thing
that
I'm
kind
of
thinking
about.
So
I'm
thinking
since
this
is
assigned
to
me
like
I
was
hoping
that
we
could
test
this
out
in
ruby
and
kind
of
at
least
have
this
as
an
example,
and
I
feel
like
we,
we
already
have
these
methods,
as
instance,
methods
which
I
like,
I
think
they
should
they
belong
there.
B
I
think
the
only
thing
would
you
be
adding
this
default
tracer
so
that
you
can
easily
easily
get
a
handle
on
a
tracer
if
you're
in
a
place
where
you
don't
already
have
one,
I
think
in
instrumentation
you're,
always
gonna
kind
of
have
a
reference
to
a
tracer,
but
I
know
like
users
when
users
come
in
and
they're
like
hey,
I
just
wanted
to
be
able
to.
You
know,
get
a
reference
on
the
current
span.
B
Then
you
kind
of
need
to
explain.
Okay,
you
need
to
instantiate
a
tracer,
you
need
to
name
a
tracer,
and
then
you
can
get
a
current
span
from
it
and
they
might
be
wanting
to
just
kind
of
get
the
currently
active
fan
to
like
add
an
attribute
or
add
an
event
to
it
or
something,
but
not
necessarily
have
had
a
tracer
available.
B
It
would
be
nice
to
just
be
able
to
do
this
through
a
default
tracer,
although
at
the
same
time
for
the
application
code,
it
would
be
nice
if
you
had
your
own
named
tracer.
So
you
know
where
this
stuff
is
coming
from.
E
B
So,
technically,
yes,
but
like
there
is
no
api
for
interacting
with
multiple
tracer
providers.
It's
basically
you
can
have
one
global
tracer
provider,
but
you
can
have
multiple
tracer
provider
instances
technically,
but
the
secondary
tracer
provider
instances
will
be
totally
off
the
books
totally
like
100
percent
manually,
managed
by
you
the
kind
of
the
programmer.
I
guess
so
so
anything
that
goes
through
like
open,
telemetry,
dot,
tracer
provider,
that's
kind
of
just
the
globally
registered
tracer
provider.
B
B
It
would
just
be
like
a
shortcut
to
like
a
default
tracer
on
the
global
tracer
provider,
and
I
think
we've
covered
this
before,
like.
I
think
that
the
multiple
tracer
provider
use
case
is
not,
you
know,
it
probably
does
not
solve
the
thing
that
it
was
introduced,
for
it
introduces
a
lot
of
weirdness,
which
I
think
has
like
definitely
yeah
I've
ranted
at
at
length.
B
But
what
I
ultimately
came
to
terms
with
is
that
I
do
think
there
is
a
way
that
people
are
going
to
want
to
be
able
to
do
like
resource
scopes.
Like
you
know
this.
This
block
of
this
chunk
of
code
belongs
to
this
stuff.
B
B
But
I
think
I'm
getting
into
the
weeds
so
coming
back
to
this
point,
because
I
think
it
is
relevant
to
yeah
I.
I
think
this
is
like
a
very
relevant
issue,
and
this
is
one
of
the
reasons
why
it
was
a
pretty
hot
topic
at
both
this
meeting
and
yesterday's
main
maintainers
meeting
is.
I
think
this
is
kind
of
like
I
don't
know.
B
I
think
this
is
right
before
ga
people
are
starting
to
look
at
some
of
these
rough
edges
around
the
api
and
really
wanting
to
make
sure
that
we
get
this
right
because
we're
kind
of
like
stuck
with
it,
at
least
for
version
1.0,
until
we
can
kind
of
break
things
so.
B
So
yeah
there
are
various
proposals
going
around,
but
I
think
the
one,
the
one
that
I
like
is
keeping
these,
as
instance,
methods
on
tracer
and
introducing
a
a
default
tracer
that
is
easily
available,
probably
just
like
either
open
telemetry,
constant
default,
tracer
or
open
telemetry.
B
Do
I,
I
guess
yeah
do
either
one
of
those
sound
better?
Is
there
a
third
option
that
is
even
better
than
those.
A
A
B
It's
it's
an
easy
way
to
get
a
handle
on
on
a
tracer
that
is
functional.
That
is
operational
that
you
didn't
have
to
specifically
name.
I
guess
so.
B
There
are
situations
in
your
code
where
you
might
not
already
have
a
handle
on
a
named
tracer
and
you
you
would
like
a
tracer
and
pretty
much
any
tracer
is
sufficient
for
you.
So
I
think
there
are
a
variety
of
circumstances
where
this
is
true,
but
anytime
you
want
to
operate
on
on
the
current
span
or
any
of
these
things
that
aren't
tied
to
state
for
a
specific
tracer.
B
This
would
be
suitable,
but
it
would
also
be,
I
think,
a
very
usable
tracer
for
like
kind
of
the
the
application
developer.
I
think
they
kind
of
have
two
choices
here.
They
could
instantiate
their
own
named
tracer
if
that's
valuable
to
them,
because
they
will
spans
will
be
annotated
with
you
know,
a
name
and
version
or
they
could
just
go
for
the
default.
Tracer.
B
Yeah
so
specific
use
cases
like
I
just
want
to
grab
the
current
span
out
of
the
ether
and
add
an
attribute
or
add
an
event
to
it,
for
example,
as
an
application
developer,
and
I
don't
necessarily
have
like
a
handle
on
a
on
a
tracer,
and
I
don't
want
to
specifically
make
one
with
some
name
just
to
be
able
to
do
this.
It's
like
I
just
want
to
be
able
to.
You
know,
grab
at
the
current
span
and
do
something
to
it.
B
B
A
E
Okay,
you
want
the
shortest
path
to
get
a
tracer.
Basically,
if
you're
going
to
add
a
helper
method
like
this,
you
want
the
shortest
path
which
is
probably
open,
telemetry.default,
tracer
yeah.
That
sounds
good
to
me.
Yeah.
Does
that
make
sense
yeah?
Is
it
also
necessary
to
do
this
for
metrics
so
having
a
default
meter?
Does
that
make
sense
at
all?
I
have
no
idea.
I
haven't
really
looked
to
the
metrics
api,
but.
B
No,
I
think,
that's
a
really
good
question
and
one
that
I'll
ask
people
that
are
a
little
more
familiar
with
the
api
than
I
am.
I
guess
the
same
thing
applies
to
default.
Logger.
B
Yeah,
I
feel
like
not
knowing
nearly
enough
about
any
of
those
other
signals
that
usually
there
is
a
sensible
default,
so
you
might
be
able
to
get
away
with
it,
but
not
always
so.
E
Signals
as
they
just
to
be
clear,
so
bogdan
is
pointing
out
that
we
have
two
ways
to
get
the
context
two
ways
to
like
we.
We
have
operations
to
set
and
get
spans.
We
have
operations
to
set
and
get
context,
and
then
I
haven't
looked
at
the
optional
global
operations.
Yet,
but
here's
proposing
that.
E
We
split
up
the
proposed
solution
is
adding
extracting
a
new
entry
to
given
context
instance,
so
the
trace
context
utilities
have
with
span
and
from
context
and
we're
talking
about
making
those
instance
variables
on
tracer
with
the
default
tracer
and
then
for
the
he's
suggesting
getting
rid
of
all
the
public
helpers
from
tracer
and
trace
contextuals.
E
E
B
That's
the
thing
that
I
think
that
we're
trying
to
like
lobby
against
and
say
that
tracer
is
kind
of
the
right
place
for
this.
Really,
I
think
somebody
john
watson,
pointed
out,
and
if
you
get
rid
of
all
these
methods,
you
are
left
with,
like
tracer
start
span
and
like
that
is
the
entire
entirety
of
tracer
and
like
at
that
point
in
time
it's
just
a
span
factory
and
you
should
probably
call
it
that
so.
B
It's
probably
the
only
reasonable
thing
to
do
so.
So
all
of
this
sounds
not
not
that
great
and
I
don't
know
like
I
honestly.
I
think
there
are
so
many
things
that
pull
me
back
to
otep
issue
68,
which
is
called
proposal,
removes
fan,
and
I
think
it's
actually
the
right
thing
to
do,
but
probably
the
right
thing
to
do
for
version
2.0,
I
feel
like
we
are
kind
of.
I
don't
know.
B
We've
been
working
on
this
for
like
a
year
now
we
should
probably
1.0
at
some
point
like
I
think
like.
I
think
we
can
come
up
with
something
reasonable
for
1.0,
that
you
know
basically
smooths
over
things
and
paves
the
way
for
for
removing
fans,
but
at
the
same
time,
all
the
complications
that
we
have
had
if
we
would
have
just
removed
spans
six
months
ago,
we'd
probably
be
better
off.
B
B
D
I
think
that
makes
a
lot
of
sense,
like
I'm,
not
sure.
I'm
fully
understanding
like
the
motivation
for
taking
stuff
off
tracer
and
to
me
it
just
sounds
like
the
spec
is
trying
to
change
the
shape
of
this
to
fit
like
what
I
understand
to
be
more.
I
guess
like
java
idioms,
where
it's
just
like
factories
everywhere
right
and
like
you're,
you
don't
have
like
a
tracer
object
that
has
cozy
cohesive
methods.
D
You
have
like
the
tracer
factory
and
then
you
have
like
your
other
utils
scattered
across
the
globe,
and
it's
things
are
less
cohesive,
which
is
like
seems
more
of
a
conventional
way
of
writing
java
as
I've
seen
it.
But
that
like.
Why
does
that
weigh
on
the
spec
before.
E
My
totally
so
I
think
it
comes
down
to
separation
between
what's
the
responsibility
of
context
and
what's
the
responsibility
of
tracer
and
right
now,
tracer
has
these
things
that
are
helping
like
bridging
the
gap
between
the
context
and
spam,
so
that
you
can
find
out
like
what
is
the
current
span.
E
The
suggestion
here
is,
rather
than
you
know,
basically,
tracer
becomes
a
vertical.
That
knows
nothing
about
context
and
then
context
is
it's
on
another
vertical
and
then
bridging
these
two
is
the
tracer
context
when
we
call
them
trace
context
utils
that
provides
the
stuff
for
actually
taking
a
current
span
and
shoving
it
into
a
context
or
taking
a
context
and
retrieving
the
current
span
right.
So
that's
that's
sort
of
the
argument.
E
I
think
that
bogdan
is
making
here
that
you
need
to
separate
these
concerns,
but
I
think
the
the
counter
argument
is
that
that's
that
ends
up
being
pretty
inconvenient
to
work
with.
E
Yeah
I
mean,
if
you
look
at
most
instrumentation,
most
instrumentation
will
have
a
tracer
right
and
in
the
same
sense,
that,
like
typical
java
programming,
you've
got
a
logger
instance
somewhere,
and
you
like
you,
have
it
available
readily
available
and
you
can
use
it
for
logging
stuff
in
the
same
in
the
same
way,
motion
most
things
most
instrumentation
or
if
you're
building
a
redis
client,
you
would
have
a
tracer
instance
that
like
is
readily
available,
and
if
you
have
that
trace,
for
instance,
you
might
as
well
use
it
for
retrieving
the
current
spam.
E
It
seems
like
a
pretty
obvious
thing
to
do,
whereas,
if
you
need
to
instead
every
time
you
want
the
current
span,
you
have
to
reach
into
open
telemetry
colon,
colon,
tracer,
utils
or
trace
you
trace
contextuals
dot
current
span.
Then
that's
kind
of
frustrating.
D
Yeah
the
way
I
see
like
the
trace
right
now
and
how
it's
used
and
like
thinking
of
like
the
use
cases
of
shopify
and
how
like
our
internal
tracing
gem,
is
used
like
that.
Having
that
tracer
is
the
way
people
use
tracing
like
it's
their
handle
to
hold
on
to
like
I
want
to
like
wave
my
tracing
wand
and
instrument
this.
They
only
need
to
grab
one
thing
and
they
can
do
everything
for
the
most
part.
D
So
breaking
that
apart
and
requiring
people
to
know
more
about
the
internal
structure
of
this
gem,
I
think
is
going
to
do
us
a
disservice
for
like
adoption,
because
now
you're,
just
making
it
like
people
just
have
to
be
really
familiar
with
how
this
is
laid
out.
All
the
different
parts,
instead
of
not
dumbing
it
down,
but
like
I'm
going
to
use
that
word
dummy
down
to
the
sense
that
you
just
need
to
know.
Okay,
I
configured
it.
D
I
figured
that
out
and
now,
if
I'm
in
my
application,
I
want
to
know
more
about
this
operation.
I
just
grab
the
tracer
and
I
do
start
spam
or
with
spam
or
whatever
right,
and
you
don't
really
have
to
think
about
anything
else
and
it
just
seems
really
almost
trivial
to
use,
which
I
think
is
a
good
thing.
Like
that's
a
positive
to
this
gem.
B
B
Cool
so
yeah,
I
guess
that's
the
crux
of
the
issue.
It
seems
like
we're
kind
of
mostly
in
agreement
here,
which
I
think
is
good
and
yeah.
I'll,
probably
just
have
a
pr
that
comes
in
sometime
this
week.
That
adds
a
a
default
tracer
and
I
don't
know
carlos
and
I
are
assigned
to
this
issue,
so
I
think
I
think
we're
supposed
to
like
write
some
kind
of
code
that
shows
what
we
think
the
world
should
look
like.
B
So
I'll
talk
to
him,
we
might
come
up
with,
like
you
know,
a
handful
of
like
code
samples
for
like
scenario,
blah
blah
blah.
I
want
to
do
this.
This
is
what
it
looks
like
kind
of
thing,
to
show
that
this
is
to
show
what
it
would
look
like.
I
guess
for
people
who
want
to
participate
in
the
in
the
discussion,
but
not
necessarily
build
a
prototype.
B
But
yeah
I
feel
like
we
are
already
like
90
here,
because
I
feel,
like
we've
kind
of
had
these
discussions
before
and
I
think
like
we,
like
I'm
happy
with
kind
of
the
solutions
that
we
have
come
up
with
for
them,
so
we're
we're
not
far
off,
whereas
I
feel
like
java,
went
in
a
very
different
direction
as
they
solve
this
and
yeah.
That's
that's
one
of
the
reasons
why
this
issue
is
as
big
of
an
issue
as
it
is.
I
think.
B
Cool,
I
thought
that
was
decent
discussion.
Anything
should
talk
about
related
to
this.
B
Yeah,
we
didn't
talk
about
this
very
much
because
the
next
one
is
also
pretty
controversial,
but
whatever
the
case,
I
really
wish
that
hotel
exporter,
otlp
endpoint,
oh,
I
think,
maybe
supposed
to
be
like
span
or
metric
endpoint.
E
E
Sort
of
I
mean
otlp
is
supposed
to
be
a
single
exporter.
I
mean
the
way
it's
structured,
it's
supposed
to
be
a
single
exporter
for
all
these
signals
right,
so
it
doesn't
really
make
sense
to
have
a
separate
you
know,
metric
exporter
or
for
otlp
in
a
separate
span.
Exporter-
and
you
know
typically
in
a
deployment
you'd-
have
them
both
pointing
at
the
same
thing.
E
So
we
ended
up
with
these
duplicated
environment
variables
and
because
I
wanted
a
unified
set
as
well.
Now
we've
got
three
environment
variables
for
every
set.
B
Okay,
yeah:
that's
fine,
I'm
fine
with
the
proliferation
of
environment
variables
and
that
all
makes
sense
like.
I
think.
The
one
thing
that
I
noticed
looking
at
them
is
that
it
would
be
really
nice
for
the
http
case
anyways
for
your
secure
or
insecure,
just
to
be
the
scheme
just
to
be
able
to
provide
like
a
a
url
for
your
endpoint.
I
think
right
now
that
gets
pieced
together
based
on
secure,
slash,
endpoint,
fragments
and.
E
Yeah,
although,
interestingly
enough
in
ruby,
you
would
often
set
insecure
separately
or
else
you
would
have
to
pass
the
url
yourself
and
then
query
it
to
say.
Is
this
secure
or
not
and
then
set
it
on
the
connection
so
having
a
separate
thing
for
insecure
actually
makes
the
implementation
easier
and
then
the
other
argument
tigaren
is
making
here
is
that
grpc
has
no
uri
scheme
really
right.
There's
there's
no
standard
scheme
of
values
for
jrpc,
so
you
can't
really
infer
it
or
you.
You
can't
build
a
uri
for
grpc.
B
Yeah
that
the
latter
was,
I
thought,
the
reason
for
this
thinking
from,
like
a
user
perspective,
it's
nice
to
be
able
to
just
provide
like
one
end
point,
but
as
you
bring
up
from
again
the
code
side,
it
actually
makes
it
a
little
bit
easier
on
on
the
programmer
to
not
have
to
see
see
if
there's
a
scheme
and
see
what
the
scheme
is
and
then
you
know
break
the
end
point
into.
B
The
thing
that
we
spent
a
little
more
time
talking
about
was
this
thing,
which
is
basically
in
line
span
context
onto
the
span
rather
than
having
it
as
a
separate
thing,
and
this
is
another
thing
where
I
feel
like
otep
issue.
68
remove
span
also
solves
this,
but.
B
When
you
were
propagating
a
fan,
you
kind
of
had
the
serializable
part
of
the
span,
and
that
is
the
spam
contacts
and
it's
basically
just
you
know,
trace
id
span
id
some
flags,
and
this
is
this
is
what
you
transmit
across
the
wire
and
it's
also
the
only
part
of
a
span
that
is
api,
readable
and
they
are
also
immutable.
So
those
are
kind
of
all
the
properties
of
a
span
context
and
why
they
were
kind
of
the
separate
thing.
B
The
rest
of
span
is
just
meant
to
be
right
only
from
an
api
perspective,
it's
only
readable
in
the
export
pipeline,
so
but
in
a
post,
otep
66
world,
where
we
kind
of
have
this
top
level
context.
It
seems
a
little
bit
more
strange
for
us
to
have
a
separate
span
context.
E
B
I'm
not
sure
what
all
the
motivation
is
behind
this.
I
definitely
can
see
there.
There
are
some
like
performance
gains
to
not
have
to
create
a
span
and
span
context
like
you
save
an
object
allocation
for
stan.
I
feel
like
that's
one
really
big
thing.
B
I
do
think
you
introduce
a
little
bit
of
confusion
as
to
what
part
of
the
span
is
readable
and
where
I
guess
that
line
becomes
blurred
for
the
users
like
why.
Why
can
I
read
you
know,
trace
id
and
span
id,
but
I
can't
read
spam
name
or
something
like
that.
E
E
I
mean,
I
think
we
even
yeah
you've
recently
made
the
change
where,
instead
of
storing
the
extracted
span
context
in
the
current
context,
you
created
a
fake
span
effectively
to
hold
it.
So
I
don't
know
I
mean
it's
a
short
path
to
to
get
rid
of
the
span
context
as
well.
B
Yeah,
I
don't
feel
super
strongly
about
this
either
way
I
feel
like
there
are,
I
feel
like
there
are
pros
and
cons
to
each
approach
to
be
honest
like,
but,
ultimately
deep
down.
I
feel
like
inlining
this
thing
and
sparing
an
object
allocation
would
make
me
feel
better
in
in
the
long
term
yeah.
I
would
agree
with.
B
That
so
yeah
this
is.
This
is
another
change,
a
foot
I
think,
given
the
current
status
of
the
ruby
project,
this
would
not
be
a
huge
change
for
us
last
thing
that
I
brought
up
is
just
trying
to
like
get
some
sort
of
consistency
in
b3
between
all
the
different
languages.
This
doesn't
affect
us
yet
because
we
don't
have
a
propagator,
but
other
languages
do
and
as
I'm
going
through,
the
implementations
like
everybody,
is
doing
something
different.
So
I
was
just
trying
to
get
us
to
agree
on
things.
B
This
will
help
us
when
we
go
ahead
and
make
an
implementation
for
v3,
but
I
don't
think
it's
worth
spending
any
time
on
here
and
that's
the
end
of
the
spec
sig
meeting
again
we
talked
about
stuff
for
a
while,
but
I
feel,
like
you
know,.
B
I
feel
like
this
was
good,
I
feel
like
you
know
there
were.
There
are
like
these
issues
that
are
hovering
at
the
spec
level
that
are
going
to
have
some
direct
consequences
on
our
our
api
and
kind
of
agreeing
as
a
group
as
to
like
how
we
want
to
approach.
B
This,
I
think,
is
super
valuable
and
will
help
will
help
us,
as
we
kind
of
have
these
discussions
like
at
the
spec
level,
to
make
sure
that
you
know
they
don't
like
hand
down
a
decision
next
week
that
we're
all
scratching
our
heads
about
and
and
hating
so.
B
In
our
in
our
repo,
so
I
guess
yeah
what
what
are
the
important
things
we
should
cover
any.
What
do
you
have
any
high
priority
things
we
should
discuss.
E
I
think
I
added
something
for
implementing
process
runtime
semantic
conventions-
oh
and
yeah.
We
also,
I
forgot
to
add
this,
but.
E
B
Was
there
I
know
we
talked
about
having
possibly
a
like
a
bug,
fix,
release
or
like
an
intermediary
release.
Is
that
something
that
we're
interested
in?
Have
there
been
enough
things
that
have
come
in
to
justify
anything
like
that?
At
this
point,.
E
E
Yeah,
actually,
we
have
a
bunch
of
breaking
changes,
so
we
may
need
to
do
a
if
we
want
to
do
a
bug
fix
release.
We
may
have
to
do
that
as
like
a
mass
release
of
everything,
0.7.
B
E
E
I'm
gonna
try
to
jump
in
on
some
of
those
things.
That
would
be
helpful.
I
should
mention
that
robert
and
I
are
probably
not
going
to
work
much
on
this
or
contribute
much
on
this
this
week
and
next
week
we're
a
little
focused
on
some
internal
things,
actually
mostly
around
rolling
out
otlp
internally
at
shopify.
E
So
yeah.
We
just
got
our
heads
down
for
the
next
two
weeks,
but
we
may
we'll
still
be
able
to
contribute
reviews
and
so
forth,
but
yeah.
This
may
be
a
bit
of
a
slow.
A
B
Cool
yeah,
that's
all
fine,
we'll
work
through
this
and
if
I
think
we
can
always
adjust
scope
if
we
need
to
kind
of
get
something
out
or
if
we
get
enough
stuff
in
that
it
makes
sense
to.
B
Interested
one
thing
I
was
going
to
ask
about
communication.
B
B
B
Yeah
at
some
point
I
think
definitely
some
at
some
point.
This
is
gonna
become
a
very
high
priority
if
it
isn't
already-
and
maybe
we
should
kind
of-
I
don't
know
once
we
have
a
lot
of
the
ga
issues,
because
the
issues
that
kind
of
come
at
us
from
like
the
spec
angle
are
like
kind
of
getting
the
sdk
and
api
aligned
across
open
telemetry.
B
They
don't
really
specify
anything
like
instrumentation
related,
but
this
is
the
thing
that
users
actually
want.
B
So
so
as
a
result,
like
our
our
backlogs
end
up
being
kind
of
like
I
don't
know,
machinery
focused
and
not
so
much.
B
You
know
focused
on
on
instrumentation
so
but
at
some
point,
as
I
think
as
we
approach
ga
and
the
spec
related
stuff
kind
of
simmers,
if
we
don't
yet
have
a
rails
instrumentation,
we
should
probably
dedicate
some
time
to
kind
of
like
figuring
out
how
we
want
to
do
this.
E
You
know
we
can
kind
of
roll
out
open
telemetry
to
a
few
small
applications
that
are
not
relying
on
rails
or
some
sinatra,
apps
or
whatever,
but
realistically
before
we
roll
this
out
everywhere
we're
going
to
need
rails
tracing
support,
so
I
mean
we
have
stuff
implemented
internally.
We
know
it's
not
great,
so
we
have
some
ideas,
or
at
least
we
know
the
bits
that
we
need
to
improve.
E
We
may
pick
this
up.
If
nobody
else
does
we
may
pick
this
up
in
maybe
a
month's
time.
I
would
guess
I
don't
know
I'm
looking
at
robert
here.
What's
your
sense
of
when
we
might
be
able
to
start
work
on
rails
tracing,
I
would
like
to.
D
I
think
it's
the
main
blocker
for
me
getting
some
of
like
various
like
teams
that
are
willing
to
adopt
open,
telemetry
and
like
they're,
I
wouldn't
say
less
critical,
apps
but
they're,
just
like
lower
stakes,
so
they'd
like
to
they're
happy
to
be
guinea
pigs
and
try
this
out
with
us
and
so
the
real
blocker
that,
for
me,
right
now,
is
craft,
graphql
and
rails
from
getting
a
few
of
them
on
so
I'd
say
after
we
get
otlp
rolled
out
internally.
I'd
like
to
put
some
some
time
into
this.
B
Yeah,
no,
that
all
sounds
good.
That
sounds
like
a
good
timeline
and
I
think
when
we
get
around
to
it,
like
it's
yeah,
I
think
it's
great,
that
you
all
are
using
open,
telemetry
internally
and
has
some
ideas
around
this,
because
I
think
that's
one
of
the.
B
I
don't
know
one
of
the
things
that
will
help
make
sure
that
we
build.
The
right
thing
is
to
actually
have
a
user
that
has
a
has
use
cases
and.
B
Yeah
make
sure
that
we
we
build
the
right
thing
for
a
user
and
if
we
build
the
right
thing
for
shopify,
it's
probably
the
right
thing
for
for
most
folks.
If
it
does
turn
out
to
be
like
a
huge
amount
of
work
and
it's
something
that
you
would
like
community
help
with.
I
think
we
can
see
about
that.
But
if
it's,
if
there's
a
lot
of
overhead
and
like
spelling
out
what
needs
to
be
done,.
E
You
know
I
strongly
suspect
we're
going
to
have
to
break
this
up.
I
mean
that
if
you
look
at
the
data
dog
instrumentation
for
rails,
it's
pretty
huge
and
I
think
really
what
we
deliver
initially
is
going
to
be
a
pretty
cut
down
version
of
that,
and
we'll
definitely
want
to
follow
that
up
with
some
some
additional
instrumentation.
D
B
Yeah
that
all
sounds
good
to
me,
like
I
feel,
like
there's
there'll,
be
a
little
bit
of
kind
of
project
management
and
road
mapping
around
this
and
yeah.
I
I
think
those
will
be
probably
some
good
discussions
to
have
in
like
two
weeks
time,
and
I
think
you
know
as
long
as
we
have
a
plan
and
people
can
see
a
plan
and
we're
working
through
it.
I
think
that'll
be
good.
A
B
Cool
yeah,
so
down
to
the
last
minute
I
saw
I'd
like
to
get
this
in
sooner
than
later.
I
think
francis
had
a
comment
for
me,
but
I'll
I'll,
try
to
address
that,
and
I
think
this
is
probably
ready
to
go
in.
I
know
you
mentioned
wanting
to
work
on
seeing
how
this
would
play
out
with
your
kafka
instrumentation.
B
E
C
E
I
would
just
move
to
like
get
this
in
so
merge.
This
I
mean
you
can
decide
whether
you
want
the
positional
or
named
second
parameter
here,
but
yeah.
I
I
would
get
this
in
and
then
we
can
tweak
it
later
on
after
you've
had
a
chance
to
play
with
it
with
a
kafka
or
something
else.