►
From YouTube: 2021-01-26 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
Hello,
andrew
and
I
are
here
from
github
and
we
are
just
flies
on
the
wall,
so
don't
mind
us,
we're
here
to
learn
a
little
bit
more
about
progress
on
the
ruby
sdk
and
you
know,
because
we
just
started
experimenting
with
it,
so
we're
looking
to
see
how
we
can
help
in
any
way.
Awesome
sounds.
B
B
D
E
E
Oh
yeah,
I'm
hanging
in
snowing
here,
so
it's
nice.
E
Oh
my
wow
minus
twice,
I
don't
even
know
I
forgot
celsius.
The
minute
I
left
europe.
I
read
daniel's
very
good
blog
post
this
weekend
on
gcp
cloud
events
thanks
for
posting
that
daniel
he's
not.
F
F
We're
at
our
usual
time
see
we
can
get
started.
I
do
see
that
we
have
a
couple
of
new
faces,
at
least
new.
B
Yes,
I'm
sorry
that
I'm
not
showing
my
face,
I
am
ariel
valenting.
I
work
at
github
and
my
teammate
andrew
is
also
here
and
we've
been
experimenting
a
bit
with
the
hotel,
ruby
sdk
on
a
small
project,
we're
trying
to
get
it
all
working
and
we
are
customers
of
lightstep
right
matt.
Are
you?
Do
you
work
at
lights
up.
F
B
Yeah
so
so
we've
been
working
with
austin,
basically
trying
to
get
the
ball
rolling,
but
we're
also
looking
to
contribute
in
any
way
that
we
can
and
help
in
any
way
that
we
can
and
in
particular
keen
on
getting
involved
on
the
metric
side.
So
listen.
B
F
No,
that's
that's
totally
cool!
It's
it's
great
that
you
all
have
showed
up.
It's.
It's
always
exciting:
to
have
users
here
and
potential
contributors.
So
please
please
come
to
meetings.
Ask
questions
everything.
F
So
yeah,
typically
I'll,
there's
a
spec,
a
spec
sig
specification
thing
that
happens
before
this.
F
So
typically,
I
just
kind
of
try
to
give
a
quick
summary
of
that
and
generally
the
stuff
that
happens
at
the
spec
sig
trickles
into
our
sig
as
as
work,
so
that's
kind
of
where,
where
the
decisions
get
made,
so
I
just
kind
of
resurface
them
here
to
make
sure
there's
no
concerns
with
the
direction
of
stuff,
and
if
there
is,
then
we
kind
of
so
I'll
go
through
a
quick
summary
of
that
and
then
we'll
kind
of
move
on
to
things
that
pertain
more
to
the
ruby
project.
B
We
are
not
coming
with
questions.
Thank
you
very
much.
Somebody
addressed
one
of
the
issues
that
we
ran
into
we're
getting
bootstrapped
and
austin
help
didn't
relate
it
to
the
team,
we'll
learn
more
as
we
go,
so
we
just
want
to
listen
in
on
this.
This
run,
hopefully
we'll
have
some
questions
for
y'all
next
time.
F
F
F
Jbcd
has
written
up
a
document,
I
think
for
this
first
issue
and
I
think
the
call
was
to
have
have
people
read
this
and
comment.
The
story
here
is
that
I
think
it
was
two
weeks
ago
there
was
a
it's
kind
of
an
all-day
metrics
meeting.
It
was
on
a
friday.
I
know
eric
was
there
and
basically
a
lot
of
people
in
the
community
who
are
various
wants
and
needs
in
the
metrics
world
kind
of
met
up,
and
I
think
there
is
some.
F
Some
desire
to
improve
change
and
make
the
the
current
open
telemetry
metrics
model
a
little
bit
more
usable,
so
I
believe,
almost
is
kind
of
part
of
of
that
mission,
so
the
metrics
there
is
like
a
metrics
working
group.
I
think
that
meets
on
thursday.
So
I
think
that
this
was
discussed
there,
but
at
the
specs
thing
was
for
other
people
who
are
interested
to
take
a
look
at
this
and
continue
the
conversation.
F
F
F
G
E
E
Do
you
know
if
there's
any
road
map
around
documentation
of
some
of
these,
like
things
like
a
resource
detection,
processor
or
like
examples
of
some
of
these,
I
know
for
us
personally
k.
The
k-8
processor
is
just
like
very
poorly
documented
and
it's
the
actual
hotel
docs
are
like
feel
like
they
haven't
been
touched
in,
like
the
community
docs
feel
like
sorely
in
need
of
an
update.
You
know
if
there's
any
it's
like.
E
I
see
all
these
issues
and
spec
stuff
around
like
some
of
these
processors,
but
it's
really
hard
to
find
actual
example
usages
or
like
clear
documentation
of
them.
Do
you
know
if
that's
something
that's
like
coming
after
1.0
or
not
at
all
or
any
discussion?
Maybe
it's
just
been
me.
F
Yeah,
I
don't
know
anything
about
the
state
of
documentation
and,
in
general,
I
kind
of
have
run
into
the
same
things.
I
think
that
you
have
where.
Basically,
as
far
as
I
know,
there
are
resource
semantic
conventions
and
I
think
ad
hockly
people
end
up
making
a
detector
for
self
of
those
resources
right
and
like
it
doesn't
seem
like.
F
There
has
been
like
a
well
plan
behind
all
those,
and
I
feel
like
the
offerings
between
different
different
language,
segs
slash
the
collector,
they
all
kind
of
vary,
and
I
feel
like
the
work
has
generally
not
been
super
well
coordinated
there.
So
this
might
might
be
something
worth
kind
of
bringing
up.
E
E
F
No,
no,
that
makes
sense,
and
I
think
you
know
this
issue
is
in
a
way
related,
but
in
general
I
think
there.
It
would
be
great
if
there's
some
standardization
and
standardization
and
exactly
what
was
collected
and
how
that
should
be
organized
like
at
a
code
level
and
anything
that
you
would
like
to
do.
That
datadog
would
like
to
do.
That
would
be
well.
F
The
next
thing
we
really
got
into
is
this
discussion
about
client
server
stands
producer
consumer.
I
know
this
is
stuff
that
we've
about
and
basically
the
the
core
issue
is
that
I
guess
the
question
was
the
spec
seems
to
indicate
that
for
for
two
sides
of
a
level
request,
you
should
have
a
span
as
the
client
span
and
a
span.
That
is
the
server
span.
F
F
So
there
are
multiple
things
that
might
think
they
are
the
server's
van
and
there
are
multiple
things
that
might
think
they
are
the
client,
so
examples
that
we
have
and
the
you
know,
rack
might
think
it's
the
servers
then
it
probably
is
rails,
might
also
think
it's
the
servers
which
it
probably
isn't.
If
rack
is
really
the
server's
fat,
you
get
similar
situation
for
that,
http
and
and
ferris,
which
one
is
really
the
clients
fan.
F
So
we've
we've
worked
around
this
in
ruby
to
make
this
to
make
this
all
work
out,
but
I
think
other
languages
are
strong.
The
fact
that
competing
instrumentation
has
the
tendency
to
try
to
produce
like
nested
servers,
fans
or
nested
clients,
fans,
and
that
is,
is
a
bit
of
a
problem,
and
it
was
a
problem
that
we
had
at
one
point
and
then
so
that
was
part
of
the
discussion.
F
I
think
the
discussion
kind
of
continued
this
example
here
of
coming
from
java,
but
you
have
multiple
nestings
of
this
git
call
with
the
client
library
and
then
kind
of
tcp
stack,
opening
a
socket,
tcp
stack
requests,
a
dns
lookup
negotiates
tls,
so
I
at
least
mentioned
some
of
these
things
seem
like
you
probably
won't
want
to
stand
for
all
these
things.
Some
of
these
things,
you
might
actually
want
events
for
them,
so
it
was
really
good.
F
I
think
other
sigs
are
encountering
this
stuff
and
the
big
takeaway
is
that
everybody's
doing
something
different,
and
nobody
knows
what
the
right
thing
to
do
is.
So
I
think
this
is
recognized,
and
I
know
they
want
to
kind
of
spin
up
a
working
group
to
kind
of
figure
out
how
to
solve
some
of
these
problems,
just
so
that
the
different
languages
aren't
all
doing
their
own
thing
here.
F
F
I
think
this
is
unlikely
to
be
something
that
is
done
quickly
or
would
block
like
a
1.0,
but
I
don't
know,
I
think
things
are.
E
So
so
is
the
implication
like
I
guess
is
the
concern
around
like
you
can't
do
pure
service
stuff
if
this
isn't
clearly
defined.
What
like,
what's
the?
Why
does
this
need
to
be?
It's
just
part
of
the
specification
that
you
need
to
have
a
client
and
matching
one,
a
one-to-one
relationship,
or
is
there
any
tagging
or
anything,
that's
like
broken
by
not
having
a
clear
one-to-one
relationship
or
is
it
just
because.
F
I
think
they're
struggling
with
this
a
lot
and
wanted
some
clarification,
but
I
do
think
that
they're
that
tracing
back
ends,
a
lot
of
them
depend
on
this
being
one-to-one.
Otherwise
things
things
tend
to.
E
F
Unfortunately,
like
I
kind
of
am
I'm
aligned
with
this
in
principle,
but
the
choices
made
for
which
were
optional
basically
meant
that
ruby
has
none
of
the
required
exporters.
All
of
ours
are
the
optional
ones.
So
for
jaeger
thrift
was
optional,
wasn't
listed
to
be
optional,
but
grpc
was
listed
as
being
required
and
for
otlp
it
was
kind
of
the
same
thing.
Grpc
was
listed
as
required
and
everything
else
is
optional.
F
We
have
proto
over
http,
so
it's
really
hard
to
make
sense
of
the
stiff,
but
this
became
the
optional
column,
and
these
green
x's
mean
optional.
F
F
Transport,
I
think
people
people
were
open
to
the
what.
E
F
I
think
that's
definitely
true
the
more
formats
that
you
have,
the
more
that
you
support
the
harder
it
becomes
to
configure
them,
and
I
think
I
think
we
run
into
this
regularly
actually,
especially
for
like
otlp
exporters.
It's
like
we're
trying
to
kind
of
like
have
a
set
of
environment
variables
that
make
sense,
and
some
of
them
kind
of
only
apply
to
the
grpc
and
some
by
a
little
bit
more
to
the
http.
F
But
yeah
I
was
at
least
lobbying.
I
I
I
don't
know.
I
guess
we
can
talk
about
this
but,
like
I
was
really
vlogging
on
behalf
of
ruby.
I
don't
think
we
want
to
remake
a
exporter.
I
think
you
know
the
thrift
one.
We
have
works
for
most
people,
so
it
would
be
nice
if,
if
we
could
just
leave
that,
as
is.
C
Yeah,
I
think,
for
ruby.
Our
our
issue
is
well
our
concern,
I
guess,
is
being
grpc
and
like
how
stable
grpc
is
in
ruby,
particularly
with
things
like
preforking
web
servers
and
so
forth.
So
that's
that's
led
to
our
preference,
at
least
at
shopify,
our
preference
to
implement
the
protobuf
http
exporter
for
otlp
and
the
thrift
encoding
for
jaeger.
F
I
think
yeah,
I
think
it's
a
very
reasonable
choice
for
ruby,
and
I
don't
know
if
we're
like
the
only
language
in
this
boat.
I
guess
where
grpc
might
not
be
like
the
the
number
one
choice
for
some
of
these
things,
so
in
general
I
think
this
is
okay.
I
think
people
are
will
probably
provide
the
exceptions
for.
F
F
It
was
the
the
local.
F
Environment
variable
so
hotel
exporter,
otlp
protocol,
so
this
was
meant
to
be
grpc,
proto-over,
http
or
json
or
http
and
in
general
most
languages.
I
think
that
have
support
for
multiple
transports.
They
ship
these
as
separate
packages.
F
F
But
that
was
the
discussion
that
took
place.
F
And
then
the
last
thing
I
kind
of
brought
up,
I
know
we
talked
about.
I
think
this
was
a
thing
that
you
ran
into
eric
and
it's
just
like
the
usability
of
the
span
processing
pipeline
and
right
now
we
have
our
batch
fan,
processor
or
simple
span
processor
and
the
span
processor
pipeline
works
well
for
those
things,
but
anything
where
you
want
to
like
modify
a
span
going
through
the
pipeline.
F
B
F
Their
their
feeling
was
that
the
they
got
spam
processor
to
be
kind
of
like
a
mobile
working
span
processor,
but
they
agree
that
it's
not
a
super
usable
state
but
good
enough
for
1.0,
because
we
are
kind
of
at
that
point
where
I
don't
know
like
there
are
so
many
things
that
could
be
improved,
but
at
some
point
we
need
to
decide
to
move
forward
with
what
we
have
and
improve
things
later,
and
I
think
this
is
the
thing.
That's
definitely
on
people's
mind
as
a
post,
one
improvement.
F
F
Quick
at
our
multi-span
processor,
like
I
was
thinking
like
what,
if
I
wanted
to
have
this
chain
where
I
had
just
one
span-
processor
added
baggage,
attributes
and
then
another
span
processor.
That
filtered
attributes
like
this
is
not
easy
for
us
to
do
with
our
multi-spanner.
F
One
readable
span
that
this
generator
is
found
to
each
processor
independently.
F
It
does
not
kind
of
pass
the
result
of
one
processor
to
the
next
see
how
you
could
set
up
like
in
the
pipeline
that
modify
the
span
and
to
see
if
it
had
anything
to
say
about
this-
and
I
didn't
see
it
talk
about
in
maltese
fans
at
all.
I
might
have
been
looking
the
wrong
spot,
but
it
seems
like
right
now.
F
We
could
possibly
improve
our
answer
in
in
ruby
if
we
pass
the
result
of
each
processor
to
the
next
one.
You
would
have
this
where
you
would
have
to
duplicate
the
you
have
to
create
a
from
the
one
pass
in.
C
So
I
think
multi-span
processor
was
intended
to
be
a
fan
out
so
when
you're
actually
sending
to
multiple
exporters
from
your
recline
process,.
F
But
yeah
guys,
if
the
multi
span
processor
is
to
have
small
exporters.
F
F
F
C
There's
an
argument
for
actually
removing
those
from
the
sdk
simply
because
they're
not
part
of
the
spec.
Only
the
simple
spam
processor
and
the
batching
processor
are
part
of
the
spec.
C
F
I
just
thought
that
I
would
bring
this
up
because
because
of
the
fact
that
tracing
is
starting
to
reach
like
like
a
1.0
and.
F
D
E
Think
this
should
block
1.0,
it's
an
inconvenience,
not
a
deal
breaker
and
you
know
there.
It's
not
as
though
zero
processing
exists
within
or
zero
yeah
processing
exists
within
a
collector,
that's
sort
of
the
preferred
thing
and
then
also
like
I
don't
know,
I
think
the
optimal
way
to
do
this
is
at
an
instrumentation
level.
You
have
a
hook
at
the
end
of
your
instrumentation,
you
after
request,
before
request
or
whatever.
So
you
have
the
context
of
where
the
span
was
created.
You
can
modify
it.
E
You
know,
whatever
you
want
to
add
some
http
header
on
the
response
for
your.
You
know,
client
spin.
So
it's
like
this
isn't
a
perfect
solution
anyway
or
there's
room
for
improvement
here.
So
I
don't
and
and
yeah
it's
not
as
I
don't
understand
why
it'll
be
blocking
it's
just
a
it's
a
feature
request,
not
a
bug
or
whatever.
E
F
F
F
D
E
Fires
is
having
was
having
a
global
outage.
I
thought
so
it
might
be
me,
I
don't
know
could
be
related,
but
or
maybe
it's
just
a
new
york
thing
but
yeah.
I
think
they
changed.
The
the
password.
Now
is
seven,
seven,
seven,
seven,
seven
on
all
meetings
and
one
of
the
meetings
got
zoom
bombed
or
something
so
they
updated.
The
links,
there's
a
if
you
go
into
this
open,
telemetry,
collector,
getter,
there's
a
message
about
it
from
ted.
F
D
Sounds
good,
so
I
have
a
draft
pr
and
essentially
what
it's
doing
is
what
I
noticed
that
we
have
an
application.
I
was
going
to
put
open
telemetry
into
production
with,
and
I
was
just
running
a
staging
environment
and
I
looked
at
our
spans
and
it
had
only
been
out
for
a
few
minutes
and
there's
hundreds
and
hundreds
of
orphaned,
dr
pops
and
all
sorts
of
venice
fans,
and
so
I
thought
it
might
have
been
the
scheduler
gems
they're
using
sidekick
scheduler,
and
it
turns
out
it's
just
a
combination.
D
So
in
sidekick
there
is
a
unicode
heart
method
that
it's
just,
I
think,
keeping
the
connection
to
redis.
Why
we're
checking
the
redis
connection?
It's
just
like
the
kind
of
like
the
polling
and
then
in,
I
think,
it's
the
launcher
class.
There
is
kind
of
like
I
think,
the
worker
loop,
and
so
the
approach
I
took
there
is
there's
like
a
method.
That's
like
process
one,
and
that
was
one
of
the
really
noisy
ones.
D
D
If
they'd
like
I
know
for
us
in
our
use
case
immediately,
we
want
to
silence
this
because
I
think
one
smaller
application
doing
this
might
be
tolerable,
but
if
we
cut
over
all
of
shopify
and
any
app
that's
using
sidekick
and
all
of
its
job
workers
spamming,
our
our
vendor
with
dr
pop
stands,
isn't
going
to
really
work
very
well
for
us
testing's
kind
of
chaotic.
I
actually
included
the
redis
instrumentation
just
to
have
a
little
bit
more
confidence
in
the
tests.
D
There's
a
lot
of
ugliness
trying
to
test
it
like
most
of
the
ugly
parts
of
this.
This
pr
I'd
say
is
just
in
testing
it
because
it's
not
like
methods
that
you'd
reach
for
yourself,
so
I
had
to
kind
of
dig
into
the
gem
and
force
some
methods
to
be
called
explicitly
that
normally
wouldn't
be
called
that
way.
D
One
of
the
patch
releases
inside
kik
4.2
changes
the
method
definition
of
the
unicode
heartbeat
to
accept
the
key
and
a
value.
I
believe
I
don't
know
how
like
how
we
want
to
do
support
for
that
or
if
we
want
to
support
some
arbitrary
patch
release
for
4.2,
because
the
latest
4.2
is
consistent
with
the
rest
of
the
psychic
releases.
D
I
don't
know,
that's
my
feel
this.
This
overall
pattern
seems
very
similar
to
an
issue
that
we
discussed
last
week
that
came
up
with
delayed
job.
So
when
it's
checking
to
see
if
there's
work,
it's
creating
a
bunch
of
my
sql
spans,
because
my
sql
they
had
the
instrumentation,
but
the
delayed
job
instrumentation
didn't
cover
this
background
work.
So
they
were
just
getting
these
kind
of
orphaned.
My
sequel
spans,
I'm
not
sure
what
you
want
to
call
them,
but
they're
just
like
out
of
context
right.
D
So
I
I
don't
know
if
this
is
the
right
approach.
I
know
with
our
internal
tracing
gem.
We
do
it
a
little
bit
differently
because
we
have
redis
instrumentation
and
we
don't
trace
the
sidekick
background
work,
but
by
default
those
spans
without
the
parents
and
redis
aren't
traced,
they
have
to
have
a
like
a
parent.
Otherwise
they
we
just
ignore
them
and,
as
a
result,
our
the
instrumentation
in
the
spans
it
generates
a
lot
less
noisy.
F
These
brothers,
that
are
not
super
useful
for
well,
it's
not
useful
when
you're
tracing
back
and
flooded
with
them,
I
think,
and
especially
if,
like
the
the
traces,
are
not
interesting,
but
if
you
are
trying
to
kind
of
use
your
back
end
to
kind
of
know
what
the
load
is
on.
F
Your
reticle
become
a
little
bit
more
interesting,
but
I
definitely
see
for
a
lot
of
users,
they're
the
uninteresting
fans
and
on
interesting
trends
and
then
having
the
ability
to
turn
that
off
is
going
to
be
something
people
are
going
to
want
so
like
in
general.
I
think
this
is
fine.
E
Yeah
I
mean
I
agree,
I
think
the
instrumentation
write
it
for
the
users
we
have,
which
is
you
know,
shopify
so,
and
you
know
no,
there
are
there's
others
now
trust
me.
There's
there's
lots
of
bug
tickets.
In
my
in
my
cue
that
I
have
to
work
on
now,
but
yeah,
I
think
it's
fine
to
just
have
it
as
a
config
and
it's
low
value.
E
I
don't
know,
let's
wait
for
someone
to
complain,
it's
my
view.
If
and
then,
when
we
noted
in
the
docs,
what's
the
worst
that
can
happen,
is
we
tell
them
to
flip
on
the
conflict.
E
Yeah,
I
feel
like
we
see
those
the
way
the
back
end
handles
them.
Is
they
probably
don't
take
up
like
they?
They
certainly
they're
going
over
the
wire
or
whatever,
but
they
are
probably
getting
either
sampled
out
at
some
point
or
the
way
they're
displayed
in
the
ui
they're,
not
clogging
up
the
ui,
because
they're
probably
they're,
I
guess
in
the
open,
telemetry
context.
E
It's
called
like
the
operation,
the
span
name,
data
dog
context
would
be
called
the
resource,
which
is
a
terrible
term,
because
now
open
telemetry
is
using
that
term
for
something
completely
different
but
welcome
to
open
source.
So
they
just
kind
of
get
shoved
into
that
little
resource
and
then
you're
not
really
looking
at
it
too
much.
Maybe
it
affects.
E
If
you
look
at
the
overall
service
latency,
it
probably
drops
the
latency
of
the
overall
reta
service,
but
yeah
we've
seen
that
also
with
you
see
it
with
rails,
making
some
connections
with
the
database
on
startup
some
they're
like
relatively
low
value
spans.
So
I
think
we'd
all
see
it
in
a
bunch
of
instrumentations.
E
If
we
can,
if
we
know
it
ahead
of
time
and
can
prevent
it
or
at
least
hide
it
by
default,
I
think
it's
probably
better
than
because
we
just
don't
know.
I
don't
know
I
just
don't
want
to
live
in
a
world
where
we're.
If,
especially,
if
there's
a
vendor,
that's
charging
on
ingest
or
something
it
would
feel
like
a
really
crummy
way
to
to
a
crummy
experience.
D
This
information,
like
by
all
means,
turn
it
on
and
just
think
it
provides
a
healthier
default
and
a
better
startup
experience
right
and
that's
to
say,
like
I
don't
think
I've
covered
every
single
redis
fan
that
comes
out
of
sidekick,
but
these
are
targeting
the
the
exceptionally
noisy
ones,
like,
I
think,
with
sidekick
launches,
there's
still
a
few
spans
that
pop
up
that
are
not
accounted
for,
but
it's
a
lot
more
reasonable.
D
I
tested
this
kind
of
in
tandem
with
just
like
a
rails,
app
just
idling
and
then
one
with
like
a
scheduled
job
and
cure
and
with
what
I
have
here
in
an
internal
sidekick,
scheduler
instrumentation
that
I'll
push
up.
Eventually,
you
you
see
just
like
the
idle
spans
you
see
like
the
eq,
the
heartbeat
and
then
the
process,
one
which
is
just
the
worker
loop,
trying
to
cue
a
job.
If
there
is
one.
E
Yeah
yeah,
we
don't
even
have
datarock,
doesn't
even
have
the
concept
this
this
untraced
convenience
method.
We
don't
really
have
that.
It
would
be
it's
a
good
feature
to
have,
and
I
think
this
is
a
good
use
case
like
this
is
a
good
example
of
its
use
case.
So
yeah.
I
think
I'm
fine
with
it.
I
haven't
reviewed
anything.
B
E
Like
three
weeks,
so
it's
not
as
if
I've,
but
I
can
certainly
leave
a
comment
to
that
effect
on
that.
E
Yeah
I
mean
I
tend
to
think
it's
important
to
have
we're
gonna
hit
this
in
the
future,
with
whatever
it
is
frameworks
that
depend
on
rack.
You
want
to
test
that.
There's
a
behavior,
you
know
the
rails
span
on
the
rackspads
are
interacting,
so
I
think
it's
okay
to
have
multiple
instrumentations.
E
I
don't
it's
all.
I'm
also
coming
from
a
place
where
it's
a
monorepo
versus
this,
which
is
separate
gems.
So
I
don't
know
like
that,
might
add
a
little
bit
of
complexity.
Maybe
split
the
reddest
things
into
a
separate
file.
Like
would
be
my
only
thought,
but
I
think
it's
useful
to
have
like
testing
sort
of
like
integrations
to
like
integration
level
tests
for
instrumentations.
If
that's
the
right
way
to
phrase
it,
I
don't
know
what
does
everyone
else
think.
F
Yeah
all
this
is
good,
so
I'll
keep
an
eye
on
it
when
it
comes
out
of
draft.
D
Actually,
if
you
just
want
to
go
back
to
the
instrumentation
install
code,
there
instrumentation
rv-
I
don't
know
if
this
is-
I
feel
like.
I
should
know
this,
but
I'm
going
to
ask
online
30
what
I'm
patching
doesn't
get
auto
required
when
you
load
the
gem,
it's
part
of
like
sidekick's
boot
up,
so
I'm
explicitly
requiring
the
sidekick
launcher
is
that
is
that
a
bad
idea?
I
don't,
I
think
it's
fine.
E
D
It
just
checks
to
see
if,
like
a
certain
like
something's
defined,
and
then
it
patches
the
classes
and
they're
available.
But
that's
not
the
case
here,
because
the
code
that's
being
instrumented,
now
gets
loaded
by
like
the
sidekick
process.
When
you
run
it,
it's
like
different
than
like
the
client
that
you
used
in
cube
jobs
in
like
a
rails.
C
It
was
working,
it
is
weird
right,
so
yeah
do
you
have
any
hooks
in
sidekick
that
would
allow
you
to
patch
this
after
it's
loaded,
there's
one
question:
the
concern
is
that
you're
going
to
be
pulling
this
in
and
patching
it
even
in
things
that
are
not
running
the
psychic
workers,
so
psychic
clients
are
also
going
to
be
loading,
the
sidekick
launcher
and
is
that
problematic,
other
side
effects
from
doing
that.
D
Yeah,
so
I
don't
know
if
it's
problematic
so
I'd
like
to
try
to
avoid
it
I'll
look
to
see,
because
I
think
there
are
some
configuration
hooks
with
sidekick
so
I'll
see
if
I
could
find
like,
maybe
like
some
sort
of
onload
hook
and
see
if
I
can
go
that
route.
D
I'll
leave
a
comment
on
that
line
with
whatever
I
come
up
with
after
I've
spent
more
time
on
it.
But
I
just
want
to
like
flag
that
now
because
it
doesn't
seem
quite
right.
F
E
Yeah,
I
don't
have
a
ton
of
that.
The
vendor
approach,
we're
taking
is
is
adding
middleware
to
the
server
and
client,
which
is
different
than
the
the
polar
and
the
like
the
launcher.
So
I
don't
have
a
ton
of.
I
think
what
francis
said
is
right,
which
is,
if
there's
a
way,
if
there's
something
we
can
check
to
sort
of
like
in
an
within
psychic
or
quick
and
psychic.
That
would.
E
D
F
F
I
think
one
of
the
one
of
the
gotchas
is
ci
systems
might
have
trouble
depending
on
how
they've
been
built,
but
this
is
a
thing
that
we
should
try
to
address
soon.
If
we
can.
G
I
just
went
through
renaming
the
default
branch
for
some
other
similar
repos
of
the
the
cloud
events
sdk
for
ruby.
I
just
did
that
renamed
yesterday
went
seemed
to
go
really
smoothly.
G
The
it
uses
the
same
mechanisms
for
releases,
the
the
same
scripts
and
stuff
that
we're
using
for
open,
telemetry,
there's,
there's
one
configuration
and
that
script
that
needs
to
change
along
with
the
along
with
three
name,
but
it's
in
one
place.
I
know
where
it
is
ci
seem
to
work
fine.
As
long
as
you
change
since
we're
using
github
actions,
I
think
we
might
have
some
places
where
it's
triggering
off
of
us.
G
You
know
commits
to
a
certain
branch
mr
master
commits,
so
so
a
couple
of
things
like
that
needs
to
change,
but
but
yeah
I've
gone
through
the
process
for
a
couple
of
repos
now.
So
I
think
I
know
where
those
things
are.
G
And
assigned
it
to
you
so
yeah,
I
think
you
would
mind
yeah,
so
I
totally
be
find
just
doing
the
doing
the
change.
If,
if
people
are
okay
with
that,
is
there
a
particular
time
or
you
know
day
where
that
that
we
want
to
do
it
there
there
are.
G
There
is
this
process
for
people's
local
local
clones,
where
you
would
need
to
change
the
the
branch
on
your
local,
clone
and
and
point
those
back
at
the
you
know
the
the
change
branches
upstream
at
github-
and
you
know
the
the
commands
are
right.
There
there's
actually
one
additional
thing
that
I
sometimes
run
into,
which
is
the
the
head
for
the
for
the
upstream.
You
might
need
to
set
head
for
for
some
of
your
remotes.
G
If
you
have
that
set
up,
but
anyway,
there's
there's
there's
there
is
a
process
that
you
might
need
to
do
for
your
local
clone.
So
I
don't
want
to
do
this
while
someone
is
like
has
all
their
stuff
on
the
floor
and
they're
they're
trying
to
get
something
done
so.
C
It
doesn't
bother
me
so
whenever
you
yeah,
like
I'm,
not
blocking
this
at
all
yeah
same
here
just.
G
Yeah
save
me:
oh
okay,
I'll
go
ahead
and
do
it
today,
then,
if
that's
okay
with
people
I'll
send
I'll
post
something
on
the
getter
and
try
to
communicate
out
to
pr
owners
that
this
is
happening.
F
We
are
at
time
anything
last
minute.
Anybody
just
want
to
pop
up.
B
I'm
curious
about
a
lot
of
things
that
I'm
gonna
learn
more
as
I
as
we
move
further
along
in
our
project
than
our
like
initial
spike.
So
that
was
curious.
I
was
curious
to
hear
about
the
problems
that
you
were
facing
now
with,
for
example
like
trying
to
hook
in
tracing
into
the
sidekick
launcher
process.
B
That
was
a
interesting
problem
I
was
like,
while
you
all
were
talking
about
it.
I
was
just
searching
around
to
see
how
other
plugins
work
with
sidekick
and
how
they,
if,
if
they
inject
stuff
into
it
and
the
rename
the
branch
rename
project
I'll
keep
an
eye
out
for
those
pr's
provide
some
suggestions,
if
I
see
anything
in
there,
but
a
lot
of
this
was
very
clear.
So
I
appreciate
that
thanks
for
letting
me
listen
in
my
first
time.
F
Yeah
no
problem
have
you,
you
had
a
last-minute
topic.
C
Yeah
sorry,
I
just
wanted
to
flag
that
we
have
a
few
pr's
opened
in
the
last
week
that
could
probably
use
some
attention.
The
other
francis
has
his
jaeger
propagator.
I
yeah.
I
think
you
probably
have
the
most
context
for
that
matt.
So
it'd
be
great.
If
you
could
take
a
look
at
that,
there's
also
this
discussion
item
around
adding
a
caller
location
for
where
faraday
was
called.
C
I've
commented
on
that
there
was
this
suggestion
from
johnny
shields
that
maybe
we
we
should
just
be
adding
the
caller
location
everywhere,
which
seems
hideously
inefficient,
so
yeah.
I
just
wanted
to
get
some
more
folks.
Looking
at
that,
and
maybe
commenting
on
how
we
might
accommodate
this
particular
issue.
F
Okay,
okay,
yeah,
we'll
do
color
is
expensive
and
should
be
avoided.
Is
my
opinion
so
I'll
be
happy
not
that
it's
not
useful
information.
It's
just
not
it's
not!
It's
not
worth
the
cost.
D
E
Try
to
get
this
is
the
week.
I
do
some
reviews
and
actually
do
be
an
approver.
I've
been
really
bogged
down
in
the
collector.
So
I'm
sorry
about
that
cool.