►
From YouTube: 2021-06-22 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
Hello
again
and
for
them
folks,
who
are
you
know
watching
this
on
youtube
later
today?
Yes,
I'm
at
the
beach
with
a
full
audio
setup,
professional,
recording,
studio
right
from
right
from
surfside,
it's
great
yeah.
It's
totally
awesome
the
waves.
A
C
C
Yeah
on
wednesday
I'll
be
going
out
to
the
cabin.
I
already
did
that
once
so,
it's
gonna
hopefully
become
a
more
regular
thing,
so
I'll
be
going
again
on
wednesday
for
the
rest
of
the
week.
I'll
just
work
mostly.
A
How
did
the,
how
did
your
internet
connection
hold
up.
C
Surprisingly,
well,
I
did
like
a
video
call
with
francis
the
last
time.
I
did
it
and
we're
actually,
I
guess,
like
the
cabin
I'm
at
they're,
sharing
a
startling
connection
with
their
neighbors,
and
so
they
just
have
their
wi-fi
like
we're.
Just
picking
up
wi-fi
from
the
cap
and
jason
joseph
works,
fine.
C
No
another
member
of
my
team.
He
was
using
starter
link
for
a
while
because
he
lives
kind
of
in
a
small
or
he
was
living
a
small
town
near
our
small
city
and
when
he
first
first
got
it.
It
was
between
like
four
and
six
pm,
it'd
get
a
bit
spotty
on
a
video
call,
you'd
get
like
the
occasional
hang
but
prior
to
him,
moving
near
the
tail
end.
There
was
no
issues
whatsoever.
A
C
A
No,
I
would
say
no,
my
mom,
my
mom
owns
a
place
up
north
in
northern
michigan
and
they
also
have
internet
but
like
it's
the
bad
kind
of
cabin
internet.
Where,
like
I
can
turn
on
netflix
and
like
I
can
watch
three
or
four
minutes
of
the
video
and
then
it'll
buffer
for
three
or
four
minutes,
and
then
I
can
watch
another
three
or
four
like
can't
quite
get
that
that
good
streaming
experience
up
north.
When
I
go.
C
A
Disabled
slack's
not
going
to
be
great,
but
actually
isn't
there
something
changed
in
the
git
protocol.
Recently
I
remember
there's
a
blog
post
about
this
internally
rdl.
Do
you
remember
what
it
was?
There
was
some
like
new
protocol.
That's
actually
a
lot
more
efficient,
but
you
have
to
enable
it
in
your
client.
I
think.
B
Yeah,
I'm
I'm
an
early
adopter
of
code
spaces,
so
I
don't
have
those
problems
of
different
problems.
B
D
B
D
A
I
know
our
marketing,
it's
we're
just
we're
not
we're,
not
in
sync
anyways.
I,
like
the
the
git
protocol,
thing
actually
came
out.
I
guess
a
couple
of
years
ago,
but
for
like
we
enabled
it
all
of
us
internally,
because
we
we
you
know
like
for
fetching
large
mono
repos.
It
makes
a
huge,
huge
difference.
So
if
you
haven't
enabled
that
like
you
should
try
it
it
should
it
should
work
with
everything
on
github
and
I
think
it
should
work.
A
I
think
gitlab
supports
it
and
I
think
it
like
most
modern
places
should
be
supporting
that
now
and
it's
not
something
that
would
be
on
by
default.
I
don't
think
it's
I
mean
it.
Maybe
they've
changed
the
defaults
on
the
client
side,
but
I
don't
think
it
was
yeah.
I
don't
think
it's.
I
don't
think
it's
on
by
default
in
the
git
client.
A
No,
no,
I'm
gonna
go
check
the
change
log,
but
I
don't.
I
don't
think
they
actually
enabled
it
globally.
I'm
sure
there's
like
a
backwards
compatibility
reason.
Probably.
C
Mine,
I
just
checked
my
config.
It's
set
to
protocol
version
two.
C
A
D
I
suspect
it's
just
the
four
of
us
today,
so
I
don't
know.
B
Anybody
have
anything,
no,
I
was
gonna
say
I
don't
know
if
the
goat
thief
is
gonna
make
it
today,
but
but
I
know
that
matt
and
eric
said
that
they
couldn't
make
it
right.
Sorry,
did
you
say,
goat
thief,
yeah
rob
kid,
that's
how
you
introduced
himself
when
we
first
met
him.
D
C
I
think,
like
I
didn't
attend
the
spec
stuff
like
matt
did,
but
we
do
have
some
pr's
open.
Maybe
we
could
take
time
for
that
unless
francis
wants
to
drive
some
content
here.
D
I
really
don't
have
anything
specific.
I
was
off
for
a
couple
of
days
last
week,
so
didn't
really
make
much
progress.
Rob
was
away
as
well
for
a
bit,
so
I
do
think
we
need
to
push
on
trying
to
get
the
rc2
out.
Rob
has
one
pr
that
he
wants
to
get
in
before
he
does
that.
So
maybe
we
can
talk
about
that
today,
yeah,
but
I
don't
really
have
anything
else.
I
wanted
to
discuss
I'll.
Take
some
notes.
B
Sorry
we're
because
y'all
share
the
link
again
to
the
meeting
agenda
doc.
C
C
Now
it
should
be
the
correct
one:
that's
good
so
just
be
selfish
and
go
through
some
of
mine,
the
install
messages
so,
like
the
I
left
the
comment
there-
and
I
I
am
thinking
about
like
I
just
replied
right
as
you
left
that
message,
but
maybe
let's
just
talk
to
it-
talk
about
synchronously
like
basically
what's
coming
up
right
now,
internally
is
as
more
and
more
users
adopt
it.
We
get
this
inevitable.
C
How
do
I
disable
the
install
messages?
So
we
have
our
opinionated
wrapper
internally
and
what
it
one
of
the
things
it
does.
Is
it
basically
adds
like
every
single
http
library
instrumentation,
because
we
don't
know
what
applications
can
have
and
we
want
to
just
give
people,
one
gem
to
add
and
everything
works
out
of
the
box,
it's
the
equivalent
of
using
instrumentation
all,
but
not
quite
the
same.
So
the
result
of
that
is
with
the
registry
when
it
fails
to
install
instrumentation,
because
it's
not
present
it
gets
that
warning
message.
C
If
it
does
work,
it
says:
hey,
it
worked
the
only
really
interesting
one
there,
for
I
think
a
lot
of
people
is
when
there's
an
actual
exception.
That's
raised,
and
that
goes
through
the
error
handler,
which
I
think
is
better,
because
one
of
the
things
we'll
probably
start
pushing
is
on
teams
to
configure
and
test
their
error
handler
to
raise
so
that
they
don't
discover
these
things
in
production
and
like
their
damper.
B
C
Will
just
blow
up
on
it,
we've
already
added
a
helper
for
that
and
one
of
the
teams
have
adopted
it.
But
to
this
it's
like
in
a
rail
tie.
We
pass
in
the
open,
telemetry
logger,
we
give
it
the
rails.
Logger,
it
kind
of
makes
sense,
have
all
the
logs
go
in
one
place,
but
the
side
effect
of
that
is,
you
know,
say
they're
using
like
hivemind,
and
they
start
their
rail
server
and
sidekick
and
whatever
else
they'll
get
like
60
lines
on
boot
of
warning
warning
warning
morning
morning.
C
A
Right
right,
what
about
just
like
I
mean
we
could
just
if
we've
got
the
log
level
thing
what,
if
about
just
making
these
logger.debug,
since
he
said
the
actual,
if
it
actually
tries
to,
was
supposed
to
install
but
then
has
an
exception,
it'll
go
through
the
error
handler
and
that
can
raise
or
do
something
different
right.
A
I
don't
know
that
was.
That
was
my
only
thought.
We
also
see
these
messages
too,
and
I
also
do
not
enjoy
them,
so
I
am
definitely
in
favor
of
squelching
it
one
way
or
the
other
for
sure.
I
guess.
C
Well,
that's
the
other
side
of
it
is
like
the
default
log
level
for
the
rails.
Logger
is
debug,
so
if
we
set
the
debug
level,
oh
and
a
team
doesn't
yeah.
So
if
the
team
doesn't
want
to
configure
it
like
it's
like
the
example
that
came
up
this
morning,
the
most
recent
one
that
finally
inspired
me
to
do
this.
They
don't
set
the
log
level
in
their
development
and
it's
debug
and
I'm
like
well,
you
have
this
set
to
the
most
verbose
setting.
C
What
do
you
expect
and
I'm
still
waiting
for
a
reply
there,
yeah
yeah,
but.
A
C
Understand
it
yeah,
like
I
I'm
in
the
same
camp.
If
I
was
the
consumer
of
this
gem
and
I
was
receiving
a
bunch
of
this
logs
view,
as
some
teams
lovingly
call
it,
I
would
want
to
turn
it
off
and
from,
but
from
my
perspective
as
someone
who's
kind
of
the
owner
of
this
like
internally,
I
don't
want
them
to
squelch
everything,
because
there
is
basically
outside
of
these
install
messages
and
maybe
the
tracer
provider
being
upgraded,
because
there's
a
debug
log
that
gets
issued
there.
C
A
Well,
I
mean
if
the
default
log
level
internally
is
debugged
then
like
that
I
can
definitely
see
how
that
makes
it
a
little
bit
more
complicated
to
address
actually
yeah.
I
don't
want
to
have
a
problem
with
it.
Honestly,
it's
fine.
As
far
as
I'm
concerned,
I
might
actually
say
if,
if,
if
we
do
go
down
the
route
of
having
a
separate
variable,
maybe
flip
it,
maybe
it
should
be
off
by
default,
but
I
don't
know
I
don't
know.
C
That's
that's
the
hard
one
too.
I
I
don't
know
because
I'm
coming
from
I'm
trying
to
think
of
like
general
audience,
but
I'm
also
trying
to
take
learnings
back
from
internal.
But
right.
If
you're,
I
don't
know
like
a
ruby
shop
that
has
a
single
application
and
you're
setting
this
all
up
and
you've
added
new
instrumentation
and
you're
firing.
Everything
up
and
you
don't
know
if
it
works
or
not
you're
like
is
it
working
and
you're
missing
the
warnings
that
say?
Oh,
you
know
I
actually
didn't
install
it.
It
did
install
it
like.
D
Can
we
distinguish
between
didn't
install
because
the
thing
you're
instrumenting
is
not
present
versus
didn't
install
because
of
incompatible
version
or
because
you
had
an
incorrect
configuration
flag
or
something.
C
Right
now
it's
it's
installed
successfully
or
not
the
not
cases
where
it
could
be
like
a
incompatible
version,
or
it's
not
present.
We
don't
currently
surface
that
we
probably
could
we'd
have
to
line
up.
The
like
could
be
look
at
the
all
the
install
hooks
to
see
how
we
want
to
pass
that
information
back
up.
C
We
could
pass
reasons
back
from
like
the
ins.
The
call
to
install
could
actually
return
something
a
little
bit
more
informative
because
it
does.
It
runs
through
all
those
guards
to
see
why
it
didn't
install.
C
You
could
pass
back
like
a
symbol
to
say
like
incompatible
or
not
present,
something
like
that
something
a
little
bit
more
verbose
there
and
then
from
there
still,
I
think,
like
what
would
we
do
there?
We
do
still
say
like
I
want
to
ignore,
like
where
do
we
give
the
dial
of
disabling?
That's
allowing
like
someone
to
reasonably
quiet
this
down.
D
So
I
think
the
the
majority
of
these
messages
come
about,
because
the
thing
that
we're
instrumenting
is
not
present
right.
We've
tried
to
we've
tried
to
load
every
possible
instrumentation
gem,
but
the
underlying
thing
is
not
present,
so
we're
dumping
out
a
warning.
If
we
can
silence
those
first
so
distinguish
those
and
silence
them,
then
we
can
assess
like
do.
We
need
to
go
further
and
have
a
little
bit
more
control
over
things.
A
Yeah
and
the
other
thing
I
was
going
to
say
about
it,
was
also
like.
I
left
a
comment
and
we're
nitpicking
about
it,
but
like
fundamentally,
if
this
makes
it
better
for
you,
I
don't
actually
think
it
really
matters
that
much
like
this
is
a
very.
This
is
also
fine.
I
think
you
know
like
as
it
is.
If
this
is
the
easiest
path
and
you've
got
other
things
to
do,
that
are
more
important.
You
know
yeah.
C
This
is
definitely
the
easiest
path,
but
I
I
don't
want
to
necessarily
do
that
if
there's
like
a
better
way
like
one
thing,
that
kind
of
makes
sense
to
me
is
when
it
doesn't,
when
it
fails
to
install,
but
it
doesn't
raise,
is
potentially
using
the
error
handler
because
you
can
configure
your
error
handler
to
behave
differently.
So,
instead
of
forcing
this
environment
variable
on
the
wider
audience
or
whoever
we
could
just
say
handled
it
like
consider
this,
an
error
handle
it,
and
then
we
can
have
our
own
custom
handler.
C
A
By
the
air
handler,
I
don't
know
if
it's
an
error
right
like
if
it
fails
to
install
because
it's
not
present
like
and
and
you
called
use
all
then
that's,
not
necessarily
an
error.
If
you
called
use
this
specifically-
and
it's
not
present
then
like
well,
maybe
that's
different.
I
could
see
how
this
branches
off
into
like
a
million
different
sort
of
edge
cases.
C
A
A
Don't
call
use
all
so
we
just
we
just
see
a
bunch
of
processes
and
stuff
telling
us
that
it
did
successfully
install
over
and
over
again
and
every
time
we
run
like
a
you
know,
rail.
D
A
C
B
Yeah
because
I
think,
like
other
more
sophisticated
logging,
libraries
you're
able
to
like
configure
them
to
have
different
categories
even
per
class,
to
say
I
want
to
increase
the
verbosity
level
of
the
messages
being
emitted
from
this
specific
class,
and
I
think
that,
because
ruby
loggers
miss
that
have
the
absence
of
that
functionality.
It's
like,
but.
D
Yeah,
like
can
you
wrap
a
logger
around
a
logo
like?
Can
we
can
we
basically
have
a
logo
wrapped
around
the
rails
logger
and
have
a
different
log
level
for
it,
so
that
the
hotel
log
level
actually
applies
just
to
the
messages
we're
emitting?
I.
B
Think
broadcast
does
something
like
that,
but
I've
never
used
broadcast
before
in
active
support
where
you
can
decorate
a
logger
to
have
different
destinations,
and
I
don't
know
if
that's
something
that
you
can
control
to
do
something
so
for
my
from
from
my
take
like
I,
I've
been
trying
to
have
us,
consider
use
for
a
different
logger
altogether,
something
like
a
semantic
logger,
which
has
a
little
more
sophisticated
configuration
capabilities.
B
But
I
understand
that
the
primary
use
case
here
for
most
people
is
they're
going
to
set
rails
locker
equal
to
the
open,
telemetry
logger
right,
like
most
folks,
are
just
going
to
do
that,
but
what
they
want
is
more
granularity
and
where
they
see
visibility
and
tune
it
up
and
turn
it
down.
Those
features,
don't
just
don't
exist
right,
yeah
yeah,
I
don't
know,
go
ahead.
C
I
was
gonna
say
that's
what
kind
of
came
up
this
morning
as
they
they
want
to
be
able
to
distinguish
and
control
dependency,
log
levels
versus
their
their
their
application
code,
but
at
the
same
time
they
want
their
logs
to
go
to
the
same
place.
They
want
to
follow
the
same
format
like
there's
some
special
internal
logger
that
most
applications
use
now,
so
we
don't
want
to
just
like
pass
in
a
generic
longer
either
we
want
to
use
whatever
their
special
one
is,
but
that
means
probably
the
rails
longer.
C
B
But
certainly
diagnostic
messages,
I
I'm
there
with
you
all
about
perhaps
dropping
that
level,
especially
for,
like
the
we
successfully
installed
this
thing
to
perhaps
dropping
that
down
to
debug
the
fail
to
install.
B
You
know
that
that
might
make
sense
as
a
debug
as
well,
but
I
understand
why
we
were
looking
at
warning
level
because
in
production
most
of
the
time
the
the
the
those
logs
are
set
really
high
yeah
and
when,
in
our
case
where
andrew
and
I
were
working,
we
were
trying
to
figure
out
why
things
weren't
getting
loaded
in
production
but
we're
in
development
mode.
Those
tend
to
be
a
little
bit
a
little
annoying.
But
again
it's
like
my
take
on
it
would
be.
B
We
would
set
up
a
separate
logger
for
it
with
different
tags
by
default,
that
we
would
admit
and
look
specifically
for
those.
A
Yeah,
if
you
want
to
just
like
wrap
a
logger,
I
mean
you
can
ruby,
does
make
that
pretty
easy,
like,
I
think
forwardable,
I
think,
is
one
of
those
magic
things
in
the
standard
library
that
just
makes
this
work
or
you
could
just
wrap
it
and
call
method,
method.
Mything
and
just
you
know,
send
everything,
but
you
know
I
don't
know
I
I
I
do
hear
the
the
worry
that
we
don't
want
to
have
like
a
flag
for
every
conceivable
possible
log
message,
and
that
would
also
be
bad.
C
B
We're
establishing
we're
establishing
a
precedent
in
prior
art
for
folks
to
follow.
A
Yeah
yeah-
and
I
know
I'm
really
good
about
finding
those
and
using
them
as
justification
for
my
own
pr's
to
perpetuate
bad
patterns.
So
I
definitely
it's
a
good
concern.
We
call
it
copy
paste
or,
yes,
we
come
from
all
over.
C
So
then,
I
think,
looking
at
seeing
if
we
can
wrap
the
rails
logger
or
whatever
logger
we
received
with
something
that
we
can
still
make
use
of
the
hotel
log
level
environment
variable
to
control.
Does
that
sound
like
a
preferable
direction
to
this.
D
Sounds
preferable
because,
as
it
stands
right
now,
the
hotel
log
level
would
actually
modify
the
log
level
of
the
logger
like
the
rails,
logger,
for
example,
right
which
seems
wrong
so
yeah.
I
would
prefer
it
if
we
had
some
way
of
wrapping
whatever
logo
we're
given
and
still
have
the
hotel
log
level
apply
correctly.
A
Well,
I
was
gonna
say
we
haven't
talked
about
it
in
a
while,
but
robert
didn't
you
and
I
want
to
start
working
on
a
open
source
version
of
our
little
rail
ties
that
we
have
going
on
independently.
We
haven't
done
that
yet
we
could
start
on
that
and
that's
the
place
where
this
could
go
right.
D
Yeah
contributory
contributo
ultimately
holds
all
the
instrumentation
all
the
auto
instrumentation
any
additional,
interesting
things
like
this,
so
the
the
useful
kind
of
wrapper
configuration
rail
tie
things
it
would
hold.
Let's
see
things
like
we
had
common.
I
can't
remember
if,
if
I
can't
remember
how
the
dependencies
work
with
karma,
so
that's
something
to
look
at
any
exporters
that
are
not
part
of
that
core
set
any
propagators
that
are
not
part
of
the
core
set
as
well.
It's
a
part
of
the
spec.
D
All
that
stuff
should
go
in
contrib
and
then
the
main
repo
should
just
be
like
api
sdk,
the
core
set
of
exporters
and
things
required
by
the
spec
yeah.
Basically,
anything.
D
Yeah
I
feel
like
we
had
one
and
then
maybe
it
went
away
because
we
weren't
using
it
or
but
it's
trivial
to
get
one
created
for
us.
I
think
we
just
probably
ping
somebody
on
yeah,
like
we're,
probably
ping.
Somebody
like
sergey
or
yeah,
like
somebody
on
the
tc
or
the
governance
committee,
can
easily
get
one
created.
A
For
us,
okay,
do
people
have
any
problems.
If
I
pursue
that
and
just
get
one
created
for
us,
even
if
we
don't
have
much
for
it
yet,
no.
D
A
A
Yeah
all
right
I'll
poke
around
at
people,
and
I
will
that
way.
We
can
at
least
start
putting
some
of
the
the
extraneous
stuff
in
there.
Not
the
logging
stuff,
because
that,
as
we
have
discussed,
is
a
good
thing
for
the
main
repo,
but
all
the
others.
Yeah.
C
Okay,
so
for
this
beer
I
think
we'll
move
on
from
it.
I
will
circle
back
and
share
whatever
I
come
up
with.
I
want
to
get
this
done
soon,
because
I'm
about
to
hit
the
everybody
at
shopify
has
to
use
open
telemetry
like
you're
being
forced
now,
so
I
want
that
to
be
resolved,
but
I
want
to
share
back
at
least
on
the
pr,
at
very
least
in
a
comment
like
what
I
ended
up
doing
there.
So.
D
D
C
Every
time
eric
apologizes
for
not
contributing
more
I'm
just
like
it's
fine,
it's
just
less
people
to
contend
with.
So
I
think
this
one's
with
the
comment
here.
It
makes
sense.
I
did
look
at
it.
I'm
sorry
I
didn't
reply
sooner
but
yeah
effectively
there
was
like
there
were
no
walks
like
it
was
either
scattering
this
code
in
a
few
different
places
that
probably
would
never
even
get
reached
or
putting
it
here.
C
Francis
replied
properly
with
an
actual
explanation,
so
I
think
this
is
probably
good,
as
is
right,
this
one's
just
adding
this
looks
correct
to
me.
Yeah.
B
B
What's
interesting
is
the
I
guess
why
wouldn't
the
specification
have
that
constraint
as
opposed
to
the
api
documentation
having
that
constraint,
but.
B
D
A
B
D
That
does
help
I
yeah
one
interesting
thing
is
this
may
trigger
a
whole
bunch
of
errors
and
are
not
errors,
but
like
warnings
in
the
builds
like
nci,
because
I'm
sure
there's
a
bunch
of
test
codes
that
just
does
like
open
to
lemtree.tracer
provided
our
tracer
without
any
name
right.
So
yeah
we'll.
C
See
what
that
looks
like
and
I
can
circle
back
and
clean
up
if
it's
crazy
or
we
can
just
delve
depth
novel
vlogger.
I
think
we're
doing
that
in
a
few
places.
Now
I
have
not
looked.
D
At
this
one,
yet
so
it
doesn't
actually
work
correctly
yeah.
This
doesn't
work
correctly.
It's
got
yeah
there's
two
problems,
one
is
that
it
doesn't
work
correctly
and
two
is
even
if
it
worked
correctly,
it
would
be
really
inefficient.
I
appreciate
that
it
attracted
a
new
contributor,
however,
which
was
good
yeah.
A
I
think
the
thing
we
might
have
to
explain
to
them
if
they
come
back,
is
that,
like?
There
are
two
paths
in
this
code
and
you
should
you
will
have
to
duplicate
this
because
we
need
a
fast
path
that
checks
and
then
we
need
to
fast
a
slow
path
that
filters
and
that's
not
necessarily
clear.
I
mean
it
is
there's
a
comment
but
like
it's
not
necessarily
clear
why
I
guess
like
it
makes
sense
to
me
but
like
we
might
have
to
tell
them
that.
But
that's
fine.
You
know
do
that
when
it
comes
up.
A
A
bug
of
our
own
creation,
in
fact,
was
the
problem,
but
I
just
noticed
that,
like
we
have
a
bunch
of
duplicated
methods
in
the
rack
instrumentation
and
that
felt
like
the
type
of
thing
to
me
that
was
like.
Oh,
this
will
break
eventually
they'll
drift.
A
The
context
is
a
good
idea
and
I
think
that's
actually
fine,
and
I
wonder
if
there's
a
way
to
do
it
without
just
duplic
without
duplicating
api
methods,
and
I
I
think
if
we
make
the
current
span
key,
not
private
in
the
rack
instrumentation,
we
can
actually
do
it
pretty
easily.
But
I
don't
know
if
that's
really
bad
or
not.
D
It's
kind
of
bad,
so
the
there
is
an
expectation
that
keys
are
kept
private
like
context
keys
are
kept
private.
Instead,
you
have
these
access
methods
to
retrieve
the
data
yeah,
the
the
context
keys
are
not
meant
to
be
shared
outside
of
whatever
module
they're
in,
which
is
ultimately
why
it's
defined
this
way
right.
C
C
C
I
don't
know
it's
the
same
with
like
the
http
attributes.
It's
just
like
a
nice
building
block
on
something.
That's
pretty
common,
pretty
standard
within
the
ruby
ecosystem.
D
Yeah
and
to
be
fair,
this
is
a
bit
of
a
murky
part
of
the
spec
in
the
sense
that,
like
we've
chosen
this
pattern
for
dealing
with
these
sorts
of
issues,
whereas
the
the
spec
ended
up
or
the
spec
mini
like
ended
up
hand
waving
about
some
of
this
and
then
ultimately
said,
you
know
what
it's
okay,
to
have
multiple
server
spans,
multiple
client
spans
that
are
wrapping
one
another.
D
I
don't
think
the
community
has
really
settled
on
the
right
way
to
do
this.
It's
just
like
they
loosened
up
the
language
in
the
spec
to
allow
that
nesting,
so
they
conceptually
you
could
opt
instead
to
have
rack
and
rails
be
completely
independent
and
rails
would
always
create
its
own
span
as
a
service
span
that
it
would
then
decorate.
A
Yeah,
but
I
mean
that
feels
I
I
like
the
fact
that
it
actually
modifies
the
rack
span,
because
that's
it
works
conceptually
closer
to
how
I
think
about
it.
I
don't
really
think
yeah
I
mean.
Obviously
I
know
rack
is
separate
from
rails,
but
like
yeah
in
the
context
of
rails,
I
consider
it
like
part
of
rails
itself
almost
so
I
actually
like
that.
A
I
was
mostly
just
trying
to
get
at
the
fact
that
we
had
duplicated
a
couple
of
api
methods
and
I
felt
like
that
was
a
bit
of
a
smell,
but
with
the
with
the
requirement
that,
like
the
key,
if
the
context
key
can't
be
shared,
then
it
does
seem
like
that's
really
the
only
way
to
do
it.
So
you
know
that's
fine,
I
think.
C
A
The
less
of
it
that
we,
the
less
that
we're
duplicating
the
better
so
I'll,
just
update
it
to
remove
just
the
stuff.
That's
not
called,
and
that's
that's
totally
fine.
It's
definitely
also
not
a
big
deal
at
all.
I
was
just
poking
around
the
rack
instrumentation
trying
to
understand
what
might
have
gone
wrong
in
our
environment,
and
I
saw
all
of
it
and
I'm
like
well.
That
feels
like
the
type
of
thing
that
could
go
wrong.
So
okay,
I'll
update
it
and
then
I'll
that's
cool.
I
have
no.
A
I
have
no
real
attachment
to
it.
Otherwise,
so.
B
So
because
I
was
completely
distracted
by
something
else,
it
sounded
to
me
like
we
were
creating
a
special
context,
lookup
specifically
for
this
instrumentation,
because
it's
sort
of
like
the
core
instrumentation
we
expect
most
folks
to
use,
and
we
we
other
other
instrumentations,
depend
on
it
like
rails,
which
augment
the
rack
generated
span
as
opposed.
C
A
D
So
I
mean
we
do
that
for
a
bunch
of
http
instrumentation,
we
do
it
for
redis
instrumentation
as
well,
and
then
we
like
you,
I
can't
remember
the
state
of
the
elastic
search
instrumentation
but
like
es
uses
http,
so
it's
generating
an
http
span
right
right
underneath,
but
it's
way
better.
If
you
could
just
augment
that
http
span
with
some
extra
attributes.
A
Yeah,
we
might,
we
might
also
have
some
use
for
this
internally,
some
of
our
like
internal
job
queueing
systems
that
are
not
really
based
on
anything
public
like
use
faraday
under
the
hood,
and
we
want
to
like
instrument
the
job
cube,
but
then
there's
also
a
bunch
of
like
sort
of
not
useless
faraday
spans,
but
like
definitely
confusing
ones,
and
you
know
we
might
be
able
to
use
a
similar
method
here
to
to
clean
that
up.
Okay,.
C
That's
something
we
push
internally
like
the
way
we
surface
our
service
graph
for
our
internal
ecosystem
is
so
like,
say
we
have
some
like
application
that
may
talk
to
like
shipping
carriers
right
they
have
their
their
own.
We
have
our
clients
that
communicate
to
them,
and
so
because
we
want
to
see
them
on
the
service
mat,
so
you
can
kind
of
get
those
inferred
slos
out
of
them.
C
C
This
is
something
that's
become
really
really
helpful
like
internally,
and
I
think
that
we've
kind
of
provided
like
the
good
building
blocks
for
that
I've
been
really
happy
with
how
that's
all
worked
out,
and
that's
similar
to
this
in
the
same
vein
that,
like
we
have
this
wrapper
here
where
it
says
like
with
span,
or
we
have
the
http
one
with
like,
with
attributes
right
so
being
able
to
do
that
for
different
kind
of
generic
things
like
http
libraries,
like
databases
like
this,
is
it's
nice,
it's
really
nice,
so
cool.
A
C
And
for
like,
I
think,
one
of
the
first
people
that
adopted
it
was
one
of
the
sales
channels
and
I
think,
like
say
like
they
like,
had
an
api
that
communicated
with
facebook
it's
like
here
now
you
can
see
how
many
times
you're
actually
getting
errors
against
facebook.
You
can
see
if
your
api
is
down,
you
can
see
and
so
for
a
team
that
had
to
depend
on
other
things.
Now
they
can
just
look
on
a
service
map
and
see.
C
Yeah
exactly
so,
I
guess
we'll
move
on
to
this
one.
This
is
the
one
that
I'd
like
to
get
in
before
we
do
the
rc2.
A
Yeah,
I'm
personally
fine
with
it.
I
just
was,
I
don't
know
if
francis
is
happy
with
it
or
not.
No,
I'm
definitely
happy
with
it.
I've
never
had
it.
D
I
am
not
happy
with
this.
I
will
provide
some
feedback.
Sorry,
I've
gotta
pop
downstairs
for
something,
but
I
will
provide
some
feedback
on
this
after
the
meeting.
I
just
have
efficiency
concerns
around
the
attach
and
detach
because
attach,
for
example,
has
four
thread:
local
accessors,
which
is
a
lot
more
expensive
than
it
really
needs
to
be
detach.
I
think,
has
two
three
three.
I
think
so.
Okay,
I'll
just
provide
some
feedback
on
that
afterwards,
it's
just
attached
and
detached
needs
some
efficiency
improvements.
D
C
A
Notifications
is
still
just
waiting
on
context.
I
don't
think
anything's
changed
on
it.
So,
okay,
the
monotonic
clock.
D
Yeah
those
to-do
still
apply,
so
I
will
work
on
that.
It
doesn't
need
to
block
the
aussie
or
the
1.0.
Okay.
A
Review
here,
okay,
he
is
he
waiting
on
us
to
review
this,
because
if
so
I'll
go
through
it
I'll
go
through
it
today
and
actually
give
some
feedback
on
it.
If
it's
actually
just
waiting
for
initial
feedback
that,
I
think
that's
valid,
I
think
there's
some.
C
It's
just
it's
a
dangerous
like
we
settled
on
the
pre-pen
mixing.
The
two
now
is
just
a
recipe
for
disaster,
so
I
think
we
have
to
be
pretty.
Let's
turn
on
that
one.
That's.
A
C
Then,
similar
to
this
this,
I
believe
I
need
to
look
at
the
actual
underlying
implementation
of
this
library
because
I'm
not
familiar
with
magic
core
at
all.
So
I
need
to
like
dig
into
it,
but
I
I
I
want
to
see
if
there's
a
good
reason
not
to
use
like
the
block
format
here
so
they're
starting
a
span,
they're
capturing
the
exception,
but
they're
not
using
the
record
exception,
there's
a
lot
of
stuff.
That's
just!
A
C
And
it
just
looks
like
that,
like
I
really
just
need
to
look
at
this
because
there's
just
a
lot
going
on
compared
to
like
really
our
http
instrumentation
for
the
bulk
for
libraries
or
all
of
them
right
now,
they're
pretty
slim
right,
like
there's,
not
a
lot
going
on
in
them,
so
I'm
it
just
raises
an
eyebrow
to
wonder
why
there
is
so
much
code
in
this
patch
here.
A
You
know,
I
also
noticed
that
there's
no
disabling
of
the
rubocop,
and
if
you
don't,
then
it
starts
complaining
about
your
method.
Lengths
and
you
start
to
split
it
out,
to
look
like
that
and
do
a
lot
of
work
that
you
don't
have
to
right.
So
I'm
starting
to
wonder
if,
well
that,
okay,
the
raptor
quest,
is
interesting.
C
Yeah
so
like
there's
a
few
things
here
and
it
does
feel
very
much
like
ruby
with
like
lots
of
small
online
methods-
and
we
talked
about
that
previously
and
I
raised
some
strong
opinions
on
how
I'm
not
very
fond
of
it
in
this
context
or
any
so
anyways
yeah.
This
looks
like
there's
a
lot
of
like
good
work
here.
C
It
just
doesn't
fit
the
style
of
what
we've
been
doing
so
far,
and
I
think
that's
just
our
responsibility
as
people
who
are
working
on
this
repo
to
share
the
wealth
so
but
yeah
this
one's
been
lingering
and
I
said
I'd
look
at
him
last
week
and
then
I
disappeared
for
an
impromptu
time
off.
So
I
will
also
get
around.
A
C
And
then
this
one
is
waiting
on
the
pr
author,
but
I
think
what
makes
sense
here
now
because
it
has
been
sitting
for
a
little
bit
and
I
think
we
have
a
pretty
good
idea
where
we
wanted
to
go.
I
think
dropping
a
big
suggested
change
again
might
be
the
appropriate
path
here,
because
I
think
it's
very
close.
I
just
need
to
find
where
the
patch
is.
C
So
I
think
this
becomes
kind
of
what
we
were
talking
about
before,
because
there's
the
faraday
instrumentation,
and
this
is
sitting
very
closely
on
top
of
it.
I
think
this
becomes
another
opportunity
where,
instead
of
doing
all
of
this
work,
we
potentially
just
augment
it
with
some
attributes
using
that
with
attributes
wrapper.
A
With
attributes
wrapper,
is
that
something
that's
in
the
in
the
repo
already?
I
don't
actually
know
if
I've
seen
it
is
that
just
something
you
have
internally,
this.
D
A
Well,
that's
nice,
this
one
here
so
okay
and
that's
something
that
our
faraday
instrumentation
already
grabs
and
deals
with
so
right.
So
if
we.
C
So
this
is
where
it
actually
picks
it
up.
So
you
wrap
your
faraday
call
like
at
any
level
and
assuming
our
context,
propagation
works
properly,
all
the
way
down
which,
in
practice
it
has,
we
merge
the
attributes
that
are
passed
down,
so
the
I
think
the
recommended
approach
that
I'll
do
here
is
basically
this
will
slim
down
and
it'll,
be
just
its.
C
Only
purpose
will
be
to
pass
down
some
elastic
search,
specific
attributes,
and
then
the
underlying
faraday
span
will
be
augmented
with
this
information,
and
I
think
that
makes
sense
here
and
that
ultimately
like,
depending
on
feedback
from
like
the
wider
community
or
once
we
start
seeing
more
adoption
of
this
internally.
B
C
This
is
something
that
could
easily
be
a
configuration
like.
I
want
it
to
actually
generate
a
spam,
like
that
looks
very
closely
to
the
work.
That's
here
or
this
exactly
or
I
just
want
to
augment
the
underlying
faraday
span.
That
could
be
a
configuration
option
I
think
for
now.
I
would
push
for
augmenting
the
underlying
span.
A
A
We
were
ariel
and
I
were
talking
about
faraday
in
general
yesterday,
because
we
we
have
a
bunch
of
stuff
that
uses
faraday
and
we
were
wondering
how
would
people
feel
if
we
changed
the
fair
to
instrumentation
to
sort
of
maybe
have
like
a
like
a
disallow
list,
a
block
list,
things
that
it
doesn't
patch
itself
for
because
we
we
can
use
like
the
attributes
wrapper
for
one
of
the
cases
we
had
in
mind,
but
some
of
the
stuff
in
our
application.
A
We
don't
actually
want
traced,
we
don't
want
every
single
faraday
called
trace,
necessarily
because
of
the
way
we
patch
it.
It's
it's
just
inserted
into.
Everything
would
like
an
option
to
maybe
not
do
that.
A
Yeah,
it's
in
the
rack
builder
one
or
not,
not
the
rack,
instrumentation,
I'm
sorry!
It's
in
the
faraday
instrumentation!
No!
No!
I
know
I'm
because
you
you
basically
want
certain
endpoints.
B
No
that
I
mean
so
there
are
certain
libraries
that
we're
are
there
certain
clients
that
we
want
to
omit
traces
from
in
our
application
and
because
everything
is
auto
instrumented
across
the
board
for
faraday
we're
seeing
traces,
we're
not
interested
in.
D
C
An
example
of
like
our
tracing
is
now
open.
Telemetry,
I
think,
is
now
tracing
like
bug.
Snag
session
updates.
A
A
Similar
for
us
and
like
we,
I
think
what
we
want
is
we
actually
want
context
propagation.
We
just
actually
don't
want
to
spam
there,
because
we
don't
care,
maybe
not
like
the
bug
snag
case,
but
we
have
some
cases
really.
We
don't
want
faraday
to
generate
a
span
here.
We
just
we
want
the
context
to
go,
but
like
we,
you
know
it's
already
captured
at
a
higher
level
or
something
so
maybe
I
mean
the
untraced
that
will
still
no.
B
A
B
I
think
about
certain
endpoints,
I'm
not
sure
about
certain
endpoints.
It
might
be
certain
object
instances
of
client
itself
if
there's
a
way
to
kind
of
to
to
remove
that
object
or
or
disable
it
for
this
specific
client
object
instance,
because
I
think
the
way
that
we
work
is
that
we
have
a
connection
object
per
sort
of
back
endy
thing
that
we're
integrating
with
we're
not
really
using
those
connections.
A
A
C
A
If,
if
an
option
for
this
somehow
is
maybe
something
that
would
have
broader
use,
because
if
it
doesn't
have
broader
use,
then
we'll
just
do
it
ourselves
in
the
way
that
works
for
us,
but
if
it
would
be
useful
to
other
people,
it
sounds
like.
Maybe
this
is
not
a
case
you
run
into
in
shopify.
You
don't
really
need
to
turn
it
off
for
certain
faraday
connections.
C
The
pure
service,
like
that's,
like
a
special
magic
tag
for
us
to
identify
different
external
clients
and
like
oh,
but
like
they're,
because
they're,
basically
injecting
some
more
stuff
on
different
connections
for
different
clients,
because,
like
you,
I
don't
actually
use
very,
very
much
or
have
very
I've
used
it
very
little
like
you're
building
these
connection
objects
and
they're
adding
to
it.
But
I
guess
I'm
at
I
imagine
your
situation.
C
A
Yeah
we
so
we
can
modify
them
to
not
use
the
middleware
if
we
were
installing
the
middleware
manually
and
not
using
the
instrumentation
install
hooks,
because
that
patches
it
in
a
way
that
you
can't
do
it.
But
right,
but
you
know
it's,
it's
not
a
huge
deal.
Necessarily.
We
were
just
starting
to
think
about
it.
We
didn't
know
if
this
was.
C
Know
yeah,
I
I
haven't
like
the
closest
thing
I've
come
to
is
like
seeing
like
just
like
repeated
bug,
snag
kind
of
pings,
and
I'm
wondering
if,
like
adding
like
an
untraced
endpoint
to
htv
stuff,
makes
sense
there,
because
I
know
for
like
the
reason
this
untraced
request
exists
in
rack.
Is
like
your
status
end
point
on
your
application.
You
probably
don't
want
to
trace
all
of
those
like
someone.
Might
we
don't.
A
We
did
discover
we
did
use
it
to
troubleshoot
a
problem
the
other
day
because
we
hadn't
gotten
around
to
putting
those
in
the
untraced
endpoints
and
then
someone
is
like.
Why
am
I
getting
too
many
404s?
I
think
arielle
was
helping
with
this
and
we're
like.
Actually
because
we
haven't
disabled
this.
We
can
see
precisely
why
you're
getting
these
four
of
course.
A
A
B
A
B
C
B
A
Yeah,
that's
the
first
one.
That's
come
up,
I
think
there's
other
ones
too,
but
that
is
the
first
one
we
found
and
like
we
can
definitely
remove
and
add
spans
and
things
to
make
things
work
without
changing
upstream
libraries.
It's
more
just.
I
think
we've
been
trying
not
to
remove
and
change
the
shape
of
the
traces
that
people
have
already
manually
decided
they
wanted,
because
a
lot
of
what's
in
there
today
is
not
stuff.
We've
put
in
it's
stuff
that
teams
have
added
over
the
years
right.
So
I
wonder
if.
C
A
C
I've
done
that
in
a
few
migrations.
I've
done
is
where
I
just
like.
Oh,
this
doesn't
make
sense
anymore,
and
so
we
just
we
augment
the
underlying
span
with
whatever
they
had
before,
but
to
like
the
polling
point
like
that
might
be
a
candidate
for
using
an
untraced
like
the
entrance
utility,
or
something
like
that.
If
you
don't
want
to
see
any
of
the
polling
there,
but
that's
tough
yeah.
D
Like
we,
we've
done
that
for
our
job
systems
or
obviously
our
job
workers
are
sitting
there
polling,
a
bunch
of
queues
for
jobs
to
work
off
and
that's
generating
a
ton
of
spans
and,
what's
really
terrible,
is
that
it
doesn't
necessarily
scale
with
workload.
D
If
you
scale
up
your
worker
pool
for
some
reason,
then
you
can
just
like
overwhelm
your
trace
collection
infrastructure
if
you
are
tracing
every
single
polling
request,
because
now,
like
everybody's
polling,
but
not
only
is
everybody
polling,
everybody's
polling
really
really
fast,
because
they've
got
no
work
to
do
right
if
you
screw
up
you're,
auto
scaling
or
whatever
for
your
worker
pool.
So
we've
ended
up
having
a
separate
tracer
that
we
use
explicitly
for
that
job
infrastructure
and
we
have
a
separate
sampler
set
up.
Just
for
that.
So.
D
Sample
rate
yeah,
I
think
it
even
has
its
own.
We
have
the
ability
to
dynamically
configure
the
sample
rate
as
well.
So
if
something
goes
really
crazy,
we
can
just
squelch
it
and
move
on.
That's
nice.
A
C
The
other
thing
for,
like
your,
like
professor
saying,
like
adding,
maybe
even
just
like
down
sampling
some
of
these
busy
end
points,
might
be
sufficient
for
your
use
case,
because
then
you
can
still
get
some
information
around
it.
You
might
still
get
some
kind
of
trends.
If
that's
what
you're
interested
in
you
can
always
just
tune
it
to
whoever
is
actually
looking
at
this
or
not
looking
at
it,
based
on
their
desire.
C
A
A
Yeah
we're
definitely
starting
to
look
at
sampling
configs,
it's
exciting,
actually,
one
of
the
things
using
using
light
stuff
before
we
hadn't
really
needed
to
sample
much,
because
that
was
a
thing
that
happened
under
their
old
collector
architecture
you
didn't
have
to,
but
now
we're
actually
looking
at
it
and
it's
kind
of
kind
of
nice
to
tune
that
sorry
for
making
that
a
long,
long
rabbit
hole.
We
went
down
useful,
no.
C
It's
yeah.
No,
it's
interesting
like
hearing
about
different
use
cases,
different
organizations
and
things
that
are
being
run
into
it's
good
because
it's
like,
even
if
we
don't
action
anything
right
now.
As
a
result
of
this
conversation,
it's
something
that's
in
the
back
of
your
head
and
you
can
think
about
it
as
you
like,
run
stuff
in
the
future.
D
Potentially,
this
untraced
concept
is
like,
I
would
say,
we've
got
a
slightly
crappy
solution
for
it,
but
this
request
has
been
in
the
ecosystem
for
a
while
and
has
been
battered
around
in
the
spec
sig
many
many
times
over,
probably
more
than
a
year
and
nobody's
really
agreed
to
a
solution
for
it.
The
the
original
places
came
up
was
people
wanted
to
not
trace
the
otlp
export
request?
D
So
that's
where
everybody
wants
a
solution
for
it,
but
there
are
a
bunch
of
use
cases
like
the
ones
you've
mentioned
that
have
also
come
up
and
been
attached
to
that
kind
of
long-running
issue.
I
think,
like
the
issue
is
being
opened,
run
its
course
for
a
while
and
then
died
without
conclusion
multiple
times
during
during
open
telemetry's
existence.
So
if
you
have
more
fuel
to
add
to
that,
then
I'm
sure
you
can
dig
out
the
issue
from
the
spec
and
add
your
two
cents.
A
There's
there
you
know
we're
we're,
making
great
progress
now
on
the
open,
telemetry
immigration
internally,
so
we're
we
may
have
strong
feelings
very
soon,
we're
starting
to
starting
to
get
up
yeah
anything
else.
We.
A
C
It's
nothing
for
me
over
time.
So,
like
I
don't
want
to
tighten
up,
I
think
like
what's
left
is
waiting
for
francis
to
teach
me
about
creating
efficient
code
and
then
I
won't
the
install
messages.
C
I
won't
lock
the
the
rc2
on
the
context
thing
I
will
and
then
once
that's
in,
I
will
put
together
an
rc
and
it'll
be
kind
of
crazy
because
we've
deviated
from
the
lock
step
versioning
across
all
instrumentation,
so
I'm
going
to
have
to
probably
run
a
script,
follow
the
versions
and
make
sure
things
are
pumped
properly
and
then
do
the
release.
So
I
I
will
do
that
once
the
context
is
merged.
A
Query
the
active
job
stuff
that
we
merged
should
I
open
a
release
request
for
that
gym
because
I
don't
think
we
released
it.
C
B
Cool
works
for
me:
cool,
okay,
thanks
for
a
good
time,
see
you
all
next
tuesday,
if
let's
converse
and
slack
about
what
happens
in
the
future,
when
we
can't
have
folks
represented
at
the
specific
meetings,
I
don't
know
if
we
can
set
up
a
rotation
where
one
person's
not
stuck
doing
it
all
the
time.
It'd
be
nice
to
hear
back
about
it,
but.
A
My
god
so
actually
the
real
question
about
code
spaces.
You
said:
you'd
used
it
for
open,
telemetry,
ruby
development.
Yeah
did
you
have
to
do
any
special
setup
for
that,
or
is
there
any
anything
that
we
could
because
we
could
make
like
if
there's
a,
we
need
to
make
like
a.