►
From YouTube: 2022-03-29 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Hello,
I'm
just
trying
to
figure
out
how
to
get
zoom
back
we're
at
google
hey
there.
It
is
how's
it
going
not
too
bad
how
you
doing.
Oh,
pretty
good,
just
chasing
down
some
some
missing
spans.
So,
oh,
no
not
chasing
down
some
missing
spans,
trying
to
figure
out
where
spans
come
from
the
opposite
of
missing
spans.
The
mystery
span:
yeah
mysteries
fans,
yeah
yeah,
it's
exciting
stuff,
but
all
good
over
here,
hey
eric
howdy,
you're,
muted,
but
that's
okay.
Whatever
you
want
to
do.
C
All
right,
it
is
about
five
after
or
so
go
ahead
and
kick
it
off
with
a
review
of
the
specs
egg,
and
then
we
can
jump
into
prs.
Metrics
walkthroughs,
whatever
makes
most
sense.
C
Right,
the
spec
sig
was
short
and
bullet
points,
although
one
of
these
points
went
on
for
quite
some
time,.
C
There
was
a
clarification
around
the
set
status
api.
I
don't
think,
there's
any
changes.
I
think
the
wording
has
just
been
changed
to
make
a
little
bit
more
sense.
It's
a
it's
an
open
pr,
but
it
seems
pretty
uncontroversial.
C
As
far
as
I
can
tell,
the
histogram
aggregation
seemed
like
it
was
kind
of
like
left
up
to
the
user
a
little
bit.
C
It's
like
the
histogram
aggregation
informs
the
sdk
to
select
the
best
histogram
aggregation
available,
I.e,
explicit,
bucket
histogram
aggregation.
C
But
again
this
is
open
and
I
think
they
were
just
saying
comment
and
bike
shed
on
the
issue
for
now.
C
The
one
that
went
on
forever-
I
believe,
is
this
one,
and
basically
there
is
a
situation
where
you
can
register
views
that
are
in
conflict
with
each
other.
C
C
Ultimately,
there
are
a
couple
things
that
you
can
do.
This
was
pared
down
from
this
end
up
getting
paired
down
in
the
discussion,
but
you
could.
One
discussion
was
whether
or
not
this
is
actually
a
initialization
time
thing.
If
this
is
an
sdk
initialization
time
thing,
one
of
your
options
is
to
fail
fast.
If
you
would
like
to,
I
think
we
tend
to
not
do
that
in
ruby
as
much
as
possible.
C
Is
to
just
log
that
there's
conflicting
views
but
but
honor
the
views
so
still
kind
of
export
the
outputs
of
the
conflicting
views
that
one
it
seems
to
be
like
the
the
most
sensible
one
to
me
from
this
conversation
and
then
there's
a
third
one
that
was
kind
of
a
little
more
weird
which
just
logged,
but
only
honor,
the
first
view
that
was
not
in
conflict.
C
So
so
I
think
that
one
was
actually
cast
aside.
That
was
cast
aside
as
a
bad
idea,
so
we're
kind
of
left
with
the
other
two
options,
and
I
think
generally,
it's
probably
going
to
be
up
to
the
side
we'll
see
if
there
is
actually
like
a
official
kind
of
spec
stance
on
this.
But
it
seems
like
if
this
was
an
initialization
time
thing
and
you
wanted
to
fail
fast,
that's
an
option,
if
otherwise,
logging
and
honoring
the
view
is
also
an
option.
C
C
But
I
remember
there
were
I
mentioned
last
week
that
there's
at
least
some
interest
in
trying
to
introduce
some
kind
of
sprint-like
notion
to
hotel,
probably
more
like
at
the
spec
level
anyways.
I
don't
think
this
is
something
that
would
be
happening
in
the
ruby
sig
I
mean
unless,
unless
we
really
want
to,
I
mean
that's
up
to
us,
but
the
robert
wants
to
be
the
scrum
master
on
this
one,
no
all
right
but
yeah.
C
So
I
think
ultimately,
maybe
they
will
experiment
with
this
at
the
spec
level
and
I
think
the
real
ideas
there
are
to
at
least
have
like
some
points
of
clear
focus
for
the
specs
egg
during
any
given
amount
of
time
and
just
kind
of
having
an
idea
of
like
what
how
many
things
are
currently
in
flight
for
the
spec
sig
to
see
like.
If
you
want
to
like
tack
other
things
on
like,
is
that
even
possible?
C
So
I
don't
know
I
I
understand
all
the
reasoning
behind
it,
like
part
of
me,
thinks
it's
very
ambitious
to
think
that
sprint
is
going
to
work
for
for
the
suspect,
sig,
but
at
the
same
time
I
kind
of
understand
the
reasonings
behind
it
and
it's
probably
worth
the
experiment
to
see
to
see
how
it
goes,
because
maybe
it
will
be
awesome.
E
It
seems,
like
you
said,
very
ambitious,
but
the
motivation
seems
to
be
sound
whether
or
not
the
the
means
is
like
the
right
way
to
approach
it.
I
don't
know
yeah.
C
Yeah,
I
I
don't
want
to
conjecture
about
how
how
that
will
go,
but
I
definitely
think
it's
coming
from
the
right
place
and
it
makes
sense
to
try
you.
You
never
know
how
things
are
going
to
work
out
unless
you
try
them.
E
Cool
does
that?
Does
anybody
want
to
talk
about
any
prs?
I've
been
trying
to
go
through
some
of
them
this
morning.
I've
merged
a
couple.
I've
got
like
another
one
about
to
be
merged,
one
got
closed
and
I'm
taking
it
over
because
the
approach
was
deemed
unworthy
by
francis
and
we
don't
define
that
law.
E
I'm
going
to
be
working
on
some
exporter
stuff
today
and
tomorrow,
trying
to.
E
Just
like
actually
do
some
of
the
stuff
we've
talked
about
in
the
past,
instead
of
leaving
it
as
just
talk,
because
it's
it's
kind
of
showing
up
as
a
problem
for
some
users
like
in
the
past,
we
talked
about
the
different
export
formats
like
grpc
or
export
protocols
like
grpc
json
and
then
we're
using
obviously
the
http
protobuf,
I'm
not
going
to
implement
the
other
styles,
but
I'm
going
to
actually
go
ahead
and
break
apart
that
gem
and
have
a
kind
of
like
an
open,
telemetry
exporter
or
yeah,
open
elementary
export,
otf
common
and
then
we'll
have
the
http
protobuf
and
then,
whether
or
not
I
like
stub
in
the
other
gems
as
like
to
do's
or
help
wanted
yeah
the
goal.
E
There
is
just
to
make
it
easier
for
someone
to
contribute
that
work,
instead
of
it
having
to
also
like
climb
over
the
hill
of
like
doing
that,
pre-work.
I
think
I
think
it'll
just
kind
of
open
the
door
for
someone
to
do
that.
Work
a
lot
more
easily
and
then
there's
some
changes
in
the
configurator
to
actually
let
people
know
that
if
they
specify
grpc,
it
won't
work.
E
So
yeah
that's
kind
of
like
what
plays
ahead
for
me.
Just
letting
people
know
that
I'm
going
to
be
working
on
that.
C
Well,
that
sounds
good.
I
did
notice
that
folks
are
using
the
agenda,
which
is
awesome.
I
feel
like
often
rob
records
us
some
awesome
notes
here.
You
can
tell
he
wasn't
here
last
week,
because
many
of
us
were
getting
no
notes
but
yeah.
C
So
since
we
actually
seem
to
have
an
agenda,
maybe
we
will
go
through
these
items
and
we
can
add
things
to
the
agenda
if
you
would
like
and
if
anything
we
start
running
short
on
time
and
something
is
super
critical
to
speak
up,
but
the
first
bullet
point
is:
can
we
get
these
merged?
C
And
these
are
these?
It
appears
as
though
they
are
probably
all
approved.
D
C
I
think
we
don't,
which
is
probably
part
of
the
reason
why
we
have
some
old
stuff
hanging
around,
but
I'm
not
sure
if
there
was
yeah.
I'm
not
sure
what.
If
any
reasoning,
if
there's
any
reason
that
some
of
these
did
not
get
merged.
C
D
Sorry,
but
no,
I
was
going
to
say,
I
think,
that's
up
to
the
maintainers
like
we're
whether
we
say
like
yeah
thumbs
up
thumbs
down.
I
think
we
would
have
said
that
in
the
reviews
like
if
we
agreed
or
disagreed,
since
these
at
least
went
through
a
maintainer
and
got
an
approval
from
at
least
sorry
one
approver.
E
Yeah,
sorry,
that's
that's
what
I've
been
trying
to
do
this
morning
just
going
through
and
getting
some
it
it's
building
up
right,
like
we
have
even
just
28
prs
in
the
repo
right
now,
not
even
thinking
of
just
the
approved
ones,
I'm
trying
to
actually
kind
of
burn
down
that
list
of
it,
so
that
that's!
I
just
put
the
onus
on
on
me
for
a
bit.
E
I'm
been
neglecting
it
a
bit,
so
I'm
just
spending
this
week
trying
to
get
things
back
in
like
fresh
state
in
terms
of
like
what
we
should
be
doing.
I
think
once
it's
approved
by
an
approver
again,
it's
just
the
onus
is
on
one
of
the
maintainers
and
there
isn't
any
like
reason.
These
are
sitting
stale
other
than
I
just
haven't,
really
looked
at
them
closely
enough
yet
to
merge
them
in
everything.
E
Plus
I
do
like
reading
the
comments
and
looking
at
the
code
and
just
like
being
thorough
there
to
talk
to
the
already
capped
one
at
the
bottom.
We
can
ignore
that
one
for
now
we're
waiting
on
andy
to
just
check,
I
think,
was
the
comment.
Aerial
left
regarding
binary
encoding
for
topics
and
I
think
in
ruby
kafka.
E
We
handle
that
so
he's
actually
looking
into
that
to
see
if
we
need
to
handle
that
case
here
properly
like
if
we
need
to
do
anything,
basically,
I'm
not
sure
so,
it's
kind
of
just
waiting
on
him
to
look
at
that
and
once
that's
good,
then
we
can
bring
it
in.
C
E
I
haven't
really
looked
at
these
other
ones
too
much
other
than
the
log
status,
one
that
one
I
was
going
to
bring
in.
Let's
see
I
finished.
C
Are
these,
it
looks
like
a
lot
of
these
are
kind
of
in
the
instrumentation
world?
Not
all,
but
would
is
some
of
this
complicating
the
split
out
of
contrib.
B
Laziness
is
complaint
or
just
time
time.
Priority
riser
ring
is
complicating
the
split
out
of
contribution
all
right.
We
just
by
we
it's
the
royal
way.
It's
me
I
just
need
to
like
do
it
so
yeah,
I'm
working
on
it,
I'm
trying
to
clear
some
time
ariel
and
I
can
sink
on
maybe
pair
again.
We
made
some
really
good
progress.
The
first
time
we
paired.
C
C
I
feel
like
I'm
derelict
in
my
duties
for
the
most
part,
and
I
try
not
to
merge
a
lot
of
stuff
because
I
do
feel
like
I
am
a
little
less
in
touch
than
like
robert
for
example.
C
So
I
don't
want
to
mess
things
up
by
being
too
eager,
but
I
feel
like
I
can
definitely
and
reviews
and
comments
to
help
kind
of
move
this
stuff
through
and
if
ever
I
can
be
of
helpful
or
if
ever
I
can
be
helpful
in
getting
things
like
unblocked,
always
feel
free
to
reach
out
to
me,
and
I
will
jump
on
things.
B
E
Don't
feel
like
I
again,
I
I'm
I
feel,
like
I'm
a
bit
of
a
walker
position,
so
I
think
that's
where,
like
the
splitting
out,
work
becomes
handy,
but
I
also
don't
think
it's
like
extremely
time
sensitive,
either
again
like
if
some
of
these
issues
that
are
like
sitting
open
are
like
high
severity,
and
it's
like
we're
like
they're
all
important.
I
don't
want
to
like
diminish
that,
but
it's
like
some
of
them
might
be
like
lower
urgency
than
others.
E
But
if
someone
sees
someone,
that's
like
this
like
needs
to
be
fixed
and
released
like
today.
I
don't
think
there's
anything
wrong
with
like
it
can
happen
in
slack
like
just
like
identifying
that
urgency
or
that
sense
of
like
pressure
on
it
like
that,
does
help
it
shouldn't
be
necessary,
but
it
might
help.
D
I
think
one
of
the
things
that
it's
hap,
that
we
want
to
do
so,
like
one
person,
for
example,
submitted
four
patches
here
and
so
psychologically.
If
I'm
waiting
now
to
almost
you
know,
some
of
these
are
are
19
days
old
right.
It
makes
me
if
I
were
a
contributor.
D
It
would
make
me
feel
like
the
feedback.
Loop
is
very
slow
in
order
for
me
to
get
things
addressed,
and
I
have
to
constantly
maintain
those
things
myself
on
a
fork
or
whatever
it
is,
and
so
that
that
might
lead
to
discouragement.
I
know
it
would
discourage
me
so
if,
even
if
it's
a
small
fix
or
something
it,
I
think
what
that
does
is
build
a
little
bit
of
a
psychology
or
or
sets
a
tone
for
people
to
feel
like
their
contributions
are,
are
released,
timely
for
them.
D
If
that
makes
sense-
and
I
think
that's
more
about
that
feeling
of
of
of
turn
around
time-
that
feeling
of
acceptance
that
feeling
of
willingness
to
contribute
more
because
the
the
longer
the
feedback
loop
for
me,
the
less
likely
I
will
be
to
contribute
in
the
future.
C
I
I
agree,
and
thanks
for
bringing
that
up,
I
think
we
should
definitely
try
to
engage
people
who
are
contributing,
especially
these
kind
of
like
smaller
quality
of
life.
Slash
bug
fix
things.
I
think
the
the
more
we
can
engage
with
new
people
who
are
helping
out
like
the
more
help
we
will
get.
C
So
I
guess
thanks
for
calling
that
out-
and
I
think
we're
talking
probably
about
these-
these
four
active
job
action,
job
xcon
bunny.
So
maybe,
if
we
wanted
to
prioritize
getting
some
of
these
things
in
those
might
be
ones
that
we
could
look
at.
D
I
don't
know
that
we
need
to
look
at
them
right
now
on
this
cause.
I
know
the
the
thing
is
we
got
to
give
robert
a
chance
to
kind
of
ingest
what
he's
seeing
and
give
him
a
chance
to
read
it
without
feeling
the
pressure
of
six
of
us
kind
of
watching
over
his
shoulder
and
be
like
hurry
up.
B
It
takes
like
an
hour
just
to
like
spin
everything
and
whereas
like
if
it's
just
you
know
like
let's
say,
rob
or
ariel
or
someone
has
reviewed
it
and
it's
like
we
can
sync
here
and
they
can
be
like
cool
like
here's,
the
specific
thing
to
watch
out
for,
like
oh,
you
have
to
make
sure
the
memcache
port
on
your
container
chain
like
so
I
don't
know
it
could
help
to
just
say,
let's,
like
add
a
couple
minutes
in
this
meeting
to
say
like
pr
review
for
specifically
stuff.
That's
like
gotten
approval.
B
Maybe
that
way
like
that's
like
you
know,
I
feel
like.
Traditionally,
it's
been
like
we're
looking
for
like
two
approvals
kind
of
of
this
group
here,
yeah
yeah,
I
don't
know
thinking
out
loud
how
to
make
this
work
gooder.
B
I
do
think
when
it's
split
it
when
can
trip
split
out
it'll,
just
because
there's
more
people
who
can
push
things
through,
like
I
think,
that'll
help.
So
you
know,
I
think,
I'm
a
blocker
here
to
some
extent.
C
Yeah
thumbs
up
to
keeping
the
specs
saved
like
10
minutes.
I
think
there's
a
lot
that's
talked
about
there.
I
can
always
like
cherry
pick,
the
relevant
things
and
at
least
having
like
a
a
block
to
discuss
prs
and
at
a
bare
minimum,
at
least
kind
of,
have
a
focus
list
for
us
to
kind
of
like
review
during
the
week
to
at
least
at
a
bare
minimum.
Have
a
decision
on
at
the
next
time.
I
think
would
be
a
a
good
idea.
B
B
D
Am
I
the
only
one
that
lost
eric
we've
all
lost
eric?
Oh
okay,.
C
D
I
I
think
what
he
was
saying
was,
although
we
can
improve
on
some
things,
we're
not
as
bad
as
other
six.
E
C
So
in
I
guess
in
the
spirit
of
having
like
a
focus
list,
do
we
want
to
maybe
try
to
like
do
the
top
half
of
this
list,
maybe
from
active
job
up
just
trying
to
get
like
a
review
in
on
those
sometime
this
week
and
and
feedback
in
and
if
they're,
okay,
merge
them
and
if
not
we'll
figure
out
what
to
do
with
them
next
week.
C
And
then
we
can
try
to
move
through
some
of
these
older
ones
that
we
may
have
to
play
a
little
ketchup
to
see
if
they're
still
relevant
or
like
what
actually
happened
back
then.
C
D
It's
like
you
know
if
I
could
get
eyes
on
it,
that'd
be
great,
so
this
is
the
one.
This
is
a.
I
finally
followed
up
on
the
one
pr
that
we
talked
about
with
respect
to
regen
dependencies.
So,
as
you
know,
the
other
github
monolith
doesn't
use
rubygems
to
load
dependencies.
D
So
what
I
did
was
per
our
conversation.
Robert
was
went
through
and
threw
the
versions
in
version
lookups
in
every
gem
where
was
possible,
so
that
was
step
one.
So
now,
there's
a
bunch
of
like
structural
kind
of
duplication
everywhere,
but
step
one
just
use
the
version
constants
wherever
possible,
and
that's
where
we
are
so.
This
will
make
it
possible
for
us
to
adopt
additional,
auto
instrumentation.
E
Okay,
I
was
looking
at
this
and,
like
it
yeah,
it
all
looks
good.
I
wanted
to
ask
you
if
it
made
sense
for
your
use
case
to
bypass
this
check.
E
E
D
A
specific
problem
with
the
faraday
gem
that
this
compatibility
check
did
help
us
identify
with
things
that
were
not
related
to
the
monolith,
but
so
I
find
that
the
compatibility
check
to
be
good
and
I
think
that
if
something
were
to
break
it
would
give
me
something
to
look
into.
D
But
if
we
bypass
the
compatibility
check
and
we
start
mixing
things
in
and
they're
broken,
then
I
have
to
say
like.
Oh,
I
have
to
now
disable
this
instrumentation
that's
going
to
impact
a
bunch
of
people
if
other
people
are
trying
to
do
term
upgrades
and
stuff
like
that,
so
I
would
rather
it
be
non-obtrusive
breaking
than
absolute
breaking.
But
you
know.
E
D
Yeah
my
escape
hat
was
was
essentially
monkey
patching
the
instrumentation
and
adding
the
version
checks
myself
in
order
to
make
them
happen,
and
that's
not
sustainable
for
us.
I
don't
think.
G
Do
I
do
see
some
constant
calls
in
in
the
new
in,
like
the
right
hand,
of
the
ors
here,
for
instance,
the
q
version
there?
If,
if
q
isn't
loaded,
there's
something
that
would
catch
the.
D
Exception
so
the
way
that
these
are
invoked
is
there's
a
installable
predicate
check.
First,
that
checks
for
the
constants
being
defined
in
almost
every
case
of
these
gems,
okay
and
then
it
goes
and
looks
for
the
constants,
and
then
it
goes
through
the
this
flow
of
doing
the
compatibility
check
and
then
it'll
do
the
injection
of
the
patches
right
so
first
to
check
to
see
if
there's
any
constants
present.
Second,
it
checks
to
see
the
version,
compatibility
and
then
third,
it
tries
to
put
the
mixins
in.
G
G
D
C
This
is
slightly
interesting.
Actually,
I
know
back
when
we
first
started
introducing
auto
instrumentation
and
contributors
for
using
gem
dot
loaded
specs.
I
thought
about
this
for
a
moment
whether
or
not
like
this
versus
the
constant
would
be
better.
C
C
I
think
you
have
to
like
require
something
in
order
for
it
to
be
loaded,
but
if
anybody
knows
the
intricacies
here
feel
free
to
chime
in,
but
I
did
ask
myself
the
question,
because
I
was
kind
of
anticipating
that
the
version
would
actually
use
constants
from
the
package,
and
this
is
really
only
because
that's
how
a
lot
of
things
worked
in
in
new
relics,
auto
instrumentation,
I
think
they
generally
relied
on
on
the
constants
versus
the
gem
loaded
specs.
D
So,
as
I
understand
it,
jump
loaded
specs
it's
if
something
when,
when
your
environment
is
bootstrapped,
say
you're
using
bundler
that
it
when
you
go
and
require
your
dependencies,
it's
going
to
go
and
load
the
jump
specification.
I
have
not
walked
through
all
of
that,
but
there
are
some
cases
where
the
constants
don't
exist,
and
eric
pointed
this
out
that
the
the
data
dogs,
auto
instrument-
you
know,
instrumentation,
you
know
in
cases
like
in
our
case
right
delayed
job,
doesn't
define
a
specific
version,
constant,
that's
in
the
gem
spec
itself.
D
There
are
things
like
the
google
protobuf
gem
that
the
version
is
in
some
package
that
you
don't
necessarily
reckon
you
know.
You
won't
won't
see
and
rails,
for
example,
here
right
it
has
a
version
function
that
returns
a
gem
version
object
instead
of
return
of
instead
of
using
the
constant
again
the
aws
core.
So
like
all
these
little
edge
cases,
all
these
little
situations
are
all
a
little
bit
different
and
I.
G
Only
raised
this
because
in
our
instrumentation
at
honeycomb
it
might
be
naive,
but
any
time
that
we
were
trying
to
do
lookups
like
this,
we
just
wrapped
it
in
an
exception,
handwriter
rescue
load
error
and
then
that
would
trigger
a
couldn't
load.
That
instrumentation
and.
G
Maybe
that's
a
garden,
that's
worthy
to
add
to
the
gem
version.
Maybe
we
have
that
card.
E
Sorry,
I
was
going
to
say
it's
just
the
the
check
is
either
in
the
base
or
the
registry.
It
might
be
in
the
adjacent
file
to
this
one
called
registry.
F
F
E
Yeah
there
we
go
so
when
it
goes
through
and
it
actually
tries
to
install
the
install
will
run
through
the
presence
check
and
the
compatibility
check.
So
if
either
of
those
checks
raise
because,
like
they're
trying
to
reference
a
constant,
that's,
not
defined,
you
get
a
slightly
different
fail
to
install
instrumentation
message
like
because
there's
the
the
happy
one
where
it's
like.
E
Oh
you
don't
have
this
gem,
like
compatibility
check
with
the
present
check,
failed,
but
then
there's
the
like
something
exploded,
one
and
then
you'll
actually
get
the
back
trace
and
what
the
instrumentation
name
was
that
it
tried
to
install
a
fail.
So
there
is,
there
is
guards
around
that.
That's
a
good
like
question
rob
because
that
could
suck
if
we
didn't,
but
we
have.
We
have
actually
run
into
this
check
in
production
before
ourselves.
So.
G
Pads
that
would
conceivably
be
calling
present
and
gem
version
in
this
are
basically
go
through
here.
The
instrumentation.install
calls
those
things
and
it's
wrapped,
in
a
exception
handler
so.
E
Yeah
I
actually
like
looking
at
like
aerials
pr.
E
There
is
like
this,
like
sense
of
like
duplication,
but
like
kind
of
as
like
we're
just
discussing
like
some
gems,
don't
define
a
version
or
they
do
it
in
different
ways.
So,
like
the
fact
that
it
looks
a
little
bit
repetitive,
I
think
is
okay,
because
I
think
every
instrumentation
package
is
going
to
be
a
little
bit
different
and
we
have
to
account
for
that
like
trying
to
generalize.
It
right
now
might
be
a
little
over
ambitions
and
then.
D
Yeah,
the
the
the
pr
that
this
derived
from
or
right
that
this
came
from
has
the
has
an
attempt
at
generalization.
So
if
you
are
interested
in
taking
a
look
at
what
generalization
might
look
like,
take
a
look
at
that
other
pr.
G
It's
not
awful
to
like
gems
are
going
to
be
the
things
that
we
are
instrumenting
are
going
to
do
things
differently
and
having
the
opportunity
to
say
this,
instrumentation
needs
to
look
up
the
gem
version.
This
way
seems
reasonable.
A
couple
different
ways
to
look
it
up.
One
is
maybe
faster
than
the
other.
Maybe
it's
not
yeah
things
yeah,
it's
maybe
duplicative,
but
I
I
I
think,
what
I'll
rephrase,
what
or
paraphrase
what
robert
you
were
saying.
G
It's
maybe
makes
the
gem
version
method
a
little
bit
more
reliable,
which
is
the
monolith
problem.
Where
can't
rely
on
one
way
to
look
up
a
gems
version.
E
There's
also
some
code
in
instrumentation
base.
If
I
recall
correctly,
we
don't
need
to
look
it
up,
but
I
think
it
tries
to
infer
the
version
from
like
looking
at
the
like
it.
It
uses
the
constant
lookup
to
try
to
find
a
version.
I
think
it
does
that.
I
don't
know
if
I'm
imagining
that
now
or
like
this.
E
The
instrumentation
that's
something
else,
never
mind
you
can
go
to
that
comment,
but
yeah
anyways,
to
kind
of
like
sum
up
my
thoughts
on
ipr,
it's
good
we
can
after
this
call,
I
can
approve
and
merge
it
after
some
of
those
other
more
older
ones.
Finish:
ci
yeah
they're,
like
the
most
pedantic
comment
I
could
make
about
it
and
I
don't
actually
want
you
to
make
this
change,
because
the
comment
feels
too
brutal.
E
Is
that,
like
you,
could
move
the
constant
lookups
on
the
left
side,
left-hand
side
of
your
operator,
because
it's
faster
potentially
but
don't
don't
feel
like
you
need
to
make
that
change,
because
that's
kind
of
ridiculous,
but.
F
C
Like
is,
is
the
constant
based
version,
lookup,
more
reliable
and
is?
Would
there
be
any
reason
to
consider
just
like
switching
over
to
that
as
like
the
preferred
preferred
way
to
look
up
the
version
and
then,
for
obviously
with
a
with
leniency,
for
you
know,
edge
cases
and
other
things
we
don't
have
like
a
reliable
version,
constant.
E
I
I
think,
that's
also
a
very
reasonable
comment
because,
like
why
would
the
two
differ
like
in
what
cases
could
they
differ?
I
I
don't
know
if
there
is,
but
if
one
of
them
is
referencing
and
code,
the
version
it
says
it
has
do.
We
trust
that
more
prob,
probably
maybe.
E
D
C
Every
gem
I've
seen
ever
like
the
gem
spec
references
this
thing,
so
I
kind
of
think
you
can
get
away
with
just
the
with
the
version
by
a
constant
lookup
when,
when
such
a
version
exists
and
could
probably
get
rid
of
the
gem
loaded
specs
part
of
this.
B
The
whole
point
of
this
pr
is
that
there's
some
cases
I
think
we
need
the
loaded
specs
there's
some
cases
where
it's
hand
coded
in
there
in
some
cases
where
it's
like
string
and
interpolated
like
they
read,
they
interp
they
like
call
like
g
sub
on
the
readme
and
stuff
like,
I
think
so.
I
think
we
do.
I
think
we
need
both,
but
I'd
be
totally
fine
with
the
either
order.
I
don't
think
it
matters
too
much.
B
It's
a
one-time,
there's
no
performance
issue,
we're
worried
about.
So
my
opinion
is
it's
less
work
to
just
do
what
we
have
and
if
somebody
wants
to
change
it,
they
can
change
it.
G
Yes,
okay,
I
made
a
comment
in
chat.
I
noticed
some
of
the
calls
to
loaded
specs
string
of
the
version,
the
gem
name,
dot
version
and
then
some
of
them
are
in
that
version
for
the.
D
Try
it
very
very
esto,
roberto.
I
love
this
feature
called
a
suggestion.
I
will
accept
your
comments
and
then
you'll
get
credit.
D
But
it
that
just
means
that
we're
missing
test
coverage.
E
The
reason
for
that
I
think
the
missing
test
coverage
on
those
is
because
you
have
to
pull
in
it's
it's
a
pain.
You
asked
to
mock
those
ones
yeah.
I
know
that
firsthand
but
yeah,
I
think
with
with
the
addition
of
like
actually
doing
the
constant
look
up
or
like
kind
of
like
we're.
Looking
at
your
like
action,
viewed
up
version,
adding
ampersands
all
over
the
place
makes
sense
before
we
were
doing
that.
E
I
didn't
like
it
as
much
because
it
kind
of
hit
away
the
error
a
little
bit
of
what
went
wrong
like
you
didn't
know
why
it
failed.
Actually
I
don't
know,
I
don't
ignore
everything
I
just
said.
D
So,
taking
a
taking
a
deep,
taking
a
deep,
deep,
deep
breath
here,
the
the
exceptions
to
the
rule
are
rails,
having
its
own
version
function,
aws
core
doing
some
things
like
reading
a
file
to
figure
out
its
version,
but
that
ends
up
generating
a
constant,
that's
not
named
version.
It's
called
like
core
gem
version
and
then
delay
job
which
doesn't
have
a
version
explicitly
in
ruby
code
at
all.
So
in
the
in
the
cases,
the
only
one
that
we
actually
need
to
do,
the
gem
loaded,
specs
look
up
is
going
to
be
delayed
job.
G
G
B
G
C
And
I
feel
like
we
could
always
we
could
have
the
convention
to
prefer
the
the
constant
based
version
if
it
exists,
if
it
doesn't
gem
loaded
specs
is,
is
an
option
if
that
works.
C
G
So,
like
the
rails
instrumentations,
we
support
back
how
many
rails
versions
and
how
long
have
they
had
the
dot
version
method
on
their
classes?
I
don't
know
that's
what
I
think
loaded
specs
save
this
from
case.
Somebody
doesn't
have
a
constant
or
have
this
method
on
a
gem
that
somebody's
using
from
the
mists
of
the
past.
G
I'm
I
I
think
I
might
be
a
fan
being
sort
of
still
new
here
rub
some
ampersands
on
it
keep
the
loaded
specs
on
the
left,
because
it's
it's
current
behavior,
so
we
know
we
won't
break
backwards
and
refine
later.
If
we
find
that
we
can.
Is
that
reasonable.
E
C
I'm
also
kind
of
happy
with
getting
rid
of
it
unless
we
need
it.
I
feel
like
there
might
be
like
the
occasional
thing
where
you
need
to
fall
back
to
that,
but
I
feel
like
if
you
can
use
the
constant-based
lookup,
you
should
be
okay
and
I
feel
like
we
do.
Have
it's
been
a
while,
since
I
belonged
to
all
of
the
appraisals,
but
we
should
at
least
have
like
some
sparse
version
testing.
At
least
we
should
be
at
like
the
goal
posts
and
some
some
versions
in
between.
C
Okay,
so
it
sounds
like
there
will
be
an
update
to
this
and
we
should
all
take
a
look
when
it
comes
in
and
we
have
some
direction.
E
E
D
Likewise,
so
what
we
need
to
do,
though,
also
is
like,
is
encode
these
ideas
somewhere
so
like
we
got
to
figure
out
a
way
to
like
encode.
These
decisions.
E
That's
a
really
good
point:
I'm
I'm
really
historically
bad
at
that.
It's
just
like
keeping
it
in
your
brain
is
not
good
enough
when
you
have
a
community
of
people
working
together,
but
I
behave
as
if
it
is
do
you
like.
Does
anybody
have
any
thoughts
of
like
like
where
for
something
like
this?
It's
like.
We
can
agree
that
this
is
a
good
idea.
We
want
to
follow
it
going
forward
as
like
new
instrumentations
get
added,
etc,
but
like
where
do
we
just
stuff
this
information?
E
Even
if
it's
like
a
dock
in
the
repo
like
it
can
be
anywhere,
it
doesn't
have
to
be
too
complicated
to
start
like,
even
just
like
a
folder
called
docs,
and
then
it's
like
decisions
on
instrumentation
like
something
I've
always
really
liked
in
working
on
some
projects
where
people
run
like
decision
logs,
not
like
not
to
be
confused
with
like
a
change
log
but
like
a
decision.
Log
is
like
the
apr.
E
Yeah
yeah
it
it
doesn't.
I
don't
know
I
yeah,
it
could
be
an
adr.
I
honestly
would
if
we
wanted
to
not
start
with
something
a
little
more
like
I've
seen
them,
they
seem
kind
of
involved,
or
maybe
I'm
just
like
so
adverse
to
writing-
that
they
look
involved
but
like
if
we
had
a
bullet
point
list
with
like
decisions
and
dates
on
them.
Like
that's
good
enough
for
me,
I
don't
know
how
many
will
feel.
D
I
think
that's
the
spirit
of
adrs
right.
Adrs
are
like
imagine
them
as
being
like
small
database
migrations
and
then
the
final
documentation
is
a
reflection
of
the
current
state
of
all
those
adr's
rolled
up,
and
it
doesn't
have
to
be
like
a
20-page
document
like
it
happens
at
some
companies
that
have
an
octocat
as
the.
E
I
think
that's
the
thing
is
I've
whenever
I've
seen
an
adr,
it's
like
someone's
magnum
opus,
and
I
was
like
whoa.
This
is
like
my
computer,
like
my
sublime
crash
trying
to
load
the
dog,
you
know.
C
I
think
this
is
a
good
idea
and
I
think
we
should
find
a
way
to
record
these.
That
is
that
has
minimal
friction
and
it
could
just
be
like
once
we
get
this
thing
started.
We
could
just
quickly
jump
some
a
note
down
in
the
agenda
with
like
a
a
star
or
some
sort
of
thing
to
de-mark
this,
as
this
should
go
in
the
decision
logs.
I
feel
like
there's
been,
there
have
been
so
many
conversations
I
know
like
back
in
the
early
days.
C
C
We
had
conversations
about
like
strict
mode
or
not,
and
just
a
bunch
of
things
that
I
feel
like
we've
had
to
like
rehash
like
many
multiple
times
as
people
come
into
the
project,
and
I
just
feel
like
if
we
had
some
of
these
things
around,
that
it
would
be
useful
for
us
to
remember
what
we
decided
actually
and
useful
for
people
new
to
the
project.
C
C
E
F
C
D
Okay,
I
just
want
to
say
folks:
if
you
have
some
time,
we've
got
a
bunch
of
things
that
still
need
review
other
than
the
thing
I
just
asked.
So
if
you
can
dedicate
like,
I
don't
know
an
hour
to
look
at
a
pr
or
two
a
day,
that'd
be
like
huge
and
like
and
feedback
to
people.
Second
thing:
we've
had
a
bunch
of
mergers
that
have
occurred,
but
we
haven't
cut
any
releases
and
frankly,
I've
lost
track
of
all
the
things
that
we've
kind
of
rolled
in.
D
So
I
know
we
don't
want
to
like
do
like
a
release
them
all,
but,
like
anybody
got
any
tips
on
narrowing
them
down
to
figure
out
which
gems
we
want
to
roll
out
and
then
lastly,
this
was
gonna
be
a
longer
conversation,
but
one
of
the
challenges
that
we've
had
with
doing
the
extraction
of
the
contrib
repo
rob
is
gone.
D
I'm
sorry
eric
is
gone
right,
but
one
of
the
challenges
we've
had
is
the
base
instrumentation
coupling
between
the
sdk
gem
and
the
instrumentation
based
gem,
because
they
both
rely
on
the
registry
class.
D
So
if
we
were
to
split
out
the
contrib
repo
and
take
only
the
instrumentations,
the
base
gem
is
going
to
be
required
in
both
directions,
so
making
changes
to
things
around
the
base.
Instrumentation
is
a
little
bit
harder.
Every
instrumentation
that
derives
from
bass
is
auto,
registering
itself
with
the
registry
right.
So
that's
where
that
coupling
comes
from
and
then
there's
const
there's
a
essentially
service,
lookup
right,
so
doing
full
class,
calling
it
by
the
class
method
for
that
memoized
registry
variable
in
the
sdk
configurator.
D
E
If
you
can
wait,
we
could
talk
about
like
this.
That
would
be
a
pretty
useful
conversation
for
like
next
week.
If
you
have
some
thoughts,
I
think
that
the
tld
of
my
like
gut
reaction,
because
I
thought
about
a
little
bit
before
it's
just
like
that-
instrumentation
based
gem
gets
split.
The
registry
stays
with
the
sdk
and
the
base
class
goes
to
the
other
side
of
the
fence,
and
it
depends
on
that
one
little
registry
file
that
stays
close
to
the
sdk.
E
I
think
so
because
the
one
of
the
motivations
is
that
if
someone
implements
their
own
sdk
and
still
wants
to
use
auto
instrumentation,
they
shouldn't
require
sdk
and
all
the
auto
instrumentation
should,
in
theory,
work
because
it's
only
depending
on
the
api,
but
also
this
registry
thing.
So
that's
the
thing
like,
I
think,
that's
the
requirement
that
we
need
to
satisfy
is
that,
like
a
non-open,
telemetry
sdk,
that's
api
compliant
should
be
able
to
work
with
instrumentation.
C
I
feel
like
at
one
point
in
time
I
had
stuck
the
registry
in
the
api,
which
was
definitely
questionable,
but
it
does
solve
this
problem,
but
that
something
else
that
can
be
thought
about
it
sounds
like
robert
has
a
better
idea,
though
we
are
on
a
time
yeah.
I
will
do
my
best
to
try
to
work
through
some
pr's
this
week,
so
hopefully
we
can
maybe
try
to
like
get
things
back
on
track
and
then
kind
of
come
up
with
some
ways
to
keep
things
on
track
from
there.
So.