►
From YouTube: 2022-01-25 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
D
I'm
slightly
confused,
I'm
looking
at
my
calendar
and
like
I
have
copied
this
event
to
my
calendar,
which
is
how
I
got
here
but
like
on
the
open,
telemetry
public
calendar,
I'm
not
seeing
the
event,
I'm
just
curious
it.
How?
How
did
everybody
else
get
here
and
is
this
thing
on
the
hotel
public
calendar
or
did
the
event
kind
of
fall
off.
A
I
a
while
back
like
I
had
added
it
to
the
my
like
the
public
calendar
to
my
own,
like
google
calendar
and
then
obviously
the
zoom
meetings
changed
at
some
point
and
then
I
just
dropped
all
the
old
ones
and
re-added
the
calendar
and
that's
how
I
find
it
now.
I
don't
know
if
I
had
to
do
that
more
than
once,
but
that
was
approximately.
The
step
was
just
adding
the
calendar
to
my
google
calendar
and
the
links
in
there
trying
to
find
the
link.
Otherwise
is
a
pain.
D
D
D
D
All
right,
I
know
we've
kind
of
had
some
discussions
about
a
contrib
repo
and
I
feel
like
we
have
some
work
to
do
there,
so
I
will
try
to
kind
of
get
through
this
stuff
fairly
quickly,
not
just
kind
of
give
a
brief
overview,
not
dive
in
too
deep.
So
we
have
more
time
to
talk
about
other
stuff.
D
So
the
things
that
I
will
mention
is
that
j
macd
did
like
a
pretty
long
presentation
about
the
current
state
of
metrics
and
really
he
had
like
this.
D
Sub
presentation
was
in
the
presentation
about
some
commodities
that
he
was
kind
of
finding
with
the
current
apis
and
the
way
he
wanted
stuff
to
work
and
go
so
he
was
hoping
to
be
able
to
kind
of
relax
a
couple
of
things
in
the
specification
you
know,
within
the
constraints
of,
I
think
the
api
is
technically
supposed
to
be
stable,
but
he
was
saying
the
changes
that
he
wants
to
make.
D
There
would
be
things
that
could
be
backwards
compatible,
but
if,
if
you
are
interested
in
this,
I
would
recommend
kind
of
just
like
reading
through
these
slides.
The
key
points
were
that
he
wanted
to
have
like
multiple
callbacks
per
instrument
and
gave
some
examples
of
how
that
would
work.
D
And,
ultimately,
I
think
this
has
to
do
with
it.
Ties
into
views
and
views
is
kind
of
like
one
of
the
parts
of
the
the
sdk
that
they've
been
kind
of
like
punting,
but
I
think
somehow,
all
in
the
end,
this
ties
into
wanting
to
be
able
to
have
per
reader
metric
views
configuration,
and
I
think
ultimately,
it
seems
like
you
can
have
multiple
views
per
reader
is
kind
of
the
current
setup.
D
I
think
this
example
is
from
spec
as
it
currently
is,
and
he
would
like
to
be
able
to
have
reader
per
view,
and
it
would
kind
of
look
like
this.
So
if,
if
you
are
enough
into
metrics,
where
any
of
these
words
that
I'm
saying
almost
make
sense,
even
if
I
am
butchering
them
a
little
bit,
which
I'm
pretty
sure
that
I
am
feel
free
to
like
dive
into
these
like
a
little
bit
more,
I
know
js
is
a
little
bit
further
ahead
and.
A
A
It
does
report
request
up
pretty
close
there's
just
like
some
validations
that
need
to
be
added
and
some
tests,
but
it's
like
very
close
to
the
final
api
product
and
I'm
going
to
be
starting
on
the
sdk
stuff,
I'm
actually
meeting
with
them
this
afternoon
to
go
over
like
the
implementation
details
and
we'll
be
looking
at
adding
like
a
a
prometheus
exporter,
probably
as
well
in
the
near
future.
A
D
Cool
yeah,
no,
I
I
am
actually
very
interested.
I
kind
of
feel
like
I
feel
like
the
metrics
work
is
like
a.
It
is
a
big
chunk
of
work
and
I
feel,
like
everything
that
I
come
to.
An
hotel
is
already
like
half
finished
and
there's
like
so
much
ketchup
to
play
that
I
don't
know
where
to
begin
so
the
fact
that
we
actually
have
the
early
stages
of
something
concrete,
like
I
feel
like
I
could
follow
along
this
is
my
last
chance
to
like
start
at
the
beginning.
D
So
I
would
like
to
like
not
pass
this
one
by
and
we'll
yeah
try
to
get
some
time
to
to
look
things
over
and
then
I
think
I
can
start
comparing
with
some
of
the
other
frameworks
and
yeah
some
of
the
other
languages
and
come
up
to
speed.
I'm
not
multiple
at
a
time.
So.
A
Yeah
the
api
like
for
our
repo,
it's
a
good
spot,
to
jump
in
right
now,
because
you
can
just
like
side
by
side
the
api
spec
with
the
pr
and
just
follow
along,
and
you
can
see
like
how
it's
set
up.
We
did
like
similar
to
the
trace,
like
upgradable
tracer,
like
with
the
proxy
tracer,
we're
doing
that
approach
with
like
meter
provider,
meters
and
instruments
because
they
have
to
be
like
upgradable
after
they've
been
declared
so
that
one's
a
little
bit.
A
I
think
that's
the
only
part,
that's
like
a
little
bit
tricky
to
get
like
get
your
head
around,
or
it
was
for
me
this
just
like.
As
a
general
note
like
the
metrics
api
and
sdk
is
a
lot
more
complicated
and
muddled
feeling
than
the
trace
api
sdk.
D
The
one
thing
that
I
will
add
is
that
both
js
and
java,
I
think
when
they
were
talking
about
the
multiple
callbacks
per
instrument
for
async
instrument,
people
were
kind
of
thumbs-upping
that
and
saying
that
that
was
going
to
solve
some
of
the
problems
that
they're
running
into
so
cool
excited
to
see
that
we
are
moving
forward
and
ruby,
though.
D
And
yeah,
I
think,
having
a
better
understanding
of
this,
will
help
me
like
at
least
bring
back
some
of
these
issues
from
the
spec
sig
in
some
intelligible
way.
D
I
don't
know
a
lot
more
to
say
about
that:
the
sampling,
pr
that
I've
been
bringing
up
optimistically
for
at
least
the
last
three
months-
maybe
even
six-
I
don't
know
timely
flies
october,
so
five
months
whatever.
D
I
think
I
think
it's
really
ready,
like
it's
really
kind
of
like
last
call
for
for
reviews.
So
unless
anything
comes
in
during
the
last
calls
that
derails
this
it
does
have
quite
a
few
reviews.
People
are
generally
happy
with
it,
so
it
looks
like
it
is
going
to
merge
soon.
D
This
came
out
of
the
login
sig,
the
login
sig
wanted
to
add
a
new
like
logger
name
field
to
the
logging
data
model,
and
people
brought
up
the
fact
that
the
logger
name
is
really
analogous
to
the
instrumentation
library
name
in
in
the
rest
of
the
data
model.
So
why
not
just
reuse
that
and
then
you
know
there
were
some
discussion
about
how
the
that
kind
of
works,
but
now
the
name
is
not.
D
D
But
then
there
were
some
further
discussions
today
that
changing
that
instrumentation
scope,
and
if
that
is
what
people
are
providing
when
they
get
like
a
tracer,
then
you
know
the
scope
could
change
to
be
something
else.
Now
they
could
use
like
the
class
name
or
just
some.
You
know
imaginative
scope
that
they
wanted
to
use
and
we
would
lose
the
instrumentation
library
and
back
ends
have
already
kind
of
like
started
to
build
functionality.
D
On
top
of
that,
so
you
can't
really
pull
out
the
instrumentation
library
rug
from
underneath
people
who
have
already
started
building
on
top
of
it.
D
D
Ultimately,
I
think
they
were
thinking
about
under
instrumentation
library,
adding
something
called
like
additional
scope.
That
would
be
kind
of
a
hierarchical
nesting
of
information,
and
there
would
be
some
way
to
smooth
this
over
and
otlp.
I
think
it's
because
it's
like
an
added
field
that
it's
not
a
problem,
so
that's
ongoing.
I
think
tigran
is
bringing
it
up
because
he
really
needs.
D
Are
the
scenes
going
to
be
named.
He
kind
of
needs
this
to
like
wrap
up
the
logging
data
model,
which
is
supposed
to
be
on
this
quarter,
and
he
doesn't
want
to
wait
till
the
last
day
of
the
quarter.
So
he's
kind
of
just
really
calling
for
people
to
start
caring
about
this
and
giving
some
input
and
that's
where
that
landed.
D
And
if
anybody
is
super
interested
in
prometheus,
there
is
a
initial
prometheus
specification.
A
Well,
some
of
them
all,
just
I'm
gonna
like
follow
up
and
read
curious
about
the
prometheus
when
I'll
dig
into
that.
On
my
own
time,
though,
I
went
to
the
instrumentation
sig
last
week
and
it
there's
nothing
new
to
bring
back,
which
is
kind
of
unfortunate.
A
A
C
D
Where
should
we
head
next?
Are
there
any
issues
that
we
should
talk
about?
Is
there
any
issues
prs
or
contrib
related
stuff?
What
is
the
the
best
next
topic.
A
I
think
can
trip,
I
don't
know
if
anyone
actually
started
doing
it.
If
it
happened,
I
missed
it.
A
There
was
like
we
should
just
start
a
discussion
or
continue
existing
discussion
for
having
a
contrib
and
start
clarifying
what
lives
where
and
but
I
think
that's
just
something
that
needs
to
happen.
I
don't
know
if
we
want
to
do
that
right
now,
but
I
think
that
was
kind
of
like
the
drop-off
point
there.
I
think
we've
kind
of
settled
on
the
point
that
hey
yeah.
D
D
Are
there
a
big
question
about
maintainers
and
approvers?
I
think
we
already
kind
of
agreed
that
it
would
be
nice
to
to
add
some
more
folks
to
that
repo
probably
retain
what
we
currently
have.
A
D
Yeah
yeah.
No,
I
think
many
thumbs
up
on
these
suggestions.
D
He
also
kind
of
summarized
how
we
can
preserve
the
git
history,
which
is
nice,
saves
us
from
having
to
google
this
yeah.
D
Is
so
besides
actually
provisioning,
the
repo
is
there
anything
else
that
we
need
to
start
looking
at
in
order
to
get
this
off
the
ground.
A
A
A
I
don't
know
if
I
don't
want
to
volunteer
at
volunteer
aerial,
but
it's
like
if
you
feel
like
the
github
person,
might
be
a
good
person
to
lean
on
for
github
actions,
but
I
I'm
actually
really
excited
for
that
aspect
of
splitting.
The
that
you
own,
I
think
deployments
and
like
releases,
should
be
a
lot
simpler
with
the
two
repos
split,
because
it's
like
right
now
you
make
a
change
in
one
place
and
it
oh,
like
12.
Other
different
places
need
to
be
changed
in
lockstep,
which
is
kind
of
annoying.
D
Originally
we
kind
of
set
up
ci
through
circle.
I
think,
and
then
I
don't
know.
Setups
are
always
simple
when
you
start
things
off
and
then
you
just
gradually
add
to
them
into
the
point
where
they
become
incomprehensible.
But
then
at
some
point
I
think
an
aws
intern
came
through
and
converted
us
over
to
github
actions.
D
So,
but
I
believe
that
daniel
azuma
knows
a
lot
about
all
these
things.
I
think
he
ultimately
kind
of
ended
up
reviewing
and
correcting
a
lot
of
the
the
work
on
that
conversion
over
to
actions,
and
he
definitely
knows
about
our.
You
know
it's
more
about
our
release
pipeline
than
anyone.
D
So
I
think
it's
worth
yeah.
I
I
think,
he's
a
very
busy
person,
but
I
think
it's
worth
kind
of
reaching
out
to
him
to
see
like
what
bandwidth
he
would
have
for
helping
us
out
on
the
contrib
repo-
and
I
don't
know,
maybe
we
can
pay
extra
special
attention.
Just.
Let
me
kind
of
have
some
clue
as
to
what's
going
on
behind
the
scenes.
B
Also,
if
wishes
were
fishes,
it
would
be
cool
if
we
could
matrix
this
thing
so
that
you
get
separate,
builds
for
the
separate
gems
so
that
you
can
see
at
a
glance.
Oh
it's
this
instrument,
and
certainly
with
all
this
broken
out.
It's
this
instrumentation
fail
like
it's
not
the
whole
build,
and
you
don't
have
tens
of
thousands
of
lines
to
scroll
through.
You
have
hundreds
to
thousands.
A
A
B
A
A
D
I
was
just
gonna
say
I
think
we
should
at
least
strive
for
parity
for
now,
and
I
think
yeah
like
I
was
saying.
Maybe
we
can
pay
a
little
bit
more
attention
when
this
gets
set
up.
I
said
we
have
some
some
understanding
of
what's
happening
behind
the
scenes
and
then
I
think
the
door
is
open
to
us
to
kind
of
make
improvements
as
we
see
fit.
D
I
think
I
don't
know
whenever
you
get
a
mature
build
system
in
in
place,
there's
usually
at
least
from
where
I
said,
comes
a
fear
of
like
touching
or
changing
it
usually
easy
to
break
and
like
hard
to
figure
out
what
you
did.
D
Reach
out
to
daniel
one
way
or
another,
perhaps
by
and
mentioning
him
on
this
discussion
just
mentioned
that
we'd
like
to
split
this
out
and
that
you
know
he
has
done
some
awesome
setup
on
our
our
main
revo.
D
Would
you
be
interested
that
we're
willing
to
help
out
with
contrib
repo
and
see
how
that
goes?.
D
A
I
think
like
we
have
to
make
sure
that
both
places
work
before
we
turn
one
of
them
off.
So
I
think,
like
moving
the
code
over
is
relatively
harmless
as
long
as
we
have
like
it's
not
too
painful
to
update
it
like
because
until
it's
fully
cut
over
there's
a
risk
of
trying
to
keep
both
in
sync.
A
B
Rob
please:
okay
as
a
proposal
to
brainstorm
around
of
those
four
listed
things,
resource
detectors,
instrumentations,
examples
of
instrumentations
and
some
propagators,
which
of
those
are
the
easiest
to
run
and
change
infrequently,
I
think,
maybe
the
propagators,
I
would
say
so
yeah.
B
So
if
we
move
those
first
or
copy
those
first
get
ci
running
and
like
okay,
we
can
wire
this
up
to
test
multiple
gems,
because
there's
two
there
we're
like
all
right.
We
see
how
it's
wired
together,
they're
unlikely
to
change
in
the
in
this
in
between
period,
and
so
then
we
could
turn
them
off
there
and
start
migrating
them.
That
way.
A
A
D
It's
been
a
long
time
since
I've
looked
at
all
this
stuff,
but
once
we
have
two
of
these
things,
like
I'm
vaguely
recalling
that
at
least
at
one
point
in
time,
when
we,
whenever
we
added
a
new
library,
we
would
add
it
to
the
break
file,
and
that
was
enough
to
kick
a
lot
of
things
off.
Is
that
is
that
the
process
now?
Is
there
multiple
places
that
we
need
to
add
things.
A
I
automated
a
lot
of
that
away
in
the
sense
of
like,
because
the
thing
that
gets
added
the
most
in
terms
of
that
is
instrumentation
so
like
I
had
that
I
had
that
instrumentation
generator
bit,
and
so
when
you
run
that
for
a
new
gem,
it
just
jams
in
the
code
into
the
relevant
release
files
so
that
you're
less
likely
to
forget.
You
might
get
a
lint
error,
because
some
of
it
needs
to
be
alphabetical,
and
I
did
not
do
that.
But
at
the
very
least,
stuff
gets
added.
So
it's
sort
of
automated.
A
D
It
is
now
part
of
the
new
system.
I
suppose
that
works,
probably
for
the
the
deployment
stuff,
ci,
there's,
probably
like
ammo
file.
If
you
have
to
copy
over
and
tweak,
I.
B
Think
I
think
it's
largely
driven
by
appraisal,
because
it's
like
a
give
me
a
a
give
me
a
ruby,
runtime
on
a
platform,
a
ruby
version
on
a
particular
platform
and
then
appraise
so
it's
an
appraisal,
config.
I
think
that
would
need
to
get
things
added
to
if
I'm
remembering
correctly.
A
Sort
of
like
the
appraisal
is
just
like:
that's
the
the
test
command
that
runs
right.
It
says
like,
instead
of
just
like
rake
test,
it's
like
exec
appraisal
rate
test.
So
then
it'll
run
the
different
version
checks
against
like
the
different
instrumented
library.
D
Yeah,
I
think
that
I
think,
by
virtue
of
copying
over
the
code,
we
will
get
all
the
appraisal
files
it's
just
kind
of
like
the
actual
stuff
that
spins
up
the
test.
Runner,
I
think,
is
oh.
D
Things
so,
at
any
rate,
I
think
this
probably
sounds
like
a
reasonable
plan
of
at
least
getting
a
couple
of
libraries
over
there
and
getting
those
set
up,
and
then
I
suppose
the
next
step
would
just
be
trying
to
figure
out.
A
A
But
if
you
get
the
new
repo
set
up,
then
we
can
just
start
moving
over
like
the
the
fluffy
gentle
stuff,
like
the
readme
and
things
like
that,
and
we
start
looking
at
setting
up
the
ci
like
imagine,
we
could
probably
get
pretty
far
with
copy
paste
like
setting
up
the
ci
sounds
daunting,
but
if
we
just
like
like
this
is
gonna
have
the
insight
of
like
the
caliber
of
developer.
I
am
it's
like.
A
We
could
just
port
the
whole
repo
over
and
remove
the
bits
that
shouldn't
be
there
and
it'll
probably
work
like
instead
of
trying
to
add
like
be
additive,
we
could
be
subtractive
right,
like
just
pour
everything
and
then
yank
out
the
bits
that
don't
don't
belong
there
and
then,
once
everything
works.
If
we
can
deploy
a
set
of
new
gems,
then
we
go
to
the
original
repo
and
then
again
be
subtractive
and
just
remove
all
the
instrumentation
and
related
stuff.
D
I
feel
like
we
could
do
that
if
we
were
confident
that
we
could
make
the
transition
before
things
start
changing
yeah
before
things
start
changing
between
the
repo.
I
feel
like
that's
where
it
becomes
like
a
little
bit
more
of
a
challenge.
A
Yeah,
I
think
what
it
really
means
is
like,
in
my
mind,
is
like
we
would
potentially
not
make
any
changes
to
any
instrumentation
or
anything
that's
going
over,
while
this
transition
is
happening.
But
that
means
someone
needs
to
be
focused
on
the
transition
so
that
it
that
time
frame
is
days
not
weeks
right,
because
we
don't
wanna.
A
If
there's
a
bug
that
needs
to
get
fixed,
we
really
really
don't
want
to
have
this
be
the
blocker,
so
that
just
means
like-
and
it
may
be
en
end
up
being
me
or
maybe
I'll
bug,
one
of
my
people
to
do
it.
But
we
just
need
someone
to
commit
to
like
starting
this
and
then
finishing
it
in
like
a
contiguous
block
of
time,
so
it
doesn't
sprawl.
D
D
D
That
might
be
a
pretty
quick
way
to
do.
It.
Rob
is
saying
that
the
toys
config
is
fairly
dynamic,
so
I
suppose.
B
It
was
the
toys
config
that
I
was
thinking
of
when
I
was
saying
appraisal.
I
was
what
I
was
thinking
of.
Was
the
toys,
knowing
that
a
gem
is
present
and
having
rules
about
how
to
test
it
and
it,
and
it
figures
out
that
there's
a
gem
by
the
presence
of
a
gem
spec
in
a
directory
and
then
oh,
that's
the
directory
and
based
on
the
presence
of
other
things.
It
knows
how
to
run
the
test,
and
so
it
should,
if,
if
we
bring
that
config
over,
the
dynamicism
should
figure
it
out
mostly.
B
B
A
D
Yeah,
I'm
sure
he
can
just
execute
a
sql
query
on
the
prod
db
and
you
know
update
all
those
relationships
with
no
problem.
B
C
A
Off
off
topic,
but
I
thought
it
would
be
fun
news
to
share
like
we
recently
migrated.
Our
shopify's
monolith,
like
the
the
big
big
big
for
repo,
is
now
on
hotel,
the
one
that's
like
the
15
year
old
rails,
app
is
now
using
otel
and
it's
using
all
the
auto
instrumentation.
It
has
pretty
much
I'd
say
like
zero
customizations
to
any
of
it.
D
A
Yeah,
the
only
like
one
of
the
only
issues
we
saw,
which
we
had
two
spots
where
things
went
wrong
we
had,
we
did
have
some
like
proprietary
instrumentation
around,
like
some
lousy
gem
that
we
forked
a
long
time
ago
and
the
behavior
of
us
capturing
exceptions
like
the
in
span
it.
A
It
surfaced,
leaky
tests,
which
was
fun
so
like
we
didn't
actually
break
anything,
but
we
broke
ci
because
we
surfaced
bad
tests
because
we
were
actually
raising,
except
for
like
capturing
the
exceptions
which
identified
some
behavior
of
like
a
gem,
that
it
was
instrumenting
that
was
leaking
exception,
state
and
then
trace
parent.
We
we
aren't
using
transparents,
but
other
than
that,
it's
I
would
say
it
was
meant
to
like
the
way
we
have
everything
set
up
was
meant
to
be
a
drop-in
replacement.
A
So
it's
about
the
same.
The
resource
detection
is
better
and
the
job
instrumentation
is
better
because
we're
using
links
now-
and
so
that's
a
lot
nicer.
So
no
more
like
crazy,
long
traces
from
like
the
requests
that
infuse
the
job
and
then
the
job
runs.
You
have
this
like
blown
out
trace
because
we're
using
links.
Now
you
actually
just
get
a
job
and
cues,
and
then
it
runs
and
the
the
run
job
links
back
to
it.
A
So
you
get
better
timing
on
your
requests,
no
more
like
long,
long,
long,
traces,
but
like
literally
they're
the
only
issue
with
the
the
ci
issue,
with
like
this
one
proprietary
instrumentation
that
we
had
so
that
was
really
awesome
to
see
like
like
for
reference
like
even
our
custom
instrumentation
gym
in
this
monolith.
There
was
like
patches
on
patches
on
patches
on
top
of
that
tracing
gem,
and
we
were
we
just
blew
it
all
tim
just
blew
it
all
away
and
everything's
working
great.
A
A
Yeah
yeah,
no,
nobody
has
yelled
or
anything
so
we're
we're
still
due
for,
like
actually
doing
like
a
deep
performance
investigation
of
the
impact
like
open,
telemetry
ruby
has.
This
is
like,
regardless
of
that,
but
we
actually
want
to
like
do
the
whole,
like
ebpf,
like
profiling,
against
it
to
see
what
the
real
like
numbers
are.
No,
we
didn't
notice
any
impact
on
latency.
We
didn't
notice
anything,
nothing
negative!
Everything
came
out
green.
A
I
just
think
it's
like
it's
fine,
because
it's
just
kind
of
like
whenever
you
hear
about
like
a
big
monolith,
there's
always
like
something
weird
about
it
and
it
had
to
do
something
special.
You
know
this
is
not
doing
anything
special
at
all
like
whatsoever,
it's
stock,
instrumentation,
it's
raising
the
same
stuff,
that's
in
the
repo
right
now,
so
I'll
probably
do
some
like
cheesy
blog
post
about
it.
D
On
that
note,
I
did
read
an
interesting
blog
post
last
week.
I
don't
know
if
anybody
saw
amy
toby.
I
know
she
has
showed
up
to
a
couple
of
meetings.
She
would
yeah,
they
adopted
hotel
at
equinox
medal
and
it
was
a
long
mystery
about
some
concurrency
issues
that
they
ended
up
having
after
they
used
hotel,
ruby,
not
the
fault
of
hotel
ruby,
but
I
think
because
the
rest
of
the
code,
I
don't
know
what
you
should
read
the
blog
post.
D
No,
the
conclusion
was
that
they
had
some
concurrency
issues
with
their
app
but
that
they
weren't
kind
of
exhibited
until
they
used
until
we
started
using
hotel
because
hotel
uses
locking
for
things.
So
I
think,
like
the
yeah,
the
their
concurrency
code
is
really
not
thread
safe
as
as
written,
but
because
there
was
like
no
contention
for
anything
else.
They
never
saw
the
problems,
but.
B
On
all
the
sections
is
that
the
I
wrote
a
short
story
about
chasing
ghosts
in
the
software
machine.
Is
that
it?
That
is,
it.
B
B
D
Yeah,
I'm
not
I'm
not
sure
where
to
go
with
this
either
other
than
new
section
of
interest.
It's
definitely
a
section
of
interest.
I
feel
like
it's
a
blog
post
that
details,
like
you,
know,
a
pretty
interesting
like
debugging
session.
I
don't
know
that
hotel
ruby
was
like
the
biggest
help,
but
it
didn't
hurt
and
it
wasn't
the
cause,
but
it
was
the
thing
that
helped
them
figure
out
that
there
was
this
other
latent
problem
that
had
existed
in
the
software.
For
I
don't
know,
six
or
seven.
A
Years
that
sounds
like
it
sounds
like
business
as
usual
to
me,
which
is
kind
of
comforting
in
a
way
like
of
the
apps
that
are
like:
hey
hotel,
ruby
broke
our
app,
and
then
you
actually
dig
into
it
and
you're
like
sorry,
your
app
was
broken
before
we
got
here
it
just
it
just
showed
up,
because
for
actually
you
have
observability
now.
B
B
Disease
rates
go
down.
If
we
stop
testing
like
sure,
if
you
don't
you
don't
instrument
your
app
yeah
tests
can't
fail.
If
you
don't
run
right.
B
That
is
consistent
with
lots
of
our
customers
too,
that
they
use
any
sort
of
amount
of
instrumentation,
whether
it's
ours
or
competitors
or
the
open
telemetry
standard
and
send
it
somewhere
and
look
at
what
your
app's
actually
doing
and
discover
all
sorts
of
exciting
things.
D
So
yeah,
I
guess
we
got
onto
that
by
talking
about
happy
news
from
from
shopify.
B
Oh,
I
guess
I
could
put
that
I
I'll
I'll
bring
back
happy
reports.
Sorry
yeah.
D
A
D
A
D
Yeah,
I'm
I'm
committed
to
getting
the
repo
provisioned
and
I
will
mention
I
will
mention
on
this
issue
when
it's
ready
as
well
as
broadcast
that
in
in
the
slack
and
then
we
can
kind
of.
D
Work
through
those
next
steps
of
getting
something
into
the
repo
and
getting
the
group
of
maintainers
approvers
over
there
well
and
yeah.
I
guess
we
can
just
kind
of
use
this
discussion
and
slack
to
kind
of
get
through
these
first
initial
phases
and
then
next
week
figure
out
where
we
are
and
what
what
the
next
steps
the
next
next
steps
will
be.
A
Okay,
cool
just
to
like
compare
it
a
reminder
if
you
do
want
to
look
at
the
api
stuff,
the
pr
still
up
right
now.
So
it's
like
good
time
to
comment.
I'm
going
to
try
to
get
this
moving
a
bit
faster
than
it
has
been
so
we're
going
to
try
to
get
like
some
movement
going
on
the
metric
stuff
in
a
big
way.
So
that's
going
to
be
a
good
chance
to
get
in
this
reminder
kind
of
a
call
out.
D
A
Nothing
for
me,
my
like
resolution
here
is
just
to
stay
as
focused
as
I
can
on
metrics
in
terms
of
open
commentary
ruby
until
that
hit
some
stable
usable
point
and
then
it'll
be
the
arduous
battle
of
seeing
if
I
can
get
us
to
adopt
it
internally
at
shopify
and
then,
if
that
happens,
I'll
start
bragging
about
it.