►
From YouTube: 2022-10-04 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
C
D
D
B
Excuse
me
we
might
want
to
put
on
our
safety
belts.
First
yeah
foreign.
D
I
guess
I
can
do
that
if
we're
in
the
the
Gathering
phase.
E
A
C
There's
a
long
bike
shed
over
this
issue,
basically
I
think
the
issue
as
I
understand
it
is
that
the
metrics
pipeline
is
incredibly
complicated,
number
one
and
I
think.
Ultimately,
there
are
reasons
for
it
and
what
I'm
understanding
is
you
know
it's
it's
a
lot
more
complicated
than
tracing
you
have
an
exporter
in
that
is
you
know
that
overlaps
with
tracing?
It
is
the
thing
that
will
get
data
out
of
your
application.
C
But
then
you
also
kind
of
have
this
metric
reader
interface
and
there
is
in
kind
of
the
export
of
metrics.
There
is
some
interplay
between
the
reader
and
the
exporter,
so
that
is
one
reason
for
kind
of
some
complications
and
I.
Think
one
of
the
reasons
why
that
exists
is
that
metrics
can
kind
of
either
be
like
a
push
or
pull
based
system.
So
there's
like
just
a
lot
more
Machinery
around
and
ultimately
this
issue
is
raised
because
there
is
a
there's,
a
PR
to
add
an
exponential
histogram
as
the
default
aggregation.
C
This
was
being
set
on
the
exporter
and
I.
Think
the
confusion
was
coming
in
in
that
the
aggregation,
I
believe
typically
happens
in
the
metric
reader,
so
it
kind
of
just
seemed
like
it
was
like
a
misplaced
option.
I
guess,
however,
after
long
long
yeah,
this
led
to
many
bike
sheds
about
about
kind
of
the
division
of
responsibility
between
the
metric
reader
and
the
exporter
and
where
and
whether
or
not
this
makes
sense
and
where
it
makes
sense
to
have
this
option
so
I
think
the.
C
Yeah
the
end
result
is
that
everybody
agreed
that
stuff
was
very
complicated
and
could
be
expect
a
lot
better.
I,
don't
think
anybody
agreed
exactly
where
this
option
belongs
so
so.
C
This
is
kind
of
a
long-standing
thing
in
open
Telemetry,
the
the
attributes
definition
in
in
the
protobufs
kind
of
allows,
nested,
Maps
or
arrays
of
attributes.
C
However,
in
tracing
and
metrics,
it's
kind
of
restricted
to
to
individual
scalar
values
as
well
as
kind
of
uniform
arrays
of
those
types,
but
not
nested,
Maps
or
or
arrays
of
those
types
logs
does
allow
this,
and
so
Neff
has
been
trying
to
at
least
like
clarify
this
at
the
spec
level
and
I
think
each
time
he
tries
to
do
this,
it
looks
like
he's
changing
the
behavior
and
people
are
having
some
problems
with
it
and
then,
when
this
came
up,
people
were
starting
to
ask
about
like
well.
C
Maybe
we
should
change
Behavior.
Maybe
we
should
allow
these
nested
attribute,
values
and
I.
Don't
know.
I
spoke
out
against
this
a
lot
a
long
time
ago.
I
didn't
say
anything
today,
because
I'm
exhausted
well
still
about
this
conversation,
but
basically
I.
Don't
know
that
back
ends
actually
support
this
like
if
you
wanted
to
query
out
a
value
that
was
in
a
you,
know,
deeply
nested
attribute
structure
like
how
do
you
go
about
doing
that?
C
I
think
the
only
way
that
you
would
go
about
doing
that
is,
you
would
have
to
flatten,
like
flattened
that
nested
structure
into
like
a
single
key
with
a
bunch
of
dots,
probably
using
some
standard
way
to
do
this,
and
that
gets
really
complicated.
C
If
you
had
an
array
somewhere
in
the
middle
of
that
like
unless
somebody
can
show
me
how
to
flatten
that
stuff
in
a
reasonable
way
and
have
it
a
an
array
smack
dab
in
the
middle
and
come
out
with
a
key
that
doesn't
have
like
a
numeric
index
somewhere
in
the
middle.
Then
then,
yes,
I,
think
I
think
this
is
pretty
complicated
and
unless
less
back-ends
do
natively
support
querying
deeply
nested
structures.
E
Mean
it
may
not
be
appropriate
in
the
spec
like
because
it
may
be
something
like
you
said:
most
back-ends
don't
support
it,
but
certainly
some
databases
do
support
that
style
of
thing.
My
beloved
postgres,
for
example,
I
know,
can
support
I
think
virtually
arbitrary
Json
queries.
E
If
you
choose
to
store
the
data
as
a
Json
object,
at
least
so
it
certainly
can
be
done,
but
I
mean
from
a
spec
level.
I
think
it's
certainly
reasonable
to
say
that's
by
far
that's
far
from
Universal
and
as
complicated
so
like
from
that
aspect,
I
think
it's
fine
to
say
no,
but
like
also
I
mean
there
are.
You
know
some
at
least
relational
database
systems
that
can
do
this
today,
but
it's
yeah
support
varies.
C
Yeah
I
think
it
would
be
a
big
change,
mainly
just
because
the
various
tracing
back
ends
would
have
to
somehow
find
a
way
to
support
this
or
yeah.
B
Yeah
a
reason:
Like
Jaeger
ends
up
getting
a
sort
of
like
our.
B
Like
our
I,
don't
know
reference
point:
if
Jaeger
ends
up
again,
don't
support
it,
then
the
Spectrum
support
it
kind
of
thing.
C
Yeah
I
think
I.
Think
a
lot
of
these
arguments
were
kind
of
the
original
arguments
that
at
least
led
to
the
spec
saying
that
you
were
limited
to
like
at
least
homogeneous
arrays
of
the
the
Primitive
types
that
we
support,
and
even
that
is
kind
of
like
bending
the
rules.
I
feel
like
a
lot
of
a
lot
of
backends
to
support
that
you
just
kind
of
like
Json
serialize
or
like
stringify
that
thing
in
in
some
in
some
way,
but
yeah.
C
So
I
guess
this
conversation
may
continue
and
we'll
see
like
it's
been
a
while,
since
this
has
happened,
so
people
may
be
very
interested
in
trying
to
support
nested
attributes
everywhere.
I
guess
I
would
have
to
open
my
mind
to
this
idea
again.
If,
if
these
conversations
do
start
happening.
E
Go
ahead,
I
was
just
going
to
say,
I.
Think
the
difficulty
of
crafting
a
spec
is
not
allowing
yourself
to
be
bound
by
what
exists
today
and
enabling
future
Innovation,
but
also
not
being
so
far
out
there
that
nobody
can
ever
implement
it
and
just
disregard
it.
So,
like
I,
can
kind
of
understand
why
we
might
not
want
it,
but
that
was
that
was
just
a
comment.
Rob,
please
go
ahead.
D
Flattening
a
deeply
nested
structure,
if
you
throw
some
Json
on
a
field
and
then
say
I
would
like
you
to
unpack
that
for
me.
If
it's
a
mess
in
the
resulting
back
end
I'm,
like
fix
your
instrumentation
like
as
maintainers
of
Auto
instrumentation,
we
should
probably
not
just
throw
big
old
objects
onto
an
attribute.
D
We
should
be
judicious
about
the
names
of
the
things
that
we
put
on
spans,
but
if,
in
manual
instrumentation
an
open,
Telemetry
user
wants
to
throw
Json
on
a
thing
and
hope
the
back
end
can
expand,
it
either
store
it
in
postgres.
So
you
can
query
against
it.
I
don't
know
your
back
end
and
honeycomb.
We
would
flatten
it
all
out
and
if
you
get
integer
indexes
in
your
attribute
names,
I
can
explain
why.
C
That
when
we
were
when
this
is
originally
being
discussed,
I
think
there
was
the
Insight
that
the
dotted
keys
for
semantic
conventions
were
really
like
a
hash
in
Disguise
yeah.
So
it
sounded
to
me
like
the
Trend
was
just
going
to
be
anywhere.
You
would
see
a
dot
just
make
it
a
nested
map
and
that
seemed
to
me
to
be
maybe
counterproductive
in
the
long
run
like
it's
super
expressive
like
I'm,
not
going
to
argue
that
point
and
that
you
could
make
some.
C
You
know
you
could
organize
your
data
in
some
very
interesting
ways,
but
ultimately
you're
going
to
have
to
like
flatten
that
back
down
to
something
sane,
I
think
in
in
a
back
end
on
the
way
in
and
it
seemed
like
it
was
going
to
be
more
work
than
put
than
possibly
it's
worth
in
less
back
ends
kind
of
natively
support.
All
this
and
there's
you
know
a
huge
amount
of
benefits
to
it.
C
What
any
case
I
feel
like
I
yeah,
we'll
see
if
this
conversation
kind
of
continues
and
and
where
it
goes,
but
I
don't
know
that
we
need
to
solve
anything
here.
Don't.
A
C
The
same
vein,
I
think
we
was
a
discussion
about
structured,
stack,
Trace
to
exception
attributes,
and
this
is
also
kind
of
something
that
was
talked
about
in
the
past
and
deemed
to
be
far
too
complicated,
and
nobody
could
agree
on
it,
but
Tristan
who
works
in
erlang,
which
produces
insane
stack
traces
that
nobody
knows
how
to
do.
Anything
with
would
really
like
to
see
some
some
way
for
back
ends,
kind
of
make
sense
of
this
stuff
and
I
think
it
makes
sense.
C
I
think
it
would
make
it
would
make
sense
for
us
to
have
some
more
definition
around
this,
for
the
benefit
of
tracing
back
ends
to
not
have
to
implement
kind
of
their
their
own
parsers
for
every
every
language,
but
but
yeah
I
think
there's
some
discussions
about
this
being
possibly
a
difficult
thing,
but
yeah.
C
If
Tristan
is
willing
to
do
the
work
to
socialize
this
and
make
everybody
happy
I
think
it
would
be
a
good
addition.
B
I
think
Samurai
also
brought
up
something
about
bug,
snag
supposedly
participating
in
some
discussion
about.
B
Handling
stack
traces
and
exception
reporting,
so
it
might
be
interesting
to
follow
up
with
them
and
see
what
the
buck
snack
people
have
to
say
about
it.
I
don't
think
I've
seen
anything
come
through.
C
Who
was
engaging
with
bugsag.
C
A
C
Some
communication
lines
with
bug,
sag
and
I-
do
remember,
Sam
bringing
so
I
thought
you
mentioned
that
that
this
would
be
a
good
thing
to
to
point
them
at
if
they
have
opinions
or
if
they
have
like
formats
that
they
have
been
using,
that
really
work
well
for
them,
it
might
help
Hotel
take
some
shortcuts
and
come
up
with
a
good,
a
good
format.
A
C
All
right,
last
but
not
least,
I
have
one
minute
left
and
I.
Think
that's
that's
really.
Where
we
were,
is
we
only
made
it
to
Diego's
question
about
semantic
convention,
stability
and
the
tldr
is
that
semantic
conventions
are
not
stable,
and
it
is
something
that
people
are
aware
of
and
they're
aware
that
this
is
kind
of
like
a
in
an
issue
and
something
that
we
would
like
to
try
to
be
able
to
get
to
some
level
of
stability
sooner
than
later.
C
I.
Think
one
of
the
big
things
is
that
they
wanted
to
get
like
subject
matter
experts
in
kind
of
each
of
these
domains
to
to
Hash
things
out
and
just
kind
of
make
sure
that
we
are
representing
things
in
a
in
a
sane
way,
so
I
think
they
kind
of
did
that
with
http,
and
there
was
kind
of
the
HTTP
cement
conventions
working
group
I
think
they
kind
of
would
like
to
make
sure
they
they
do
that
or
something
like
that
with
most
of
these
other
kind
of
name
spaces
before.
C
C
I
think
there
are
a
few
more
issues
that
did
not
get
discussed
because
we
spent
too
much
time
like
shedding
other
things.
C
I
guess
I
will
point
out
this
otlp
Json
stabilization
thing
as
as
I
think
that
I
think
is
important,
something
that
that
many
of
us
have
been
asking
about
for
years
at
this
point
and
it
seems
like
they're,
this
is
actually
there's
a
list
of
things
that
needed
to
be
done
to
make
otlpjs
unstable,
and
this
is
like
the
final.
B
C
Casing
and
the
lower
camel
case
naming
for
the
jsonified
Proto,
there's
actually
been
a
heated
discussion
about
this
and
I.
Think
Yuri
cares
quite
a
bit
about
this,
or
has
been,
and
mainly
just
been
saying.
Why
don't
we
just
go
with
the
lower
camel
case?
C
It's
kind
of
the
default,
the
Proto
I
guess
the
Proto
spec
allows
for
either,
but
I
think
his
point
was
that
it
was
the
allowing
both
of
those
representations
was
kind
of
because
they
were
forced
to
do
that
for
some
design
kind
of
choices
that
they
made
in
the
past
and
that
just
oh
green
on
one
would
probably
be.
E
We're
all
okay,
so
I
am
curious.
It
is
the
do
you
do.
We
think
that
the
Json
thing
is
going
to
end
up
being
like
Intel
supports
both,
because
it
feels
very
much
like
one
of
those
holy
war
style
things
that
we,
the
ones
that
endlessly
get
debated
and
like
know
the
emperor
agrees
on,
and
are
we
just
gonna
kind
of
say,
like
both
our
fines
that
we
can
like
move
on?
Is
that
the
idea
you
think.
C
Mean
I,
don't
know,
I
think
there
are
some
practical
concerns
here,
but
but
yeah
I'm
not
sure
I
think
this.
Is
this
really
the
last
issue
and
I
think
it
depends
on
how
you
want
to
parse
this
stuff
and
I?
Think
a
lot
of
the
Proto
Tools.
C
I,
don't
know
how
how
they
work
in
all
languages,
but
I
think
most
of
them
have
at
least
an
option
where
you
can
Parts
the
incoming
request
using
either
casing
I'm
sure
there
are
like
trade-offs
to
using
those
options,
but
as
long
as
you're
as
long
as
your
tooling
supports
this
I,
don't
see
it
being
like
a
huge
issue
either
way,
but
there
might
be
Tooling
in
some
systems
that
you
know
are
expecting
lower
camel
case
and
it
might
force
you
to
have
to,
like.
C
You
know,
write
a
bunch
of
custom
code
to
do
other
stuff
and
I.
Think
that
is
maybe
a
valid
concern
here.
But
I.
E
C
Yeah
I
think
mainly
you
know.
The
maintainers
of
the
Proto
have
just
been
really
reluctant
to
Mark
Json
stable
because
of
the
the
message
names.
So
there's
a
lot
of
changes
that
you
can
make
that
are
protobot
backwards,
compatible
that
are
not
you
know,
Json
backwards
compatible,
but
I
think
at
least
for
tracing
in
metrics.
They
are
they're
happy
enough
with
the
way
things
are
named.
There's
enough.
B
C
A
history
behind
it
that
they
don't
anticipate
any
like
you
know,
dramatic
changes,
so
I
think
there
have
been
some.
C
You
know
crossing
crossing
the
t's
dotting
the
eyes
on
on
the
rest
of
the
stuff
around
Json,
but
that
sort
of
thing
stand.
D
That
does
make
me
wish
that
they
hadn't
resisted
the
include
the
version
of
the
Proto
in
something
the
user
agent,
a
header
or
something
because
if
they
decide
to
do
something,
that's
backwards,
breaking
and
Json,
but
not
backwards
breaking
and
either
the
Proto
Buffs.
D
C
But
so
I
think
I
I
was
kind
of
in
that
same
frame
of
mind
and
it
seems
like
the
problem
ends
up
being
the
browser.
The
browser,
the
prime
source.
C
Of
course
is
is
the
enemy
of
everything
that
you
want
to
do
by
header
somehow,
and
you
end
up
having
to
like
jam
things
into
the
body,
and
then
it's
like
you're
back
to
square
one
and
we're
like
well,
if
I,
if
it's
backwards,
incompatible,
I,
don't
know
actually
how
to
parse
the
body
to
get
the
information
back
out
and
so
yeah
going
back
to
the
first
thing.
I
learned
in
software
engineering
is
browsers,
are
the
worst
stay
away
from
them
and
they
will.
D
That
was
one
of
the
proposals
and
it
still
was
getting
pushed
back
of
like
the
Proto's
backwards
compatible.
We
shouldn't
accommodate
backwards,
breaking
changes
with
a
version
number.
We
should
just
not
make
backwards
breaking
changes
which
sounds
like
don't
write
bugs,
but
I
couldn't
convince
anybody
of
that.
C
There
is,
or
was
something
about
a
user
agent,
and
my
guess
is:
it
has
already
merged.
A
D
D
D
C
I
will
say
the
last
last
thing
is
that
you
know
in
having
these
conversations
a
lot
of
people
end
up
with
the
the
version
goes
in
the
end
point,
and
that
is
one
I
feel
like
all
these
things
have
pros
and
cons,
but
if
otlp
Json
is
declared
stable,
I
think
you
would
get
a
you
know,
a
fully
new
version
and
technically
a
different
endpoint
to
to
deal
with
this
I
think
that
would
be
the
the
only
Escape
hash
we
have
allowed
ourselves.
Given
that
there's
another
way.
C
So
now
that
we
have
angered
Sam
beyond
belief,
nobody,
let
him
watch
this.
The
the
recast
later.
C
C
B
Oh
yeah,
I'm
gonna
individually,
release
all
the
packages
and
then
and
then
release
an
a
new
version
of
all
of
them.
If
it's
necessary.
B
Assuming
that
you
know
we
don't
have
to
do
anything
to
bump
the
first
like
I,
don't
know
what
the
version
constraints
are,
for
example,
in
all
right
now,
if
they're
all
minor
version
constraints,
then
we
don't
have
to
bump
them.
People
get
the
latest
versions
and
it'll
be
fine.
C
Well
so
yeah,
it
seems
like
some
some
releasing
releasing
will
happen
if
we
can
figure
out
the
actual
names
and
stuff
and
anything
else
that
we
should
discuss
any
any
PRS
hot
topics.
D
D
They
were
just
using
an
instrumentation
all
package
and
use
all
in
their
config,
and
some
of
many
of
the
Rails
instrumentations
failed
to
load,
and
it
became
hard
to
debug
that
my
current
theory
is
that
maybe
it's
on
a
version
of
rails
and
therefore
all
of
the
action
gang
that's
older
than
the
minimum
version
in
the
gems
in
the
instrumentation
gems.
But
I
haven't
heard
back
from
them
on
that.
D
If
it
is
a
rails
version,
that's
above
the
minimum
version,
I
imagine
there
will
be
more
troubleshooting
and
maybe
that
can
inform
more
Diagnostics
that
might
get
put
out
by
the
instrumentations.
D
B
I,
don't
think,
there's
a
lot
of
information
other
than
what
might
come
from
the
error
Handler,
because
the
messages
are
essentially
like
I
pointed
them
out
to
you.
Messages
are
essentially
like
hey
this
didn't
load
or
did.
B
B
If
it
was
an
exception,
the
error
Handler
would
have
also
print
that
out.
D
B
B
C
D
So
that
is
an
interesting
point.
We,
our
current
Ruby
documentation,
was
cobbled
together
from
like
honeycomb's
documentation
of
using
Hotel
Ruby,
which
was
me
like
taking
notes
on
it
using
Hotel,
Ruby
and
Ariel
helped
me
massage
it
and
it
says,
try
to
initialize
this
as
early
as
possible
in
the
startup
process,
but
really
like
in
an
initializer
at
a
point
where
you're
running
the
initializers
I'd
imagine
you'd
have
rails
loaded
at
that
point
like
you're,
not
delaying
requiring
action
pack
before
the.
C
We're
on
this
topic:
okay,
one
thing
that
I
think
we
are
probably
not
doing
in
our
instrumentation
and
I
would
have
to
look
at
the
stuff,
because
I'm
not
I,
can't
say
that
I
am
fully
current
on
on
all
of
our
rails.
Instrumentation
idiosync
idiosyncrasies,
but
active
support
has
these
on
load
hooks
and
they
are
incredibly
useful
if
we
find
that
stuff
is
not
is
regularly
not
working
for
users.
C
I
think
the
the
onload
hooks
are
going
to
be
our
way
out
of
this.
So
like,
ultimately,
like
the
really
brief
tldr
on
these
things
is
that
rails
uses
Ruby,
like
Auto
load
for
a
lot
of
things,
so
it's
like
just
mentioning
a
constant
will
cause
it
to
load.
C
You
know
in
in
lieu
of
an
actual
require
somewhere
and
that
can
that
can
hose
the
rails
initialization
process.
Sometimes
you
can
load
something
sooner
than
rails
would
and
configuration
something
applied.
Things
get
clobbered,
there's
a
number
of
different
things,
but.
E
They
support
you
know
terrible
suggestion
and
I'm
curious
what
you
all
think
about
it.
Should
we
start
trying
to
move
our
rails
instrumentation
Upstream
at
this
point,
because
you
are
correct
in
that
rails.
Initialization
is
complex,
especially
with
autoloading,
and
it's
a
bit
of
a
mess
and
we've
done
a
fairly
decent
job
but
like,
as
you
noted,
the
basically
the
best
advice
we
can
always
give
is
loaded
extremely
early
as
soon
as
you
possibly
can,
which
even
still
doesn't
fix
everything.
E
C
I
mean
that
would
be
the
Holy
Grail.
We
would
really
like
to
see.
Hotel
being
you
know,
natively
included
or
having
first
class
native
support
in
in
the
various
languages,
but
I
think
in
the
interim
I
mean
one
thing
we
can
consider
is
all
the
things
that
our
instrumentation
install.
C
If
you
wrap
them
in
an
on
load
for
whatever
component
they
are
modifying,
I
think
this
is
going
to
be
inevitable
at
some
point
and
probably
will
will
fix
some
weird
timing
stuff,
because
I
think,
ultimately,
what
ends
up
happening
is
that
rails
will
queue
these
up
when
rails
is
ready
to
actually
load
one
of
these
components,
it
will
run
through
them
all
and
it
will.
C
It
will
alleviate
some
of
these
timing
things,
but
actually
adding
this
stuff
into
rails
would
be
super
awesome.
If,
if
anybody
knows
anybody
would
be
receptive
to
such
a
conversation,.
D
A
C
I
could
see
like
a
first
class
way
to
plug
into
notifications
or
I
set
up
notifications
that
rails
could
install
for
you
with
a
simple
configuration,
we're
not
impossible
to
follow
right.
E
Yeah
I
was
going
to
say,
the
difference
is
definitely
one
of
like.
Does
it
work
out
of
the
box
if
a
rails
maintainer?
Should
they
come
back
and
say
well
how's
this
different
than
active
support
notifications?
That's
a
little
bit
like
me,
walking
into
the
kitchen
and
saying
man
I'm
really
hungry,
and
then
someone
says
like
well
there's
some
bread
go
make
a
sandwich
and
like
yeah,
of
course
you
can
assemble
it
yourself
but
like
if
you
were
looking
for
a
sandwich
and
then
the
answer
is:
go
make
a
sandwich.
E
Well,
they're,
not
the
same
thing.
Maybe
you
should
go
make
the
sandwich
totally.
Maybe
you
should
do
that
but,
like
you
know,
different
one's
the
raw
ingredients,
I'm
hungry
I,
don't
know
if
you
can
tell
I'm
thinking
about
lunch.
Well
now.
D
I'm
hungry
too
well,
and
there
was-
and
this
came
up
like
months
ago,
Robert
in
doing
rails,
instrumentation,
there's
stuff
that
is
not
active-
support
notified
that
the
hotel
instrumentation
does
tell
you
about.
E
Well,
that
could
be
part
of
upstreaming.
It
then
is
actually
making
that
available
in
notifications,
because
I
do
suspect,
you're
right.
The
pushback
will
be
like.
Why
not
active
support
notifications,
to
which
well
it's
not
out
of
the
box,
and
then
the
answer
could
be
well
like.
Okay,
we'll
make
a
nice
one
out
of
the
box
and
then
maybe
we'll
we'll
ship
it
by
default.
Maybe
so
I
think,
like
that's
that's
just
how
I
imagine
it
playing
out.
It
seems
reasonable
from
their
perspective,
I'm,
sure
and
I,
think
yeah.
E
D
E
Think
yeah
and
they
they
have
a
benefit
of
not
really
having
any
semantic
conventions
that
are
applicable
to
them.
I
think
so
it's
a
little
bit
more
of
a
free-for-all,
but
that
is
what
we
do
for
anything
action
view.
Specifically
it's
all
done
with
notifications,
but
yeah
I
know
it's
kind
of
the
Holy
Grail.
It's
a
big
goal.
E
It's
a
famous
city
planner
in
Chicago,
who's
famous
quote,
is
make
no
little
plans.
They
have
no
magic,
disturb
men's
blood
and
will
probably
not
be
realized,
and
it's
one
I
think
about
a
lot.
It
is
shooting
for
the
moon,
but
that's
useful
to
think
about
I,
don't
know
if
we
need
to
do
it
right
now,
but
we
could
submit.
D
Can
submit
a
whole
new
active,
active
telemetry.
C
C
To
be
honest,
because
I
feel,
like
I,
really
I,
understand
the
drive
to
make
things
as
uniform
as
possible
between
different
languages,
so
that
we
can
make
the
most
of
them
kind
of
on
tracing
back
ends
and
not
have
to
have
intimate
language
knowledge,
but
I.
C
Also,
sympathize
with
the
I
mean
ultimately
I
think
the
first
party
instrumenters
that
are
going
to
have
to
figure
out
what
tangled
web
of
conventions
we
have
decided
on
and
how
to
kind
of
the
gymnastics
needed
to
transform
the
data
in
into
those
things
and
just
finding
the
right
balance
between
that
and
then
I
feel
like
there's
also
kind
of
like
this
gray
area.
C
That
seems
like
it's
becoming
a
little
bit
less
gray,
where
there
seems
like
there
might
be
room
for
kind
of
language
and
framework
specific
semantic
conventions,
which
I
think
has
been
at
least
initially
kind
of
resisted,
but
I
feel
like
that's
The
View.
That
is
changing
a
bit
so.
C
In
any
case,
it
seems
like
it
would
be
useful
to
kind
of
at
least
go
through
the
exercise
and
see
like
how
how
difficult
this
is
in
practice.
And
if
there's
any
feedback,
I
guess
to
supply
to
two
things.
Why
there's,
maybe
still
a
chance
to
influence
them.
A
C
D
I
could
revisit
the
the
release.
Request
works
when
I
didn't
call
it
mongodb
so
that
release
request.
Workflow
is
green.
B
Yeah
there's
I
I
was
looking
through
that
it
looks
like
the
the
changes
to
action
pack
weren't
picked
up,
so
maybe
it
was
missing
like
conventional
commits
or
something
that
how
to
not
do
that
and
I
think
one
of
these
at
least
the
mango
one
I
was
ex
I
think
we're
going
to
advertise
that
one
wait.
Maybe
it's
not
the
Mongol
one
shoot.
B
One
of
them
changed
like
the
obfuscation
default,
key
name.
B
D
So,
as
I
understand
it,
we
would
like
not
do
anything
with
this
particular
request.
We
would
have
to
go
back
in
and
do
a
new
request
for
a
gem
to
say
no,
you
need
to
be
a
minor
bump
or
a
major
bump
in.
B
A
No
I
do
I,
often
like
whenever
I
open
a
release,
request
I
edit.
It
I'm
just
like
full,
stop
push
up
a
commit
just
to
trigger
CI,
first
and
foremost,
because
you
don't
want
to
discover
it
later,
but
then
I
sometimes
will
shamelessly
do
a
little
adjacent
bumps.
If
you
have
that
weird
interdependency
stuff
going
on
but
I
think
that
should
not
be
an
issue
potentially
for
the
instrumentation
all,
but
I
think
we
were
very
sorry.
I.
Think
you
resolved
that
before
we
split
the
repos
so.
E
If
we're
out
of
things
to
talk
about
on
the
agenda,
I
am
curious.
If
there's
any
metrics
update
from
Robert
and
where
that
stands,
I
think
in
my
understanding
is
I
think
the
metrics
reader
interface
I
think
was
next,
but
I
don't
remember
if
that
was
that's
actually
correct
or
not.
A
Yeah,
that's
the
next
on
my
to
start,
I
have
not
started
yet.
I
have
a
sense
of
the
work
but
I
think.
More
importantly,
there
is
a
nice
opening
for
someone
to
work
on
asynchronous
instruments.
Should
they
desire
I,
don't
I,
don't
believe
any
of
I.
Think
like
that's
good.
Parallel
work
like
the
metrics
reader
shouldn't
have
any
impact
on
the
other
things.
Now.
A
That's
just
setting
up
a
nice
interface
and
whatever
readers
we
want
to
have
out
of
the
box
so
that
we
can
start
working
on
exporters
once
the
readers
are
done,
then
there's
room
for
parallel
work
on
exporters
right.
You
can
still
be
that
common
interface,
so
avoiding
churn,
but
yes,
lots
of
room
for
people
to
work
on
asynchronous
instruments,
so
I'm
no
longer
discouraging
contributions
to
this
work.
E
Cool
that
actually
answers,
one
of
the
main
questions
I
had,
which
was
I,
wasn't
sure
if
it
was
actually
ready
for
async
instruments,
even
though
I
think
I've
asked
you
this
before
and
you've
probably
answered
it.
I
found
myself
unable
to
remember
so.
That's
cool
I
will
maybe
start
on
that.
I
think
I
have
been
curious
about
doing
it.
So
I'd
like
to
poke
at
it
for
a
little
bit.
A
Cool
yeah,
definitely,
and
even
if,
if
the
next
time
this
question
comes
up,
I
haven't
worked
on
Metric
readers,
potentially
instead
of
shaming
myself
I'll
invite
people
to
work
on
the
metric
readers,
but
we'll
see
I
do
I
do
strive
to
work
on
it.
A
A
Excellent
and
I
did
I
did
try
to
order
them
in
what
I
thought
felt
like
a
kind
of
logical
work
on
this
next
sort
of
thing,
so
that
was
my
intent
was
that
anyone
could
just
start
tripping
down
that
list.
E
I
have
I
have
claimed
one
of
them.
I
will
not
commit
to
any
anything
additional,
because
I
know
better
than
to
do
that
these
days.
But
I
will
start
with
this
one
and
see
how
far
I
get.
E
I'm
gonna
drop
off
and
go
get
some
food.