►
From YouTube: 2022-03-22 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
I
noticed
that
I
was.
I
was
looking
for
pr
through
pr's,
for
once
the
spec
sig
ended
a
little
bit
early,
so
I
thought
I
would
try
to
do
something
useful
and
I
managed
to
approve
a
couple,
but
one
that
I
tried
to
approve,
which
is
not
not
approvable
500
error.
D
B
B
D
D
D
D
Also,
the
sandwiches
are
generally
better.
What
else
I
don't
know,
that's
all
I
got.
C
C
I
do
like
I
don't
know.
I
was
having
like
a
lot
of
like
joint
pain
and
issues
like
that
and
yeah
paleo
in
keto.
Diets
are
supposed
to
be
like
good
for
for
inflammation
if
you're
having
like
any
inflammatory
problems
just.
E
C
C
Yeah,
are
we
expecting
anybody
else?
Should
I
start
sharing
a
screen
and
get
things
rolling
or
should
we
talk.
C
Excellent
yeah,
I
had
a
rough
day
yesterday.
Like
I
don't
know,
I
think
my
cat
like
hit
some
button
on
my
keyboard,
and
it
has
like
some
macros.
It's
like
it's
a
programmable
keyboard
and
if
I
would
hit
like
command
slash
like
the
comment
out
code,
it
would
like
start
to
cut
and
paste
some
comment
I
made
in
slack
earlier.
In
the
day
it
was
ridiculous
and
then
I
kind
of
like
reset
the
keyboard
and
then
my
command
key
was
not
working
and
I
spent
several
hours
trying
to
get
this
keyboard
restored.
C
C
C
So
the
good
news
is
the
specs
egg
was
quite
short,
so
we
should
be
able
to
get
through
this
pretty
quickly
with
yeah,
with
with
minimal
disappointment
in
boredom,
which
is
rare,
but
there's
really
just
the
stable
burndown
list
appears
to
be
empty,
which
is
seems,
like
things
must
be
done
or
just
not
added
to
the
list,
and
then
there
was
an
announcement
that
the.
C
And
then
there
was
a
pr
to
clarify
the
default
enabled
behavior
for
metric
views.
I
think
I
was
just
saying
that
yeah
that
that
all
instruments
are
enabled
by
default,
even
when
views
are
configured.
C
C
C
Right,
I
guess
now
what
I
was,
as
I
mentioned.
Looking
brief
briefly
through
pr's,
it
definitely
seems
like
we
have
a
few
open,
but
also
noticing
that
github
is
having
some
some
issues.
C
A
I
don't
think
I
have
anything
new
or
exciting
for
metrics,
so
I'm
gonna
just
like
out
of
like
talking
about
it
today,
just
because
I
honestly
haven't
pushed
it
well,
we
can
talk
about
it
if
we
have
a
lot
of
open
time,
but
I
haven't
really
pushed
anything
new
since
last
time
we
spoke.
I
think
we
should
try
to
maybe
focus
on
the
the
pr's
that
are
open,
and
maybe
just
I
don't
know
if
we
want
to
like
mob
review
and
go
through.
I
don't
know
if
that
makes
sense.
C
Yeah,
no,
I
I
think
I
totally
make
sense.
I
know
arielle
posted
in
the
slack
that
he
had
a
handful
of
things.
I
looked
at
the
this.
One
was
really
straightforward
and
basically.
B
I
agree
with
I'm
down
to
review
some
stuff.
I
did
want
to
give
a
brief
update
on,
can
trip
which
is
ariel
and
I
met
last
week
and
did
a
little
bit
of
a
walkthrough
of
like
what
needs
to
get
migrated
and
a
like
a
burn
down.
We've
recorded
it,
it's
pretty
straightforward.
We
had
some
there
was
and
and
matt
we
saw
appreciate
your
input
as
well.
B
The
only
outstanding
items
were
there's
some
stuff
that
lives
in
open
telemetry
instrumentation
base
that
probably
like
needs
to
live
elsewhere
with
it's
like.
The
registry
lives
in
instrumentation
base
the
gem,
but
there's
no
real
specification
around
where
it
has
to
live,
but
we
probably
want
to
move
it
out
of
base
if
we're
going
to
move
instrumentation
based
into
trip,
because
otherwise
what
happens
is
the
sdk
has
a
dependency
on
instrumentation
base,
which
is
unusual.
B
The
only
other
thing
was
like
some
admin
stuff
around
like
getting
the
ruby,
so
the
ruby
gems,
like
api,
key
to
be
able
to
publish
to
rubygems
from
the
contrib
repo.
Oh
matt
responded.
We
didn't
see
it
originally,
but
our
fearless
leader,
mr
ware,
added
our
permission.
So
now
I
guess
we
can
add
that
we
can
add
a
a
secret
to
the
contributor,
but
other
than
that,
it's
pretty
straightforward
and
it's
just
going
to
be
a
matter
of
ariel
and
I
one
of
us
spiking
it
out.
B
I
had
said
I
would
do
it
this
weekend
and
then
my
grandmother,
mother-in-law
and
mother
were
in
town
and
I
did
not
do
anything.
But
that's
all
I
have
freaking
trip.
C
Cool
yeah,
while
we're
on
this
topic
so
to
understand
the
instrumentation
based
situation,
we
expect
that
instrumentation
will
depend
on
instrumentation
base.
It's
a
little
bit
inconvenient
that
sdk
that
the
sdk
depends
on
it.
Just
for
the
registry
is
that
what
is.
B
Yeah
there's
basically
within
sdk
there's.
I
think
it's
like
in
the
configurator.rb
file
that
has
a
lot
of
like
sort
of
helper
functions
around
instrument
all
and
stuff.
There's
just
like
a
little
function.
That's
like
hey,
like
create
a
registry
and
add
all
our
instrumentation
to
it,
which-
and
you
know
the
registry
itself
lives
in
base,
but
it's
actually
not
on
the
base
class.
It's
on
like
the
open,
telemetry
instrumentation
class,
but
there's
no
specification
around
where
the
registry
like
has
to
live.
We
could
move
it
somewhere.
B
You
know
we
could
probably
move
it
into
the
sdk.
We
could,
I
don't
know,
there's
we
weren't
quite
sure,
but
the
idea
would
be
we'd
probably
want
to
separate
out.
We
don't
think
the
sdk
should
hold
a
dependency
on
base,
so
we
should
move
it
somewhere.
B
C
Yeah
yeah,
I
think
so
I
think
yeah.
The
registry
was
just
a
convenient
place
to
list
all
of
kind
of,
like
the
discovered
instrumentations
via
subclassing
instrumentation
base
more
or
less
and
then
just
having
a
thing
to
like
run
through
and
see
like.
Can
I
install
this?
C
So
that's
really,
that's
really
what
it's
there
for,
I
think
like
in
the
back
of
my
mind,
I
was
thinking
like
in
the
future.
You
might
be
able
to
do
more
with
it
if
you
wanted
to
just
if
you
wanted
to
like.
C
I
don't
know
just
just
have
some
some
tasks
to
kind
of
list
things
out
list
out
like
the
availables
list
out
the
installables
list
out.
The
things
that
like
are
something
is
some
condition
is
not
met
for
some
reason,
but
those
are
all
like
theoretical,
so
I
don't
know
if
we
would
ever
want
them
or
need
them,
but.
B
Yeah,
I
think,
there's
a
lot
of
work,
there's
a
lot
of
value
to
having
some
list
of
like
canonical
what's
installed
and
what
you
can
install.
The
only
issue
is
just
more
that
not
issue
is
just
the
specification.
It's
not
specified
anywhere.
There
are
such
things
that
registry
and
specification,
as
far
as
I
know,
so,
it's
sort
of
a
matter
of
like
us,
placing
just
putting
it
somewhere
that
doesn't
so
we
remove
we
uncouple
base
and
sdk
as
well.
Yeah.
C
Yeah
and
and
the
full
back
story
on
that
is,
like
yeah,
there's,
definitely
no
specification
on
it.
I
I'm
responsible
for
the
registry.
I
just
introduced
it
because
it
was
a
convenient
thing
for
for
for
knowing
what
instrumentation,
for
just
what
instruction
instrumentation
was
discovered
and
having
some
way
to
just
kind
of
iterate
through
it
and
attempt
to
install
it.
B
Yeah,
no,
it's
good,
it's
good
to
have.
Let's,
let's
move
on
to
the
prs,
I
think
right,
there's!
No,
there's
nothing!
Actually
here
just
giving
an
update
in
case
you
know,
what's
falling.
C
Cool
yeah,
if
anything
comes
up
on
contrib
or
anything
else
where
I
could
help
unblock
anything,
always
feel
free
to
reach
out
to
me.
D
There's
one
that's
kind
of
just
been
kicking
around
in
my
mind:
it's
the
error
with
uppercase
http
methods,
number
one,
one,
four,
seven!
I
I
guess
ariel.
A
D
Francis
aren't
here
so
maybe
this
is
not
a
good
one,
but
I've
just
kind
of
been
watching
the
back
and
forth
on
this
and
kind
of
been
like
all
right.
Let's,
let's
let's
get
this
in
and
it
seems
reasonable
to
me.
C
All
right,
so
we
had
talked
about
this
last
week
and
last
week
this
was
kind
of
like
a
constant
was
like
a
default
proc.
I
think,
and
that
was
like
immutable
constant.
We
were
not
totally
stoked
about
that,
but
it
looks
like
the
refactor
has
been
to
just
kind
of
dynamically,
create
the
the
hash
but
ultimately
freeze
the
value.
C
I
am
fine
with
this.
This
is
kind
of
what
I,
where
I
thought
this
would
end
up
going
last
week.
Anybody
have
any.
A
I
I
don't
know,
I
think,
I'm
being
maybe
a
little
too
lacks.
I
think
ariel's
concerns
are
valid,
like
that.
Having
a
constant
that
has
a
mutating
value
is
probably
not
the
best
right
like
it's
it's
it
kind
of
like
it's
surprising,
behavior
like
if
I
have
a
constant.
I
expect
it
to
be
constant
right,
but
we're
declaring
a
constant,
but
then
through
the
powers
of
ruby.
A
A
I
don't
think,
like
I
don't
know
we're
already
doing
it
in
net
http,
which
isn't
a
good
reason
to
do
it
in
other
places.
But
again
like
can
we
just
mutate
the
way
this
is
accessed
a
little
bit
so
that
it's
not
a
constant
and
then
just
move
on?
C
That
was
that
was
kind
of
the
sentiment.
Last
week
was
like.
We
should
probably
have
something
better,
just
common
to
all
http
instrumentation,
but
really
we
should
not
trouble
this
user
to
do
that
for
us
just
to
fix
their
bug.
But
I
guess
just
to
talk
this
through
a
little
bit
kind
of.
What's
going
through
my
mind
here
is
like
ultimately,
I
think,
with
with
the
default
proc
you're
gonna
end
up
in
this
end
state
with
your
constant
anyways
like
once
enough
stuff
has
been
run
through
it.
A
A
It's
like,
maybe
I
don't-
I
hadn't,
even
looked
at
it
that
recently,
so
that's
changed
since
last
time
I
looked
at
it.
I
think
again
like
this
is
the
perfect
example
of
like,
let's
ex
like,
I
guess
I
just
I'm,
always
apprehensive
of
testing
the
patience
of
someone
who's
like
volunteering.
Their
time
to
improve
this
and
say
like
is
their
goal
to
fix
the
bug
or
do
they
just
want
to
make
this
better
and
be
a
part
of
the
process
right?
A
If
it's
the
latter,
then
this
is
fine.
This
isn't
like
an
issue
because
then
we
take
whatever
ultimately
happens
here
and
we
extract
it.
But
that's
like
the
part
that
I'm
more
concerned
with,
but,
like
I
agree
like
doing
the
work
up
front,
seems
fine,
because
then
we
do
that
work
up
front.
We
extract
it
out
and
then
all
the
http
instrumentation
can
share
that
upfront
work
right
and
they
can
all
benefit
from
it,
and
that
becomes
like
a
good
thing
and
I
think
that's
like
a
smart
way
of
doing
this.
A
B
C
Okay,
there
we
go
so
yeah
feel
free
to
like
add
your
lgtm
plus.
Maybe
we
would
like
to
move
this
to
a
common
place
someday.
C
Yes,
sir
all
right,
I
should
have
asked
that
first,
what's
what's
up
next.
A
C
Yeah
I'll
jump
into
this
one,
because
I
looked
at
it
and
approved
it
earlier
as
well.
This
one
was
like
actually
straightforward.
I
feel,
as
we
go
down
his
list,
they
get
more
complicated
and
require
more
discussion.
So
we
we
looked
at
his
straightforward,
ci
change.
C
This
one
is
basically,
I
think
we
introduced
like
procs
before
enums
in
our
configuration
system,
so
there's
a
handful
of
options
that
were
really
they
were
implemented
as
props,
but
it
could
have
been
genomes
and
I
think,
ariel
went
through
and
fixed
a
lot
of
those
that
they
would
be
overrideable
by
environment.
Variable.
B
Pr
should
be
good
to
go,
yeah
context:
proxy
came
originally,
then
we
were
like.
Oh,
let's
make
everything
configurable
by
mvar,
but
you
can't
configure
mvars,
but
I
can't
configure
procs
by
an
embar
because
that's
unholy
so
he
kind
of
snuck
in
this
enum
thing
but
didn't
apply
it
everywhere,
because
that's
a
bunch
of
extra
stuff
that
we
didn't
want
to
do
wasn't
relevant
and
then
ariel
did
the
nice
work
of
applying
it
everywhere.
So
it
should
enable
a
lot
more
configuration
by
environment
variable
it's
pretty
good
good
stuff.
I
think.
C
B
B
But
this
was,
I
think,
where
we
left
it.
I
was
looking
for
a
little
bit
of
feedback
from
like
matt
and
rob
is
not
other
rob
because
they
would.
You
all
might
be
impacted
by
this.
B
Yeah
I
okay
gosh.
If
I
were
docs
more
or
less,
we
weren't
sure
where
to
put
the
rail
tie
and
whether
to
have
it,
auto
rail
tie
or
whatever
I
don't
know,
I'm
not
explaining
that.
Well
and
I
was
concerned
that
oh
gosh
right
and
we
were
going
back
and
forth
on
how
to
add
it
and
god
stuff
happened.
B
I
was
worried
that
I
think
the
way
it
was
written
at
the
time
it
would
just
you
know
someone
would
do
a
minor
or
patch
upgrade
to
instrumentation
all
and
it
would
all
of
a
sudden.
This
rail
type
would
kick
in,
and
we
were
kind
of.
I
was
saying
like:
let's
not
do
that.
Let's
have
it
be
optimable
as
part
of
the
rails
package
and
ariel
didn't
feel
that
was
necessary
because
we're
not
1.0
and
for
other
reasons.
B
So
we
went
back
and
forth
a
little
bit
and
I
don't
know,
let's
see,
I
don't
know
what
his
last
comment
was.
I
think
it
was
undetermined
and
ariel
was
on
vacation
and
he
appears
to
have
moved
the
rail
tie
to
the
rails,
instrumentation
specifically,
which
we
all,
I
think
agreed
to
do
and
also
made
it.
B
Oh
gosh
also
made
it
be
opt-in,
not
automatic
and
also
appears
to
have
done
something
with
resource
attributes,
but
I'm
not
sure
so.
I
think
he's
sort
of
updated
to
meet
the
feedback
we
had.
B
The
trade-off
to
our
feedback
is
that
it's
slightly
more
work
for
a
user
to
get
this
out
of
the
box
stuff.
So
you
know
I'm
open
to
bike
shed
on
that
or
whatever
I
don't
have
super
strong
videos.
Although
I
apparently
wrote
5
000
words
about
it,.
C
So
I
guess
one
thing
that
would
be
helpful
for
me
to
understand
where
things
currently
stand
is:
what
do
I
have
to
do
if
I
am
an
end
user
to
get
rails?
Instrumentation
like
it
sounds
like
this
does
not
work.
B
Well,
the
difference
is
like
you're
saying
if
this
change
were
merged
right
now,
what
would
you
would
still
have
to
you
would
either
have
to
do
something
like
this
code
change
or
I
think
what
he
suggests.
What
he's
updated
it
to
be
was
like
kind
of
that
weird
sort
of
like
middle
ground
thing.
I
suggested
where
it's
like.
You
modify
your
gem
file
to
require,
but
I'm
not
I'm
I'm
not
let
let
me
look
at
it.
I
should
just
have
open
the
stuff
in
my
browser
too,.
B
So
that's
where
we
weren't
sure
what
to
do,
whether
to
have
it
be
just
automatic.
If
you
install
a
gem,
have
it
be
modify
the
gem
file
or
have
it
be
requiring
code
changes.
E
E
A
Because
this
is
it
like
the
hauling
correctly
and
I'm
just
like
I
just
skimmed
through
the
tr
there's
a
lot
of
like
test
scaffolding
there,
it's
just
probably
good.
I
have
this
weird
disdain
towards
testing
rail
ties
because
of
like
how
much
effort
it
is
to
set
up,
but
this
is
basically
the
approach
like
you
initially
proposed
eric
right,
where
you
said
it's
just
like
in
your
gem
file.
You
just
add
a
require
line
to
the
explicit
thing
so
like
if
some
this
is
like
99
hands
off
like
auto
instrumentation.
E
B
That's
I
finally
realized
where
I
put
the
update,
which
was
in
the
commit
message,
which
is
where
you're
supposed
to
write
the
stuff
and
I
just
blew
over
it
yeah
robert
summarized.
It
perfectly.
I
think
it's
a
sort
of
unorthodox
approach
so,
like
I'm
open
to
being
told
it's
wrong
and
bad,
but,
like
I
don't
know,.
A
I
think
the
reason
why
it
appeals
to
me
so
much
is
that
like
there's
never
well,
I
don't
want
to
say
never.
I
don't
see
a
realistic
path
to
having
like
the
100,
no
code
change,
adding
of
instrumentation.
Like
I
don't
know.
If
that's
even
like
a
reasonable
goal,
it
seems
weird
right
so
like
at
some
point
someone
is
going
to
have
to
edit
their
jump
file
right
at
which
point
if
they
they
don't
want
to
edit
anything
else
beyond
the
gem
file.
A
They
just
want
to
add
auto
instrumentation
and
they
don't
want
to
configure
the
sdk,
which
I
don't
think
is
in
the
same
camp
as
auto
instrumentation.
But
again,
let's
say
we
want
to
satisfy
that
use
case
which
isn't
unreasonable
to
do
so
because
the
rest
becomes
done
by
environment
variable
they
literally
beat
the
documentation
and
say
require
this
file
out
of
the
rails,
instrumentation
their
rails,
app
and
now
it's
hands
off
and
then
any
extra
configuration
like
say.
A
I
want
to
use
the
otlp
exporter
and
I
want
to
set
the
collector
address,
so
I'm
doing
that
all
through
environment
variables,
so
that
environment
variables
kind
of
fall
into
that,
like
not
really
code
configuration
right,
so
I
feel
strongly
towards
this
being
the
right
decision
again
like
I'm,
always
happy
to
change
my
mind
if
a
sufficiently
strong
argument
opposes
that,
but
like
this
seems
like
a
pretty
good
place
to
be,
I
think
having
it
auto
configured
by
default
would
be
the
wrong
choice,
because
if
someone
is
already
configuring
it
and
they're
using
rails
instrumentation,
which
one
wins
that's
weird
yeah.
E
B
B
I
should
review
the
other
portions
of
this
which
I
haven't,
so
I
think
this
still
requires
a
thorough
review
because
it's
a
chunky
lot
of
code
in
there,
although
most
of
its
tests
scaffolds.
But
it
looks
like
this-
is
in
a
good
place
and
the
issues
have
been
resolved.
D
I
had
a
sort
of
a
related
question
so
feel
free
to.
We
can
just
steamroll
over
this
if
necessary,
but
like
so
the
use.
All
thing
is
kind
of
like
like
you'll
like
if
you're
using
use
all
if
you're
someone
that's
pulling
in
our
gem,
then
it
is,
does
seem
possible
that
if
we
like
add
a
new
type
of
instrumentation
in
some
release,
then
you're
just
gonna
get
new
spam.
That's
kind
of
like
the
whole
point
right.
It's
like
oh
cool,
like
we
instrumented,
like
you,
know,
active
job.
D
D
Then
you
just
like
automatically
are
going
to
get
this
new
stuff,
and
I
guess
is
that
an
accurate
understanding
of
like
how
this
is
all
working.
And
then
I
guess
like
the
follow-on
to
that.
Possibly
the
bike
shed
is
like.
Do
we
want
to
like,
like
the
opposite
of
a
deprecation
or
something
I
don't
know.
D
This
sounds
like
a
bad
idea,
as
I'm
saying
it
out
loud,
but,
like
you
know,
we
can
log,
maybe
a
warning
or
something
that's
like
hey
like
if
we
wanted
for
the
sake
of
argument,
if
we
wanted
to
include
the
rail
tie
and
use
all
right,
we
could
say
hey
at
the
next
point:
release
like
we're
going
to
include
a
rail
tie
as
part
of
this
use
all
hook.
I
don't
know
I'm
saying
it
out
loud
and
it
seems
bad,
but
it
does
kind
of
feel
weird
to
be
like
adding
instrumentation
automatically.
B
I
do
think
it's
a
weird
state
a
little
because
our
docs,
the
docs,
the
like
up
and
starting
five-minute
to
value
docs
like
point
and
that's
for
all
the
languages
like
points
you
to
like
here's.
The
here
grab
everything
and
call
use
all
and
never
worry
about
it
again
and
then
like,
but
I
don't
know,
I
think,
there's
some
in
my
mind.
It's
like
there's
some
onus
on
the
user
to
like
they.
B
B
If
you
care
more,
if
you're
more
defensive-
and
you
only
want
to
bring
in
certain
instrumentations-
you
can
still
use
use
all
but
only
require
the
specific
instrumentations,
and
perhaps
we
could
do
a
stronger
job
of
explaining
that
in
the
docs
but
yeah
it's
I.
I
agree.
It's
a
little
weird.
It
is
sort
of
the
industry
standard
in
my
mind,
but
whether
that's
right,
I
don't
know.
A
I
think
what
makes
it
a
little
bit
more
kind
of
awkward
to
think
about
sometimes
is
like
there's
different
ways
of
opting
in
and
out
of
instrumentation
that
you've
brought
as
part
of
your
your,
like
your
gem
file,
because
you
have
like
use
all
and
then
use
right.
So
it's
like
use
always
just
grab
everything,
and
then
you
have
used,
which
is
like
explicitly
picking
the
ones
that
you
want,
but
you
can
also
disable
it
through
environment
variables.
A
On
top
of
that,
so
you
can
say
I'm
going
to
use
all
and
then
I'm
going
to
pass
in
a
flag
to
disable
three
of
the
ones
that
I
included
by
default.
And
so
then
you
have
different
ways
of
like
opting
in
and
opting
out.
You
can
opt
in
and
out
through.
Just
whether
or
not
you
have
those
instrumentation
packages
in
your
gem
file,
you
can
opt
in
or
out
based
off
of
use,
all
or
use
specific
ones,
and
then
you
can
opt
in
or
out
by
environment
variables.
A
I
think
that
there's
like
too
many
combinations
of
how
you
can
opt
in
and
out
of
instrumentation.
We
talked
about
this
a
while
back.
We
never
acted
on
any
of
it
because
it
was
kind
of
it
felt
a
bit
nebulous
to
me
if
I
could
just
like
throw
care
to
the
wind
and
not
weigh
in
other
people's
opinions.
I'd
probably
get
rid
of
like
use
and
use
all,
and
I
just
have
use
all
be
the
default.
So
then
your
your
two
knobs
for
opting
in
and
out
become.
A
Did
you
include
the
instrumentation
in
your
gem
file,
or
are
you
explicitly
disabling
it
in
your
environment
variable
so
that
the
expectation
is
people
are
more
intentionable
intentional
about
what
instrumentation
they
bring
in
and
then
the
environment
variable
becomes
like
oh
something's,
broken
and
like?
I
need
to
do
a
no-code,
deploy
and
just
like
turn
this
off
as
fast
as
possible.
A
So
it
gives
you
that,
like
really
quick
and
dirty
escape
hatch,
but
again,
there's
like
probably
arguments
to
be
made
for
the
other
cases
of
like
supporting
these
these
deployment
strategies,
but
I
would
just
like
to
see
it
simpler.
I
think
it's
even
just
like
a
little
bit
winded
to
explain
the
current
state
of
how
you
can
opt
out.
D
C
I
think
these
are
all
good
discussions.
I
feel
like
configuration,
is
a
pain
and,
like
I
feel
like
every
like,
mature
apm
product,
that
I've
seen
just
becomes
like
a
tangled
mass
of
various
configuration
options
for
everything
and
it
becomes
rocket
science
pretty
quickly
to
like
figure
out.
C
Yeah,
I
think
that
was
kind
of
the
end
of
that
thought.
Just
more
or
less
these
things
do
end
up
being
being
complex
and
just
trying
to
kind
of
maybe
support
too
many
theoretical
use
cases,
and
maybe
not
all
of
them
are
practical.
So.
C
I
guess
this
also
points
a
little
bit
towards
one
of
the
things
I
was
talking
about
with
this
registry
a
little
bit
earlier,
it's
like
being
able
to
actually
like
print
out
like
what
is
available,
what
got
installed
and
what
did
not
get
installed
and
why
it
didn't
it's
like
you.
You
could
imagine
that
you
had
to
have
a
rape
task
where
you
could
kind
of
debug
your
instrumentation
and
find
out
that
you
know
x,
instrumentation
was
available,
but
it
was
disabled
by
environment
variables.
That's
why
it
wasn't
installed.
C
That's
all
I
have
to
say
about
this
for
now.
I
do
think
it
would
be
useful-
maybe
maybe
I'll
just
chime
in
at
the
end
of
this
and
just
ask
arielle
like
what
what
do
the
docs
look
like
today,
if
I'm
a
rails
user
and
want
to
use
this
just
so
that
it's
clear
what
the
install
looks
like
I'm
guessing.
What
I
end
up
doing
is
eric
correct
me
if
I'm
wrong,
but
I
would
require
this
in
my
gem
file.
C
A
A
I
don't
know
how
well
it's
tested
based
off
of
the
pr,
probably
really
well
tested
at
this
point,
but
the
only
tricky
part
becomes
like
making
sure
that
gets
called
in
the
right
order,
but
I
I
would
just
have
to
double
check
it
against,
like
our
internal
thing,
because
I
know
ours
works
so,
but
yeah
gen
file
require
this
rail
tie
and
then
you
get
the
auto
sdk
configuration.
B
So
in
these
stocks
it
would
just
be
modified
slightly
in
so
that
in
the
top
level
gem
thing
there
would
be
like
a
comma
after,
like
all
and
like
require
and
then
a
path.
We
should
so
feedback
on
this
pr
will
be
like
we
should
add
this
to
the
docs.
So,
like
people
aren't
having
to
guess
like
so
people
can
just
copy
paste
and
yeah.
I
think
there
is
a
little
bit
of
a.
I
don't
know
if
it's
a
race
condition
or
not,
or
just
like
a
I
don't.
I
don't
know
the
ordering.
B
I
had
left
feedback
on
this.
Originally
I
saw
way
back
in
the
day.
I
don't
know
if
anyone
here
has
ever
worked
in
new
relic,
but
way
back
in
the
day
you
relic
had
a
real
tie
like
this,
and
you
can
provide
a
uh-huh.
I
just
like
to
I
just
like
to
twist
the
knife.
At
times
you
can
provide
a
hook
in
your
initializer
or
you
can
set.
B
You
can
specify
what,
where
you
want
to
hook
in,
and
one
of
the
options
is
like
before
the
initializer
folder
runs,
which
I
think
is
what
we
want
to
do.
I
think
we
want
to
run
before
anything
in
conflict,
slash
initializers,
but
ariel
had
given
feedback
that,
like
maybe
that
was
not
actually
what
it
was
doing.
I'm
not
sure
I
haven't
looked
at
the
rail
tie
like
source
code
in
a
minute,
but
yeah.
I
think
my
only
feedback
here
is
let's
document
this,
so
people
can
just
be
mindless,
autonomous
tons
and
copy
paste.
A
End
that
I
just
double
checked:
that's
what
the
approach
he's
doing.
There
is
what
we're
doing,
but
I
think
there
is
some,
like
you
said,
probably
have
to
double
check
the
the
actual
specs
for
grail
ties,
but
I
think
there
is
some
alphabetization
ordering
that
happens.
I
think
I
I
could
be
remembering
that
wrong,
but
this.
C
A
B
A
C
All
right,
then,
final,
question,
slash
comment
like
one
potential
con
to
this
approach
is,
it
looks
like
it
would
be
hard
to
pass
any
arguments
to
use
all
the
way
this
is
structured,
like
you're
kind
of
reliant
on
environment.
Variable
configuration
at
this
point
is
that
a
fair
assassin.
B
It's
it
just
calls
use
all
with
no
arguments
essentially
and
we
rely
on
the
and
we
rely
on
environment
variables,
and
I
think
the
way
robert's
phrase
in
the
past
is
right,
which
is
like
which
is
like,
if
you
want
to
get
more
visibility
like
cool,
like
turn
off
the
automatic
controls,
I'm
like
you
can
start
to
configure
it
yourself.
If
you
really
need
to
like
pull
in
you
pass
something
specific
and
to
use
all
that's
not
configurable
by
nvar,
but
like
most
of
it
is
so.
C
C
Everything
is
kind
of
like
hard
coded
in
the
code,
which
is
not
usually
where
you
want
it,
but
if
you
had
environment,
variable
and
or
file,
and
then
some
really
complex
precedence
between
when
you
would
choose
one
over
the
other,
then
everything
will
become
a
little
easier.
B
Yeah,
I
still
think
the
use
case
for
all
this
stuff
is
like
the
person
who's
just
on
a
poc
and
needs
to
get
something
working
in
10
minutes
just
to
be
like
look
team.
Here's!
What
tracing
is
you
see?
It's
really
cool
like
and
yeah,
and
it's
like,
we
can't
optimize
for
every
use
case
via
magic,
like
sometimes
you
just
have
to
configure
stuff.
C
Yeah
and
then
vendors
will
update
their
docs
they're
like
first
a
standard,
ruby
app
do
this
for
rails.
It
will
be
just
a
slightly
different
setup.
C
All
right
yeah,
so
the
the
resolution
on
this
is
maybe
yeah.
I
think
I
know
how
to
use
this.
I
wish
it's
going
to
for
everybody
following
along
and
to
make
sure
that
the
assessment
is
correct.
I'll,
just
ask
the
question
on
this
pr
like
what
does
the
configuration
look
like
for
the
user
and
is
there
somewhere?
We
can
document
that.
A
C
All
right,
I
think
this
makes
sense
based
on
this
conversation.
Is
anybody
ready
to
like
add
an
approval
to
this.
A
C
A
A
A
D
A
That's
exactly
what
happened
to
me.
I
did
have
a
lot
of
tests
internally
for
a
rail
tie
and
they
didn't
catch
a
mistake
I
made
the
rail
tie
test
worked
because
it
called
the
rail
time,
but
something
I
forget
what
it
was
it
just
it
didn't
catch
it.
I
was
like
okay
well,
this
is
this
is
stupid,
like
I
just
deleted
the
test
as
like
move
on,
but
again
like
I
don't
want
to
fight
thorough
and
like
ariel's,
thorough
right,
so
it's
I'm
a
little
bit
conflicted.
A
B
E
C
Yeah,
I
I'm
with
two
minds
on
this.
One
is
like
the
testing
is
already
here,
but
so
ariel
has
already
done
the
hard
work,
but
then
again
like.
C
Really,
you
know
this
is
the
code
and
a
lot
of
it
is
just
effectively
testing
rails.
A
That's
what
I
originally
had
that's
like
what
the
original
testing
was
is
like
me,
trying
to
cleverly
do
that
and
then
conditionally,
just
like
swapping
the
configuration
hook
with
the
version
appropriate
things
needed
and
it
was
like
it
was
going
to
grow
with
added
instrumentation
so
like
when
we
added
active
record
stuff.
We
added
active
record
to
this
like
test
app,
and
that
was
like
honestly
a
nightmare,
and
I
I
don't
want
to
misquote
him,
so
I
don't
even
say
his
name,
but
someone
from
the
rails
team.
A
A
C
Like
concrete
projects
or
something
in
like
prominent
projects
in
the
rails,
ecosystem
that
we
might
point
at
as
like,
hey
look
they're,
they
are
testing
or
not
testing,
and
if
that
would
help
us
feel
better
about
this
decision,
or
not,
I
don't
know,
is
that
a
terrible.
A
Idea,
I
think
it's
a
terrible,
terrible
idea
I
did
like.
I
did
actually
look
at
that
too
and,
like
some
of
the
stuff
like
I
forget,
I
checked
some
like
more
common
gems,
like
with
like
auto
instrumentations,
to
tell
stuff-
and
I
was
like:
are
they
testing
the
real
ties
and
like
a
lot
of
them
was
I
didn't,
because
I
was
trying
to
find
examples
of
how
to
do
this
properly
and
you
kind
of
quickly
realize
why
a
lot
of
prominent
public
repos
aren't
doing
it
right.
A
I
I
think
for
this,
like
I'm
gonna,
I'm
gonna
leave
it
at
ariel's
discretion
if
it
becomes
a
real
like
crazy
maintenance
burden
in
the
future,
I'm
liable
to
delete
it
all
whatever.
Maybe
I'll,
say
that,
but
I'm
gonna.
Basically,
I
think
I'm
gonna
just
review
this
file
and
approve
it,
and
let
ariel
know
that,
like
at
his
discretion,
he
can
drop
all
the
tests
and
just
keep
the
rail
tie.
A
If
he's
comfortable
doing
that,
because
I
am
if
it
becomes
like
a
friction
point
for
like
test
failing
and
like
adding
new
version
support
again
might
throw
away
the
rail
tie
tests.
A
B
B
We
only
run
in
ci
or
something
that's
like
spin
up,
get
lab,
spin
up
discourse
or
something
like
common
rails,
app
see
if
the
rail
tie
works
like
and
see,
if,
like
and
literally
test
like
log
output
or
something
and
make
sure
that,
like
the
instrumentation
like
hit
it
with
a
fake
request,
just
like
basically
a
really
happy
integration
test
on
a
containerized
like
rails
app,
so
we
don't
actually
need
to
like
handle
this
but
yeah.
I
agree
with
you,
robert
and
we're
also
over
time,
so
I
don't
want
to
talk
about
in
circles.
C
Yeah,
I'm
I'm
going
to
agree.
I
just
like
just
looking
at
this
pr
and
realizing
that
this
is
really
the
only
relevant
file
and
just
thinking
about
any
future
developer
on
this
project
like
coming
into
this
directory
like
it
would
be
so
much
nicer
if
you
just
knew
that
this
was
the
only
thing
that
was
relevant
here.
I
guess,
and
that
literally
everything
else
here
is
test
set
up.
C
C
I'm
happy
to
forgo
the
testing
and
if
yeah
I'd
be
happy
with
the
yagni
approach,
we
don't
need
it
until
we
realize
that
we
do,
and
if
we
do,
then
we
can
figure
out
if
it's
actually
just
better
to
spin
up
an
app
or
if
we
want
to
reintroduce
some
of
this
stuff.
C
Discussion
I
didn't
feel
like
this
is
def.
I
feel,
like
we've
answered
a
lot
of
the
hard
questions
here
and
are
pretty
much
in
agreement
with
things
so.