►
From YouTube: 2021-11-23 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).
B
A
What
time
is
it
and
over
there?
Oh.
A
A
Sorry,
I
yelled
at
you
in
the
I
wasn't
yelling,
but
when
I
reread
my
comments
it
might
have
been.
Maybe
in
your
internal
voice
it
could
have
come
off
as
yelling,
so
it
didn't
mean
to
be
rude
in
the
open
issues
or
whatever
just
just
trying
to
make
sure
you
know
we're
all
doing
we're
all
being
careful.
B
We
we
understand
that,
and
it's
all
good,
we
didn't
mean
to
make
any
unnecessary
noises.
So
something
like
that.
A
Yeah,
it's
fine.
I
think
it's
good
to
express.
I
think
github
doesn't
have
a
good
way
to
show
that,
like
people
are
interested
in
a
thing
like
the
emoji
reactions
are
kind
of
small
and
like
they're,
easy
to
miss
and
then
but
yeah
yeah,
so
glad
to
see.
There's
interest
in
the
aws
features:
what's
up
matt
and
yeah,
hopefully
get
it
reviewed
and
merged
this
week
and
stuff.
A
C
If
I
can
get
the
unmute
button,
I'm
in
northern
idaho
and
it's
on
pacific
time,
if
you
go,
I
don't
know
more
into
like
central
or
eastern
idaho.
It's
on
mountain
time.
Are
you
in.
A
And
you
have
a
mirror
sorry,
while
we
do
terrible
american
geography,
most
people
in
america
know
less
about
american
geography
than
most
people
in
the
world.
Probably
surprisingly,
good,
not
surprisingly,
but
I'm
one
of
them.
A
I
know
yeah,
I
know
that
boise
state
has
a
cool
football
field
and
that's
it's
kind
of
my
idaho
knowledge,
but
that's
fine
pennsylvania
doesn't
have
much
going
for
it.
So.
A
It's
you're
pretty
far.
C
C
A
C
So
yeah
there
was
there
were
these
two
issues
that
I
because
I
was
late.
I
did
not
like
I
missed
the
discussion,
but
they
both
seemed
like
relevant
and
potentially
important,
and
one
of
them
has
to
do
with
the
the
noaa
tracer
star
span
and
I
believe,
as
things
were
specked
you
were
supposed
to
create
at
least
two
ways:
written
you're
supposed
to
create
a
new
span
instance
but
reuse,
the
parents
spam
context.
C
I
think
I
think
I
got
that
right,
but
this
change
is
basically
saying
that
is
wasteful
and
why
not
just
return
the
parent's
van.
So
I
feel,
like
I
feel,
like
francis,
would
have
some
good
spidey
senses
on
this.
D
So
we're
actually
we're
working
with,
like
a
monkey
patch
and
our
own
rapper
gem
to
do
something
similar
to
this.
D
Our
version
is
potentially
also
wasteful,
we're
creating
like
the
no
span,
but
what
we're
doing
is
its
span
id
becomes
its
parents
family.
So
we
create
all
these
no
ops
bands,
but
we
set
this
fan
id
to
be
the
parents
fan
id
so
that
if
you
hypothetically
dropped
like
99
of
the
traces
in
a
request,
you
would
still
maintain
the
structure
of
the
spans
that
retained.
D
So,
if
you're
keeping
your
server
span-
and
maybe
some
outbound
client
spans-
and
you
want
to
preserve
the
structure
of
the
like
the
hierarchy,
all
those
no
outspans
are
just
thanking
the
parents
fan
id.
D
But
if
we
just
return
the
parent
span
itself.
Instead
of
creating
these
knowledge
spans,
it
seems
reasonable.
But,
like
again,
I
don't
know
what
I'm
missing.
If
we
were
to
just
not
create
those
no-ops
fans
all
together
like
what
could
be
the
implication
of
that
shouldn't,
be
anything
but
yeah.
Just
for
the
context.
We
are
actually
working
on
something
similar
like
this.
C
Yeah,
no,
that
all
sounded
good
and
very
interesting
and
I've
always
kind
of
felt
the
no
op
tracer
works,
weird
weirdly
in
a
hotel
and
that
it's
probably
actually
super
inefficient,
and
that's
not
what
you
want
out
of
the
no
watch
racer.
You
really
want
it
to
be.
As
yeah,
you
wanted
to
be
an
easy
off
switch.
I
guess
that
you
know
keeps
you
from
littering
your
code
with
a
bunch
of
conditionals
and
is
just
as
low
overhead
as
possible,
and
I
think
this
takes
it
a
step
closer.
C
D
Do
you
want
to
like
take
a
quick
tangent
first
to
explain
what
we're
doing
to
provide
context?
Why
we're
doing
it?
Yeah
yeah
go
for
it.
Basically,
we
have
a
high
volume
producing
service
and
right
now
we're
doing
sampling
at
the
collector.
D
But
the
end
result
is
that
we're
ending
with
a
lot
of
broken
trips,
because
the
service
happens
to
sit
between
a
lot
of
them,
but
because
it's
such
high
volume
we
need
to
control
like
it's
span,
output
and
what
we
really
want
is
we
don't
want
to
break
any
of
our
traces
and
we
don't
want
to
sample
this,
but
reality
sets
in
when
the
span
volume
is
like
absurdly
high
right,
like
we
just
have
to
face
that
somehow
so
we're
working
at
controlling
the
robots
to
give
the
traces
that
are
emitted
from
it,
and
so
it
would
be
like
a
low
velocity
mode
where
you
could
only
retain
the
server
spans
and
client
spans
so
that
you,
if
something
talks
to
it,
you
retain
that
service
band.
D
If
it
talks
to
something
else,
you
retain
that
client
span,
but
you
need
to
preserve
that
hierarchy
so
that
you
can
actually
look
up
trace
in
a
structured
way.
But
to
do
this,
you
need
to
preserve
the
hierarchy,
which
means
passing
along
that
span
id
within
those
non-recording
spans
and
we're
using
a
sampler
to
do
this.
So
basically
the
sample
will
say
this.
D
Span
but
its
span
id
is
the
server
span
or
the
client
span
back
and
we're
really
excited
about
the
part.
I'm
really
excited
about
this
approach
as
eric's
root
for
the
hundredth
time,
but
that's
the
motivation,
but
the
spec
doesn't
support
it
right
now.
I
did
bring
it
up
with
ted
in
the
instrumentation
saying
as
an
aside
to
see
and
he
thought
it
made
sense
as
well.
D
So
hopefully
there'll
be
some
more
support
for
this,
but
because
I
think
this
back
doesn't
say
that
we
can
do
this
so
we're
we're
monkey
patching
the
tracer
providers
internal
spam
create
right
now
in
ruby
to
make
this
possible.
So
that's
like
the
full
story.
C
Cool
yeah,
no,
that
sounds.
It
sounds
like
a
good
approach
and
it
sounds
like
it's
not
an
unusual
problem.
I
guess
to
have
like
one
of
these
services
that
is
kind
of
like
a
thing
that
that
many
requests
go
through
and
that
you
are
not
going
to
want
to
have
like
full
verbosity
on
everything,
but
if
you
can
just
limit
it
to
like
the
server
stand,
you
know
nine
times
out
of
ten,
like
you
can
at
least
gather
that
one
and
keep
the
traces
from
breaking
so.
D
Yeah
and
then
the
idea
is
like
you
want
to
provide
optional
support
to
say,
like
request
high
velocity,
we
have
means
of
doing
that
through
baggage
right,
so
you
check
the
baggage,
and
so
if
another
service
is
debugging
something
and
they
want
the
request
for
the
service
to
not
drop
any
of
the
additional
spends,
you
could
then
request
it.
But
for
let's
say
99
of
the
traces
that
aren't
forced
you
would
have
lower
about
low
velocity
mode
or
something
like
that.
C
C
Cool
yeah
so,
like
I
was
saying,
I
don't
know
what
discussion
actually
happened
around
it
if
this
was
just
like
a
link
in
the
doc,
you
know
just
briefly
mentioned,
but
it
does
not
have
any
approvals
and
the
conversation
is
pretty
minimal.
So
it
does
look
like.
C
D
C
Cool
and
this
this
is
another
one.
I
think
that
definitely
has
implications
for
us
and
could
potentially
be
interesting,
but
this
is
supporting
per
tracer
configuration
through
the
tracer
provider.
C
So,
potentially,
I
think
that
means
sampler
id
generator
span
limits
on
a
per
tracer
level.
C
I
guess
this
is
a
new
functionality.
I
I,
I
guess,
I'm
just
kind
of
thinking
how
this
like
works
with
like
1.0,
and
this
seems
like
a
pretty
big
change,
but
I
guess
you
can
technically
add
things
and
it's
backwards
compatible,
but
yeah.
This
is
a
totally
new
idea.
It
was
a
totally
new
document
that
is.
C
C
Whatever
it
is,
it
looks
like
an
a-plus
to
me,
so
you
all
can
read
through
it
and
give
it
a
grade
and
chime
in
on
the
conversation.
If,
if,
if
you
like
it
or
if
you
hate
it.
C
A
C
My
guess
is
that
you
would
have
like
the
global
configuration
like
what
you
have
now,
but
you
would
be
able
to
override
it
on
a
per
tracer
basis,
so
yeah
you
would
exactly
be
able
to
do
that
and
it
was
kind
of
like
I
don't
know.
I
at
least
saw
this
line
where
you
could
kind
of
like
do
something
like
that.
C
So
you
could
set
a
difference
like
a
different
sampling
rate
for
a
tracer.
A
C
A
C
Yeah,
if
you
think
through
this
and
have
some
revelations
of
it
being
amazing
or
terrible,
feel
free
to
share
them,
maybe
at
that
next
next
meeting
or
whatever.
A
C
All
right,
so
there
was
a
decent
amount
of
talk
about
metrics.
There
will
not
be
a
metric
sig
due
to
the
thanksgiving
holiday.
What's
the
time
was
spent
in
issue
triage?
I
don't
know.
C
A
Yeah,
I
have
a
few
things,
but
yeah
you
nev
did
you
want
to.
I
know
you've
been
waiting
anxiously
all
day
for
this
meeting,
because
you
love
talking
to
us
all
our
cheery
attitudes
and
jokes.
What
how
how
are,
how
are
things
going
with
you
all?
What?
Where
would
you
guys
like
eyes
on
any
yeah.
A
I'll
admit
I
haven't
reviewed
it,
yet
I'm
planning
to
review
this
week
I
mentioned,
but
yeah
I've
haven't
had
a
chance
yet,
but
yeah
is
there
anything
on
the
top
of
your
mind,
things
you
were
uncertain
about.
I
know
we.
There
was
an
issue
where
it's
hard
to
denote.
B
B
A
I
promise
I
will
give
it
a
thorough
review
this
week.
I
just
haven't
had
time
yet
I
think
yeah.
As
long
as
off
the
top
of
my
mind,
I
know
that
the
the
message
attribute
limit
is
a
known
issue
within,
so
I
think,
as
long
as
we're
kind
of
sticking
to
what
the
approach
that
I
guess
node
is
doing,
you
know
there's
no
specification
around
it.
It
might
be
good
if
tomorrow,
I
know
like
I
usually
go
to
the
collector
meetings.
A
I
can
see
if
some
of
the
aws
folks
have
opinions
on
how
they'd
prefer
it
to
be
handled
so
that,
just
generally
speaking,
we
know-
I
don't
know
if
they
have
some
implementation
in
x-ray.
They
know
about
or
they
have
plans
to
hit
like
it
might
be
good
to
try
to.
We
can
maybe
try
to
loop
in
someone
from
that
team
to
get
a
review
because
you
know
they're.
Ultimately,
they
would
know
the
most
about
their
services.
The
only
other
thing
what
else
is
yeah?
A
I
think
we
should
try
to
have
some
way
to
test
in
appraisals
like
have
appraisals
for
v2
and
v3
of
the
sdk,
to
make
sure
we
have
some
tests
for
each
version.
A
We've
kind
of
taken
an
approach
here
of
like
try
to
guarantee
as
little
backward
compatibility
as
possible
like
because
we
can
now
like
say:
oh
we're
only
supporting
the
current
and
future,
but
I
think
with
aws
there's
a
lot
of
usage
of
both
at
the
moment,
so
it
makes
sense
to
support
both
as
long
as
you
know,
we
feel
comfortable
doing
that,
which
I
think
is
fine
yeah,
but
yeah
outside
of
that.
I
don't
want
to
talk
too
much
before
actually
reviewing
I've
probably
talked
too
much
without
evan
actually
reviewed.
A
E
We
lay
maurice
from
the
x-ray
team,
which
I
try
to
to
understand,
who
I
can
talk
to
in
aws,
to
understand.
What's
the
preferred
method
to
do
it,
I
think
that,
besides
from
javascript,
nobody
else
implemented
the
context
propagation
in
those
systems,
and
nobody
can
tell
me
how
they
want
to
do
it
yeah
and
what
he
does
is
a
ruby
guy
like
they
had
a
ruby
guy
in
x-ray,
but
he
left
and
nobody's
ruby
currently,
and
he
tried
to
talk
with
the
sqs
team,
but
they're
very
busy.
E
From
sqs
like
to
talk
with
us,
but
I
couldn't
all
my
efforts
well
like
no.
A
Worries
we
have
aolita
is
so
I
know
like
x-ray
is
a
different
pm
than
the
hotel,
aws
folks
and
then
so.
That's
added
complication,
but
I
know
alelita
is
on
the
governance
committee,
I
believe
within
hotel,
so
she
ought
to
be
able
to,
and
I
have
a
decent
relationship
with
her
from
when
I
was
at
a
dog,
so
I
might
be
able
to.
I
could
ask
her
but
yeah.
I
think
it's
fine,
it's
not
the
end
of
the
world.
A
A
woman-
yes,
I
can
try.
I
know
they're
very
active
on
the
collector
they're,
very,
very
active
contributors,
so
I
think
they
want
to
see
it
would
make
sense
for
them
to
care.
I
think
it's
in
their
their
incentives
are
aligned
with
ours
here.
So
I
could
ask
you
know
I
can't
promise
anything
but
and
honor
anarag
right
who
reviewed
our.
I
think
he
did
our
tc
review
matt
he's
at
aws
as
well
and
anthony
marabella.
So
there's
a
few
people
I
can
bug.
A
C
Cool
yeah,
no
just
taking
a
glance
through
this
it
it
looks
good
and
on
track.
I
think.
Like
always,
the
big
question
is
like:
what
really
should
these
semantic
conventions
be,
and
I
think,
like
they
are
kind
of
undefined
for
some
of
these
systems.
I
think
they
are
loosely
covered
by
the
message.
Q,
spec
and
I
do
know
there
is
a
working
group
around
looking
at
how
to
best
instrument
message
cues.
So
I'm
not
sure
how
interested
they
are
in
in
sqs
over
sns.
C
E
I
attended
the
meetings
for
a
messaging
instrumentation
and
specification
and
a
lot
of
ideas
and
discussions,
and
it
will
probably
be
changed
in
the
following
month,
but
I
think
the
current
implementation
follows
the
current
specification
which
will
need
to
be
updated
once
the
specification
is
updated
yeah.
There
are
so
many
problems
and
open
issues,
it's
still
not
converging,
but.
E
C
Cool
yeah,
no,
I
I
agree.
I
think
it
makes
sense
to
move
forward
with
this
stuff
because
you
all
are
doing
some
great
work,
and
this
is
this
is
working
for
you
and
others.
So
I
think
I
think
the
spec
will
come
along
and
I
definitely
yeah
encourage
you
all
to
like
participate
in
kind
of
that
respect,
work.
That
happens
just
that
you
can
speak
up
for
kind
of
the
decisions
that
that
you
made
and
if
anything
does
change
yeah.
We
will
kind
of
address
that,
as
it
comes.
C
But
yeah
so
so
all
of
us
should
try
to
get
some
eyes
on
this
if
we
do
some
spare
cycles
in
the
coming
days.
Thank
you.
Thank
you
for
your
contributions
and
patience
on
this
stuff
and
also
feel
free
to
keep
like
poking
us
and
bugging
us.
If
stuff
isn't
happening
like
I
think
yeah,
I
think
we
all
welcome
the
occasional
nudge
because
it's
it's
necessary
to
run
an
open
source.
So
don't
feel
that
I
think.
D
Maybe
we
should
consider
introducing
kind
of
assigned
reviewers
like
we,
don't
really
use
the
assigned
to
functionality
that
much
on
people
requests
not
gonna
try
to
impose
this,
but
we
talked
about
it
very
briefly
like
earlier
in
the
week
that,
maybe
if
like
say
eric,
has
been
beautifully
reviewing
these
pr's,
that
he
could
just
assign
himself
and
so
that
we
know
who's
handling
the
review
and
the
ownership
of
getting
these
pr's
through.
D
On
behalf
of
like
the
open,
telemetry,
ruby
side
of
things
and
then
also
the
authors
of
the
prs
know
who
they're
kind
of
dedicated
contact
person
is
to
kind
of
nudge
of
it?
I
don't
know
if
anyone
has
any
stronger
weak
sentiments
towards
that.
I
think
it
makes
sense,
and
also
for
for
us
personally,
like
the
shopify
folks.
D
It
gives
us
a
bit
more
visibility
into
time
being
spent
in
the
open
source
repo
which,
like
is
good
like
we
know
we're
spending
time
there,
but
it's
just
nice
to
just
you
know
what
has
rob
been
working
on.
What
has
erika
working
on.
We
can
actually
just
kind
of
track
that
a
little
bit
more
reasonably.
C
Yeah,
I
think
that
makes
sense,
I'm
seeing
a
lot
of
thumbs
up
from
the
rest
of
the
crowd.
D
Cool
yeah
then,
like
I,
I'm
going
to
try
doing
it
myself.
So,
even
if
it's
like
a
pr
that
I
didn't
author,
I'm
going
to
like
assign
myself
to
say,
like
I'm,
committed
to
shepherding
this
through
in
some
capacity-
and
I
know
obviously
it
requires
like
a
maintainer
to
give
it
the
final
like
nudge
through,
but
still,
I
think,
like
the
the
value.
Is
there
whether
it's
an
approver
or
maintain
your
own
scientific
jar.
A
I
hit
a
few
small
things.
One
is
that
ariel
has
an
interesting
pr
up.
That,
I
think,
is
a
good
gateway
to
having
better
testing
like
automated
testing
of
versioning,
essentially
he's
using
the
the
ideas
like
right
now.
A
lot
of
our
like
compatibility
is
based
on
I'm
sort
of
talking
on
his
behalf,
because
he's
not
here
it's
based
on.
A
We
just
have
like
a
compatible
block
and
you
just
sort
of
like
say
you
know
oh
greater
than
version
whatever,
but
a
lot
of
that
metadata
then
gets
is
just
in
line,
and
so
you
can't
programmatically
outside
of
maybe
like,
like
adding
appraisals,
it's
hard
to
say
like
what
your
version
compatibility
is.
A
What
he's
doing
is
basically
adding
a
little
helper
method
to
the
base
class
where,
instead
of
defining
like
all
this
custom
logic,
you
just
supply
the
gem
name
that
you're
patching
and
what
it
does
is
it
looks
at
your
gem
spec
and
determines
what
your
and
allows
in
the
gem
spec
for
you
to
add
min
and
max
version
request.
You
know
basically,
whatever
versioning
you
supply
in
the
gem
spec
for
the
gem
that
you're
patching.
A
You
know
this
gem
greater
than
x
version
less
than
whatever
and
then
from
there
it.
It
sort
of
like
auto,
generates
a
default
compatibility
block
or
not
audit
it.
It
supplies
like
and-
and
it
can
be
over,
you
know
like
if
you
supply
your
own,
it
can
be.
It
can
overrule
us
because
some
things
you
can't,
I
don't
know,
maybe
compatibility-
could
be
based
on
something
arbitrary
in
the
future.
It's
based
on
platform
or
something
that
we're
not
gonna,
really
be
able
to
like
know
but
yeah.
A
I
thought
it
was
a
helpful
thing
and
then
also
it
would
allow
us
in
the
future.
If
we
want
to
programmatically,
like
you
know,
do
maybe
appraisals
based
on
we
could
just
programmatically
grab
all
the
vert
major
versions
and
do
appraisals
instead
of,
like
you,
know,
defining
them
manually
anyway.
I
I
think
he
was
looking
for
feedback
on
it.
I
had
said
like
originally.
I
was
like
this
looks
interesting
to
me,
but
it's
possible,
I'm
not.
A
I
haven't
given
it
like
a
thorough
review
and
I
also
haven't
thought
like
super
deeply
about
whether
there's
cases
that
this
is
oversimplifying
things
or
whether
this
just
makes
things
more
complicated
and
does
it
add
any
value
so
yeah,
just
kind
of
trying
to
socialize
it.
I
know
he's
been
working
on
a
little
and
at
this
point
like
I
think
he
doesn't
want
to
spin
his
wheels,
probably
without
getting
like
some
feedback,
so
yeah
just
bring
it
up.
A
So
people
have
opinions
here
I'll
try
to
get
a
review
out
this
week,
but
my
personal
opinion
here
is
like
I
kind
of
like
it.
So
if
people
see
something
wrong
like
you
know,
I
I've
kind
of
I
already
have
rose
colored
glasses
a
little.
So
so
that's
the
one
I
don't
need
you
know
like.
We
don't
need
to
like
bike
about
right
now.
The
other
is
oh
doing
some
testing.
Internally,
I
found
out
that
we
don't
tim
actually
he's
not
here
turns
out.
A
A
Some
of
the
method
signatures
have
changed
like
pretty
significantly
in
rail
7
and
right
now
we
would
just
quietly
patch
and
then
blow
up
in
production,
which
would
be
bad
so
because
the
method
signatures
are
just
like
outright
different
and
they
use
keyword
arguments
so
like
it.
You
know
we'll
just
throw
some
goofy
errors,
so
we
probably
need
to
restrict
our.
We
need
to
max
version
our
active
record
instrumentation
until
we
have
so.
A
D
A
It
might
have
tests,
but
the
only
reason
it
would
explode
is
like
the
way
it
would
explode
is
you
would
call
this
method
that
we've
overwritten
that
now
accepts
fewer
keyword,
arguments
and
so
in
practice,
that
method
will
now
get
called
with
more
keyword,
arguments
that
the
r
patch
method
doesn't
know
exist
and
so
it'll
throw
an
error
like
we
don't
recognize
these
arguments,
so
we
would
their
test
would
have
to
assume
that
they're
testing
it.
You
know
in
a
way,
that's
not
like
right
now,
I
think.
A
D
A
Oh
it'll
throw
an
error
at
runtime
like
when
the
method
gets
called.
Assuming
I
mean
assume,
assume
no
test
suite
for
an
application.
That's
not
a
requirement
of
running
a
rails.
Application
is
having,
like
a
you,
know,
a
full
suite
of
unit
integration
tests.
It
would
patch
successfully
and
then
based
on
some
like
underlying
internals.
So
you
know,
I
think,
when
you
call
upsert
all
under
the
hood
is
calling
just
like
upsert
a
few
times,
then
it
would
throw
an
error
at
runtime,
so
it's
not
probably
anyway
the
so.
A
A
I
think
we
should
probably
not
let
people
install
it
or
just
say
it's
unsupported
until
we
have
some
degree
of
confidence
that
you
know
it's
whatever
not
going
to
crash
people's
apps.
So
that's
the
other
thing
that
was
on
my
mind.
I
have
to
add
an
issue,
but
just
a
heads
up
in
case
people
are
any
other
folks
are
running
rel7
in
production.
C
Does
it
make
sense
to
have
an
issue
describing
potential
problems
as
as
a
solution
is
being
worked
on
or.
A
I
mean,
I
think
we
should
do
two
things
and
they
should
be
done
in
concert
which
is
like
one
is
just
add,
a
small
one-line
pr
to
their
active
record,
instrumentation
that
in
our
compatible
block
have
it
be
greater
than
rails,
four
or
whatever
it
is
less
than
you
know.
Rail,
seven
or
you
know
just
add
a
major
just
at
a
max
and
I'm,
I
think,
there's
a
minor
version
out
of
max
as
well
and
then
in
concert
with
that
had
an
issue
to
say,
support
rail7.
A
Just
so
people
recognize
that
it's
being
worked
on,
I
mean
we
could
add
a
more
descriptive.
We
could,
you
know,
always
add,
like
a
debug
log
or
something
in
the
instrumentation
to
say
like
hey
at
this
time.
It's
not
supported
we're
working
on
it
but
yeah.
So
I
think
it's
two
things.
One
is
like
be
protect
users
and
then
the
other
is
like
inform
them
that,
like
we're,
not
we
we're
going
to
work
on
it.
It
just
not.
C
Yeah,
I
think
that
sounds
good.
I
think,
just
at
a
bare
minimum,
having
like
an
issue
like
rails,
rail
7
support
is
needed
just
that
if
people
run
into
a
problem
like
they,
they
know
that
we're
aware
of
it,
and
they
know
it's
actually
a
problem
and
aren't
tearing
their
hair
out,
trying
to
actually
get
things
to
work
when
they
won't
work.
C
E
E
Whether
it
should
be
emerged
or
not,
I'm
okay,
if
you
think
it's
not,
it
does
not
belong
here,
I'm
okay
with
it.
Just
if
you
want
to
discuss
it
and
decide
what
to
do
with
it.
D
I
think
one
of
the
things
that
stands
out
to
me
is
like
it
seems
a
little
too
generic,
because
it's
going
to
try
to
infer
the
deployment
environment
based
off
of
various
common
environment
variables,
but
then
it
becomes
a
bit
like
a
kind
of
like
a
guessing
detector
right,
and
so,
if
we're
gonna
check
for
sinatra
rails,
iraq
should
we
also
be
checking
for
rota
and
various
other
frameworks
and
to
what
end
do
we
stop
checking
and
which
one
has
priority,
for
whatever
reason
two
are
set?
D
So
if
you
have
say
like
rota,
environment
variable
send,
and
you
have
rack
and
sinatra,
and
they
differ,
which
one
takes
priority
right.
That
becomes
really
difficult
like
it
sounds
weird,
and
why
would
anyone
have
that
in
deployment
environment,
but
we
kind
of
have
to
trust
that
it
probably
will
happen
and
that
it
it's
just.
D
It
feels
a
little
too
generic.
From
from
my
viewpoint,
I
think
if
you
want
to
set
your
deployment
environment
based
off
of
say,
a
rails
environment,
it
would
make
sense
if
that
existed
in
the
rails.
Instrumentation,
we
have
a
rails,
instrumentation
package.
We
can
reliably
at
that
point
within
that
instrumentation
package.
We
know
that
rails
is
available
or
is
set
up
on
this
project
because
it's
going
through
the
install
process
and
we
can
pull
directly
from
like
a
rail
tie
and
set
the
rails
environment
and
the
same
thing
is
true
of
rack.
D
If
we
want
to
try
and
refer
the
deployment
environment
from
rack,
we
could
do
it
as
part
of
the
rack
instrumentation.
But
again
you
run
into
a
bit
of
a
conflict
that
says
well,
I
have
rack
and
I
have
rails
and
they've,
given
me
two
environment
variables
and
for
whatever
reason
they
differ,
which
one
do
you
choose.
D
E
The
problematic
entity
in
open
telemetry,
because
it's
immutable,
you
have
to
decide
about
the
values
before
you
set
up
the
tracer
provider
and
and
that's
why
it's
a
problem
to
to
have
it
in
the
instrumentation,
because
when
your
instrumentation
loads,
it's
too
late
to
update
the
resource.
E
So
what
it
means
is
that
we
have
to
add
it
as
span
attribute
instead
of
resource
attribute,
which
can
also
work
and
not
against
it.
I
think
it
can
be
good,
but
it's
like
in
the
specification
currently
it's
part
of
the
resource,
which
I
think
makes
sense,
because
it's
like
something
static,
that's
only
configured
for
the
service
in
all
and
not
for
the
specific
spam.
E
I
know
that
our
customers
want
it
and
need
it,
because
the
environment
is
very
important
for
people
that's
collecting
telemetry
and
even
if
it's
not
a
100
percent,
accurate,
it's
better
than
not
supplying
it
at
all,
and
I
know
that
we're
going
to
to
have
it
in
our
this
drawer
like
it's
it's
currently
in
our
distro.
I
just
added
the
code
to
the
official
repo
to
share
it
with
other
people
if
they
want
to
use
it.
E
But
if
you
think
it
does
not
belong
here,
it's
okay
like
in
javascript,
we
have
the
contributor
which
accepts
like
contributions
like
third
party
contributions,
which
may
be
not
part
of
the
core
functionality,
but
people
may
still
find
useful,
for
I
don't
know
many
cases,
even
if
they're
not
covering
100
of
their
cases
yeah,
but
I
think
eventually
it's
the
choice
of
the
users.
If
they
want
to
use
it
or
not
anyway,
if
you
don't
think
it
belongs
here,
I'm
totally
okay
with
it.
D
Yeah,
I
think
I
think
the
problem
is
we
don't
have
a
control
repo
which,
like
I
think
I
feel
more
comfortable
putting
it
there.
It
would
make
more
sense
again.
I
just
I
do
feel
like
it's
just
a
little
unfocused
and
it's
just
like
I'm
just
a
little
apprehensive
to
choose,
which
one
wins
like
in
that
that
condition
like
which
one
takes
priority,
which
environment
takes
priority
over
the
other
and
then
having
that
encoded
somewhere
and
then
eventually
someone
may
be
saying
they
want
to
change
it.
D
A
A
You
know
I
think,
like
let's
say
there
was
something
that
did
like
there's
a
few
like
apart
from
this
specific
issue
like
let's
say
there
is
something
where
we
it's
really
only
applicable
for
like
rails
instrumentation,
but
it
applies
to
a
resource
like
we
don't
have
a
good
home
for
that
stuff,
and
so
that's
like
a,
I
think,
that's.
A
Not
specific
to
this
issue,
but
it's
like
being
exacerbated,
I
think
it's
like
it
would
be
really
nice
to
have
a
contribute
like
contrib
is
for
me.
It's
like.
I
think
we
should
name
it
like
what
it
is,
which
is
like
a
rap
rail
sinatra,
resource
detector
and
throw
it
in
a
contrib
repo
mark
it
as
experimental,
and
you
know
tell
people
to
like
good
luck
have
fun
like,
but
we
can't
do
that
right
now.
So
I
think
maybe
this
is
like.
A
Maybe
we
should
put
this
on
hold
and
say,
like
it's
evidence
that
we
need
to
make
a
contributor,
and
once
we
have
a
contrib
repo
I
would
I
agree
like
I
would
feel
a
lot
more
comfortable
there.
I
think,
having
it
called
like
a
deployment
detector,
although
that's
like
the
semantically
correct
thing
to
say,
is
misleading
because
it's
like
a
deployment
detector,
sometimes
and
then
other
times
it's
nothing
and
we
don't
so
yeah.
I
I
mean
my
two
cents
is
like.
A
I
think
it's
I'm
a
little
is
I
don't
love
having
it,
but
I
think
it
would
be
fine
to
have
if
we
could
shove
it
on
a
contributor
and
we've
been
kicking
the
can
on
a
contributor
for
a
while.
So
maybe
we
ought
to,
I
don't
know.
Maybe
we
ought
to
like
make
an
issue
say,
and
we
can
prioritize
that
issue
accordingly
and
say
when
we
do
make
a
contributor.
A
You
know
here
is
one
of
the
things
we
want
to
add
to
it
and
that
might
be
a
decent
middle
ground.
At
the
same
time
like
I
do
feel
bad
because
I
don't
want
you
know
like
I
do
think.
There's
some
benefit
amir
and
you
need
to
like
having
you
know.
You
want
to
maintain
if
you
want
us
to
build
on
top
of
open
telemetry
like
it's,
not
necessarily
a
great
feeling
to
have
to
manage
your
own
packages
and
stuff.
So
I
see
both
sides
but
yeah.
A
E
A
You
when
you're
sorry
to
interrupt,
but
when
you
pointed
to
that
link,
that's
just
a
link
to
what
the
resource
attribute
is
called,
there's
nothing.
As
far
as
I
know,
there's
nothing
in
the
specification
that
says
a
resource
detector
has
to
be
named
after
what
the
resource
attribute.
It's
updating
is
so,
like
you
know,
gc
the
gcp
resource
detector
is
called
gcp
resource
detector,
but
it
updates
a
bunch
of
k8
deployment.
Envi
attributes,
it's
not
like,
so
I
think
there's
some.
I
think
we
do
have
some
flexibility
there
on
naming
is
my
two
cents.
C
Yeah,
I
guess
I
will
speak
up.
You
know
and
express
some
support,
at
least
in
spirit
for
this,
because
I
think
people
really
do
want
this
and
I
think,
like
resources,
the
way
they
are.
They
are
tricky
to
get
initialized
and
yeah.
I
know
I
have
worked
at
previous
vendors
and
this
is
definitely
something
that
was
part
of
those
products
trying
to
kind
of
detect
the
environment
and
there
was
definitely
a
arbitrary
hierarchy
that
was
kind
of
developed.
C
So,
like
yeah,
I
recognize
that
this
rails
and
sinatra
and
rack
and
it's
a
little
bit
subjective-
and
I
guess
one
thing
I'm
just
thinking
is
like.
Is
there
any.
C
Can
just
make
this
thing
flexible
enough
that
it
that
you
could
configure
what
things
it
looks
at
and,
as
I
was
just
kind
of
like
looking
through
it
like
a
lot
of
these,
are
just
like
really
easy
like.
If
you
had
configuration
where
you
could
just
say,
you
know,
look
at
the
rack
and
environment
variable
then
the
rails
end.
Then
the
rota
end
or
something
like
that.
A
D
I
think
I
think
at
that
point,
though,
then
you're
just
like
what
value
with
this
like.
If
you
have
to
pass
in
that
information,
I
feel
like
the
value
in
this.
Is
it's
the
no
touch
right,
you
just
say
call
this
one
line
and
it
sets
it
right,
and
I
appreciate
that
like
I
definitely
appreciate
the
need
for
it,
and
this
might
be
a
little
bit
like
shady,
but
just
trying
to
make
sure
we're
bringing
in
the
right
thing
and
again
I
I
do.
D
Personally,
I
intend
to
think
on
this
a
little
bit
more
and
try
to
come
up
with
a
more
concise
answer,
even
if
it's
just
like
yeah,
let's
just
bring
it
in
and
not
be
difficult
or
let's
push
ahead
and
get
the
control
going,
but
I
try
to
get
a
faster
turnaround
on
something
a
little
more
definitive,
but
my
first
impression
still
kind
of
holds
is
like
how
do
we
choose
the
priority
like
ordering
on
this
in
a
way
that
makes
sense,
yeah.
C
And
I
guess
the
alternative,
if,
if
we
didn't
have
this
would
be
that
users
would
pass
this
stuff
in
through,
like
the
the
hotel
resource
attributes
kind
of
yeah
global
bag
at
the
environment
level.
That
would
be
like
one
one
workaround,
but
this
one,
that's
not
a
detector,
that's
kind
of
like
you
are
telling
us
what
the
environment
is.
A
But
yeah
I
do
echo
roberts
one
can
one
big
concern
I
have
within
with
us
not
having
contrib
is
right
now
in
resource
detectors.
There's
a
method
called
like
detect
and
it
just
grabs
every
single
resource
detector
then,
like
we
document
that
method,
it's
supported
by
core
open,
telemetry,
ruby
and
like
that,
feels
a
little
dangerous
to
me
to
have
like
this
thing,
just
like
grabbing
like
gcp
is
or
the
the
platform
stuff
is
sort
of
like
well,
it's
sort
of
just
kind
of
no
ops.
A
If
it's
not
useful
and
if
it
is
useful,
people
want
to
know
their
platform
stuff,
whereas
this
one
kind
of
feels
ugly
just
to
have
it
in
this
like
cat,
you
know
like,
so
that's
the
only
thing
that's
concerning
me.
It's
like
right
now
it
would
get.
There
is
a
path
where
a
user
could
just
sort
of
like
accidentally
bring
this
in
without
even
realizing
and
yeah.
I
think
it's
pretty
common
to
maybe
have
a
slightly
different
production
environment
in
your.
A
You
know
in
what
your
rails
am
versus
sinatra
m,
defines
than
what
you
might
actually
want
it
to
be,
and
this
would
override
your
hotel
resource
attributes,
global
bag.
So,
like
yeah,
I
do
think
it's
not
com,
I'm
not
super
comfortable
thinking
on
it,
a
little
more
and
until
at
minimum
we
have
a
contributor,
but
we
don't
so.
C
A
I
mean,
I
think,
robert's
point
is
good
regardless,
which
is
like
it's
not
super
robust
and
there's
all
these
edge
cases,
and,
like
you
know
I
mean
I
guess,
here's
my
thing
is
like
amir
and
yaniv
like
it
sounds
like
you
guys
kind
of
are
unblocked
anyway,
because
you
have
a
you
know.
You
just
point
your
users
to
your
third
party
and
you
know,
package
or
gem
and
they're
comfortable
installing
that
so,
like
I'm,
not
super
concerned
either
way,
if
you
guys
are
not
super
concerned,
is
that
the
case
like
you
guys
are?
E
E
I
just
want
to
show
that
we
had
an
installation
today
on
customers
with
ruby
and
they
were
very
happy
to
see
the
environment.
They
were
like
surprised.
E
C
Yeah,
I
I
definitely
recognize
the
usefulness,
however
yeah,
like
I'll
I'll,
defer
to
what
we
want
to
do
as
a
group
for
now
like,
if,
if
we
want
to
have
have
a
specto,
just
kind
of
host
us
the
time
being
and
keep
this
in
the
back
of
our
minds.
If
people
come
asking
for
it,
then
we
kind
of
maybe
know
that
we
might
want
to
promote
that
into
like
a
contrib
repo
or
at
least
know
that
it
exists
or
point
people
towards
towards
that
repo
as
an
optional
thing.
C
But
I
think
this
will
be
useful
for
a
lot
of
people,
even
though
it
might
not
be
robust
enough
for
everybody,
so
just
trying
to
find
the
right
compromise
to
make
sure
that
people
that
want
to
use
this
functionality
can
find
it
somewhere.
C
Should
we
call
it,
then
all
right,
let's
call
it
for
those
of
you
that
have
a
holiday
this
week,
happy
holidays.
The
rest
of
you
have
have
a
good
and
happy
week
and
we'll
see
you
next
week,
bye.