►
From YouTube: 2019-10-02 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).
A
B
B
B
C
B
D
A
C
D
D
E
Okay,
probably
get
started.
Are
there
any
topics?
In
particular,
people
want
to
talk
about
today.
The
one
I've
added
to
the
agenda
is
about
whether
we
should
split
out
the
auto
instrumentation
work
into
a
separate
sig,
which
Bogdan
had
told
us
to
do
or
recommended
that
we
do.
It
feels
to
me
a
little
heavy-handed,
but
anyway
I'd
like
to
discuss
that
a
little
bit
today,
yeah
anything
else.
People
want
to
talk
about.
D
I'm,
just
gonna
drop
another
item
on
there.
There
was
this
error
handling
specification
that
was
started
a
long
time
ago,
but
I
think
there's,
there's
been
be
new
too
interested
in
I.
Think
it's
I
kind
of
asked
for
some
clarification
of
how
I
should
handle
things
in
dynamic
languages
and
I
think
we've
kind
of
gotten
that
so
we
can
chat
about
that.
I'm.
Just
gonna
pull
up
the
exact
PR
and
paste
it
in.
C
Yeah
in
terms
of
the
auto
interpretation,
I
would
like
to
discuss
it
a
little
bit
more
just
kind
of
what
I'm,
seeing
now
that
I'm
digging
in
so
Dave
David
and
I
have
been
getting
in
there
a
little
bit
more
and
then
I.
Guess
as
it
relates
to
the
separate
sig
I
noticed
that
there
was
a
some
comments
happening
on
an
update
to
the
specification,
basically
saying
that
the
same
sort
of
split
the
repo
out
should
happen
for
exporters
and
everything
else
like
it
looks
like
it's.
C
It's
it's
basically
a
recommendation
to
clarify
the
placement
of
the
exporter
implementation
and
then
there's
sort
of
a
long
discussion
about
the
fact
that
you
know,
for
instance,
python
has
an
azure
exporter
and
they
don't
want
to
have
sort
of
that.
The
comment
is
basically
saying:
listen
if
you
bundle
all
this
stuff
in
with
the
repo,
it
increases
the
maintenance
load
for
the
maintainer
x',
but
I
think
right
now
you
know
Frances
obsession
by
your
comment.
C
I
think
you
probably
feel
the
same
way
it's
like,
but
right
now
we
need
them
kind
of
close
because
they're
both
sort
of
changing
simultaneously,
at
least
in
the
short
term
and
possibly
in
the
long
term,
but
yeah.
It
seems
like
some
of
the
other
repos
and
libraries
and
SIG's
they're
a
little
further
along,
but
also
there's
sort
of
this
idea
of
you
know
are,
we
would
add
one
one
of
the
commenters
mentioned
privileges
of
the
vendor
plugins
over
another,
so
that
that
was
an
aspect
of
that
I
hadn't
considered.
A
D
C
D
E
E
A
D
D
B
Yeah,
my
feeling
was
that,
if
it
turns
out
there
are,
you
know
several
new
people
who
want
to
join
or
who
end
up
joining
and
for
whatever
reason
are
focused
on
a
lot
of
instrumentation
type
stuff.
At
that
point,
we
might
be
able
to
work
in
a
CLE
spin
it
out,
but
at
the
moment
it
feels
a
little
premature
I.
Think.
C
And
in
terms
of
the
other
recommendation
that
baktun
made
at
the
same
time
was
that
it
also
that
that
code
also
needs
to
be
in
a
different
repo,
so
in
terms
of
it
seems
like
SiC
and
repo
or
kind
of
use
interchangeably,
but
I,
there's
to
me,
there's
a
big
difference,
and
that
is
that
as
we're
spinning
up
the
auto
instrumentation
I
could
see
changes
going
back
and
forth
sort
of
cross
that
order
pretty
easily
right.
C
I'm
working
on
this,
so
I
found
a
thing
that
doesn't
exist
or
I
need
to
put
in
there
and
just
that
sort
of
barrier
to
entry
of
having
them
in
two
repositories
for
the
time
being,
which
would
seem
like
it
would
increase
our
burden
in
the
short
term.
Maybe
you
know
maybe
long
term.
It
makes
a
lot
of
sense
for
it
to
be
another
repo
or,
if
that's,
what
everybody's
sort
of
saying
too,
to
be
one
of
our.
You
know
one
of
these
projects.
C
It
needs
to
look
like
this,
like
I
kind
of
get
the
feeling
that
that's
a
lot
of
the
sort
of
standardization
stuff
that's
happening,
but
at
least
from
my
perspective.
Having
them
near
one
another
kind
of
easy
to
wire
up
and
test
and
observe,
helps
when
were
writing
them,
but
I
wouldn't
be
opposed
to
sort
of,
as
as
everything
matures
that
there's
sort
of
a
time
where
you
say:
okay,
here's
my
PR
to
you
know
take
the
instrument
ears
that
put
them
in
their
own
repository.
C
If
that,
if
that's
something
that
the
larger
community
feels
really
strongly
about,
I
think
we
talked
about
that
on
our
first
call
together,
which
was,
let's
keep
everything
kind
of
in
the
same
place.
Even
if
we're
shipping
multiple
packages,
just
cuz,
it's
gonna,
make
it
easier
for
us
to.
You
know,
keep
track
of.
What's
going
on
yeah.
E
D
C
D
I
think
it's
totally
fine
I'm
fine
if
they
hang
out
an
instrumentation
folder
indefinitely
in
all
right
in
our
repo,
because
to
me
like
a
isolated
folder,
where
there's
coming
just
no
kind
of
cross
dependencies
is
as
good
as
its
own
repo
right.
D
A
I
agree
as
well:
I
think
for
my
day,
job
is
to
do
client.
Libraries
for
Google
API
is
for
Ruby
and
Lisa.
We
have
lots
of
libraries,
often
in
the
same
repo
and
and
it
is
that
way
intentionally,
because
there's
often
a
lot
of
cross
library
work
has
to
be
done.
The
only
time
that's
we've
found
that
it's,
it
really
becomes
necessary
to
separate
things
out
into
different.
Repos
is
for
permissions
purposes,
so
gotcha
right.
A
C
Speaking
of
licensing,
it
would
be
okay
to
just
chat
for
a
moment
I'm,
seeing
some
conversations
at
light
step
about
the
licensing
for
the
data
dog
Auto
instrumentals
across
their
libraries.
They
have
different
licenses,
so
we
had
talked
about
this
before
like
make
sure
that
the
licenses
are
okay,
but
people
that
kind
of
gone
in
and
digging
now,
there's
MIT,
there's,
there's
they're
kind
of
all
over
the
map,
so
there's
an
effort
within
light
step
to
sort
of
get
people
at
data
dog
to
be
part
of
this
and
to
really
understand
the
licensing
requirements.
C
So
the
auto
instrument
is
for
Ruby
our
BSD
three
clause
and
it
sounds
like
we
just
need
to
preserve
that
sort
of
that
statement.
One
of
those
clauses
says
you
need
to
include
data
dogs-
copyright
in
there
so
we'll
just
as
we
bring
stuff
over
we'll
need
to
make
sure
that
we're
following
the
requirements
of
that
of
those
clauses
but
from
from
at
least
from
us
it
for
our
stuff.
It
seems
like
it's
okay,
although
I
don't
know
the
legalities
of
taking.
You
know,
BSD
license
code
and
dropping
into
an
apache
license
project,
but.
C
Yeah
I
just
want
to
let
her
know
they're
kind
of
like
there's
it
there's
an
effort,
there's
a
few
folks
at
like
step
that
are
gonna,
be
talking
to
folks
at
data
dog,
to
sort
of
understand
this
a
little
bit
better
and
and
probably
help
us
with
some
of
that
coordination
that
we
feel
like
we're.
Gonna
need
yeah,
obvi,.
A
D
Yeah
I'll
give
the
intro
since
I
tasted
that
in
so
Sergey
opened
this
a
long
time
ago,
like
probably
right
around
the
time,
we
started
working
on
our
own
on
our
implementation
and
they
really
had
like
a
fairly
like
tall
order.
I
think
it
said
you
know,
basically
being
the
SDK
should
not
crash
an
application,
no
matter
how
how
it's
used
by
the
user
and
that
I
think
is
slightly
easier.
D
Maybe
in
a
compiled
language,
where
you
at
least
have
a
compiler
making
sure
that
you
know
arguments
are
of
the
right
type
and
and
other
such
things,
and
then
it's
kind
of
sat
around
for
a
while,
but
there
has
been
some
renewed
interest
in
it.
So
I
was
just
trying
to
like
so
I
commented
a
couple
times
on
it
just
trying
to
get
some
clarification
like
well.
What
should
we
do
for
dynamic
languages?
D
D
The
only
option
I
threw
out
there
was
the
SDK
can
do
runtime
checks
and
providing
defaults
when
they
fail
with
the
caveats
that
the
runtime
checks
are
not
free
impact
performance
and
they
can
still
be
error-prone
just
just
because
you
have
them
doesn't
mean
that
you're
gonna
catch
everything
so
you'd
still
end
up
in
the
same
boat.
The
last
option
was
that
you
know
you
could
just
have
a
rescue
pretty
much
around
every
API
method
and
be
termed
a
null
if
an
exception
was
occurred,
but
that
leads
to
some
pretty
poor
user
experience.
D
As
your
users,
without
you
have
to
check
for
Knolls
for
like
start
span,
for
example,
and
then
Sarah
guy
kind
of
came
back
with
that
third
option,
it
was
like
well
what
about
that
option?
Three,
where
you
rescue
errors,
but
in
the
event
they
do
happen,
you
kind
of
return.
If,
if
your
method
is
supposed
to
return
something
and
returns
kind
of
a
default
or
no
op
of
that
type
and.
D
D
So
yeah
I
mean
I
think
in
the
event
of
an
exception,
you
are
going
to
be
worse
off
most
likely,
but
I.
Think
if
you
consider
that
to
be
an
exceptional
circumstance
that
most
people
aren't
going
to
run
to
is
just
kind
of
like
a
fail-safe,
a
safety
valve,
because
really
what
we're
kind
of
protect
against
are
people
using
the
AP
is
and
properly
just
like.
You
know,
passing
like
a
string
when
you
wanted
a
span
context
or
something
and.
D
E
D
A
D
Way
we're
supposed
to
fix
this
in
our
dynamic
language
is
by
like
writing
tests.
That's
kind
of
like
you
know
the
the
thing
that
that
we
end
up
doing
and
I
think
I,
don't
know
when
it
comes
to.
Observability
is
just
like
this
touchy
area
because,
like
nobody,
wants
your
observability
system
to
crash
or
application
which
I
agree
with,
but
at
the
same
time
I
think
there
is
like
the
user
has
some
responsibility
for,
like
you
know,
if
they
are
writing
code,
that
they
have
managed
to
give
you
generally
something
that
your
API
can
use.
B
Play
in
the
context
of
like
auto
instrument,
for
example
right
so
now,
you've
got
stuff
that
maybe
like
technically
a
user
has
opted
into,
but
hasn't
necessarily
instrumented
the
code
themself.
You
know,
for
example,
is
there
a
sort
of
like
project
level
differentiation
between
what
an
expectation
might
be
in
that
case
versus
you
know
somebody
hand
rolling
some
of
that
or
do
we
want
that
exceptional
use
case
scenario
to
be
the
same
across
the
board,
so.
D
So
I
definitely
feel
like.
You
should
be
extremely
defensive.
When
writing
instrumentation
I
think
that
the
SDK
itself
does
not
need
to
be
quite
so
defensive
in
terms
of
like
aggressively
type
checking
things,
because
it
does
become
the
stuffed
I
think
tenants
like
cascade.
It's
like
we
end
up
like
checking
types
you
know
in
starts
fan
in
the
sense
of
cascading,
like
any
possible
method
that
ends
up
calling
and
then
you
may
end
up.
You
know,
checking
the
same
argument.
A
number
of
times
in
a
few
different
places.
A
A
That
is
not
something
that
libraries
do
it's,
not
something
that
Ruby
developers
expect
it's
not
something
that
our
practices
as
Ruby
developers,
you
know,
accounts
for
and
so
I'm
afraid
that's
doing
something
like
that
will
actually
do
more
harm
than
good
in
terms
of
in
terms
of
what
we
really
want,
which
is
application
stability,
it'll
force
developers
to
do
something
do
something
kind
of
outside
their
the
norm.
For
this
particular
library.
That's
that
we're
providing.
A
So
yes,
we
should
make
sure
that
our
we
should
be
very
careful
in
the
internals
of
our
of
the
SDK
to
make
sure
we're
not
you
don't
have
logic
errors
that
are
there
throwing
exceptions,
and
maybe
we
should
have
some
mechanisms
to
to
to
account.
You
know
to
account
for
that,
but
usage
types
of
errors
and
things
that
are
not
in
under
our
control,
I
think
the
expectation
we
need
to
follow.
The
kind
of
the
Ruby
community
expectation
is
on
how
we
behave.
A
A
We
need
to
follow
that
so,
like
the
concept
of
a
default,
value
to
return
often
doesn't
exist
in
Ruby,
I
mean
maybe
Noah's,
but
nillas
also
has
his
own
problems.
It's
not
like
a
go
where
there
is
a
there
is
a
concept
of
a
default
value.
Ruby
doesn't
have
so
I
think
importing
some
of
these
concepts
across
all
languages
and
kind
of
had
this
idea
of
you
know
all
languages
should
do
this
kind
of
the
same
thing,
whether
they
dynamic
or
static,
or
even
between
the
dynamic
languages.
A
B
Also
curious
from
sort
of
a
like
developer
experience,
or
you
know,
developer
user
experience
perspective
on
one
hand,
there's
sort
of
a
mandate
to
keep
the
code
as
performant
and
lean
as
possible.
On
the
other
hand,
particularly
in
a
dynamic
language
like
Ruby,
some
of
the
error
checking
or
type
checking
that
we're
talking
about
Matt,
as
you
mentioned,
we
might
end
up.
You
know,
checking
something
in
a
number
of
different
places
along
the
line
which
will
clearly
end
up
with
performance
impacts
and
just
from
a
high
level.
B
D
Yeah
in
general,
I
think
users
are
going
to
want
stability
for
the
most
part,
but
I
think
I,
don't
know
like
I
think
these
things
can
be
divided
into
a
few
classes
and
like
I
guess
the
one
thing
that
I'm
really
uncertain
of
is
like
this
is
there's
this
kind
of
the
notion
that
we
should
be
able
to
handle
anything.
The
user
throws
at
us
in
our
api's
and
I
feel
like
that.
That's
a
pretty
tall
order
and
that.
D
Expecting
that
a
user
is
actually
kind
of
passing
in
kind
of
the
right
types
is
kind
of
just
the
the
contract
using
a
dynamic
language
in
general,
I've,
never
I've,
never
gotten
mad
at
a
library
when
I
was
using
the
dapi
wrong
and
I
and
I
ended
up
having
an
exception.
I've
often
been
actually
very
frustrated
with
libraries
that
just
like
swallow
that
and
give
me
like
no
feedback
that
there
was
a
problem.
A
A
Cars
will
pass
in
the
the
types
that
we
document
and
if
they
don't
then
throwing
throwing
name
air
is
throwing
argument
arrows,
throwing
whatever
you
know,
the
the
standard
errors
that
that
would
be
thrown
and
your
art
is
is
reasonable.
I,
don't
think
we
did
anything
particularly
special
that
we
wouldn't
do
with
any
other
ruby
library,
just
because
this
was
an
instrumentation
library.
That
said,
we
didn't,
have
you
know
any
central
directive
from
from
census.
Saying
hey
you
should
do
this.
This
is
I'm.
A
Looking
at
the
proposal
now
is
the
first
time
I've
seen
something
like
this
in
the
context
of
census
orphans.
One
gentleman,
if
you
guys,
saw
it
and
open
tracing
but
I
I'm,
not
convinced
that
this
is
the
kind
of
thing
that's
up
is,
as
you
say,
useful
in
a
in
a
dynamic
language
and
in
particular
in
the
movie.
D
Okay,
so
yeah
I
mean
I
think
we
can
continue
this
discussion
as
much
as
as
we
would
like
to
to
kind
of
arrive
at
what
we
would
like
to
do.
But
this
is
definitely
I,
think
that's
out
there
and
if,
if
individuals
have
opinions
or
of
our
group
wants
to
form
an
opinion,
an
opinion,
we
should
definitely
provide
this
feedback
on
this
spec.
D
So
I
feel
like
we're
we're
kind
of
like
the
we're
in
like
a
huge
minority
right
now,
I
think
from
what
I
known
Ruby's
in
this
vote
had
some
very
brief
discussions
with
the
pipe
with
the
Python
folks
and
they
there's
a
kind
of
Python
type
checking
library.
But
it's
all
kind
of
static,
static
analysis,
type
checking.
Somebody
has
to
actually
run
a
tool
yeah.
D
Library,
no,
but
ultimately,
what
they
told
me
was
like
they're
doing
no
checking
of
arguments
and
things
could
blow
up
in
very
interesting
ways
and
that
was
kind
of
their
approach.
I
thought,
maybe
JavaScript
would
be
in
the
same
boat
but
they're
using
typescript,
so
they
have
gotten
off
on
a
technicality
there.
So
I
think
I.
Think.
F
Using
javascript
you
with
ever,
it
is
a
human,
so
typescripts,
mostly
they're,
as
just
like
a
way
for
us
to
develop
in
a
kind
of
more
sane
way.
But
the
thing
that
we,
the
way
that
we've
been
looking
at
it,
is
playing
the
API
shouldn't
ever
throw
an
error
or
cost
the
program
to
crash,
and
rather
like
just
throw
out
console
errors
instead
or
like
console
warnings
being
like
hey,
you
did
this
wrong.
A
C
Thank
you
for
your
input.
I
just
want
to
piggyback
on
what
you
were
saying
and
Brandon.
Thanks
for
the
insight
from
the
JavaScript
stuff,
what
I
was
thinking
of
just
thinking
about
we're,
talking
and
Phil
you
bringing
up
the
auto
instrumentation,
that's
kind
of
where
I
was
going
with
it,
but
additionally,
how
do
these
things
cascade
through
so
instant,
for
instance,
we
have
I
mean
if
you
just
think
of
like
a
simple.
C
We
have
a
rapper
called
in
spann,
which
uses
a
number
number
of
internal
methods
right,
and
so,
when
we
think
about
maybe
not
even
the
default
values,
but
let's
say
we're
not
doing
anything.
How
does
that
cascade
through
when
we
start
putting
convenience
methods
that
rubyists
are
really
gonna
appreciate
right,
we're
we're
gonna,
see
something
like
I
need,
four
or
five
lines
to
configure.
Something.
C
How
do
we
keep
those
things
running
you
know,
and
so
are
we
are
we
sort
of
setting
ourselves
up
for
cascade
this
sort
of
no
check
for
that
check
for
that
check
for
that
and
make
sure
because
I've
you
know,
you
see
that
sort
of
years
ago
Abdi
had
that
thing
on.
You
know
confident,
Ruby
right,
this
idea
of
programming
confidently
and
not
just
you
know
this.
C
This
horrible
check
at
everything
so
I
just
wanted
to
echo
kind
of
the
sentiment
here
where
I
think
ruby
is
in
general,
are
expecting
if
I
use
the
thing
right,
it's
not
gonna
hammer.
My
app
in
particular
I
can
really
see
the
benefit
of
not
letting
the
API
crash
the
app
if
it
gets
wired
up.
You
know,
like
you,
wouldn't
want
this
thing.
C
You've
dropped
in
to
help
you
to
bring
everything
down
to
its
knees,
but
I
just
I,
don't
know
all
the
details,
so
Francis
and
Matt
I
think
you
guys
have
the
real
knowledge
of
how
the
internals
work,
but
that
would
be
something
that
I'd
be
thinking
about.
Is
how
how
does
this
defensive
programming
impact
even
our
own
code?
You
know
as
we
as
we
bring
abstractions
up
through
library,
even
though
it's
small,
it
might
still
have.
You
know
some
impact,
whether
that's
performance
or
just
the
ergonomics
of
using
the
darn
thing.
Yeah.
E
I
just
wanted
to
chime
in
with
three
things.
One
is
that
we
have
a
number
of
api's
that
have
requirements
beyond
simply
typing,
so
they
have
requirements
that
you
know
a
stream,
be
printable.
Ask
you
as
an
example
or
that
a
number
being
non-negative
in
some
of
the
metrics
to
api's.
So
some
of
our
runtime
checks
for
argument's
are
checking
that
sort
of
thing
rather
than
just
is
this
a
string,
or
is
this
a
number
or
a
boolean.
E
The
other
place
where
we
have
where
this
discussion
came
up
previously
was
what
would
we
accept
as
a
label
for
an
attribute?
Would
we
accept
both
symbols
and
strings
as
labels
for
attributes,
and
we
made
decision
at
the
time
that
we
would
only
accept
strings
because
explosive
accepting
symbols
had
more
complications
in
terms
of
you
know,
if
you
had
a
symbol
and
a
string
that
once
you
string,
if
I'd
them
came
out
to
the
same
thing,
then,
which
one
should
actually
win
out
there?
C
So
big
high
level
point
is
we're
already
checking
some
arguments.
So
it's
not
unheard
of
in
the
library.
Have
I
got
bitten
by
the
simple
string
check,
but
I
was
when
I
was
working
on
stuff.
I
didn't
expect
it
I
expect
to
be
able
just
throw
a
symbol
in
there
for
what
it's
worth
just
cuz
I.
Had
you
know
hash
like
I,
had
hashes
with
simple
keys
and
was
like
just
you
know.
You
come
from
the
rails
world
of
whatever,
of
course
that
has
its
own
problems,
but.
E
E
C
C
I
just
think
it's
a
thing
right,
it's
it's
and
that
might
be
more
of
a
difference
for
people
who
are
wanting
to
contribute
to
the
library
versus
the
people
who
want
to
use
the
library
right
if
the,
if
the
library
is
defensive,
that
really
is
only
a
bar
to
people
who
want
to
come
in
and
help
us
maintain
it,
and
we
might
have
some
standards
where
we
say
okay.
This
is
not
gonna.
C
Look
a
lot
like
Ruby
in
here,
but
here's
some
additional
things
we
might
be
doing,
but
the
Daniels
point
we
and
I
think
to
Matt's
point
too.
We
are
kind
of
used
to
just
saying
you
know,
please
just
let
me
know
if
I
have
done
something
I
shouldn't
have
otherwise
I'm
gonna,
assume,
everything's,
cool
and,
and
then
what
does
sort
of
you
know
if
JavaScript
is
saying
we're
gonna
take
the
attack
of
we're
gonna
dump
information
out
for
you,
maybe
in
the
development
environment
or
whatever
we're
gonna
spit
stuff
out
to
the
console.
C
C
C
C
Think
if
we're,
if
every
method
has
five
lines
of
code
checking
all
of
the
you
know
all
of
the
arguments
that
that
seems
like
a
bit
overkill
to
me
and
then
what
you
know,
the
fact
that,
like
sorbet,
is
spitting
up
but
Matz
is
saying
I'm
not
really
a
fan
of
that
kind
of
type-checking
I
want
to
do
something
else,
and
so
he's
got
they
were.
I
was
watching
some
talks
last
week
where
the
Ruby
typing
that
Ruby's
gonna
support
itself
will
be
like
standalone
type
definition
files
and
checking
that
way.
A
That's
we
do
have
to
make
a
distinction
here
between
things
like
checking
arguments
and
things
which
yeah
we
can
check
arguments
we
can.
We
can.
We
can
do
a
lot
of
checks,
you
can
do
fewer
checks,
checking
for
non-negative
numbers
or
things
like
that.
That
is
reasonable.
A
D
F
D
C
C
A
F
D
And
just
just
trying
to
kind
of
have
another
idea
of
how
it
works
and
I
should
just
actually
go
look
at
the
code,
but
do
you
like?
Do
you
kind
of
type
check
the
arguments
on
the
way
in
and
try
to
correct
them
before
you
create
this
fan
or
you
just
kind
of
try
to
use
them
and
if
it
blows
up,
then
okay,
no
op
stands
for
you.
D
F
Think
we
do
some
basic
type
checking
which
would
start
span.
I
feel
like
messing
that
up
is
kind
of
hard
because,
like
the
basic
price,
it's
like
you
just
need
like
we
have
this
config
object,
you
put
things
inside
the
coffee
object
and
he
meant
that
it
isn't
that
thing
like
we
sorted,
ignored,
I.
Think
it's
kind
of
hard
with
JavaScript
systems
like
there
is
no
real
type
checking,
but
in
our
text
of.
A
F
D
D
D
Yeah
I
think
these
are
definitely
things
that
we
do
need
to
kind
of
reach
a
conclusion
and
a
policy
on
just
so
that
we
can
be
consistent
moving
forward.
So
I
don't
know
if
this
is
something
that
we
should
all
tis
kind
of
noodle
on
until
the
next
thing
I
know
there
is
this
proposal
out
there
that
people
would
probably
like
to
merge
sooner
than
later,
so
I
think
it
makes
sense
to
have
some
discussion
there,
as
well
for
for
other
people
who
you
know
may
who
may
also
have
have
opinions
on
this.
D
Yeah,
it
seems
like
there's
a
very
strong
desire
to
have
this
kind
of
autocorrection
system,
even
if
api's
are
used
kind
of
incorrectly.
So
I
think
in
general
kind
of
like
our
are
check.
Our
check
and
raise
situation
is
not
what
they're
asking
for
I.
Think
it's
more
like
a
check
and
correct
I
guess
would
be
like
the
strategy
that
I
would
see
being
encouraged,
checking
correct,
and
if
you
can't
do
that,
then
just
still
return
something
of
the
right
type.
It
means
that's,
what's
being
asked
of
us,
I.
D
Could
see
like
us
trying
to
have
the
best
of
all
worlds
if
it
comes
down
to
it
by
wanting
to
abstract
our
type
checking
into
into
some
methods?
So
if
you
wanted
to,
like,
you,
know,
check
an
argument
for
a
type
and
provide
like
a
default,
if
that
fails,
that
could
be
like
you're
checking
correct,
but
you
could
probably
have
like
this
strict
mode
where
it
would
actually
raise
an
exception,
and
that
would
be
something
that
the
user
could
configure
if
they
wanted
it
to
work.
That
way,
and
it
would
not
try
to
correct
it.
C
Yeah
I
would
say
one
thing
that
you
mentioned
that
I'm,
not
not
the
only
thing
I
liked,
but
one
thing
was
to
opt
in
or
opt
out
right,
I
might
default
to
silently.
You
know
just
keep
running,
just
just
don't
bring
things
down,
but
as
I'm
spinning
things
up,
you
know
to
Daniels
point:
I
might
want
some
that
feedback
if
I'm
manually,
instrumenting
something
that's
very
complicated,
I
want
to
make
sure
I've
got
things
right.
You
know
that
also
seems
like
something
that
might
be
advantageous
to
be
able
to.
C
You
know,
provide
some
feedback
or
you
know,
fail
and
log
this
to
the
logger
I've
provided
right.
Like
tell
me
in
the
instance
that
brands
talking
about
it's
like
hey,
we
we
couldn't
set
the
span
of
because
we
had
an
error,
we're
giving
you
this
no
op
thing
and
we
are
going
to
let
you
know
you
look
like
you
tried
to
do
a
thing
and
we
did
something.
Instead,
everything
is
still
running.
We
didn't
break
it,
but
you
should
know
you're
not
kidding
what
you
thought
you
were
getting
right.
C
Mm-Hmm
like
I
could
see
that
happening.
If
you
expected
an
exporter
to
do
something
right
and
the
span
processor
had
a
problem
doing
something
like
that.
It's
like
you're,
expecting
this
data
to
come
out
the
other
end.
But
we
found
something
here
and
can't
do
that.
But
I
don't
know
how
that
stuff
gets
wired
up
and
what
the
users
expectation
is
of
where
those
messages
might
come
from,
or
you
know
how
things.
F
A
C
F
E
D
E
E
D
Yeah
I
think,
as
most
of
you
know,
I
am
dissolve
all
volunteer
time
for
me
over
the
next
couple
weeks,
but
I
am
happy
to
volunteer
some
time.
I
hope
to
not
volunteer
all
my
time,
but
I
definitely
want
to
make
sure
to
keep
up
on
things.
Keep
things
going
and
maybe
even
do
a
little
bit
of
work
myself
because,
like
it's,
not
it's
not
all
work
like
I
enjoy
doing
a
lot
of
this
stuff.
It's
just
a
matter
of
finding
the
right
balance.
I
know.
D
D
E
D
C
Speaking
of
when
I'm
working
on
the
examples,
I've
been
working
on
a
docker
compose
file
to
basically
spin
the
stuff
up
and
let
us
sort
of
use,
different
bits
and
bobs
and
have
the
dependencies
really
isolated
but
also
be
able
to
you
know,
run
the
tests
for
the
API
and
the
SDK.
Is
that
something
that
you
all
will
be
willing
to
accept
the
PR
for
to
just
have
a
compose
file?
Roll
up,
yeah
yeah.
C
So
what
I've
got
now
is
a
bit
of
a
hodge
podge,
but
it
starts
the
pretty
good
base
for
being
able
to
for
us.
We
do
all
of
our
development
and
containers,
so
we
just
want
to
have
it
isolated,
so
I
have
one
set
up:
that'll,
basically,
work
for
the
API
and
the
SDK,
and
then,
as
we
built
the
examples,
what
it
does
one
for
each
but
then
I
basically
had
them
depend
on
one
another,
because
I
was
doing
a
client-server
example,
because
I
want
to
work
on
sort
of
an
end-to-end
smoke.
C
Test
of
just
can
I
get
distributed
context
doing
its
thing,
but
as
we
as
we
get
this
going
yeah,
we
can
just
add
other
use
cases
in
there
spend
of
different
combinations
of
things
and
Matt.
That
might
also
help
sort
of
encourage
the
isolation
so
like
yeah,
you
can-
and
you
can
just
use
this
container.
You
know
this
service
or
whatever
you
want
to
call
it
to
do
that
work.
So,
okay,
cool,
yeah,
I'll
I'll,
push
my
changes
up,
so
everybody
can
benefit
from
those
I'll
get
a
PR
open
for
that
yeah.
D
Anything
that
will
be
useful
for
test
drive.
Things
will
be
useful
to
any
kind
of
contributor
and
well
yeah.
We
we
always
had
this.
We
had
a
Ruby
agent
playground,
which
was
just
like
a
sample
app
for,
like
every
possible
framework
that
we
worked
with
just
yeah
great
make
sure
that
things
worked.
The.
C
E
C
Right,
yeah
and
I
just
had
two
quick
questions.
I
know
we're
very
very
short
on
time.
One
was
in
terms
of
the
metric
stuff
that
kind
of
keeps
coming
up,
because
it's
kind
of
the
big
piece
for
missing
branches,
I,
know
you'd
kind
of
said:
hey.
We
want
to
wait
for
the
spec
to
slow.
You
know
kind
of
slow
down.
That
seems
like
there's
some
momentum
there,
but
in
general
the
other
libraries
seem
to
sort
of
be
taking
a
snapshot
of
in
time
and
implementing
that.
E
So
we
took
a
snapshot
early
on
and
we
did.
The
API
for
the
metrics
I
had
actually
started.
Looking
at
the
updates,
yesterday
almost
started
working
on
a
PR
and
then
decided
to
work
on
the
Yaga
thing.
Instead,
it
I
think
it's
worth
picking
it
up
again.
Taking
a
look
like
it
looks
like
the
spec
is
starting
to
stabilize
again
around
metrics,
so
it's
probably
something
we
can
start
working
on.
C
C
The
Python
folks
are
saying
eight
to
ten
weeks.
To
finish,
the
instrument
is
on
their
side,
so
it's
a
very
large,
very
long-running
a
goal
and,
as
I
was
looking
at
it,
I
don't
know
if
we
dismiss
this
out
of
hand.
But
if
there's
an
if
there's
a
desire
that
the
data
dog
Jim
is
using
the
open,
slim
'try
spec,
it
feels
like
a
much
faster
way
to
get
that
going
would
be
for
us
to
open
a
PR
and
say
everywhere.
You
call
data
dog
trace,
we've
put
the.
E
Sure
yeah
I
think
it's
worth
discussing
next
time.
In
particular,
one
of
the
things
that
may
go
in
pretty
soon
I
hope
is
the
open
tracing
bridge
and
that
might
provide
either
something
that's
closer
to
the
data
dog
API
or
at
least
an
example
of
what
a
bridge
is
going
to
look
like
all
right.
Then
we
could
consider
building
a
dog
bridge
initially
and
then
I
guess
I.
C
Like
that
yeah
I'm
thinking
more
in
terms
of
to
keep
momentum
going
so
that
people
are
invested
in
in
what
the
work
we're
doing
here
and
that
becomes
the
dependency
that
I
think
people
want
it
to
be
right.
Where
data
I
can
say:
okay,
we're
not
we're
not
dealing
with
the
tracing
implementation
anymore,
and
then
we
can
say
now.
C
Here's
our
road
map
for
bringing
these
auto
instrument
ORS
in,
even
though
I
still
think
we
should
wire
a
few
of
them
up,
because
they've
shown
me
a
lot
of
about
the
surface
area
of
the
library
and
how
it
works
everything.
So
it's
still
very
valuable
I,
don't
want
to
say
that
it
isn't,
but
but
the
mechanics
of
like
what
goes
first.
Maybe
we
refine
it
yeah.
E
E
C
Daniel
before
you
leave
myself
David
and
Phil
we're
all.
We
were
brought
on
by
light
step
to
help
out
with
the
with
the
Ruby
library.
So
we
actually
work
for
a
different
organization,
but
they've
contracted
with
us
to
just
try
and
help
move
things
along
and
come
in
and
just
provide
some
juice
where
we
can
so
good
to
meet.
You.
A
Yeah
I'm
I'm
gonna
spend
some
time
later
this
week,
yeah
going
over
the
issues
and
the
issues
in
the
code,
the
hot
story
trying
to
figure
out
where
and
yeah
how
I
think
sorry
I've
been
out
and
been
traveling
for
most
of
the
summer,
but
I
should
be
I
should
be
back
for
the
next
few
months,
so
yeah
cool.