►
From YouTube: 2021-05-18 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
Hey,
I
thought
15
minutes
and
then
I
leave
for
15
minutes
and
then
I'll
be
back
gotcha.
B
C
Question
for
you
does
the
zoom
video
does
this?
Does
this
change
in
clarity
when
I
zoom
in?
Does
it
like
get
fuzzy?
Are
you.
B
It's
a
little
bit.
Okay,
it's
on
the
margin
might
be
slightly
more
pixelated,
but
I
I
can
I
can
read
like
I
don't
know
the
things
behind
like
the
the
california
flag
and
stuff.
I.
B
B
C
C
C
I'm
also
terrible
at
using
pastry
bags
for
what
it's
worth.
I
I
made
little
like
cupcakes
the
other
day
and
apparently
pillsbury
sells
cupcake
frosting,
but
in
pre-filled
pastry
bags-
and
I
was
like
well
that's
handy.
I
could
be
super.
Fancy
turns
out
that
there
was
just
frosting
all
over
my
all
over
creation
afterwards,
that
it
a
couple
of
them
looked
nice
and-
and
I
learned
exactly
how
hard
pastry
bags
can
be
to
use.
C
C
D
D
Okay,
I
know
these
are
like
recorded
and
they
go
on
youtube
and
everything.
But
two
observations,
one
friend
says:
is
that
a
squire,
a
finished
choir
right
behind
you.
E
D
It's
totally
fine.
I
just
shut
off
his
video.
He
doesn't
want
to
reveal
that
he's
like
an
amazing
singer,
oh
cool
and
I
don't
know
matt
your
view
is
so
different.
Now,
I'm
like
I
look
at
your
background
and
I'm
like.
Doesn't
I
see
a
tv?
It's
it
looks.
It
looks
like
you
changed
positions.
A
D
Eric
enjoying
those
those
those
post
restriction,
views.
B
I
don't
I
just
I
think
you
can
see
the
embarrassment
anyway
there.
It
is.
F
Back
there,
it's.
B
A
By
talking
about
our
technical
details
here,
let's
see-
I
guess
this
is
our
agenda
from
from
last
week.
We
can
fill
it
in
for
this
week
at
this
point
at
some
point,
I'll
go
ahead
and
jump
in
with
the
specs
egg,
as
it
was
pretty
short.
A
So
one
of
them
we
talked
about
it
seems
like
maybe
not
an
amazing
idea,
but
nobody
really
opposed
it.
So
it
was
basically
about
trying
to
possibly
a
fast
track.
The
metrics
api
and
b,
possibly
like
try
to
release
it
as
as
being
stable,.
A
Before
the
sdk
spec,
so
that
I
think
the
the
underlying
desire
here
was
to
be
able
to
get
to
get
the
api
in
instrumentation
authors
hands.
So
they
can
see
if
it
would
be.
A
Usable
but
I
guess
yeah,
I'm
having
trouble
understanding
what
all
that
actually
means,
because
if
it's
not
usable,
it's
already
kind
of
been
released
as
stable,
so
you're
kind
of
like
stuck
with
what
you
have,
and
maybe
the
idea
is
to
just
be
like
really
incremental
with
what
you
put
in
there.
But.
D
A
Let's
see
so
there's
not
it's
not
an
issue.
I'm
talking
about
this
item
here
and
there's
not
actually
anything
linked
apparently
like
this
was
discussed
during
the
metrics
api
spec
sig
meeting.
A
A
So
this
is
a
separate
meeting
and
they
just
kind
of
brought
this
back
to
the
hotel
specs
egg
to
to
discuss.
C
So
is
the
thought
so
they're
thinking
about
releasing
the
metrics
api
spec
as
experimental
before
the
sdk
spec
is
also
released
as
experimental,
or
I
guess
I'm
wondering
like
why
the
disconnect
and
what
do
they
hope
to
gain
by
that,
because
I
would
worry
if
the
metrics
api
is
released
before
the
sdk
is
released
or
the
the
relevant
specs.
Then,
though,
you
might
get
the
wild
west
in
the
specs
or
the
sdks,
and
that
might
not
be
great,
but
I
don't
know.
A
Releasing
anything
in
in
pieces
like
this
is
there's
always
like
a
risk
that
they
don't
line
up
in
the
end,
so
if
they
want
to
release
it
as
highly
experimental
use
at
your
own
risk,
I
feel
like
that's
fine,
but
anything
more
than
that.
I
would
probably
raise
an
eyebrow,
but
I
think
there
seemed
to
be
some
desire
that
people
want
to
try
to
use
the
api
in
instrumentation,
so
that
seemed
to
be
like
the
the
motivating
concern
behind
it
all.
But
I
still
don't
know
that.
A
I
fully
understand
that,
because
I
don't
know
that
I
don't
know
that
anyone
knows
if
they've
really
done
the
right
thing
until
they've
been
able
to
see
the
thing
working
end
to
end.
I
mean
you
think:
you've
done
the
right
thing
usually,
but
you
really
never
know.
I
think
so
like
having
an
api
without
a
backing.
Sdk
does
not
seem
like
a
great
way
to
validate
something.
A
C
A
I
only
glance
at
the
the
the
otep
around
this
a
couple
weeks
ago
so
like
I
might
not
have
fully
done
my
homework,
but
I
feel
like
they
had
like
a
really
minimal
set
of
instruments.
A
Maybe
there
was
like
one
synchronous
instrument
and
one
asynchronous
instrument,
and
that
was
what
they
were
kind
of,
starting
with
as
like
a
starting
point
in
building
a
kind
of
bare
bones.
Sdk
around.
A
Yeah
here
it
goes
I'll,
keep
everybody
updated.
D
Oh,
my
god,
maybe
we
can
get
in
face
time
with
riley
andrew
and
track
and
give.
D
So
the
idea
being
that
I'm
going
to
make
an
assumption
here
based
on
this
and
that
when
you
use
a
synchronous
instrument
that
that
is
being
recorded,
that
measurement
is
being
taken
at
that
time
versus
an
asynchronous
instrument
is
that
it
is
like
potentially
queuing
up
different
measurements
that
it's
taking
before
it
sends.
E
Them
out
out
no
generally,
these
are
distinct
things,
so
generally
synchronous
instruments
are
like.
I
want
to
record
account
of
this
thing
right
now.
Asynchronous
instruments
are
the
exporter.
So
let's
say
you
have
a
pull
exporter
like
prometheus,
prometheus
scraper
at
that
time.
So,
when
you're
handling
the
prometheus
scraping
request,
the
exporter
is
going
to
go
and
call
those
asynchronous
instruments
to
observe
a
value
right
now
at
the
time
of
export.
E
E
So
that's
different
from
kind
of
batching
things
up,
so
synchronous
instruments
may
batch
up
changes
or
may
keep
the
last
value
around
until
it's
required
by
the
exporter,
but
exporters
could
be
run
in
different
modes.
You
could
have
a
statsd
exporter
that
just
immediately
like
synchronously
sends
a
udp
packet.
When
you
want
to
record
a
value
or
you
could
have
pull
or
push
style
exporters
that
are
either
scraping
or
batch
based.
E
So
the
otlp
exporter
as
an
example
would
batch
up
values
recorded
from
synchronous
instruments.
F
E
Then,
on
a
particular
interval,
let's
say
you're
exporting
every
couple
of
seconds
on
those
intervals
would
call
the
what
are
called
observers.
So
the
observable
instruments,
asynchronous
instruments-
would
call
there
observe
function
to
actually
get
a
value
from
them.
C
It
seems
really
flexible,
I
kind
of
like
the
api
in
a
way.
I
I
think
what
I
not
having
the
sdk
spec
kind
of
makes
it
hard
to
prototype,
because
I
feel
like
the
the
the
behavior
of
some
of
this
like
asynchronous
stuff,
is
gonna,
be
interesting
and
that's
the
type
of
thing
I
would
be
really
looking
for.
If
I
were,
if
I
personally
were
working
on
the
ruby
prototype
or
something
I
would
want
to
know
like
what
are
the
semantics
around
this
asynchronous
stuff,
because
I
think
there's
a
lot
of
different
ways.
A
It
does
this
is
related
to
the
open,
telemetry
schemas.
A
I'm
guessing
that
means
that
we're
moving
forward
with
this
as
as
the
way
to
ensure
or
to
give
back
ends
some
way
to
know
what
what
schema
telemetry
is
being
produced
using.
So
this
was
just
a
pr
that
adds
some
some
sanity
checking
around.
A
A
O
I
didn't
get
the
impression
that
it
was
a
controversial
thing
which
is
kind
of
please
get
some
eyes
on
it
and
then
we've
we
talked
about
both
these
fan
status
and
kind
of
service,
name
issues
the
past
couple,
spec,
cigs
or
and
ruby's
eggs,
and
I
don't
think
there
was
any
changes
other
than
at
least
on
this
one.
There
has
been
a
late
round
of
comments,
but.
A
I
think
sergey
is
just
asking
if
you
yeah,
if
the
user
overwrites
a
span
status
of
okay,
like
what
happens
to
like
potential
attempts
to
like
overwrite
the
description
or
or
other
such
things.
I
don't
know.
A
A
C
I
think
it
is
a
fractal
of
edge
cases
and
you
have
to
decide
to
stop
going
deeper
in
them.
At
some
point
decide
we
want
to
solve
these
edge
cases
and
then
anything
else
is
sort
of
like
further
deep.
A
Yeah,
I
think
they
in
general,
I
got
the
sense
of
people,
do
want
to
kind
of
just
say.
Yes,
you
know
this
is
a.
This
is
a
an
edge
case
and
we
acknowledge
it,
but
I
don't
think
anybody
had
any.
A
There's
also
not
too
much
discussion,
it's
kind
of
just
a
a
call
to
have
a
look
at
like
the
the
ongoing
conversations
for
things
and
participate.
If
you
care.
A
So,
like
you
end
up
right
now,
service
name
is
the
only
kind
of
special
attribute
in
open
telemetry
and
that
it
is
the
only
required
one,
and
it
is
one
that
has
a
standalone
environment
variable
and
it
can
also
be
set
potentially
through
this
hotel
resource
attributes,
environment
variable
and
basically,
if
you
use
hotel
service
name
and
if
you
set
it
using
hotel
service
name
and
you
set
it
using
hotel
resource
attributes,
the
standalone
environment
variable
should
take
precedence.
A
They
didn't
like
there's
some
discussion
where
it
was.
People
were
not
super
happy
that
there
were
some
environment
or
that
this
was
one
special
edge
case.
I
guess
so.
I
think
just
this
fact.
Wording
has
been
rewarded
to
say
that
some
attributes
do
have
special
handling,
and
some
of
them
do
have
a
standalone
environment
variable
and
if
you
have
a
dedicated
environment
variable
then
that
one
always
takes
precedence.
If
something
comes
from
another
place
and
then
right
now
it
just
kind
of
like
has
a
bullet
point
or
a
bulleted
list
say
of
one.
A
A
C
A
A
C
I
added
some
things,
but
actually
I
was
wondering
do
we
want
to
do
1.0
related
things,
because
we
tend
to
forget
about
that
until
the
very
end
and
I
feel
like
it's
important.
E
E
So
we
agreed
to
do
this
to
move
ahead
with
this
last
week.
We
just
haven't
had
time
to
do
the
actual
release
process.
This
might
be
a
nice
segue
into.
I
don't
know
whether
we
want
to
discuss
promoting
somebody
to
manage
releases.
A
Sure
yeah,
I
think
I
think
robert
has
been
doing
a
ton
of
excellent
work
over
the
last
year
or
more
here
and
yeah.
We
could
definitely
use
a
another
maintainer,
especially
one
that's
doing
a
lot
of
awesome
work
so.
A
So
yeah,
I
don't
remember
what
the
process
is
for
this,
but
we
should
do
whatever
it
takes.
I
think
to
to
do
that.
Do
you
have
anything
to
add
francis.
E
No,
no,
I
wholeheartedly
reject
this
recommendation.
No
robert's
been
doing
fantastic
work
and
I
know
I've
been
dealing
with
release
issues
so
far,
and
that
means
it
kind
of
gets
bottlenecked
on
me.
So
it's
useful
to,
I
think,
have
at
least
one
more
person
who's
able
to
take
on
some
of
that
work.
So
yeah.
We
should
just
figure
out
the
process
for
actually
giving
him
appropriate
bits.
A
E
Yeah
yeah,
ideally,
I'm
not
sure
how
much
time
I'll
have
this
week
to
take
it
on
so
yeah
between
us
we'll
get
it
out
the
door
somehow.
But
I
guess
first,
we
need
to
promote
robert.
F
I
think
it
would
make
sense
with
the
release
client
coming
out,
that
we
move
away
from
the
big
log
step
so
like
the
release
client,
when
we
do
the
release
for
that
it'll
be
just
just
it'll,
be
the
api
and
the
sdk
under
the
new
versioning
and
as
we
do
releases
for
the
instrumentation
libraries,
they
won't
have
to
all
move
in
tandem
anymore.
So
if
someone
adds
a
new
instrumentation,
it
will
start
at
point
zero,
one
or
whatever
our
starter
point
for
that
is.
D
F
Or
if
we
say
like
someone
patches
an
instrumentation,
we
can
just
go
ahead
and
release
that
individual
gem,
when
you
release
for
it
and
so
they're
gonna
all
fall
out
of
sync.
It
won't
be
like,
although
that's
point
17
or
whatever
it'll
be
they
can
be
buried.
I
think
that'll
alleviate
a
lot
of
the
release
headaches
now
that
I'll
be
doing
some.
F
So
let's
make
it
easy,
but
I
think
I
think
it'll
make
sense
too,
because
someone
can
identify
an
issue
patch
it
and
then
we
can
release
it
much
more
quickly
for
them
and
I
think
that'll
garner
a
lot
of
just
goodwill
towards
like
the
communities.
If
someone
comes
in
and
says,
hey
fix
this
and
not
have
to
wait
two
weeks
for
it
to
come
out.
We
could
just
release
that
patch
then,
and
there.
C
I
like
that
idea,
I
think
I
think
you're
right,
I
think
that'll
make
things
a
lot
better.
The
one
thing
I
was
wondering
about
that
is:
if
we
you
know,
we
start
if
we
start
decoupling
them
and
we
don't
release
everything
in
lockstep.
C
C
E
It's
a
little
more
open
for
instrumentation.
The
one
caveat
there
is
that
we
shouldn't
move
any
instrumentation
to
1.0
until
the
spec,
basically
until
there's
been
a
decision
about
around
semantic
conventions
and
kind
of
releasing
those
as
1.0.
So
right
now
the
spec
says
that
instrumentation
should
not
move
up
to
1.0.
Yet
until
we
figured
out
what
versioning
guarantees
we're
providing
for
semantic
inventions
and
for
instrumentation.
D
Also,
for
you
know,
labeling
the
releases
are
y'all
gonna
be
using,
or
should
I
say
we
be
using
tags
for
tagging,
specific
versions
of
the
repository
and
tying
them
to
these
releases.
F
And
that
that's
a
good
question,
I
think
that's
where
it
gets
a
bit
confusing,
because
it
is
this
mono
repo,
and
I
don't
know
if
there
is
like
a
convention
around
that
like
I
think
there
would
be
some
reasonable
arguments
for
the
taggings
corresponding
to
the
api
and
sdk.
But
I
don't
know
if
anyone
has
any
stronger
opinions
there,
I'm
it
is
a
bit
awkward.
I
think.
C
I've
seen
one
approach
where
you
create
a
separate
tag
for
each
sort
of
sub
gem
in
the
repo
and
the
version,
so
you
would
have
a
tag
for
like
api
1.0
and
then
you'd
have
a
tag
for
like
instrumentation
active
record
1.0
things
like
that.
That's
fine,
I
don't
know
how
much
it
really
matters
to
be
honest.
Git
tags
are
cool.
I
like
them,
but
whether
or
not
a
project
uses
them
or
not
has
never
really
had
much
of
an
impact
on
me.
It's
just
kind
of
a
nice
to
have
thing.
E
So
I
don't
know
yeah
we
effectively
have
tags
based
on
version
of
each
sub
gem
anyway.
So
we
have,
you
know,
open
telemetry
resource
detectors,
slash
the
what
is
it
0
170
as
a
tag
and,
yes,
that's
a
global
tag
for
the
get
repo,
but
you
know
that
represents
the
version
at
the
time
of
release
of
that
gem.
So
I
think
it's
fine
yeah.
A
So
one
thing
that
occurred
to
me
is
doing
this
conversation
and
only
back
on
track
if
this
is
getting
us
off
topic
at
all,
but
I
believe
most
other
projects
have
separated
out
instrumentation
into
a
contributory
bone.
A
We
have
not
done
this.
I
know
we
had
always
talked
about,
maybe
someday
in
the
future.
We
would
is
this
something
that
we,
I
really
don't
want
to
hold
up
1.0,
but
is
this
something
that
we
we
should
consider?
Is
there
any
reason
why
we
couldn't
do
this
post
1.0?
If
we
decided
to.
E
E
A
Yeah,
I
think
that
sounds
like
a
good
idea
once
because
I
feel
like
it's
really
painful-
to
have
instrumentation,
maybe
decoupled
from
the
repo
just
when,
when
the
api
is
potentially
unstable,
but
once
you
kind
of
have
this
stability,
instrumentation
should
really
only
depend
on
the
api
and
maybe
a
helper
jump
or
something.
But
it
becomes
a
lot
easier
to
manage
these
separate
repos.
A
E
It
would
include
instrumentation,
probably
resource
detectors
and
exporters
that
are
not
required
by
the
spec,
I
think
so.
The
zip
code
exporter
and
the
jaeger
exporter
and
otlp
those
should
all
be
part
of
the
core
repo.
I
think,
but
any
additional
exporters
that
are
contributed
should
probably
go
in
the
other
repo.
So.
E
I
mean
realistically,
it
can
be
done
at
any
time,
but
I
think
it's
a
good
time
to
do
it
post,
release
candidate
before
1.0,
so
that
when
we
do
the
split,
then
you
know
it's
clear:
we're
tagging
things
as
1.0
in
the
core
repo
and
tagging
things
outside
separately.
A
Yeah,
that's
what
triggered
me
to
talk
about.
This
was
talking
about
these
tags
in
in
the
monorepo
and
what
they
actually
mean
and
yeah.
I
think
I
don't
know
it
is
a
little
bit
of
a
of
an
undertaking
to
kind
of
split
this
stuff
out,
and
I
think
the
the
justification
that
we've
talked
about
in
the
past,
for
why
we
might
want
this.
Is
that,
like
over
time,
we
do
expect
the
the
instrumentation
repo
to
kind
of
just
like
grow
and.
A
Potentially,
have
you
know
a
number
of
contributors,
bug,
reports
etc
and
being
able
to
kind
of
keep
that
stuff
separated
a
little
bit
from
the
from
the
core
api
and
sdk
could
be
useful
from
like
a
a
management
standpoint,
and
it
also
lends
some
sort
of
flexibility.
I
think,
and
if
you
want
to
have
like
different
groups
of
people
working,
you
know,
and
you
know,
maintaining
improving,
etc
on
the
different
repos.
It
would
offer
that
flexibility.
E
Yeah
originally,
we
had
the
two
repo
set
up,
but
we
stuck
with
a
mono
repo
simply
because
we
had
a
very
small
group
of
people
working
on
this
and
we
had
a
lot
of
change
happening
to
the
apis
in
the
sdk,
and
so
it
made
sense
to
kind
of
lump
all
this
in
together
and
just
made
managing
it
a
lot
easier.
E
I
think
we're
getting
to
the
point
now,
where
we're
seeing
a
lot
more
stability
in
the
sdk
and
the
api
and
we're
also
seeing
a
lot
more
contributions
from
various
people,
particularly
to
instrumentation.
So
I
think
this
is
a
really
great
time
to
to
do
the
split.
C
I
think
I'm
in
favor
of
it,
the
only
real
thing
I've
been
thinking
about
is
issues
and
discussions,
and
things
like
that
we
might
want
to
think
about.
Do
we
want
all
of
those
centralized
into
one
repo
or
is
it
okay
to
have
them
split,
but
that's
also
sort
of
something
that
we
could
talk
about
later
and
figure
out
down
the
line.
A
Last
last
thing
that
was
kind
of
last
thought
that
was
going
through
my
head.
We
were
talking
about
this
decoupling.
The.
A
Definitely
through
jumpspec,
we
can
specify
what
versions
of
api.
It
should
only
be
api
api
and
maybe
helper
gems.
That
things
depend
on
is
there?
Is
there
anything
else
that
we
should
do
just
to
help?
Users
know
like
what's
compatible
with
what
I
think
I
think
bundler
helps
by
and
large
with
with
all
of
this,
but.
C
C
C
The
latest
api
or
one
resource
processor,
is
using
something
wrong
and
I
think
that
would
be
a
very
frustrating
experience,
but
that
that's
less
of
a
technical
thing
and
more
of
a
like
whoever
is
maintaining
the
contrib
repo
should
make
sure
that
that
there
is
housekeeping
done
to
keep
the
overall
state
of
you
know
the
the
various
instrumentations
at
least
supported
on
some
minimum
version.
I
would
say.
A
I
was
more,
I
was
more
thinking
about
the
situation
where,
like
you
know,
we
we
have
a
redis
instrumentation
at
0.19
and
that
works
with
api
1.2.
A
A
You
would
only
increment
them
if
you
updated
an
instrumentation
and
over
time
like
some
of
them
may
bump,
like
their
api
version,
and
just
for,
like
a
user
coming
in
and
knowing
that
they're,
you
know,
the
current
version
of
api
might
be
1.5
but
they're
on
1.3,
for
whatever
reason
they
just
want
to
know
like
which,
which
version
of
the
gem
should.
I.
E
I
think
there's
a
there's
some
policy
around
this
in
the
versioning
document.
I
can't
remember
the
name
of
the
document,
but
there
was
some
policy
around
trying
to
always
keep
everything
compatible
with
the
latest
version
of
the
api.
E
I
I
might
be
misremembering
this,
but
there's
this
kind
of
a
goal
to
always
keep
things
up
to
date
with
the
latest
and
always
make
the
latest
version
of
the
api
compatible
with
previous,
like
backwards
compatible
with
previous
versions.
E
But
I
think
we
should
just
review
the
language
there.
We
should
strive
to
always
keep
everything
in
the
instrumentation
repo
compatible
with
the
latest
release
of
the
api.
A
E
The
the
stated
goal
is
that
people
should
always
be
comfortable
updating
to
the
latest
api.
There
should
never
be
this
notion
of
you
know:
you're
stuck
three
versions
behind
on
the
api.
There
may
be
reasons
like
why
you
can't
move
up
the
sdk,
but
the
api
should
always
be
be
safe.
A
C
Yeah,
it
could
be
a
problem,
but
I
I
kind
of
feel
like
it's
a
bridge
we'll
have
to
cross
when
we
get
there.
I
think
that
spec's
own
stability
guarantees
will
give
us
a
lot
there,
and
I
also
suspect
that
in
practice
the
problem
probably
won't
be
that
bad.
That
often
is
my
gut
feeling.
I
do
think
it
will
come
up,
but
I
don't
think
it
will
come
up
terribly
often
and
as
for
like
people,
not
knowing
what
versions
to
pick
in
the
case,
it
does
come
up
somehow
and
we
can't
solve
it.
C
That
is
precisely
what
the
readme
is
for
and
we
can
have
a
nice
little
matrix
of
like
you
know,
here's
here's!
Here's
where
you
find
the
really
nitty
gritty
details,
it's
something
it's
just
something
we
have
to
maintain
as
documentation
if
the
situation
does
come
up
where
we
have
incompatibilities
or
something
that's,
but
that
would
be
true
with
any
project.
We
maintain
right,
like
it's
kind
of
always
true.
F
A
Need
maybe
we
will
need
a
matrix?
I
don't
think
we
need
to
preemptively
have
one
if
we,
if
we
don't
need
it,
if
there's
already
a
place
for
it,
then
we
should
probably
fill
it
in,
but
other
than
that.
As
long
as
we
are
honest
in
the
gem
spec,
I
think
like
people
will
be
able
to
figure
things
out
and
bundler
will
help
enforce
that.
So
it's
it's
all
solvable
and
workable.
A
I
just
wanted
to
like
make
sure
that
if
this
does
end
up
being,
if
there
are
any
rough
edges
for
the
user,
that
we
just
try
to
make
it
as
nice
for
them
as
possible,
but
we
can
be.
You
know.
D
I
hate
to
drag
this
conversation
on,
but
the
only
other
use
case
I
can
think
of
is
like
there's
going
to
be
some
auto
instrumentation
for
stuff
that
we
don't
use
on
a
regular
basis
and
we
may
not
be
as
familiar
or
might
even
have
the
capacity
to
maintain
all
those
instrumentations
like
folks
are
gonna,
sometimes
contribute
and
not
use
it
anymore,
and
it's
just
gonna
be
there
and
it'll
grow
stale,
and
I
think
we
have
to
be
realistic
and
not
push
ourselves
too
hard
to
try
to
maintain
every
single,
auto
instrumentation
up
to
date
and
communicate
that
to
people.
D
E
Yeah
totally
maintain
a
responsibility
here
basically
includes
you
know.
If
nobody
is
maintaining
a
particular
piece
of
instrumentation,
then
we
should
ultimately
remove
it
and
explicitly
state
that
it's
not
supported
going
forward.
Yeah,
like
you
know,
we
we
have
to
curate
what
we're
going
to
accept
and
maintain
there.
I
have
had
vendors
approach
me
before
saying
you
know.
E
Could
you
add
support
for
this,
or
could
you
add,
support
for
like
an
older
version
of
rails
and
it's
like
we
are
willing
to
accept
contributions
and
we're
also
willing
to
accept
continued
support
for
those
contributions,
but
yeah
we're
we're
not
we're
not
here.
You
know
maintaining
these
things
that
nobody's
using
or
nobody
else
is
contributing
to
forever
so.
C
You
know
the
nice
thing
with
the
instrumentation
based
extraction
is
that
I
think
in
some
ways
it's
easier
for
people
who
maybe
want
to
contribute
that
stuff
and
we
don't
want
to
maintain
it
for
them
to
still
be
able
to
have
it
and
have
it
play
nicely
with
the
ruby
ecosystem.
It's
sort
of
like
you
know.
C
If
you
really
want
to
go
ahead
and
write
it
and
host
it
yourself
and,
like
you
know,
if
you're
not
able
to
commit
to
maintaining
it,
that's
fine
but
like
you
can
still
plug
into
our
ecosystem
and
you're
still
welcome
it's
just
sort
of.
We
may
not
be
able
to
maintain
it
for
you.
I
think
that's!
That's
one
of
the
nice
side
effects
of
that
extraction
that
I
liked
a
lot.
E
Yeah
we
should
commit,
though,
if
we're
making
api
changes
or
we're
making
anything
making
changes
would
break
instrumentation
in
that
instrumentation
repo.
We
should
commit
to
going
and
fixing
up
all
the
instrumentation
in
that
repo
to
conform
to
the
latest
version
of
the
api,
but
that's
separate
from
tracking.
You
know
changes
to
active
record
and
then
going
and
ensuring
that
the
active
record
instrumentation
still
works
with
the
latest
thing.
E
Cool
so
yeah,
we
need
to
proceed
with
a
1.0
release.
We
need
to
proceed
with
promoting
robert,
so
we
can
help
with
1.0
release
and.
C
About
the
1.0
release,
or
in
general
in
general,
I.
C
Things
on
the
dock,
but
we
don't
have
to
talk
about
them,
talk
about
them.
It's
just
if
I
would
appreciate
eyes
and
comments
later
about
elasticsearch,
I
think
actually
is
something
interesting.
I
know
robert
has
weighed
in
on
it
a
little
bit
too.
I
think
the
relevant
discussion
is
how
much
duplication
should
there
be
between
instrumentations,
because,
like
the
the
pr
as
written,
actually,
I
think
will
duplicate
a
lot
of
spans
from
other
types
of
auto
instrumentation,
and
so
that
might
be
useful
to
talk
about
the
other
thing
on
there
was
just
about.
C
I
thought.
Maybe
it
would
be
nice
to
have
a
rail
tie
available
for
the
community
robert,
and
I
have
also
been
talking
about
that
as
well
and
thoughts.
There
would
also
be
appreciated,
but
if
people
have
other
things
that
need
more
synchronous
attention,
we
can
talk
about
all
of
those.
You
know
on
the
issues
and
stuff.
F
Yeah,
the
the
tldr,
the
elasticsearch
one
right
now
is
just
there
was
one
point
I
brought
up
that
I
don't
know
how
much
it
matters
it's
kind
of
nitpicky
like
the
instrumentation
gems,
called
open
on
transformation
elasticsearch,
but
it's
only
currently
instrumenting
transport,
so
the
elasticsearch
gem
is
kind
of
a
wrapper
for
these
subjects,
their
api
and
their
transport
gems.
F
If
this
instrumentation's
only
actually
instrumenting
a
very
specific
subset
of
the
this
wrapper
like,
should
we
call
it
elasticsearch
or
elasticsearch
transform
instrumentation
like?
Should
we
have
the
name
be
that
or
should
we
keep
it
more
general
that
says
like
if
you
want
elastic
search,
instrumentation
just
include
this
gem
and
it'll
include
its
sub
components,
it
kind
of
has
like
echoes
of
rails
and
all
of
its
sub
gems.
I
don't
know
if
it's
the
thing
that
I'm
fighting
with
right
now
is.
F
I
don't
know
if
it's
really
worth
the
effort
to
get
that
granular
with
it.
But
then
what
that
also
kind
of
segued
into
is
that
elasticsearch
transport
instrumenting?
That
is
like
a
very
close
wrapper
to
basically
our
faraday
instrumentation
right
so
like
they're,
going
to
get
the
exact
same
information
from
faraday,
because
this
is
the
transport
is
a
very
tight
wrapper
on
faraday.
E
Do
you
want
to
using
the
thing
about
like
adding
remember
we
have
that
helper
that
lets,
you
add
tags
to
spans.
E
Yeah,
so
you
could
add
any
elasticsearch
specific
things
to
those
spans.
F
That
that
would
make
sense-
and
I
think
it
would
reduce
the
complexity
of
all
of
this
down
to
probably
like
a
three-line
method
or
three-line
patch.
You
know
so
that
probably
is
the
desired
thing.
Anything
that
specifics
elasticsearch
can
be
added
there,
but
it
does
it
does
make.
It
is
predicated
on
them
using
faraday
instrumentation.
I
don't
know
if
we
want
to
say
well,
you
can
use
this
without
faraday
or
you
can
use
it
with
faraday,
and
I,
like
you,
can
configure
it
to
behave
differently.
F
But
I
don't
like
there's
a
lot
of
permutations
of
this,
that
I
could
see
continuing
to
come
up
as
time
goes
on
and
it's
like,
we
should
probably
think
about
how
we
want
to
settle
on
it.
Even
if
we're
just
deciding
once
right
now
and
maybe
we'll
go
back
on
it,
but
like
I'm
more
in
favor
of
saying,
use
your
networking
instrumentation
to
instrument
your
networking
calls
instead
of
the
thing
calling
your
networking
library.
F
So
I
would
say
that,
like
using
the
http
attribute
context,
wrapper
thing
in
elasticsearch
would
probably
suffice
here
and
it's
less
code
to
maintain
it's
seems
simpler
and
then,
as
for
naming,
I
keep
going
back
and
forth
on
it.
But
I
think
because
this
is
a
pretty
small
gem
and
looking
through
the
api,
instrumenting
kind
of
looks
difficult
there,
because
there's
not
a
lot
of
common
common
instrumentation
points
there.
I
couldn't
find
one
through
a
little
bit
of
searching.
It
wasn't
obvious
to
me
is
what
I'm
trying
to
say
so.
F
A
B
I
think
this
is
like
a
port.
I
I
don't
know
if
the
elastic
search
instrumentation
was
written
four
years
ago
from,
and
it's
like
based
on
classy,
though
so
I
don't
know
off
top
of
my
head.
I
think
there's
a
larger
question
around
specification
and
how
gen
and
it'll
never
get
answered,
because
nothing
gets
answered
in
spectra
like
how
you
would
handle
these.
B
I
think,
there's
a
you
know,
like
roberts,
laid
out
like
a
very
common
sense
explanation,
for
I
think
the
what
the
approach
I
would
prefer,
but
yeah,
would
you
assume
in
general,
when
you
have
these
like
http?
I
don't
know.
Aws
is
the
same
thing
elastic
same
thing
like
you.
Have
these
wrappers
underneath
an
http
client
which
it
seems
like
this
is
a
question
about
more
than
it
is
like
elasticsearch
itself.
I
can
check
real,
quick
and
see
what
but
yeah.
B
F
I
have
with
the
I
looked
at
the
datadog
one
and
the
original
pr
was
a
very
close
port
of
it.
So
there's
a
lot
of
similarities,
there
they're
doing
the
transport,
they
are
patching
the
performance
quest,
they're
using
different
approaches
and
different
stuff
there.
B
Let
me
get
the
link
so
that
this
is
the
the
and
there's
some
coin.
Has
he
added
that
quantized
stuff?
Yet
I
don't
believe
so.
That
was
the
only
other
part
I
thought
was
missing.
Here
was
and-
and
you
know
I
don't
know
where
that
lives,
but
yeah.
F
C
Pretty
janky
you
should
have,
is
our
faraday
instrumentation
implemented
as
a
middleware,
or
is
it
wrapping
things?
I
I
don't
know
where
I
I
know
this
is
something
that's
probably
abhorrent,
but
what
I
would
almost
want
is
for
the
elasticsearch
instrumentation
to
be
able
to
inject
the
faraday
middleware.
If
it's
not
already
present
like
globally.
F
I
think
that's
actually
potentially
okay,
well,
probably
because
I
did
that
already
with
the
rails
instrumentation,
it
looks
for
the
right.
F
Jams
it
in,
I
think
it's
reasonable
to
do
some
reuse.
I
think
the
only
concern
there
is
like
versioning
stability
if
it's
like,
depending
on
a
specific
version,
and
it
gets
kind
of
janky
there
as
long
as
we're
cautious
about
that,
I
think
it's
probably
okay.
I
think
it's
the
reasonable
thing
to
do.
If
you
know
that
elasticsearch
is
using
a
fair
day
and
we
have
fairly
instrumentation,
we
know
it
works.
Why
not
just
do
that?
C
Yeah,
I
think
it
actually
could
work
because
there
could
be
versioning
shenanigans
down
the
road,
but
as
long
as
you're,
more
or
less
blindly,
injecting
as
long
as
there
isn't
some
compatibility
that
like
says
you
know,
our
information
no
longer
supports
faraday
1.0
at
all,
or
something
like
that.
Then
you
should
be
able
to
just
inject
the
middleware
and
let
it
do
its
thing
and
our
own
instrumentation
incompatibilities,
probably
don't
matter
that
much.
F
Cool,
I
think
we
have
a
couple
minutes
and
this
might
be
a
longer
discussion
in
a
couple
minutes.
If
you
go
to
the
elasticsearch
pr,
I
left
the
comment
in
the
form
of
basically
a
giant
snippet
of
code.
F
I
just
want
to
see
like
maybe
get
a
sense
of
the
room
so
to
speak
in
that
kind
of
approach
like
if
it's
too
direct
being
like
hey
you've
got
this
pr
out.
Instead
of
giving
you
a
bunch
of
guidance,
I'm
just
going
to
rewrite
a
whole
blob
of
code
for
you.
I
know
some
people
don't
like
that.
I
don't
know
how.
If
we
think
that
this
is
okay,
I
think
they
resolved
it.
F
So
it's
probably
collapsed,
but
but
to
the
point
of
like
the
blob
of
code
that
I
linked,
it
would
be
the
client
patch
comment
of
the
client
patch
that
one-
and
so
I
think,
that's
yeah,
so
I
just
basically
did
like
a
wholesale
like.
Let's
just
make
this
simpler,
there's
two
points
on
to
make
that
do
or
questions
to
ask
the
group.
Do
we
think
that
this
is
like
an
okay
approach
to
say,
hey
like
it
might
just
be
easier?
F
If
I
just
rewrite
this
for
you
and
put
that
as
a
suggestion,
it
can
come
as
a
like
a
pretty
harsh
directive
if
it's
coming
from
someone
who's
like
an
approver
and
a
maintainer
on
the
repo.
So
I
don't
know
if
I'm
just
like,
perceiving
that
because
of
past
experiences,
where
I've
seen
people
who
don't
like
receiving
that
kind
of
feedback
or
that
type
of
comment
on
their
pr
and
then.
A
E
F
E
It's
reasonable,
I
mean
you,
can
add
some
descriptive
text
around
the
suggestions,
saying
you
know
that
that
kind
of
softens
it
if
you're
concerned
about
that,
but
I
don't
think
you
should
feel
bad
about
saying
you
know
here's
a
suggested
rewrite
of
this
chunk
of
code.
E
If
you're
going
to
rewrite
the
entire
pr,
then
maybe
throw
up
an
alternative
pr
or
something
but
or
or
offer
high
level
suggestions.
But
I
think
this
I
think
what
you've
done
here
is
perfectly
okay.
In
my
opinion,
yeah.
B
C
Something
something
to
think
about
if
it's
just
a
different
way
to
do
it
if
you're
concerned
that,
like
maybe
the
length
of
it
or
something,
is
going
to
come
off.
Strangely,
I've
had
good
approach
with
opening
a
pr
against
the
pr
branch
itself
for,
like
bigger,
like
I
think,
maybe
there's
a
different
approach
that
way
they
can
see
it
in
context
from
their
own.
C
They
can
see
it
in
a
different
context
and
I
think
it
has
slightly
different
connotations
when
you're
proposing
it
that's
just
another
tool.
I've
used,
I
don't
know
how
well
that
works
with
forks
of
repos,
because
internally
at
github.
I
do
that
a
lot
but
like
we
don't
fork
each
other's
repos
a
lot,
so
it's
a
little
different,
but
that
I
think
that
has
a
slightly
different
spin
on
it
and
like
maybe
in
some
situations,
if
you're
worried
about
it.
Maybe
that's
just
another
approach.
You
could
take
cool,
but.
D
Hey
look:
we
had
this
conversation
among
the
six
people.
You
were
not
present,
we,
it
would
have
been
nice
if
you
were
here
and
we're
really
concerned
about
how
you
know
you're
receiving
this
feedback
well,
and
we
want
you
to
feel
included,
but
that
that
will
go
a
long
way.
E
F
F
There's
this
tendency
to
blow
apart
these
methods
into
or
these
these
patches
into,
like
a
ton
of
little
methods
like
right
now,
I'm
just
where
this
is
coming
from.
I'm
redoing
the
the
redis
instrumentation
utils
file,
and
I
think
we
should
fight
me
if
I'm
wrong,
be
a
little
bit
more
diligent
of
like
pushing
back
for
these
like
over
complications
like
we
don't
need.
You
know,
like
15
method,
calls
to
format
a
string
it
can
be
in
line,
and
that
was
really
the
motivation
for
this.
F
This
suggested
change
here
was
there's
like
two
extra
methods
and
it's
things
that
don't
really
need
to
be
split
out
into
separate
methods.
I
know
people
like
to
organize
their
thoughts.
That
way-
and
I
don't
know
if
it's
even
like
a
it's-
probably
less
than
negative
negligible
of
performance
on
the
the
actual
application,
but
it's
still
just
it's
simpler,
like
pushing
things
in
line.
I
absolutely
would
hope
that
I
can
continue
to
push
this
type
of
attitude
towards
the
repo,
but
I
don't
want
to
be
the
odd
person
out
on
that.
One.
C
No
last
time
I
had
this
problem,
it
was
robocop
complaining
about
my
method
length
that
it
was
revoked
complaining
about
my
abc
complexity,
and
I
think
that
if
we
actually
want
to
change
the
behavior,
we
should
probably
address
those
first,
because
I
think
robocop
is
very,
very
strict
there.
I
think
it
complains
if
your
method
is
longer
than
20
lines
and
it
doesn't
pass
the
I
so
that
that
will
force
this
type
of
thing.
D
E
Guide
or
style
style
guide
or
something
we
should
update
the
rubric
everybody
I
see
so
many
commits
that
are
like
overriding
stuff
in
robocop
or
or
adding
those
little
tags
next
to
methods
like
I've
done
in
a
bunch
of
places
as
well.
D
E
Yeah,
if
we're
doing
that
so
much-
and
we
disagree
with
what
the
cop
is
suggesting,
then
we
have
the
power
to
just
go
in
and
change
that
configuration.
So
we
should
do
that.
I
would
like
to
get
to
a
point
where
we
have
useful
warnings
only
enabled
for
the
cop,
and
we
do
that
globally
across
the
project.
Ideally,
there's
one
configuration
file
for
the
entire
project.
Instead
of
all
these
ones
scattered
around.
F
F
C
Just
change
it
to
soft
failure
as
well.
You
know
I.
I
appreciate
that
it
makes
me
think
about
things.
What
I
don't
like
is
that
it
just
yells
at
me,
if
it's
not
right,
it's
just
that
it
fails
stuff.
You
know
some
of
this.
We
could
also
just
make
a
warning,
and
you
know,
then
it's
sort
of
like
think
about
it
and
that's
it,
but.