►
From YouTube: 2022-05-03 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
About
as
good
as
my
monday,
I
suppose,
how
about
you
it.
B
C
A
Please
join
in.
A
A
D
E
We
shopify
was
at
we
had
like
a
department
gathering
last
week,
so
forgive
us.
We
were
in
a
large
auditorium
being
indoctrinated.
C
Can
you
hear
me
we
hear
you,
that's
wonderful,
yeah
I
yeah
last
week
I
was
being
indoctrinated
with
sam,
but
it
was
fun.
I've
gone
through
it
many
times
over
the
last
three
and
a
half
years.
C
But
prior
to
that
I
was,
I
was
sick,
so
I've
been
kind
of
have
been
off
the
grid
for
a
while
and
I've
traveled
and
moved
multiple
times
so,
but
I
am
now
stable
and,
as
you
can
see,
I've
released
all
of
the
jammies
yesterday,
so
nobody
can
chase
me
with
pitchforks
now,
because
I've
done
the
thing
that
everyone's
been
waiting
for
for
too
long.
D
A
B
D
Let
it
speaking
of
which
yeah
our
last
our
last
spec
sig
update,
was
sponsored
by
tito's
vodka,
the
only
all
corn
vodka,
that
reo
has
a
hat
of,
and.
B
D
D
B
E
D
All
right,
I
will
admit
that
I
was
multitasking
during
this,
so
I
will
make
it
quick
and
probably
not
go
too
deep
into
most
of
the
issues.
Although
this
one
was
probably
the
most
important
and
it
is
introducing
scope,
attributes
and
yeah,
you
all
are
probably
familiar
with
the
fact
that
instrumentation
library
has
been
changed
to
instrumentation
scope
and
it
was
a
huge
painful
change,
really
just
like
a
name
change.
D
Actually
that
was
the
only
thing
that
was
gained
from
it,
but
now
there
is
scope,
attributes
and
I
think
somewhere
in
here
it
will
show
us
what
the
proto
message
looks
like
and
yes,.
D
So
we
used
to
just
have
instrumentation
library,
it
got
renamed
instrumentation
scope
and
it
had
a
name
and
a
version,
and
I
believe
that
was
it
now:
we've
gained
this
attributes
yeah
key
value
attributes
under
instrumentation
scope,
but
this
is
an
otep
and
tigran
is
looking
for
feedback
on
this.
D
I
think
I
don't
know
it
seems
like
it
might
muddy
the
the
tracer
api
a
little
bit,
because
I
think
the
proposal
is
that
you,
when
you
get
a
tracer
from
the
tracer
provider,
you
would
pass
in
the
name
the
version
and
then
the
instrumentation
scope.
It
seems
like
your
instrumentation
scope
is
kind
of
like
locked
in
in
time.
I
guess
it's
kind
of
bound
to
that
tracer,
so
they're
not
really
like
dynamic
attributes,
if
that
makes
sense.
D
B
I
only
learned
of
this
thing's
existence.
Just
now.
I
plan
on
reading
it
and
forming
an
opinion
things
that
I
can
think
of
are
attributes
precedence
where
something
gets
set
on
the
tracer
that
represents
the
scope
and
and
the
same
field
attribute
name
is
used
on
a
fan
or
signal
just
state
outright.
The
specifics
going
to
override
the
generic
so
that
we
agree
on
on
that
sort
of
behavior,
but.
B
And
they
don't
they
don't
conflict
until
you
try
to
go
like
I'm
going
to
form
one
event,
that
is
the
merge
of
all
the
resource,
attributes,
scope,
attributes
and
signal
attributes.
B
B
Just
if
we
state
outright
here's
here's
if
you're
gonna,
if
you're,
if
you're
merging
these
attributes
into
a
flat
record,
this
is
the
order
of
precedence,
go
specific
to
general.
D
Yeah,
I
feel
like
that's
that's
reasonable.
I
do
kind
of
feel
like
it
ends
up
being
kind
of
like
a
a
vendor
problem
like
if
we
were
all
like
really
good
vendors.
Our
our
data
model
would
be
the
otop
model
and
you
wouldn't
have
to
flatten
everything
down,
but
we
all
have
you
know
the
models
that
we
have
and
there's
definitely
some
flattening
happening
in
all
of
them
that
I'm
aware
of
so.
B
Well,
and-
and
would
you
want
a
query,
I
would
like
all
of
the
scope
that
one
of
the
examples
in
here
was
what
db
connection
I
would
like
all
of
the
scope
db
connections,
but
if
something
got
specific
on
the
signal,
you
don't
want
to
query
on
that
one
I
don't
know,
I
I'll
read
it
and
form
an
opinion.
I'm
just
talking
out
of
side
of
my
mouth
right
now.
C
It's
interesting,
like
I
yeah.
This
is
kind
of
like
an
interesting
addition.
Ariel
and
sam
myself
were
talking
the
other
day
and
talking
about
like
how
to
kind
of
divide
up
like
a
monolith,
and
if
you
want
to
like,
have
named
segments
to
it-
and
it's
like
talking
about
like
maybe
using
instrumentation
scope,
it's
like
does
it
make
sense
to
add
extra
information.
I
don't
know
if
this
makes
this
easier.
B
I
could
picture
it
being
easy
as
a
as
a
as
a
vendor
who
has
to
ingest
this
stuff
and
we've.
I've
recently
had
to
go
and
tinker
with
like
recording
the
the
scope,
name
and
version.
B
There
is
basically
this
little
interstitial
data
wrapper
between
resource
and
the
signal
that
maybe
it's
appropriate
to
like
shove,
a
little
bit
more
data
on
there.
I
don't
think
when
you're
querying
you
want,
like
a
person
using
the
data
that
is
produced.
I
in
my
experience
and
also
I
could
totally
be
shaped
by
the
the
way
that
my
product
works.
I
don't
think
a
person
trying
to
look
at
their
telemetry
wants
to
have
to
remember
whether
it's
a
resource
attribute
or
a
scope
attribute
when
they're
doing
queries.
B
It's
my
impression
on
this,
and
I
could
be
wrong.
Correct
me,
if
it
is
my
impression,
is
that
we
have
these
layers
so
that
the
line
protocol
isn't
repetitive,
so
that
you're
not
restating
a
name
and
a
key,
a
key
and
a
value
repeatedly
on
the
same
event
span
log
whatever
and
that
compressing
the
line
protocol
doesn't
necessarily
mean
that
you
want
to
think
in
these
terms.
When
you're
using
the
data
downstream.
B
C
C
A
C
Definitely
an
interesting
addition.
I
need
to
like
actually
read
the
full
things
I
haven't
seen
it
prior
to
now
and
try
to
form
an
opinion,
but
it's
probably
helpful.
Like
I
mean
at
worst,
you
don't
use
it
right
right,
which
is
like
my
my
initial
takeaway
from
this
is
like.
Well,
I
guess,
if
we
don't
need
it,
we
don't
use
it
right,
but
I
definitely
see
that
there
could
be
some
use
cases
that
are
derived
out
of
it.
D
Yeah,
I
maybe
should
have
started
with
the
motivation.
The
motivation
does
list
like
two
known
use
cases,
so
one
is
to
add
support
for
meter
short
name.
Apparently,
meter
names
can
get
unwieldy
and
back
ends
want
to
have
a
short
name,
so
that
is
one
the
other
one,
which
sounds
somewhat
interesting
and
maybe
could
be
used.
D
I
don't
know
the
discussion
of
trying
to
segment
stuff
up
in
a
monolith.
Maybe
has
an
analog
here,
but
it
says
add
support
for
differentiating
the
type
of
data
emitted
from
the
scopes
that
belong
to
different
data
domains,
for
example
profiling,
data
emitted
as
log
records
or
client-side
data
committed
as
log
records
needs
to
be
differentiated,
so
it
can
easily
be
routed
and
processed
differently
in
the
back
ends.
B
Which
is
an
attribute
you
could
put
on
every
record
that
came
out,
but
I
could
see
it
being
convenient
that
if
you
know
when
you're
instantiating,
a
tracer
or
a
logger,
is
that
what
they're
called
I
haven't
caught
up
with
the
log
signal.
Yet
it's
convenient
to
say
this
is
true
for
everything
that
this
tracer
is
producing.
So
again,
don't
put
it
on
every
event.
Just
put
it
on.
A
So
let's
say
you
have
instrumentation
scope
for
a
database
connection
and
that
thing
has
a
set
of
attributes
on
it.
That
are
what
database
you're
connecting
to
what
the
net
peer
name
is,
etc.
A
And
then,
because
your
application
is
sophisticated,
you
have
another
connection
pool
which
uses
the
same
instrumentation
name
right,
so
that'll
be
the
same
instrumentation
scope,
name,
it's
the
same
library
version.
So
it's
the
same
instrumentation
version
number,
but
a
different
set
of
key
value
attributes,
so
any
spans
generated
from
that
can't
be
grouped
together
in
the
same
instrumentation
scope
because
we're
not
going
to
merge
those
key
value
attributes
together
across
both
scopes.
B
So
you'd
like
in
a
in
a
trade,
a
tracer
maps
to
instrumentation
script
right,
you
get
an
instrumentation
scope.
A
It
sounds
like
to
me
and
seems.
A
Uh-Huh,
I'm
with
you
yeah
what
and
and
and
when
we're
transferring
that
data
around
the
span
is
gonna
have
to
keep
a
reference
to
its
tracer,
because
right
now
it
only
knows
about
its
processor
to
signal
to
its
processor.
If
it's
started
or
finished,
which
means
the
span
would
have
to
know
what
tracers
is
associated
with
in
order
to
accept
or
to
carry
the
instrumentation
scope.
A
A
Trace,
if
you
run
a
file
search
and
look
for
the
trace,
the
sdk
trace,
span
class
and
look
for
the
two
span.
Data
method
on
it.
C
So
when
we're
creating
a
span
so
like
in
your
tracer,
when
you
do
like
start
span,
which
is
what
ultimately
ends
up
calling
tracer
provider
internal
span,
create,
it
is
supplying
it
with
the
instrumentation
library
or
soon
to
be
renamed
instrumentation
scope.
So
it
does
get
passed
in
that
reference
to
the
instrumentation
library,
which
has
the
name
and
version.
A
So
we
might
have
to
defer
some
set
of
attributes,
because
right
now
we're
we
are
memoizing,
the
tracers,
for
example,
internally
and
instrumentation,
we're
sharing
that
globally
and
then,
if
we
wanted
to
have
like
more
granular
attributes
per
instruments,
the
instrumentation
scope,
it
would
mean
perhaps
that
on
construction
of
the
tracer,
we
provide
attributes,
in
addition
to
the
name
inversion
at
initialization
or
we're
somehow
amending
that
to
the
scoped
thing.
A
A
It
derives
that
from
like
it
connects
to
the
database,
and
then
it's
like
tell
me
or
anything
that
would
talk
to
zookeeper
right
to
figure
out.
Who
am
I
talking
to
now
who's
my
net
peer?
Now
you
would
get
netpear
ip
addresses
and
names
from
those
systems,
and
those
would
be
on
like
a
per
transaction
or
per
interaction
scope.
B
That
stuff
sounds
like
the
semantic
conventions
you
put
on
your
client
or
server
spans.
To
say
this
is
my
peer
for
a
client
call
which
isn't
like
scope
level,
it's
sort
of
like
a.
Maybe
we
put
breaks
on
on
what
scope
means
like
like
the
rename
of
scope
to
away
from
libraries
now
like
it's,
not
we're
not
talking
about
the
instrumentation,
we're
talking
about
this
vague
context
and
or
we're
talking
about
context
and
now
we're
in
in
abstract
land,
where
anything
can
be
a
context.
So
anything
would
be
a
scope.
A
Yeah,
I
think
it's
kind
of
like
these
things
aren't
the
resource
attributes
because
they're
not
global
to
the
entire
run
time.
These
are
things
that
are
specific
to
some
particular
context.
So
then
you
know
it's
only
about,
like
you
were
saying,
rob
it's
like
all
of
these
things
are
the
same
data,
so
we're
trying
to
reduce
the
amount
of
data
we're
producing,
except
that
you
don't
necessarily
have
pure.
B
Name
on
every
spam,
like
it
talking
to
a
database,
you
don't
necessarily
have
met
peer
on
every
span.
You
have
net
peer
on
the
client
connection,
the
I
made
a
connection
and
then
I
did
some
things,
but
if
you
want
to
know
your
peer,
that's
on
the
client
connection
call
not
it's
not
true
for
everything
running
through
this
instrumentation
library,
which
is.
A
A
A
You
know
what's
wrong
with
speculating
and
sure
I
think
I.
C
B
Something
I
will
say
of
the
two
use
cases.
The
meter's
short
name
is
like
that's:
okay,
okay,
I'm
instantiating
a
an
instrumentation
library
of
some
sort,
logs,
the
meter
or
or
tracer.
It's
got
a
long,
unwieldy
name.
I
want
to
give
it
an
alias
okay,
that
is,
that
seems
appropriate.
It's
an
alternate
name
which
is
true
for
anything
produced
by
a
meter
or
a
tracer
or
whatever
differentiating
the
type
of
data
emitted
from
the
scopes
that
belong
to
different
data
domains.
D
I
do
get
the
impression
that
this
stuff
is
probably
going
to
be
used
more
by
people
instantiating
tracers
themselves
and
less
so
by
the
auto
instrumentation
side
of
things,
but
like
looking
at
kind
of
like
our
instrumentation
base
like.
I
do
think
that
if
somebody
did
want
to
provide
scope,
attributes
for
the
auto
instrumentation,
it
could
come
in
through
config
and
it
could
still
get
kind
of
like
instantiated
and
the
tracer
could
be
memoized
and
everything
should
still
be
fine.
D
If
we
wanted
to
go
that
route,
I
do
kind
of
get
the
impression
this
is
maybe
coming
out
of
like
a
logging
use
case.
Since
it's
just
like
appearing
now,
and
that
seems
to
I
don't
know
the
word.
Logging
and
logger
appears
more
than
once
in
the
spec.
So,
given
that
we
all
only
read
headlines,
we
can
assume
that
it's
all
about
logging.
D
A
A
A
That
seems
so
weird
to
me.
If
it's
something
that's
separate
and
it
should
be
separate,
then
the
instrumentation
scope
shouldn't
have
it
in
the
message
person.
You
know
me
speaking
personally.
There
should
be
a
different
message
that
includes
the
instrumentation
scope
and
and
those
key
attributes.
Personally
speaking,
you
know.
D
So
yeah,
I
think
I
think
this
has
been
a
useful
discussion.
I
think
the
call
really
is
to
see
like
can
this
be
done,
and
can
this
be
done
in
a
backwards
compatible
way
and
are
there
any
concerns?
D
So
I
think
if
there
are
concerns,
it's
totally
valid
to
raise
them
right
now.
This
is
not
like
a
done
deal
by
any
means
so
some
time
on
it.
D
D
B
D
D
There
are
graph
ql
semantic
conventions,
probably
relevant.
We
have
graphql
instrumentation
and
I
know
I
seem
to
recall
that
we
had
to
that.
A
lot
of
these
things
were
maybe.
C
D
C
That
I'm
excited
but
yeah
we're
not
doing
what
is
described
here,
but
I
am
happy
that
there
is
a
formal
definition
now
because
I
think
we're
using
selected
operation,
name
and
selected
operation
type
believe
that
came
from
jslam.
C
I
think
I
think
a
few
I
think
at
least
two
vendors
I
knew
of
were
using
it,
which
may
have
influenced
it,
but
I'm
happy
that
someone
has
put
forth
this
attempt
to
find
conventions
for
graphql,
because
previously
I
think
whatever
came
up
was
like.
Should
we
treat
it
like
an
rpc
or
so
I
have
no
strong
opinions
other
than
I'm
happy.
That
work
is
going
into
this
that
I
will
happily
consume.
D
Eric
I
gotta
mention
for
some
reason,
nice,
but
yeah.
I
guess
I
guess
it's
good
and
I
assume
that
we
probably
have
a
few
a
few
rogue
conventions
in
our
instrumentation
and
likely
because
it
takes
a
pr
that
starts
on
march
29th
and
gets
40
comments
in
order
to
get.
D
Oh
and
the
next
one
is
kind
of
in
the
same
vein.
I
feel,
like
we've
talked
about
this
for
the
last
month,
ongoing
and
it's
apr
to
formalize
and
stabilize
the
these
semantic
conventions
for
http
spans,
and
a
lot
of
these
things
are
our
renames
and
refactors
what's
currently
around.
So
this
would
be
we'd
have
to
make
a
pass
through
our
http
instrumentation
and
update
this
stuff.
So
I
think
there
are
continuing
calls
it's
merged
latest.
D
D
All
right
again
kind
of
we
mentioned
this
several
weeks
ago.
There
is
this
project
management
proposal
and,
more
or
less,
I
believe
the
goal
here
is
to.
I
think
when
I
first
talked
about
it,
I
was
like
framing
it
as
like
sprints
for
hotel,
which
I
think
is
probably
the
wrong
way
of
looking
at
it.
D
But
the
right
way
of
looking
at
it
is
definitely
like
having
at
least
at
the
spec
sig
level,
having
like
a
limited
set
of
focus,
focus
points
at
any
given
point
in
time,
so
that
people
know
like
what
is
actively
being
worked
on
in
spec,
and
you
know
how
how
full
that
plate
is.
If
you
have,
you
come
up
with
a
new
idea
and
what
the
chances
are
that
the
spec
sig
has
the
time
to
kind
of
expand
its
scope.
D
So
yes,
generally
the
idea-
and
I
think,
they're,
just
kind
of
going
to
the
specifics
of
how
they
want
this
to
work.
I
have
not
read
this
document
and
I
was
only
half
listening
during
this
part
of
the
meeting.
So
if
you're
interested
read
the
document,
I
suppose,
but.
D
D
Again,
half
paying
attention
the
thing
I
that
did
catch
my
ear
was
the
semantic
conventions
for
summary
metrics,
and
this
is,
I
think,
mainly
if
you
are
writing
instrumentation.
You
will
sometimes
come
across
systems
that
you
are
getting
metrics
from
that
kind
of
already
have
an
aggregation
for
you.
D
So
it's
like
you're,
not
necessarily
using
like
an
otlp
instrument
to
compute
these
yourselves.
It's
like
you
might
be
pulling
them
out
of
something
like
one
example
is
jmx.
Nobody
should
know
about
this,
but
if
you
do,
if
you
don't
it's
something
from
java,
if
you
do
shame
on
you
for
knowing
about
it,
but
sometimes
like
the
stuff
is
already
in
some
average
and
p50.
So
I
think
the
suggestion
was
that
when
that
happens,
this
should
be
recorded
as
a
summary
metric
in
hotel.
But
I
don't
know
if
we
actually
have
one.
D
D
Probably
good
to
read
the
doc,
but
I
think
I
guess
any
more
practical
thing:
nobody
should
know
about
jmx
and
nobody
should
go
reading
about
it.
But
prometheus,
on
the
other
hand,
is
a
thing,
is
a
ecosystem
where
summaries
are
quite
prevalent
as
a
data
type
so
being
able
to
support
those
seamlessly
would
be.
D
A
good
idea
and
they're
just
kind
of
one
of
these
other.
You
know
compound
metric
types
where
it
you
have
one
metric
name,
but
then
you
have
like
a
bucket
of
values
that
will
be
associated
with
it
and
it'll
be
like
a
somewhat
standard
bucket,
usually.
D
E
I
was
gonna
say
without
going
super
deep
on
like
meta
process.
Maybe
we
can
time
box
our
spec
sig
overview
to
x
number
of
minutes
moving
forward
so
that
we
don't
eat
up
our
ruby
sig
time,
but
just
throwing
it
out
there
yeah.
D
Two
thumbs
up
on
that
this
thing
does
tend
to
somehow
drag
on
almost
as
long
as
suspect,
sig,
sometimes
so,
like.
I
think
we've
suggested
10
or
15
minutes,
but
we
should
hold
ourselves
to
should
we
hold
ourselves
to
15
minutes.
I
think
10
minutes
is
probably
a
little
optimistic
I'll,
be
the
15
minute
timer
next
week.
Please
do
the
15
minute
timer
and
whatever
we
don't
get
to
we
can
just
like
you
know
we
can
just
call
it
so
yeah.
D
We
always
yeah.
We
always
short
ourselves.
So
on
that
note,
what
are
the
things
that
we
had
to
talk
about?
A
Yeah
this
morning
somebody
reported
that
they
were
unable
to
install
the
latest
version
of
the
faraday
instrumentation,
and
it
seems
that
it
has
a
is
transitive
dependency
on
ruby
gems
points
to
an
older
version
of
the
instrumentation
base,
and
I
cannot
seem
to
understand
why
it's
doing
that-
and
I
don't
know
if
something
failed
as
part
of
the
release.
A
D
So
I
believe
I
thought
if,
unless
my
memory
is
failing
me,
that
instrumentation
should
not
depend
on
the
library,
the
instrumented
library
itself,
it's
like
in
that
way,.
A
A
If
you
look
at
the
source
code
right
now
on
main
faraday
says
it
depends
on
open
telemetry
base,
20.,
not
optimistic.
I'm
sorry,
pessimistically
on
bug
fixes
for
20.
you'll
note
that
it
seems
that
the
hotel,
sdk
1
3
version
has
the
right
reference
to
base,
but
faraday
20
that
got
released
yesterday
does
not.
A
It
depends
on
the
older
incompatible
version
of
base
if
you
click
on
the
link,
so
I
I
submitted
a
few
links
in
the
in
the
zoom
chat,
the
second
one
being
what
ruby
gems
thinks
the
dependencies
are.
It
thinks
that
transitively
there
is
a
runtime
dependency
of
the
20
gem
on
base
19.
C
E
C
A
A
All
right,
so
that
was
all
that
was
all
we
have
to
figure
out
a
way
to.
C
Wonder
if,
like
doing
looser
constraints
on
the
gem
spec
dependencies
there,
because
right
now
we're
pinning
it
to
minor
or
the
patch
right
like
in
faraday,
it's
saying
what
is
it
saying
that
last
release
would
have
saying
it
said
that
it
could
it
couldn't
go
to
0.20?
It
could
only
go
to
the
latest
0.19.
C
A
My
my
take
on
this
is
that
we
probably
need
something
that
verifies
that
things
can
be
released
and
things
will
install
correctly
yeah
without,
like
all
of
these,
because
we
have
a
bunch
of
code,
the
things
I'm
removing
from
the
gem
files
right
now,
which
is
like
I
depend
on
the
local
path
of
this
thing,
yeah,
and
so
I'm
trying
to
like
remove
as
much
of
that
as
possible.
A
But
I
don't
know
you
know
it's
almost
as
if,
like
as
part
of
the
build
this
release
process,
it
should
try
to
do
the
release
like
a
like
a
dry
run
kind
of
thing
and
then
try
to
install
it
all.
But
you
know
it's
a.
C
D
C
Right
now,
yeah
and
I
agree
you're
what
you're
describing
like
an
actual
mechanism
that
says
like
and
does
this
actually
work
is
really
good.
Instead
of
me
optimistically
saying
like.
If
this
process
does
work,
it
should
work.
It's
like
well
of
the
two
paths
there.
C
I
think
what
you
described
sounds
a
lot
more
sane,
whereas,
like
our
current
reality
is
just
a
little
bit
cumbersome
and
it's
just
like
we
were
talking
about
this
yesterday
we
were
looking
at
the
some
of
the
code
in
there
and
it's
like
there's
a
lot
going
on
in
there,
and
hopefully
we
can
simplify
that
and
therefore
simplify
our
release
process.
I
think
even
just
decoupling,
the
local
paths,
it
might
add
a
little
a
few
extra
steps,
but
it'll
bring
us
closer
to
that
described
state.
A
Yeah
we
actually
started
like
working
on
it
just
sitting
on
my
hands
here.
Sad
myself
and
robert
had
a
powwow
yesterday
and
we're
gonna
start
moving
forward
to
try
to
get
something
ready
for
next
week
or
in
two
weeks,
because
I
go
on
call
next
week.
So
we'll
see.
F
C
That
change
is
very,
very
helpful
for
both
the
migration
and
just
again
what
we're
dealing
with
right
now.
So
I'm
really
excited
to
see
you
fixing.
A
This
yeah,
so
so
so
similarly
there's
going
to
be,
I,
I
only
did
the
instrumentation
because
there's
so
many
files,
but
if
in
the
contrib
repo
there
is
an
issue
where
I
list
I
create
like
a
draft
list
of
of
tasks
to
perform.
A
You
know
if
you
all
have
a
chance
to
look
it
over,
do
that
and
if
you
can
jump
in
and
help
wink
wink
rob
hayworth
where
you
know,
please
please
jump
in
the
water's
fine,
except
for
merge
conflicts.
That
always
you
know.
A
F
A
F
And
if
you
want
to
take
feedback
back
to
the
product
teams,
it's
an
interesting
question
as
to
why
code,
spaces
and
actions
use
different
runtimes
somehow,
but
I
mean
oh,
my
god
is
that
shade
from
a
former
employee
and
it's
not
shade
from
before.
I
don't
know
what
you're
talking
about.
I
don't
know
what
you're
talking
about.
D
D
F
E
Yeah
this
is
this
is
not
well
said,
every
time
my
tests
fail
on
open,
telemetry,
ruby
and
I
go
into
github
actions.
It's
just
like
there's
like
wild
amounts
of
like
empty
space
and
then
we're
running
all
of
the
instrumentation
tests.
E
In
the
same,
I
don't
know
words,
but
like
the
same
runner,
it's
and
it's
it's
just
impossible
to
like,
like
even
as
like
contributors
like
first-time
contributors,
you're,
just
like
what
the
hell
is
going
on
here
and
I've
been
trying
to
think
about
how
to
can
we
make
this
any
better
and,
like
maybe
github,
actions,
would
let
us
spawn
like
child
process,
child
jobs
or
something
but
like?
Does
anyone
have
ideas
for
how
to
make
this
better?
Besides,
like
splitting
stuff
out
into
contrib,
which
maybe
it'll
just
get
better
when.
C
F
The
the
toy,
dot,
rb
or
whatever
it
is,
is
doing
a
lot
of
the
heavy
lifting
for
us
in
this,
but
I
don't
know
between
that
and
the
release
flakiness
that
it
causes
like
we
may
want
to
take
a
harder
look
at
like
if
that's
actually
saving
us
a
lot
of
effort,
at
least
for
the
builds.
I
mean
it
would
be
nice
if
we
could
take
advantage
of
like
a
real
matrix
build.
Is
that
just
habit?
A
F
C
F
B
I
think,
but
no
I
I
well
yeah
I
shut
up
when
robert
when
robert
started
talking
I'm
like
I'm
gonna.
Let
somebody
know
what
they're
talking
about
talk.
B
I
remember
having
the
same
same
complaint
as
sam
a
few
months
back
and
that
like
windows
got
brought
up
as
one
of
our
test
platforms
is
complicating
life
and
the
the
amount
of
time
it
takes
to
spin
up.
One
of
these
runners
we
was
a
reason
to
at
the
time,
was
a
reason
to
keep
the
number
of
runners
low
so
that
you
didn't
pay
the
spin
up
time,
but.
A
B
B
A
B
What
does
that
look
like?
Because
I
know
in
not
github
actions
when
I
do
a
matrix
build
it
just
it
would
just
make
the
list
on
the
left
get
very
long
and
not
necessarily
like
sorted
by
all
the
ruby
two.
Five
gem:
gem:
gem,
jim
ruby,
two:
six
gym!
You
know
it's
ruby,
two:
five,
random
gem,
ruby,
two,
six,
some
other
gem,
ruby,
two,
seven,
the
different
gem
and
it's
it
might
be
like
that.
It
will
be
like
that.
Maybe
cool.
A
Imagine
if
you
will
each
one
of
those
jobs
now
appears
with
the
instrumentation,
depending
on
the
granularity
that
we
choose
right,
because
we
we
you
know
at
least
for
this.
For
this
repository
it
would
only
be
the
sdk
api
that
would
be
that's
a
base.
It
would
be
a
subset
when
we
move
to
the
contrib
package.
The
contrib
package
will
be
not
as
friendly,
so
you
know.
F
I'm
wondering
if
we
could
do
this
there's
a
lot
of
different
ways
to
do
it
to
make
that
readability
problem
go
away
like
we
could.
We
could
say
that,
like
okay,
we
have
a
separate
job
for
each
gem
and
then
like
there's
a
matrix,
build
of
ruby
versions
for
each
one
or
something
like
you
can
play
around
with
the
level
of
organization
until
it
feels
right.
But
honestly,
even
if
it
was
a
long,
unwieldy
list,
it's
like.
F
Yes,
but
like
different
ascii
characters
and
less
xml,
and
it's
just
like
sequences
of
equals
and
colons.
If
I
remember
correctly,.
A
B
F
They
have
that
too
there's
there's.
F
Suite
of
directives
you
can
use
to
like
control
the
output
of
it.
We
just
take
advantage
of
none
of
it.
Okay,
I've
talked
a
lot
about
this.
I'm
happy
to
take
a
stab
at
this
today.
Actually,
I
I
have
not
a
ton.
I
have
some
meetings
and
stuff
on
my
plate,
but,
like
I
don't
know,
I
could
poke
at
this.
If
nobody
else
feels
strongly
inclined
now
the
flakiness
of
our
tests
and
like
a
release
process,
I
don't
want
to
touch
that
personally,
but
like
can
make
it
look
prettier.
A
The
only
thing
that
I
would
say
andrew
is,
we
are
gonna,
try
to
rip
this
all
out
and
put
it
into
a
several
repo.
So.
F
F
D
A
Around
here
yeah,
we.
D
A
I
did
the
thing
that
I
read
in
my
leadership
book,
which
was
don't
do
it
yourself
delegate
it
so
I
I
said
chris:
could
you
help
us
come
up
with
a
plan
on
how
we
could
handle
this
and
he
said
sure
I'll
gather
some
research
on
how
this
is
handled
elsewhere?
Oh
I'm
like
thank
you,
chris.
Let's
get
a
look
at.
C
So
I'm
gonna
go
on
a
recorded
call
before
everyone
leaves
to
say
that,
like
this
question
got
asked
because
it
took
a
long
time
to
people
don't
want
to
release
care
about
having
a
really
schedule
if
stuff
gets
released
in
a
timely
fashion.
This
is
a
symptom
of
like
things
taking
too
long
to
get
released,
and
I'm
like
super
aware
of
that.
But
at
the
flip
side,
if
there
is
a
risk
release
schedule,
then
it
holds
us
accountable
to
doing
it
at
that
interval.
F
B
Be
interesting
to
know
if
chris's
interest
in
a
release
schedule
is
that
things
aren't
being
released,
often
enough
or
some,
and
maybe
this
isn't
the
case
with
him,
but
some
places
are
a
little
bit
conservative
about
when
they
update.
So
if
things
happen
too
quickly,
they
like
well,
we
know
we,
we
do
our
updates
on
this
interval.
So
we
can
sync
up
our
interval
with
this
dependency
that
we've
got,
but
I
think
you're,
probably
right.
If
we,
if
things
get
released
on
a
when
they're
releasable,
then
I
think.
B
Speaking
of
updates
to
new
signals
when
we
go
to
update
what
version
of
the
proto
are
we
on
right
now
and
I
I
could
go
look
at
this.
You
know
what
I'll
look
this
up
and
ask
questions.
I.
B
B
I
have
a
request
that
when,
when
we
update,
I
think
it's
to
0.12
or
greater
that
it
includes
the
renaming
of
don't
use.
Instrumentation
library
do
the
scope,
because
if
it
goes
on
instrumentation
library
on
the
wire,
it
gets
weird
for
us
because
we're
we
in
our
this
is
speaking
of
honeycomb
in
our
ingest
right
now.
B
I
have
to
we're
parked
on
a
slightly
old
proto
for
ingest,
so
we're
looking
for
instrumentation
library
spans
at
whatever
the
proto
field
is
for
that,
because
people
are
sending
us
beta,
metrics
and
we're
trying
to
like
hey
upgrade
your
java
agents
folks.
B
So
we're
stuck
on
this
like
previous
proto
for
a
little
while,
but
it's
not
a
problem.
If,
when
an
instrumentation,
when
an
sdk
moves
from
when
they
go
to
the
new
version
of
the
proto,
they
also
do
the
code
rename
so
that
they
they
use
scope
instead
of
instrumentation
library.
C
Yeah
yeah,
that
makes
a
lot
of
sense.
That
is
something
that
is
like.
Yes,
I
have
my
insight
on
that
and
it's
like.
B
F
F
B
C
C
Cool
yeah
we're
quite
a
bit
over
now
and
if
anybody
has
anything
else,
otherwise
we'll
free
each
other
by
anyone
want
to
say
a
final.
Thank
you
to
teos
or.