►
From YouTube: 2019-09-25 Ruby SIG
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
E
That's
dirty.
B
A
Prepubescent
daughter
is
sucking
up
a
lot
of
in
the
household
lately.
C
D
C
E
B
A
C
C
D
F
Yeah
sorry
I
think
we're
actually
in
good
shape,
or
this
is
probably
a
good
time
to
start.
Looking
at
the
dead,
your
dog,
instrumentation
libraries,
the
only
other
thing
is
I,
am
today
I
started
looking
at
Yaga
and
what
it
would
take
to
actually
build
the
de-ager
exporter.
So
that's
any
other
update
I
had
is
there
anything
else?
People
want
to
chat
about
or
just
dive
into,
the
auto
instrumentation.
C
C
David's
got
some
time
to
give
us
so
light.
Step
has
contracted
with
us
to
as
Ted
young
put
it
just
sort
of
try
to
be
a
booster
rocket
to
any
of
the
projects
we
can
do
since
Rubies,
one
of
the
primary
language
he's
working,
we
figured
that'd,
be
a
great
place
to
help
out,
and
we
were
talking
about
people
internally,
who
had
some
time.
David
has
some
time,
and
he
said
in
particular,
I
really
like
to
just
get
into
a
project.
C
G
Well,
so
yeah
I,
don't
know
how
much
looking
any
of
us
have
done
at
at
this
problem.
I've
sure
know:
I've
referenced
an
issue
on
open
telemetry
Ruby
that
opened
a
long
time
ago,
kind
of
like
glaze
out
this
railtie,
like
DSL
and
kind
of
the
whole
idea
behind
that
really
is
ways
to
be
able
to
ship
instrumentation.
That
is
technically
kind
of
separate
from
the
SDK.
You
know
it
separated
from
the
SDK
they
can
live
in
their
own
repos,
but
they
can
be
installed
and
managed
by
the
SDK
like
fairly
simple.
G
Simply
so
I
feel
like
this
is
a
problem
that
I
haven't
actually
seen
any
real
great
solutions
to
like
theta
dog
New
Relic.
G
All
all
of
the
big
APM
providers
have
always
kind
of
shift
their
instrumentation
with
the
SDK,
so
that's
kind
of
the
one,
the
the
thing
that
will
come
kind
of
from
from
that
issue,
but
it
was
all
that
was
kind
of
that
was
written
up
before
the
data
dog
instrumentation
was
donated
so
I
think
in
light
of
all
that,
I
think
like
one
of
the
first
big
questions
is
like.
G
Yeah
I
think
there
are
pros
and
cons,
but
I
think
ultimately,
you're
gonna
have
people
who
want
to
be
able
to
just
pick
and
choose
the
instrumentation
that
they
want
and
only
have
that
for
their
application
and
I
think
that
you're
gonna
have
people
who
are
just
going
to
want
just
install
anything
that
will
work
with
my
app
kind
of
situation
and
I.
Think
I
think
you
saw
both
of
those
with
this
independent
jump
situation.
G
If
you
want
it
just
by
having
one
gem,
that
is
basically
an
omnibus
gem
with
all
the
other
jobs,
a
mega
gem
of
instrumentation
yeah.
C
You
know,
maybe
causes
some
Mikey,
behavior
or
something's,
trying
to
wire
something
up
before
it's
available
or
you
know,
we've
all
lived,
you
know,
III
I
think
it
would
be
nice
to
be
able
to
say
hey
regardless
of
the
mechanism.
You
know
the
specifics
of
let's
use
a
block
or
let's
use
the
rail
tie
idea
or
you
know,
let's
use
something
closer
to
what
the
data
dog
stuff
does.
I,
like
yep
here
right
at
the
top
I,
can
say,
use
this
use.
C
A
A
G
Yeah
and
I
don't
know
like
you
can
read
through
this
rails
high,
like
proposal,
because
I
feel
like
it's,
it's
pretty
lightweight
and
it's
not
actually
that
hard
to
have
both
if
using
something
like
that.
So
basically
the
way
the
way
it
works
is
you
we
would
ship
a
a
an
open,
telemetry,
instrumentation
class
for
each
library,
which
would
presumably
be
jumper
library,
you
subclass
this
class
and
that's
what
kind
of
have
this
DSL
in
it
and
in
that
subclass
this
is
kind
of
the
glue
to
wire
up
the
instrumentation.
It's
not
the
instrumentation
itself.
G
It's
the
thing!
That's
going
to
install
it
and
by
sub-classing
that
class
it
uses
the
inherited
hook
from
Ruby,
and
then
it
just
kind
of
keeps
track.
These
are
all
the
subclasses
and
then
that
essentially
gives
you
this
instrumentation
registry
and
then
at
some
point
early
in
the
program
you
can
run
through
the
registry
and
see
like
what's
compatible,
what's
enabled,
if
so
install
it.
That's
kind
of
in
a
nutshell,
how
that
all
is
expected
to
work
so.
G
We
can
look
at
that.
Looking
at
the
data
dog
instrumentation,
they
kind
of
had
this
patcher
patcher
interface,
which
it's
pretty
similar
in
that
it
has
a
lot
of
the
same
capabilities,
so
I
think
I,
don't
know
if
it
has
from
from
what
I
haven't
looked
deep
enough
to
figure
out
how
they're,
actually
installing
everything
I
somehow
suspect
that
they're,
actually
just
like
looking
in
the
file
structure
of
the
controller
and
installing
from
there
but
I
haven't,
haven't
looked
at
things
that
deeply.
G
But
my
thought
is
if
we
wanted
to
go
out
after
something
like
this,
we
could
probably
merge
the
ideas
in
patcher
and
that
railtie,
like
thing
and
kind
of
come
up
with
the
best
of
both
worlds
and
the
end
goal
of
that
would
be
to
provide
a
and
instrumentation
registry
and
B
just
provide
the
spot.
Where
you
put
your
glue
code
to
glue
up
the
instrumentation
in
terms
of
the
instrumentation
itself.
G
I
think
we
just
use
the
data
dog
instrumentation
as
it
is
just
convert
it
over
to
the
open,
telemetry
API,
so
I
feel,
like
that's
a
little
more
straightforward.
So
the
other
thing
that
I,
at
least
in
my
glance,
through
through
data
dogs
instrumentation
noticed,
was
they
have
kind
of
per
per
instrumentation
configuration.
So
each
one
of
them
has
like
a
configuration
file
in
its
subclasses.
G
Its
subclasses
some
kind
of
data
dog
configuration
class
and
it
also
gets
wired
up
as
part
of
the
kind
of
global
configuration
for
for
for
the
for
the
gem.
It's
like
data
dog,
dot
configuration
and
then
it
kind
of
has
this
hash
and
syntax,
and
you
know
it's
kind
of
like
a
registry
I
think
itself,
so
the
one
I
was
looking
at
was
like
the
RAC
instrumentation
and
if
you
wanted
to
get
access
to
its
configuration,
they
had
a
dog
that
configuration
rack
and
then
that
kind
of
returns
that
object
or
yeah.
G
F
Yeah
we
had
a
bunch
of
questions
about
configuration.
How
we
want
to
do
that
kind
of
feel
like
whatever
we
come
up
with,
should
use
the
same
configuration
mechanism
for
the
SDK,
the
exporters,
at
least
like
the
ones
that
are
part
of
the
open,
telemetry
orgs
are
the
ager
exporter,
for
example,
and
this
kind
of
auto
instrumentation
piece
as
well,
so
that
we're
not
like
configuring
three
separate
pieces.
It's
you
know
in
a
single
block
somewhere
yeah.
G
I
think
that
makes
sense,
so
I
think
one
one
task.
One
action
item
should
be
like
explore
a
configuration
system,
that's
going
to
work
well
for
for
all
these
systems
and
I
think
like
prior
art
to
look
at
will
be
definitely
What's
in
data
dog
right
now,
because
it's
pretty
good
and
I
think
another
thing
to
look
at
is
probably
open,
census,
Ruby
and
kind
of
both,
both
of
them
kind
of
have
a
a
DSL
like
like
structure
to
them.
G
H
C
C
C
C
So
I
don't
know
if
you
took
a
look
at
that
gist,
I
wrote
that
basically
tried
to
exhaust.
You
know
cover
everything,
so
Matt
Francis
what
what
y'all
brought
up
in
the
get
her
channel
so
that
it
might
be
in
a
place
not
in
get
her,
because
that
doesn't
last
I
mean
last
but
kind
of
hard
to
surface
and
came
up
with
this
idea
that
you
know
a
few
of
the
things
we
wanted
to
talk
about
would
be
the
organization
you
know.
How
do
we
want
this
thing
organized
just
at
a
very
basic
level?
C
Where
do
we?
Where
do
we
want
the
code
just
a
reference
back
to
that
sort
of
technical
forking
process
out
of
otep
one,
which
is
that
idea
of
you
know,
fork
basically
fork
the
gym?
Got
the
data
dog,
specific
stuff,
create
the
general
thing
and
then
sort
of
reverse
the
dependency,
so
that
data
dog
depends
on
this
new
thing,
which
I
think
is
like
the
global
idea
behind
this
whole
process.
That
one
is
a
little
interesting
to
me
when
we
get
there,
because
it
has
to
involve
some
people
that
data
dog
but
I
just
I.
C
C
Wiring
I
don't
have
a
strong
opinion
on
the
actual
mechanics
of
that,
so
I
think
I've
seen
the
class
inherited
registry
thing,
I
think
the
ROM
RB
guys
did
that
a
lot
where
they
had
a
lot
of
the
like
extra
things,
sort
of
say:
hey
when
you,
when
you
include
me
I,
basically
say
hey
I'm
here,
you
know
and
you
can
use
me
in
your.
You
know
repository
configuration
stuff
and
you
know
if
we
want
to
use
ESL's
or
just
you
know,
basic
stuff:
I
don't
have
a
strong
opinion
on
that
either
I
know.
C
There's
a
lot
of
stuff.
I've
read
is
that
performance
does
matter
and
a
lot
of
these
cases
so,
for
instance,
I've
seen
some
of
your
PR
comments
where
it's
like
hey
we
could
they
save
ourselves
some
allocations
and
things
like
that,
so
I
would
say
more
than
anything.
It
sounds
like
you
just
want
to
be
light.
You
know,
with
whatever
we
do
in
terms
of
performance
and
then
I
get
same
same
exact
thing
for
configuration,
whether
that's
hey,
we
really
like.
C
We
can
start
with
what
day
doc
has
we
can
retrofit
that
we
can
expand
it
or
contract
it
to
fit
our
needs
and
it
does
it
fit
the
needs
of
the
exporters
attending
of
any
other
efforts
of
the
of
the
code
base
that
that
require
configuration.
Can
we
make
that
more
generally
useful,
I
think
that's
great
and
then
I
think
just
coming
up
with
a
priority
and
Francis
your
idea
of
just
take
an
easy
one
start
with
an
easy
one
is
totally
cool
with
me.
I
wanted
to
make
sure
we
didn't
have
if
any.
C
If
someone
had
like
a
particular
axe
to
grind,
like
you
mentioned
sidekick
and
I,
think
rescue
were
the
two
that
you
were.
Okay,
I
really
want
to
see
how
you're
doing
that
I
can
imagine
your
description
of
you
know
why
you
want
that
so
kind
of
coming
back
to
that
in
that
gist,
I
can
share
that
if
you
want
on
my
screen.
So
everybody's
looking
at
it
I,
don't
I,
you
know,
I
think
we
can
answer
these
questions
pretty
quickly.
For
me,
it's
we
have
been.
We
have
time
allocated.
C
We
have
been
given
this
gift
to
say:
hey
we're,
gonna,
sponsor
your
open
source
contributions,
which
we're
super
excited
about,
and
I
don't
want
to
barge
in
here
and
be
like
hey,
hey,
you
know,
let
me
and
so
I
want
to
start
with
an
issue
that
you
know
was
identified
in
the
priority
list
that
Francis
gave,
which
was
really
helpful.
Thank
you
and
in
our
discussion
with
the
White
step
folks,
yesterday,
I
kind
of
echoed
most
of
this
was
just
we're
here
we
want
up,
we
want
to
contribute.
We
want
to
help
you
out.
C
That
could
also
be.
Can
you
document
that
for
me,
can
you
join
you
just
refine
that
in
a
certain
way,
because
we're
not
experts
in
the
domain
we'll
really
need
your
technical
guidance
to
make
sure
that
we're
doing
the
right
thing
in
the
right
place.
You
know,
but
maybe
that
could
also
sort
of
serve
to
almost
give
you
a
way
to
delegate
a
little
bit
the
actual
work
right
so
Francis.
If
you're
investigating
the
Yeager
exporter,
you
might
say:
here's
some
technical
guidance,
here's
some
here's.
C
C
G
C
C
You
know
Gantt
chart
and
then
I
just
tried
to
put
some
of
the
stuff
in
the
high-level
so
that
we
know
we
were
talking
about.
Also,
you
know
Dave
if
David
were
coming
in
and
maybe
helping
me
out
here
on
this.
You
have
some
context
in
terms
of
the
organization
from
what
we
just
described.
It
sounded
like.
We
had
a
couple
of
options
and
if
I
just
I'll
just
read
through
this-
and
we
can,
we
can
just
kind
of
pick
him
off.
C
The
idea
felt
like
we
had
two
big
pieces
was
created,
Jim
per
per
integration
or
just
have
them
sort
of
built
in
right.
Just
like
you
said
ship
them
with
the
library.
I
just
haven't
been
nestled
in
there
and
it
sound
like
both
of
you
kind
of
had
a
strong
preference
for
the
prior,
like
the
the
former
I
should
say
the
creating
a
gem
per,
even
if
they're
in
the
repo
right
sort
of
mono
repo
style.
G
Couple
advantages
there
I
think
one
is
that
definitely
there
are
going
to
be
people
who
want
that
or
it's
like,
if
you
don't
want
it,
it's
like
you're
gonna
have
to
do
a
lot
of
configuration
to
like
whittle
down.
You
know
these
set
of
instrumentation
to
one
that
you
want,
but
I
think
the
one
the
one
really
big
advantage
you
get
with
this
is
that
somebody
wanted
to
bundle
their
own
thing.
G
G
F
C
So
j/s
kind
of
does
this
thing
where
they
you
don't
know
if
you've
looked
at
it,
but
they've
got
all
their.
You
know
they're
using
Lerna,
so
they
have
some
tooling
to
kind
of
help
with
this
process.
But
the
idea
of
we've
got
our
exporter
sitting
in
here.
We've
got.
You
know
the
this
is
sort
of
everything
we
can,
sir.
You
know
sponsor
and
create
around
this,
which,
which
is
nice
they've
chosen
to
call
these
plugins
I
would
be
fine
with
that
as
well.
C
You
know,
I
think
one
of
the
overarching
goals,
I
kind
of
heard
from
the
community
level
was,
you
know
if
someone's
got
a
good
idea.
Let's,
let's
let's
steal
that
idea
and
and
when
I
move
from
the
JavaScript
world
to
the
Ruby
world.
Can
things
be?
You
know
closed
right?
At
least
I
know
I'm
working
with
the
same
domain
and
kind
of
working
with
the
same
thing.
So
did
you
all
have
kind
of
idea?
Would
you
would
you
see
this
sitting?
C
D
C
G
Think
so
I
think
it
all
bill
doesn't
make
the
top-level
a
little
less
busy
and
you
can
sure
but
I'm
super
flexible
on
this
I
don't
feel
like
I
have
like
really
strong.
F
C
Don't
really
have
a
good
way
to
do
note
so
I'm
just
gonna
make
some
notes
on
paper
here
and
then
I'll
translate
those
to
this
document,
so
Jim
her
and
I
I
think
I
was
looking
just
as
a
semantic
gated
dog
calls
them
integrations
we're
calling
them
sort
of
instrumentations
or
instrument
errs.
What
does
do
you
have
a
term
that
you
prefer
so
that
I
use
think
the
same
thing.
F
Everywhere
I
mean
I.
Like
instrumentation
I
know
there
was
a
debate
around
this
I'm
actually
trying
to
find
the
issue.
There
was
a
debate
around
what
exactly
this
stuff
would
be
called
pretty
early
on
in
the
project
and
I
just
Oh
I'll
dig
it
out
and
see
kind
of
where
we
got
to
in
naming
all.
C
Okay,
so
I,
that's
great!
That
gives
us
a
home
for
the
for
the
code.
We
don't
have
to
I
think
exhaustively
talk
about
the
technical
forking
process,
but
my
questions
were
kind
of
like
I
mentioned
at
the
beginning,
I,
don't
this
doesn't
feel
like
that.
What
this
doesn't
should
say
this.
The
forking
process
doesn't
feel
like
what
we're
doing
right
now
right.
C
We
we're
saying,
let's,
let's
sort
of
absorb
the
the
auto
instrumentation
work,
the
data
dog
has,
but
we're
not
necessarily
focused
on
being
able
to
have
that
library
depend
on
this
work
right
now
right.
It's
not
sort
of
a
we're,
not
we're
not
sort
of
making
that
fork
today.
Does
that
just
assume
right
so.
G
Gen
per
library
for
an
education
scheme
and
then
make
this
gem
that
has
all
the
instrumentation
and
furthermore
make
this
kind
of
instrumentation
registry
thing,
and
at
that
point
they
can,
they
can
depend
on
that.
Gem
and
I
think
the
registry
part
I,
would
see
being
part
of
the
open,
telemetry,
API
I
think
the
actual
install
method
that
does
the
installing
should
be
part
of
the
SDK,
and
we
can
talk
about
that
a
little
bit
more
but
like
they
could
just
depend
on
that.
C
So
sort
of
drop
into
you
know
where
they
have
in
data
dog,
where
they're
you
know
iterating
over
their
list
of
available
instrumentations
or
you
know,
whatever
whatever
that
happens,
to
be
and
say
instead,
I'm
gonna,
I'm
gonna,
you
know,
depend
on
this
open,
telemetry,
omnibus
something
or
other
I'm
gonna
bring
it
in
I'm
gonna.
Look
at
the
registry
and
use
that
as
my
sort
of
list
of
things
that
are
available
to
configure
to
auto,
configure
and
install
so
they
would
have
their
own
installation
code
just
like
our
SDK
would
have
its
own
installation
code.
C
G
And
so
I
mean-
and
that's
only
I
think
where
the
installation
code
resides
up
to
debate,
because
I
could
still
see
this
being
something
that
it
could
be
something
that
is
so
Universal
that
it
could
be
part
of
the
API.
It's
just
like
yeah
all
right,
but
it
could
be
something
unique
enough
where
SDK
is
want
to
have
like
a
little
bit
more
control
over
the
approach.
Yeah
I
definitely
think
deep.
G
G
F
G
Ultimately,
down
the
line,
if
they're
going
to
use
this
instrumentation,
they
have
to
their
SD,
they
need
to
be
in
implementation
of
the
open,
telemetry
API.
It's
that
fair
to
thing.
F
C
Think
what
you're
basically
saying
is,
if
we
do
this
right,
we'll
be
providing
a
thing
that
and
from
what
I
heard
yesterday,
a
lot
of
the
data
dog
stuff
is
already
depending
on
open
tracing.
Yes
like
like
so
you
know,
possibly
with
shims
and
other
things.
It
might
be
a
little
more
straightforward,
but
it
sounds
like
while
that
otep
describes
this
exact
process,
and
we
may
do
that
fork
to
propose
the
way
that
DD
trace,
for
instance,
could
depend
upon
Oh.
C
Tell
Ruby,
that's
that's
something
that,
as
we
flesh
this
out
and
we
become
more
compliant
right
with
the
with
different
specifications.
You
you're
basically
saying
at
certain
point
we
could
just
say
look
rather
than
depending
on
the
thing
you
have.
You
could
depend
on
this
and
then
you
could
plug
in
your
own
exporters
or
whatever.
C
Or
what
have
you
so
that
you
get
everything
you
had
before
without
specifically
saying:
let's,
like
the
data
dog
thing
would
have
been
nice
if
we
were
starting
fresh
and
didn't
have
all
of
this
in
the
sense
that
we
could
have
worked
it
and
said:
oh
look!
What
we
get
for
free!
Let's
take
the
data
dog
guts
out
and
kind
of
set
them
aside.
You
know
we
could
have
done
a
little
more
of
that,
but
since
we
are
already
down
the
road
on
the
the
other
implementation,
we
could
basically
say
use
this.
Instead.
F
Think
you
probably
need
to
have
a
conversation
with
data
dog
right.
What
their
expectation
is.
Are
they
expecting
to
continue
maintaining
their
own
SDK
and
somehow
make
that
compliant
with
open
telemetry,
or
are
they
looking
to
basically
have
a
shim
over
the
top
of
the
open,
telemetry
SDK,
in
the
same
way
that
we're
building
shims
for
like
open
senses
and
open
tracings
I
can.
H
Partially
answer
that
question
also
hey
guys,
I
read
it
the
ground
and
the
JavaScript
stuff
has
been
going
swimmingly
well
and
so
I
think
I'd
start
spending
some
more
time,
helping
vo
so
yeah,
yes,
so
I
think
a
big
part,
so
I
think
partly
abet
is
like
anyway.
Data
dog
doesn't
want
to
maintain
their
own
agents
anymore,
which
is
why,
which
is
like
partially
like
one
of
the
benefits
that
they
want
to
get
out
of
like
open
sourcing
it
where
they
can
like.
H
G
So
would
they
use
kind
of
the
reference,
implementation,
SDK
and
basically
export
to
data
dog,
or
would
they
I
think.
H
G
I
think
either
way
kind
of
the
thing
that
we're
proposing
there
will
be.
There
will
be
a
path
for
that
I
think,
but
we
should
definitely
engage
with
them
just
to
make
sure
just
to
know
as
early
as
possible
what
what
their
expectations
are
around
this
just
to
make
sure
that
we
meet
them.
So.
F
Looping
back
to
one
of
I,
don't
pose
a
question
or
not,
but
given
that
data
dogs
instrumentation
is
written
on
top
of
or
written
to,
the
open
tracing
spec
to
some
extent
like
an
easy
path
forward,
is
to
just
write
the
open,
tracing
shim
and
then
write
the
instrumentation
in
terms
of
the
open
tracing
shim.
I
prefer
not
to
do
that.
That's
probably
going
to
have
some
additional
overhead
I'd
rather
write
the
instrumentation
directly
to
the
open,
telemetry
API.
G
G
C
Yes,
a
Pierre
sort
of
the
organization
stuff,
I
I
was
thinking
more
of
the
maintenance
overhead
in
terms
of
yeah
like
if
we
had
Jim.
If
we
have
basically
because
I
I
was
I'm,
not
a
fan
of
like
little
tiny
gem
sitting
in
their
own
repose.
Just
because
of
that
overhead
would
be
nightmarish,
I
think
at
this
stage
in
the
project.
So
it
was
that
but
but
maybe
also
there's
the
performance
overhead
of
these
kinds
of
things.
G
C
Just
to
kind
of
draw
draw
the
technical,
forking
question
to
not
really
to
a
close
but
I
I'm,
just
keeping
some
notes
and
then
Francis
I
can
suggest
those
to
the
agenda.
Just
so
I'm
just
sketching
him
down
really
fast,
but
eventually
we
feel
like
DD
tres
could
depend
on
Motel
Ruby.
Would
we
want
to
engage
with
data
doggone
how
to
move
forward
and
really
find
out?
What
are
their
expectations?
Are
they
expecting
to
maintain
theirs
Brandon?
We
think
you've
added
some
color
to
that
which
is
probably
not
right.
C
The
idea
is,
let's
get
out
from
under
this.
If
there's
a
larger
community
here
doing
this
kind
of
thing
we
can.
We
can
leverage
that
and
also
sort
of
help
them
by
providing
our
code
and
then
also
some
questions
around.
Are
we
interested
in
like
shim
or
rewriting
that
tooling,
so
that
it's
speaking
directly
the
you
know
tor
to
the
direct
API?
Does
that
sound?
Like
the
couple
things
we
discussed?
C
Okay
on
the
installation,
wiring
I
feel,
like
Matt,
would
kind
of
jump
to
that
one.
So
we
we
basically
have
answered
most
of
my
questions
there,
but
the
idea
you
know
DD
tres
has
a
bunch
of
installation
of
wiring.
We
know
I,
think
Francis,
I
think
I
distilled
this
down,
but
essentially
it's
like
whatever
we
provide
back
today
to
dog,
we'll
need
something
like
this
and
I.
Think
Matt,
that's
what
you
identified,
which
was
whether
they're
looking
to
the
registry
or
their.
You
know
Otto
inflating
a
bunch
of
classic.
C
We
don't
know
yet,
but
we
know
that
they'll
need
some
mechanism
mechanism
to
hook
up
this
stuff
to
and
then
I
just
captured
a
note
here
about
sort
of
the
prevalence
of
the
auto
wiring.
It
Shopify
right.
There's
a
lot
there's
a
lot
more
of
that
than
the
other,
but
there
still
is
the
other.
So
we
want
to
consider
both
both
use
cases
and
then
Matt
I
wanted
to
also
just
sort
of
you
know.
Mention
I
have
your
notes
in
here
about
the
issue.
C
You
have
open
nineteen,
which
talks
about
the
slightly
different
approach
and
and
sort
of
your
comment,
which
I
think
you've
said
multiple
times
now,
which
is
look
if
we're
gonna.
Do
that?
Let's,
let's
look
at
both
and
see.
Are
there
ideas
from
from
both
that
would
work?
Can
we
can
we
sort
of
bring
in
what
you
have
and
use
the
other
things
or
you
know,
maybe
with
terms
and
or
you
know
how
we
wire
that
up.
C
So
most
of
my
questions
here
have
been
answered,
so
you
know,
you've
said
how
you
want
to
have
it
installed.
We
might
port
over
some
of
their
code.
My
question
about
sort
of
being
iterative
is:
can
we
sort
of
have
something
that
works
for
now
and
then
improve
on
that,
and
it
looks
like
that
seems
to
be
the
general
approach
anyways,
we
want
opt
in
or
opt
out
right,
so
we
want
to
be
able
to
say
yes
sign
me
up,
no
don't,
and
that
might
be
man
I.
C
Think
if
I'm
here
you
quickly,
you
might
say,
look
if
you
bring
in
this
big
gym.
You
can
get
access
to
all
these
things.
That
might
also
come
with
the
ability
to
have
them
on
a
wired
up,
or
you
know
something
like
that,
and
then
I
had
mentioned
sort
of
the
pros
and
cons,
but
I,
don't
think
that's
necessarily
a
big
deal.
C
Seeing
is
how
we
want
both
it's
largely
it's
and
then
just
I
might
poke
around
and
just
see
if
there
are
other
gems,
like
you'd
said
that
are
doing
this
and
or
how
are
other
language,
implementations
kind
of
wiring
things
up
just
so
that
we,
you
know,
aren't
reinventing
a
bunch
of
stuff
so
and
then
on
the
configuration
I
think
you
also
answered
that,
which
is
maybe
we
adopt
a
similar
configuration
system
and
we
strive
for
something,
that's
sort
of
unified
where
it
sounded
like
if
we
can
have
something
that's
doing
configuration
that
could
also
be
used
for
the
other
pieces
that
we
want
to
attach
to
this,
like
the
exporters
and
stuff
like
that,
that
would
be
ideal
right,
okay
and
then
the
last
one
was.
C
You
know
priority.
So,
echoing
Frances
statement
like
eventually,
if
we
are
going
to
do
what
the
otep
says,
which
is,
let's
become
the
dependency,
then
we'll
need
to
have
all
of
those
implementation
patients
and,
let's
start
with
something,
that's
easy
and
then
just
keeping
track
that
we
know
sidekick
and
rescue
are
of
particular
interest
to
Shopify
and
Frances,
and
so
you
know
I
might
just
take
a
glance
at
them
in
terms
of
complexity
and
size
and
where
I
think
I
can
jump
in
and
and
or
something
that
might
be
easy
for
me
to
test.
C
You
know
so
that
I
can
court
server
see
it
running.
I
also
note
that
the
DD
trace
library-
I
didn't
put
this
on
my
notes,
but
they
have
a
very
large
docker
compose
file
to
try
and
help
stitch
together.
You
know
everything
they
need
to
test
all
of
this
stuff.
So
you
know
if
we
have
some
interest
in
doing
that
as
well.
That
might
be
a
really
good
starting
place.
You
know
to
be
able
to
sort
of
say:
oh
I
can
spin
up
an
environment
that
has
these
things
and
I
can
and
I.
C
G
You
so
you
might
mentioned
testing
and
I.
Think
your
husband
actually
should
be
one
of
the
bold
headings
under
here,
because
it
this
ends
up
being
actually
like
a
fairly
interesting
problem.
In
that
a
lot
of
these
instrumentation
yeah.
A
lot
of
these
instrumentations
will
work
for
a
range
of
versions
for
a
framework,
and
in
order
to
like
say
that
this
works
with
a
range
of
frameworks.
You
should
be
testing
with
a
lot
of
things
in
the
range,
so
you
kind
of
I,
don't
like
at
New.
G
Relic
anyways,
like
our
our
test
matrix,
is
pretty
pretty
exhaustive,
where
we'll
run
tests
for
instrumentation
for
a
wide
uhm
for
a
wide
number
of
versions
in
the
range
that
we
support.
It's
not
all
of
them.
But
then
you
also
so
say
it's
you
know,
rails
5,
I
think
there's
only
like
two
minor
versions
of
rails
5,
so
you're
gonna
have
at
least
two
things
there.
G
Maybe
you're
gonna
pick
two
from
each
one
like
the
first
and
the
last,
so
you
might
have
four
so
you'll
have
four
versions
of
rails
5
like
you'll
test
against,
but
then
you'll
usually
have
another
aspect
of
that
matrix,
which
is
the
versions
of
Ruby
that
you're
testing
against
too.
So
if
you're
testing,
it's
like
a
ruby
to
four
to
five
JRuby
and
truffle
Ruby
that
ends
up
being.
You
know
four
times
for
sixteen
different
runs
of
your
same
tests.
G
G
C
C
G
I
think
I'm
I
think
we
probably
need
some
sort
of
right
yeah.
This
looks
actually
very
much
much
like
what
I
expected
it
would
look
like
and
yeah
I
think
appraisals
is
perfectly
fine.
I,
don't
know
where,
where
that
exactly
was
back
when
the
multiverse
was
created,
but
I
think
you
could
have
chosen
to
go
either
direction
there
and
using
I
mean
multiverse
does
have
a
cooler
name
so
well,
but
we're
using
the
thing.
G
C
C
You
know,
they've
got
a
lot
of
workflows
running
and
then
they've
got
this
really
nice
sort
of
docker
compose
set
up
to
sort
of
build
out
those
environments
I'm
not
suggesting
that
we
just
start
copying
files
over
you
know,
but
we
at
mutations
we
use
use
docker
for
all
of
our
development
environment,
so
I
have
a
I,
have
a
little
docker
compose
files,
I've
written
just
to
be
able
to
spin
up
the
Ruby
environment
really
easily
and
just
switch
between
the
two
gems
and
everything.
C
So
you
know
if
we're
looking
at
doing
that,
we
could.
We
could
sort
of
put
that
in
with
this
kind
of
work
as
as
needed.
Right
I'm,
like
I,
said
I'm
not
suggesting
just
a
wholesale
here's,
a
big
you
know,
300
line,
talking
flows;
well,
good
luck,
everybody,
but
but
more
like
bring
it
in
as
needed.
But
I
can
see
myself
as
where,
as
we're
writing
these
instrumentation
I
can
see
us
needing
to
have
these
things
connected
in
a
way
where
we
can.
D
G
I
think
ultimately,
I
think
we
need
to
kind
of
set
up
like
how
can
we
start
to
put
this
into
motion
because
I
think
yeah,
like
you
all,
look
like
you're
ready
to
get
working
on
this
as
soon
as
possible?
It's
like
how
can
we
possibly
start
to
kind
of
work
on
this
and
kind
of
get
a
spike
going
and
make
sure
that
our
process
is
gonna
work
so.
C
C
That
sounds
like
the
place
to
start,
let's
start
there,
and
if
that
will
work,
that
battle
might
short-circuit
a
little
bit
of
the
wheel
again,
we
don't
have
to
re-litigate
any
of
the
stuff
we
can.
Just
you
know,
I
think
we
have
a
good
place
to
start.
You've
answered
all
the
questions
really
well,
so
alright.
G
So
the
auto
install
isn't
necessary
to
like
at
least
first
test
that
that
that
thing
works,
but
I
think
that's
kind
of
the
next
step
is
to
start
working
on
the
auto
install
stuff.
G
If
we
do
kind
of
think
we'll
go
with
like
a
hybrid
between
kind
of
that
issue,
that
I
created
and
what's
around
in
the
data,
Dogpatch
or
something
I
would
definitely
be
interested
and
kind
of
working
on
I
at
some
point
started
a
branch
where
I
was
starting
kind
of
the
implementation
of
things
from
issue
19.
It
was
so
long
ago,
like
I,
don't
remember
how
far
I
got
hood
but
I
I
would
be
happy
to
dust
that
off,
and
at
least
like
get
some
of
the
basic
structure
out
there.
C
C
We
have
some
PRS
that
bring
in
maybe
one
or
two
of
them,
and
then
that
would
be
a
place
for
you
to
start
working
on
auto
installation
and
that
wouldn't
get
in
the
way
of
building
more
of
those
things
because
they
could
be
manually
connected
and
then
you
could
start
to
say:
okay,
I've
layered,
this.
You
know
Auto
installation
piece
on
top.
That
would
be
perfectly
fine
and
it
would
allow
us
to
kind
of
stay
out
of
your
way
but
keep
moving
yeah.
G
I
think
that
makes
sense.
The
only
other
thing
that
I
will
add
is
that
see
I'm
currently
winding
down
things
at
my
current
job,
I'll
be
moving
on
to
another
job,
so,
like
I
have
been
super
busy
this
week.
Friday
is
my
last
day
and
then
I
am
kind
of
off
for
two
weeks
and
I
do
hope
to
be
able
to
do
a
little
vacationing
and
R&R
during
that
time.
But
I
also
know
that
I
also
want
to
keep
in
touch
with
the
project
and
continue
to
kind
of
push
that
forward.
G
So
I
do
plan
to
do
some
PR
review
and,
like
I,
don't
mind
working
on
some
of
those
wiring
up
stuff,
but
like
yeah
like
that's,
but
that's
kind
of
my
situation,
but
I
would
encourage
anybody
who,
like
is
depending
on
me
for
anything
to
like
reach
out
to
me
over
to
get
her
order
that
that
whole
time
and
the
worst
thing
I
will
tell
you-
is
I
will
get
to
it
tomorrow
or
in
a
couple
days
or
when
I
have
time.
You
know.
E
G
F
We
have
a
limited
number
of
people
who
can
actually
merge
PRS
right
now.
It
would
be
good
to
start
expanding
that
set
of
people
in
general.
The
rules
we've
been
following
right
now
or
that
like
we
need
at
least
one
reviewer
from
a
different
company
to
approve
before
merging
that's
kind
of
being
an
informal
thing,
but
I
think
it's
a
useful
thing
to
have
going
forward.
I,
don't
know
if
that
necessarily
needs
to
apply
to
the
instrumentation
gems.
C
C
Brandon
has
a
lot
of
the
spec
knowledge,
so
we
felt
like
maybe
between
our
group
and
and
Brandon,
can
provide
some
what
Matt,
what
I
think
you've
been
providing
in
France,
where
I
think
you've
been
providing,
which
is
sort
of
tracking
what's
happening
in
the
larger
context,
and
then
saying
does
this
kind
of
fit
or
what
so
Matt?
The
idea
was
I.
Think
last
time,
you'd
identified
that
hey,
there's
some
PR
is
waiting
for
me.
C
You
know
and
I'm
I
don't
want
to
be
the
blocker,
so
Brandon
had
volunteered
to
sort
of
say,
like
hey,
I'm
tracking,
all
this
stuff,
anyways
right
and
I'm
doing
the
same
kind
of
work
over
in
the
JavaScript
here,
if
I'm
paraphrasing
correctly
Brandon's
that
sound
about
right,
like
I'm
kind
of
already
doing
that.
If
you
wanted
talk
about
it,
though
I'm.
H
Not
like
it,
why
don't
you
at
all
like
at
all
at
all,
but
but
I've
sort
of
been
like
helping
Shepherd
the
JavaScript
stuff
and
made
sure
that,
like
just
sort
of
sanity
checking
things
as
it
goes
along
just
being
like
okay?
Well,
this
seems
like
a
little
bit
too
complex
at
the
API
layer,
like
maybe
we
should
rethink
about
it.
They're,
like
oh
well,
there's
conversation
happening
at
the
specification
level,
so
maybe
we
should
hold
off
on
this
until
that
finishes,
or
maybe
like,
for
example,
with
metrics.
H
The
thing
that
I
proposed
was
just
like.
We
should
sort
of
take
a
commit
and
then
just
like
base
our
metrics
API
off
of
that.
So
we
at
least
have
something
moving
forward
that
people
can
develop
against
if
they
want
to.
So
that's
sort
of
the
role
that
I
didn't
play
in
JavaScript
and
I'm
happy
to
sort
of
like
hop
in
with
Ruby
and
do
something
similar
if
it
makes
you
guys,
lives,
easier,
I
think.
G
You
know
any
eyes
on
anything
coming
in
for,
like
sanity,
checking
the
correctness
and
making
sure
that
you
know
it
is.
It
appears
to
be
in
line
with
the
spec.
Even
if
the
fine
details
are
a
little
hazy
and
I
think
the
rest
of
us
can
pick
up
that
fine
detail
work.
So
I
took
an
action
item
last
week
to
kind
of
reach
out
to
people
who
had
at
one
point
been
interested
in
in
open
telemetry,
we're
coming
to
the
sig
meetings,
etc.
G
G
One
of
them
I
will
you've
everybody
anonymous
just
because
all
this
is
up
in
the
air,
but
I
think
one
of
them
has
been
busy
traveling
super
interested
and
hopes
to
be
able
to
start
work
on
open
telemetry
sometime
during
October,
so
like
I
think
that
would
be
great
if
that
happens,
and
that
would
probably
turn
into
like
a
really
high
quality
reviewer
for
us
as
well.
So
I
feel
like
that.
That
would
help
out
a
lot.
I,
don't
know
another
one.
G
Super
interested
as
well
is
just
like
incredibly
busy
with
work
right
now,
but
wants
to
contribute
as
soon
as
their
stuff
kind
of
winds
down
a
little
bit.
Third,
one
I
have
not
given
up
hope
on
yet,
but
I
haven't
heard
anything
yet
so
so
that's
kind
of
where
we
are
on
that
front.
I,
don't
know
what
Shopify's
involvement
might
be
going
forward,
at
least
in
terms
of
being
able
to
maybe
like
review
here
and
there
at
least
I
expect
you're
gonna
be
super
busy,
Francis
but
and
I
know.
G
F
We
have
a
fairly
new
hire
who's
working
on
some,
the
tracing
stuff,
but
his
new
to
Ruby
and
neuter
tracing
so
is
going
to
be
picking
a
few.
So
the
small
things
to
work
on,
but
he's
probably
not
going
to
be
super
active
as
a
reviewer,
and
then
we
have
one
other
person.
Who's
been
doing
some
work
on
this,
but
is
currently
more
interested
in
focusing
on
the
open,
telemetry
collector
rather
than
the
Ruby
instrumentation.
F
G
So
fing
gross,
alright,
so
I
guess
we've
kind
of
given
the
lay
of
the
land
for
the
you
know,
foreseeable
future
and
I
think
like
definitely,
you
can
rely
on
me
being
around
and
being
a
reviewer,
maybe
a
little
spotty
over
the
next
two
weeks,
but
still
present,
and
then
we
may
have
a
new
person
coming
in
that
I
really
hope
will
be
a
strong
reviewer
I
think.
Ideally,
we
have
at
least
three
of
these
people
and
that
will
make
our
lives
a
lot
easier.
I
feel
like
two
is:
we're
spread
a
little
thin
so.
G
Brandon,
if
you
want
to
kind
of
help,
help
out
a
little
bit
and
then
everybody
else
who
just
wants
to
help
out
that's
great
and
I,
think
I
think
in
time.
We
will
find
that
third
person,
but
yeah
I,
think
having
having
strong
having
a
strong
tracing
background
is
super
useful
for
this
stuff
and
the
more
Ruby
the
better
combined
with
that
so
I
think
that's!
Those
are
the
things
that
we're
looking
for
in
in
these.
We
do
it
in
these
reviewers.
So.
H
F
C
Thank
thank
you
guys
for
going
through
all
that
stuff.
That
gives
us
some
place
to
start
and
I'll
like
I,
said.
I'll
push
this
into
that
proposal,
paths
or
the
way
you
described
it
it.
You
know,
given
the
length
of
this
document.
This
is
this
will
be
much
smaller
and
focused
now
I'll,
sort
of
act
that
on
Francis
to
the
issue
that
you
created
and
sort
of
say
this.
This
is
how
we're
gonna
propose
going
forward.
I'll,
get
your
feedback
and
then
I
think
we'll
start
there
and
I
have
absolutely
just
to
say
it
explicitly.
C
G
It's
not
like
I
think.
The
main
thing
is
that,
like
I've
already
done
a
little
bit
of
the
word
right
right,
I
feel
like
it
would
be
easy
for
me
to
push
some
of
that
stuff.
G
A
little
before
yeah
same
time
like
I,
just
want
to
make
it
totally
clear
that,
like
if
the
proposals
that
are
like
seem
like
they're
a
bad
idea
and
not
what
we
want
to
do
like
I
think
we
can
pull
it
change
course,
like
I'm,
not
wedded
to
these
ideas
at
all,
I
think
the
end
goal
there
is
I
have
kind
of
the
best
auto
instrumentation
story
that
we
can
have
so
great.
You
can't
stress
that
enough
great
okay.
C
Fantastic
well,
I
really
appreciate
the
time
y'all
spent
today
helping
us
get
started,
because
this
was
mainly
focused
on
what
we
can.
We
can
do
and
giving
us
sort
of
a
big
block
of
work
to
start
on.
So
that's
a
very
intimidating
list
of
instrumentation
integration,
so
I
think
we
have.
We
definitely
have
a
to-do
list
and
we
we
can.
We
can
get
started
and
I'm
gonna.
You
know
the
focus
will
be.
How
do
we
get
something
in
front
of
you
sooner
rather
than
later,
so
that
we
can
start
to?
C
You
know,
decide
if
we
even
like
the
direction
right.
You
know.
Where
is
this
gonna
go?
Do
we
like
the
way
that
Jim
is
set
up
yeah
we'll
get
going?
I
do
notice.
One
thing
they
haven't
changed
the
licensing
on
the
data
dog
code.
It's
still
under
their
copyright.
They
have
not
open
sourced
that
technically,
so
we
might
want
to
make
some
enquiries
before
I
start
copying
things
over
okay,
I'll
poke
around
in
the
light
step
area
because
they
might
have
more
direct
contact
with
someone
so
brand
new.