►
From YouTube: 2020-09-11 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
Morning
morning,
not
so
good
here
in
portland,
but
I
hope
it's
good
for
you
in
europe
why
we
have
terrible
wildfires
and
the
whole
city
is
covered
with
smoke
and
ash.
A
B
B
B
C
B
B
D
B
Cool
well
give
one
more
minute
to
see
if
hopefully
bogdan
will
show
up,
he
wanted
to
talk
about
the
typed
keys.
D
D
But
your
changes
look
great
to
me.
I
think
we
are
using
some
small
type
safety,
but
if
they
deliver
the
improvements
in
allocations
and
also
if
those
changes
help
the
instrumentation,
it's
okay.
For
me,.
B
Yeah
they
make
the
semantic
attributes
a
lot
easier
to
use,
since
you
just
can
use
them
directly
has
keys.
You
don't
have
to
do
any
sort
of
weird
gyrations
on
them
yeah
and
it
does.
It
should
save
a
little
bit
of
allocation
in
the
string
case
and
in
the
rest
of
other
cases
it
should
be
the
same
yeah
anyway.
B
The
types
in
the
interesting
the
type
safety
is
really
only
lost
on
the
consumer
side,
which
is
not
an
api
surface,
which
I
think
is
good
because
we
can
address
that
can
always
be
addressed
later
inside
the
sdk.
If
we
want
to
change
the
way
that
that's
exposed
in
there
it's
easier
to
do
than
if
the
api
changes,
so
the
api
is
just
as
type
safe
as
it
was
before,
which
is
nice
all
right.
Well,
let's
get
started
since
looks
like
nobody
else.
B
Is
here
right
now,
so
thanks
for
showing
up
everybody's
already
on
the
agenda
attendees,
so
that's
good.
B
B
So
just
be
a
hopefully
an
easier
way
to
kind
of
see
all
the
things
we
need
to
get
done
and
be
able
to
track
our
progress
towards
that.
One
thing
that
I
know
that
trask
has
been
doing
in
the
instrumentation
is
to
kind
of
track
how
that
burn
down
has
been
going.
So
I
might
start
doing
that
in
the
upcoming
weeks.
B
Just
to
see
how
we're
doing
we
got
lots
of
things.
I
think
we've
got
21
21
things
in
the
to
do
at
the
moment
for
ga
and
that
will
grow
as
the
specs
start
getting
a
little
solidified.
I
know
there's
going
to
be
a
few
things
coming
soon
and
this
shouldn't
be
big
deals,
but
there's
probably
going
to
be
a
few
here
and
there.
B
Well,
these
this
isn't
all
of
the
items.
This
is
just
the
p2
and
above
so,
okay,
I'm
trying
to
make
it
at
least
manageable.
D
B
Yeah,
I
mean
honorable,
I
think,
has
been
spreading
his
time
throughout
specs
and
instrumentation
and
java
so
see
how
it
goes
yeah.
So
we
talked
a
little
bit
about
the
typed
typed
attribute
key
pr.
I
got
a
little
feedback
from
honorable
some
small.
I
think
smallish
tweaks
anybody
who
is
interested
in
this,
since
it
is
a
really.
I
know
I
don't
know
how
much
giovanni
I
thought
you
took
a
little
bit
of
a
look,
but
it's
a
pretty
significant
change
to
the
api,
but
I
think
it's
a
good
one.
A
B
Know
all
the
tests
also
yeah
it.
I
would
what
I
would
do
is
kind
of
ignore
the
tests.
The
tests
I
mean.
Obviously
I
mean
I.
It
would
be
good
to
double
check
that
I
didn't
delete
important
tests,
but
I
think
the
more
important
thing
to
look
at
is
what
the
api
changes
are
and
kind
of
how
how
that
api
impacts
the
semantic
attributes.
B
For
me,
it
actually
makes
the
api
a
little
easier
to
use
because
you
don't
have
to
be
constructing
these
attribute
values
everywhere,
especially
when
you're
setting
when
you're
actually
set
like
setting
attributes
in
instrumentation
you
just
the
value
is
the
value
and
your
keys
are
pre-allocated,
almost
always
actually.
Carlos
one
thing
that
is
worth
considering
about
this
that
came
up
is
the
the
open
tracing
shim,
because
we
can't
pre-allocate
those
keys.
B
I'm
not
super
worried
about
it,
but
it
definitely
was
something
that
you
know
bugged
me
a
little
bit
while
I
was
converting
all
the
code
I
mean
before
we
were
having
to
wrap
all
the
values,
so
I
mean
either
way
you
were
having
to
do
something
during
the
shim,
so
okay,
yeah,
so
take
a
look
for
people
who
haven't
looked
you'd
be
great.
Actually
nikita
would
be
great
if
you
could.
B
You
know,
spend
a
few
cycles
on
monday
or
something
looking
just
because
as
the
instrumentation
author,
it
will
probably
end
up
impacting
you
and
the
agent
I
mean.
C
B
Yeah,
I
was
that's
why
it
was
if
you
could
just
kind
of
look
at
the
a
couple
of
the
api
classes,
and
maybe-
and
actually
maybe
the
better
thing
to
do
is
just
look
at
the
change
in
the
semantic,
whatever
the
semantic
attributes
class
is
because
that's
what
will
probably
impact
you
the
most,
so
I
don't
think
it'll
take
too
long
if
you
kind
of
just
make
sure
only
look
at
a
couple
things
rather
than
trying
to
comb
through
the
gigantic
change
set.
B
C
Point
being
that
we
at
splunk
wanted
to
want
to
support
a
aws
lander.
We
we
did
some
preliminary
work
and
it
seems
that
we
don't
want
to
just
say:
okay,
here's
your
lambda
code
just
take
the
whole
java
agent
slap
together
and
let
it
roll
because
that
doesn't
work.
But
so
we
wanted
to
do
something
more
intelligent,
more
smart,
and
we
think
that
for
that-
and
so
we
started
thinking
where
should
we
put
that
code
because
that's
not
instrumentation
per
se,
so
should
we
create
new
repo?
Should
we?
C
What
should
we
do
exactly
so
we
wanted
to
talk
about
that
today,
right
now,
but
but
since
since
then,
anurag
had
created
a
pull
request
in
instrumentation
with
aws
lambda
support,
so
we
are
a
little
bit
skeptical
for
for
his
approach,
but
he
said
that
aws
is
very
interesting
in
making
open
telemetry
support
lambdas.
C
B
Cool
yeah,
I
know
what
I
mean
new
relic's
approach
to
this
when
we,
when
we
did
this,
I
don't
know
a
year
or
a
year
and
a
half
ago,
was
to
create
something
that
was
complete.
I
mean
it
didn't
relate
to
our
java
agent
at
all.
It
was
a
completely
separate
module
that
I
think
used
open,
tracing
apis
and
implemented
like
a
lightweight
lambda
tracer
for
open
tracing.
B
So
I
wonder
whether
there's
some
of
some
some
I
mean
I
don't
know.
Obviously
underog
probably
is
more
in
tune
with
what's
going
on
there,
but
some
sort
of
similar
approach
where
you
can
kind
of
use
a
light,
maybe
a
lightweight
sdk
or
something
like
that
for
tracing-
might
be
an
alternative
approach.
Anyway,.
C
So
yeah
yeah,
so
the
question
that
we
wanted
to
to
ask
today
is:
where
should
we
start
putting
all
that
work.
B
So
yeah
that's
a
good
question:
it's
not
instrumentation!
I
mean
it
could
be.
There
could
be
instrumentation
right.
There
are
there's
aws
stuff
that
happens
in
lambda
that
you
might
want
to
have
instrumentation
on,
but
in
general
yeah.
I
don't
know,
that's
a
that's
a
tricky
one.
I
don't
have
a
good
answer.
It
feels
similar
to
the
spring
like
spring
boot
support,
though,
doesn't
it
kind
of
it's
like
a
like
some
extra,
some
special
stuff
for
a
specific
framework?
B
But
maybe
okay
yeah,
maybe
all
of
that
stuff
needs
it's
kind
of
its
own
repo
to
live
in.
I
don't
know,
but
it
does
the
spring
stuff.
You
use
use
instrumentation
code
or
is
it
kind
of
standalone.
C
Well,
it
uses
what
we
call
manual
instrumentation,
so
it
uses
like
wrappers
or
whatnot,
which
we
use
in
autoimmune
instrumentation
as
well.
So
there
is
some
some
amount
of
shared
code
right
and
so
far
we
prefer
to
have
that
share.
It
called,
although
in
our
report,
because
well
sometimes
we
change
both.
C
B
So
the
next-
I
guess
one
thing
I
didn't
mention:
we
did
release
0.8.0
this
week,
so
that
was
that
last
week
I've
lost
track
of
time.
Anyway,
that's
out
there
and
the
agent
code
got
released
yesterday,
two
day
and
a
half
ago.
Something
like
that.
So
there's
a
now
instrumentation
agent
for
o.8.0
as
well,
and
I
tested.
D
B
And
it
works
yeah.
So
the
next
issue
I
had
was
just
I
there's
an
issue
to
move
trace
flags
into
the
span
context,
and
I
think
carlos
yu
and
bogdan
had
a
little
bit
of
concern
about
just
putting
the
boolean
on
the
span.
Context.
Creation,
rather
than
the
byte
itself
and
honorable
had
a
counter
point
that
the
byte
nature
of
it
is
really
very
specific
to
the
w3c
trace
context
and
not
really
or
to
yeah,
to
w3c
format
and
not
necessarily
a
generic.
D
Yeah,
I
am
open
to
any.
I
I
think
there
are
a
few
alternatives
to
make
that
work.
One
is
that
just
accept
a
boolean
and
then
we
add
our
loans
in
the
future
or
offer
a
trace.
You
know
a
byte
utility
class
for
creating
this
byte,
something
like
that.
I
don't
know
but
yeah.
Otherwise.
It
finally
looks
good
to
me.
B
Yeah
that
that
creation
api
is
the
only
one
that
ends
up
being
tricky.
I've
run
into
that
a
bunch
with
all
these
kind
of
refactorings
around
spain
context
is
that
creation
api
is
kind
of
it's
easy
to
for
it
to
explode
into
kind
of
a
crazy
combinatoric
mess.
D
Yeah,
but
what,
as
I
was
saying,
what
about
creating
a
class
for?
We
can
have
a
class
that
you
know
like
which
just
has
static
methods,
and
then
you
create
this
byte
with
some
parameters
I
mean
at
this
moment
it
would
be
using
only
samples,
but
if
we
add
more,
we
can
just
set
them
through
this
utility
class.
B
B
Yeah,
why
don't
we
do?
Why
don't
we
do
this?
I
mean
this
is
what
I
let
me
here's
my
suggestion.
My
suggestion
is
we
keep
the
boolean
on
the
create
right
now
because
it
is
the
most
common
case
and
then,
if
we
start
like
if
w3c
starts,
adding
a
whole
bunch
of
extra
booleans
to
the
flags
which
my
guess
is
that's
years
out
at
this
point,
we
could.
D
B
Yeah
I'll
put
a
comment
about
that
in
the
pr,
and
hopefully
bogdan
will
get
a
chance
to
to
discuss
to
look
at
it
because
then,
if
we
can
get
that
and
the
keys
in
there,
I
think
that
closes
out
a
major
p1
issue.
Like
all
of
I
think
that
basically
will
solidify
the
api.
B
For
ga,
which
is
good,
that
would
be
a
big
that
would
be
a
big
step
forward.
If
we
get
the
aside
for
baggage
baggage
is
the
only
thing
that's
not
done
yet,
then
right,
we
still
have
to
have
the
baggage
apis,
depending
on
how
those
how
the
spec
turns
out
and
we
need
to
bring
the
propagator.
D
We
used
to
have
a
propagator
for
correlation
context.
Oh.
B
B
D
I
want
to
talk
to
you,
john,
but
maybe
we
can
do
at
that
protocol
yep.
That
sounds
fun.
D
B
E
B
A
B
No
there's
discussion
going
on
with
folks
from
I
think
reactor
from
project
reactor
about
their
context,
but
I'm
pretty
sure
that
requires
java
8.
So
unless
we
can
beat
on
dyna
trades
about
java.
B
D
D
B
E
E
E
B
E
Nichola
nicola
nikita
and
trask
won't
be
happy.
E
I
think
I
do
think
it's
really
interesting
the
difference
in
momentum
between
instrumentation
and
the
core.
I
did.
B
Theories
about
this
I've
had
discussions
with
my
manager
about
this,
and
by
the
way
did
you
you
knew
you
knew
april
leonard
yeah,.
E
Yeah
she's
just
joined
the
the
alumni
slack
so
yeah
she's.
I
forgot.
E
B
B
Everyone
kind
of
was
like
oh
well,
that's
all
working.
We
don't
need
to
put
resources
into
it
and
kind
of
never
just
lost
all
of
the
traction,
because
everyone
thinks
well.
It's
working
java
doesn't
need
any
help.
It's
all
working
great
and
I
keep
on
beating
the
drum,
especially
like
in
the
maintainers
meeting
and
then
like.
We
need
help
like
this
is
not
like.
We
are
not
moving
at
any
kind
of
pace
towards
ga
at
the
moment.
D
What
other
languages
are
in
a
bad
state?
It's
just
that
they
don't
say
that
like
python
is
in
similar
state
and
group
is
a
similar
like
there's
only
math
and
francis,
and
they
are
doing
that
in
the
free
time,
mostly
so,
just
don't
believe
them
like.
I
think
that
we
are
under
staff
everywhere,
mostly
but
yeah.
So
I
know
it's
a
problem,
but
it's
not
only
with
the
java
world.
B
Yeah
javascript:
well,
they
think
the
big
difference
is
that
java
is
the
way
I
think
by
a
lot
they're
going
to
be
the
number
one.
It's
the
biggest
piece
of
the
ecosystem
right.
So
but
I
know
that's
true
in
the
go
like
in
the
golang
repo,
I
talked
to
tyler
all
the
time,
the
other
tyler
tyler
john
and,
like
he's
really
the
only
one
doing
any
work
there
and
he's
having
to
rewrite
all
the
apis
like
I
am
so
I
mean,
I
think
it's
in
a
very
similar
state,
like
you
know,.
E
B
You
agree,
metrics
are
even
worse,
like
I
think.
Tracing
is
well
like.
I
think
that
the
number
of
tracing
solutions
out
there
they
all
look
kind
of
roughly
similar,
and
so
that's
a
lot
easier.
But
metrics
is,
I
mean,
we're
inventing
a
whole
new
metrics
thing
rather
than
piggybacking
on
one
of
the
existing
ones
and.
E
B
And
and
so
they're
just
there's.
D
E
I
would
say
not
much
effort
required.
Okay,
if
it's
doing
something
like.
D
Like
okay
yeah,
so
for
the
record,
you
know
I'm
thinking
about
this
system.
Metrics
still
that
I
have-
which
I
probably
sergey
here
will
retake
that,
and
it
is
just
to
provide
system
metrics
for
the
java
runtime
and
maybe
also
for
the
for
the
system
as
a
whole
and.
E
Difference
between
system
collecting,
you
know
general
health
and
status
metrics
versus
things
like
throughput
and
resp
and
latency
metrics.
So
one
is
collecting
state
from
like
jmx
and
beans.
The
other
is,
you
know,
tracking
metrics
directly
from
spam
data
yeah.
Yes,.
B
E
Fork-
the
code-
I
don't
know
we
didn't,
we
don't
generate
any
metrics
really
on
the
datadog
side
in
the
tracer.
Our
metric
generation
is
done
by
the
agent
except
for
so
so
we
have
two
different
parts.
We
have
the
agent
that
generates
the
metrics
based
off
of
the
traces
and
we
have
jmx
fetch,
which
is
like
a
separate
kind
of
library
that
collects
all
the
help
metrics,
and
so
originally
that
jmx
fetch
was
used
by
the
datadog
agent.
E
It
would
launch
as
a
process
and
connect
to
remote
jvms
and
collect
metrics.
That
way,
so
that's
the
way
that
the
the
traditional
datadog
jvm
integration
worked.
So
we
just
took
that
jmx
fetch
embedded
it
into
the
java
agent
as
a
library
and
run
it
that
way,
but
that
doesn't
necessarily
that
doesn't
really
make
sense
for
open
telemetry.
So
they
kind
of
just
skipped
over
that.
E
Okay,
interesting.
I
do
think
that
it
would
be
beneficial
for
open
telemetry
to
have
like
a
similar
concept
of
something
that
can
collect
open,
telemetry
metrics
from
either
like
a
remote
process
or
internally,
as
a
library
yeah
similar
to
jmx
fetch,
and
it
doesn't
even
have
to
be
directly
used
by
the
sorry.
It
doesn't
have
to
be
tied
directly
to
the
java
agent.
Sure
sure
sure
look
at
it.
B
Being
built
in
a
separate
repo
right
now,
like
the
new
repo
was
created
for
it,
I
don't
remember
what
it
was
called.
B
E
B
B
D
B
E
B
B
E
Tyler,
I
know
you,
we
know
you,
you
like
ruby
a
lot,
but
no,
I
like
groovy
for
testing
okay
and
that's
it.
Okay,
okay,.
B
E
Good,
the
nice,
so
I
I
would
be.
E
With
that,
I
certainly
like
kotlin
better
than
just
standard.
You
know
j
unit,
but
I
do
like
a
lot
of
the
semantics
that
you
get
with
spock
yeah
the
table
like
the
table
based.
B
B
If
we
could
get
that
some
other
way
yeah,
you
know
I
would
totally
be
on
board
we're
gonna
need
java.
Is
it
java
for
not
14?
When
do
we
get
the
big
the
multi-line
strings,
multi-line
strings,
but
that's
not
the
same
john
no,
but
you
could
put
all
that
data
in
a
multi-line
string
and
then
have
a
parser
for
it,
which
is
all
groovy.
Does
that's
all.
That's
all
that.
B
Like
it's
not
just
it's
groovy,
there's
no
compiler
tyler,
it's
all
runtime!
It's
all
interpreter
it
just
parses
that
crap.
When
you
run
it
well,
it's
magic!
Well,
that's
right!
You
could
implement
the
same
magic
with
multi-line
strings.
I
mean
not
me,
I'm
not
going
to
implement
that.
Somebody
can
actually
collin
already
has
multi-line
strings.
Doesn't
it
they
should
be
able
to
do
something.
E
Colin's
got
all
sorts,
it's
like
the
the
play
test
bed
for
all
the
new
java
features.
It
seems
well
it's
better
than
scala,
though
at
least
it's
not
like
you
used
to
be
such
a
big
kotlin
fan
boy.
John.
What
happened?
I
just
happened
to
be
able
to
use
it.
I
mean
I've
been
working
on
the
agent
code.
I've
been
working
on
this
stuff
java,
7.
you're,
not
you're,
not
trying
to
rewrite
everything
in
kotlin,
I'm
shocked.
B
E
B
B
Team
anymore,
so
yeah
anyway,
that's
a
longer
story.
E
It's
definitely
been
popcorn
time
in
the
in
our
alumni,
slack
yeah,
I'm
sure,
I'm
sure
anyway,
yeah
we
don't
need
to
delve.
B
Alrighty,
well,
nothing
certainly
nothing
on
the
record,
that's
being
recorded
and
put
on
youtube
all
right,
carlos
you
and
I
need
to
have
a
little.
You
know
small
chat,
so
kicking
you
out!
Tyler!
Oh
okay,
see
you
soon.
B
D
I
could
say
that
there
is
a
well.
There
are
a
few
concerns.
The
first
one
is
that
he
will
be
less
effective,
because
I
mean
I
know
that
he
has
been
doing
a
lot
of
stuff
in
both
repos
but
being
also
a
maintainer
can
change
the
dynamic,
but
I
guess
we
can.
We
can
see
that
he
can
try
and
see
how
it
feels.
D
Well,
I
guess
my
question
is:
do
you
have
an
alternative?
No
that's
the
thing,
so
I'm
fine
with
that.
So
given
that
fact,
so
I
say
I'm
fine
with
it.
I
just
want
to
let
you
know
a
pair
of
things
that
they
are.
On
top
of
my
mind,
the
first
one
is
that
I
think
I
I
think
the
plan
so
far
is
that
working
on
me
were
back
into
full
action,
or
at
least
some
decent
action
after
ga
or
like
ga,
is
at
a
specification
level.
D
B
Yeah-
and
I
think
that
would
definitely
still
be
the
case,
but
it's
one
of
these
things
like,
for
example,
bogdan,
wanted
to
talk
about
the
the
typed
key
stuff
this
morning,
but
he
didn't
show
up
to
the
meeting.
So
it's
like,
like
it's
really
hard
for
me,
to
make
progress
when
the
like
one
of
the
maintainers
who
says
he
wants
to
have
a
discussion
about
it,
isn't
able
to
do
that
for
whatever
reason.
D
Yeah
yeah
that's
totally
valid,
but
at
least
I
would
like
to
have
a
like
kind
of
warning.
You
know,
or
just
like
a
note,
I
hate
we
plan
to
do
this,
breaking
change.
You
know
so,
of
course,
if
the
maintainer
doesn't
show
up,
then
it's
okay
too
bad.
You
know
we
try
our
best,
but
yeah
I
mean
I
just
don't
want
this
to
be
like
a
free
pass
like
you
guys
changing
the
api.
D
So
the
thing
is
that
I
think
that
probably
there-
and
I
was
talking
with
that
with
andrew-
that
there
are
probably
a
lot
of
designs
that
we
made
in
the
past
and
I'm
afraid
that
they
will
be
redone
because
and
we
didn't
write
anywhere.
You
know
like,
for
example,
the
file
that
and
drag
started
on.
Why
spawn
is
not
close
possible?
That's
a
good
point.
You
know
like
we
took
it
for
granted.
D
We
never
explained
why
and
then,
of
course
like
if
we
have
new
maintainers,
they
may
you
know
change
that,
and
you
know
without
these
previous
notes.
So
that
would
be
my
thing
I
would
say,
and
the
second
thing,
which
is
most
mostly
a
minor
thing,
is
the
fact
that
I
know
that
what
you
want
to
do
like
to
like
to
prototype
things
a
lot
in
your
case.
It
has
been
after
things
that
we
really
needed
with
him.
D
You
know
a
matter
of
style
and
sadly,
for
for
because
of
the
ga
requirements,
I
think
that
we
are
expecting
to
we're
expected
to
be
working
on
specific
items
that
are
ga
not
distracting
items
so
pretty
good
or
for
bad,
no,
no
more
prototypes,
unless
we
really
need
them
and
like,
for
example,
prototypes
for
the
grpc
context,
thing
that
we
will
know,
that's
perfectly
valid,
you
know
or
things
that
you
did
work
for.
You
know
attribute
removing
attributes.
D
Sorry,
like
yeah,
like
the
one
you
need
in
the
past
or
removing
you
know
the
separated
class
for
divide,
for
example,
perfectly
valid
values
that
that's
pretty
much.
What
I
wanted.
B
It
wasn't
something
that
was
really
designed
from
a
you
know:
a
user,
a
user-centric
perspective,
and
so
that's
one
of
the
reasons
why
I've
been
doing
all
these
I'm
working
so
hard
to
try
to
get
all
these
api
changes
done
before
ga
because
after
ga,
obviously
it's
done.
But
I
think
having-
and
I
know
like
the
open
census
apis
and
the
way
google
approaches
it.
B
They're
like
they're,
much
more
concerned
with
performance
rather
than
developer
ergonomics,
and
for
me
I
am
generally
concerned
more
with
developer
ergonomics
than
performance
and
so
having
and
the
chance
to
actually
build
some
something
that
does
both
and
actually
work
through.
These
designs
has
been,
I
think,
is
going
to
be
very
valuable
for
the
long-term
health
of
the
project,
and
I
think
I'm
like
this.
Is
this
we're
basically
at
the
end
of
that,
except
for
context.
B
Like
context
is
the
only
thing
that's
left
at
this
point,
it's
just
and
I
think
that,
if
we
had
had,
if
you
and
bogdan
had
had
more
cycles-
which
I
know
you
don't-
we
probably
could
have
gotten
these
api
changes
done
six
months
ago
and
not
be
worried
about
it
now,
it's
just
everything
has
been
very
slow
because
of
the
lack
of
resources,
so
I
think
we're
getting.
I
think
it's
very
close
if
we
can
get
these
last
couple
over
the
finish
line.
D
Okay,
okay
and
just
to
be
clear
again
you
don't
you,
don't
really
think
we
there's
another
improvement
needed.
I
mean.
B
For
context,
like
everything
else,
I
think
is
fine
metrics,
I'm
not
100
sure
on
yet,
but
I
think
metrics
has
obviously
also
been
pissed
off.
I
know
there's
like
having
starting
to
have
chats
with
the
people
the
micrometer
folks
they're.
Very
they
don't
hang
on.
My
cat
is
gonna.
Try
to
attack
me
the
they're,
like
the
fact
that
we
have
different
instruments
for
doubles
and
longs.
They
think
is
really
stupid
and
they
think
they
think
it's
an
optimization,
that's
not
generally
useful
or
needed.
B
So
that's
one
place
where
I
think
we
might
want
to
still
have
a
discussion
about
whether
there's
really
a
need
in
instrumentation
space
to
distinguish
between
doubles
and
longs
on
our
instruments,
and
I
wanna
I
mean
definitely
now
that
we're
starting
to
have
discussions
with
micrometer.
I
think
we
still
have
an
opportunity
to
talk
about
some
of
that
stuff,
but
that's
that's
all
on
the
metric
side.
Aside
from
that,
like,
I
think
the
apis
are
pretty
solid
aside
from
context,
obviously
make
sense.
B
So,
okay,
I've.
B
B
D
Yeah
and
as
I
said,
I'm
just
a
little
bit
yeah
like
not
concerned,
but
just
like
a
little
bit
of
slightly
in
a
very
small
amount
about
starting
to
change
things
because
of
the
style.
You
know,
I
don't
know
it's
just
maybe
it's
my
bad
experience
when
I
was
in
the
mono
team.
D
I
remember
that
a
long
time
ago,
like
when
maintainers
changed
so
many
dinners,
they
used
to
change
everything
used
to
match
their
personal
style,
and
then
you
lose
history,
and
you
know
how
you
have
a
lot
of
distractions
and
then
you
have
another
maintainer
who
comes
after
six
months
and
then
it's
like
again
like.
No,
please
don't
do
that.
You
know
like
if
it's
not
broken,
don't
fix
it.
You
know
unless
there's
there's
a
reason
like
there's
an
improvement
or
it
needs
to
be
improved
for
the
sake
of
clarity.
In
that
case,
no
problem.
B
Yeah,
no,
I
think
I
understand
the
understand
the
concerns,
but
I
mean
honorable
also
has
a
huge
amount
of
experience
working
in
tracing
like
working
on
sleuth
and
working
on
area
and
other.
So
I
think
his
perspective
having
a
having
a
third
or
fourth
perspective
in
there
is
also,
I
think,
super
valuable,
so
yeah
that
part
is
pretty.
D
B
I
think,
he's
been
really
good
about
making
sure
that
if
we
want
to
change
like
change,
something
that's
not
up
to
spec
like
to
go
into
the
specs
and
actually
work
to
make
sure
that
the
specs
are
correct
and
that
whatever
change
we
make
is
relevant,
and
I
have
one
of
the
things
that
I've
made
sure
I've
done
is
kind
of
defender
of
the
spec
it's
uncomfortable
sometimes,
but
I'm
like
hey
people
come
in
and
like
hey,
let's
make
this
change.
I'm
like
that
seems
like
an
interesting
change,
but
the
spec
says
this.
D
B
Yeah
well,
I've
been,
I
mean
it's
definitely
not
fun,
but
it's
also
a
little
bit
it's
an
easy
out
as
a
maintainer.
It's
like
yeah,
you
can
say
this
sounds
cool,
but
hey
the
spec
says
something
completely
different.
We
really
need
to
if
we
want
to
change
this,
let's
talk
about
it
in
the
spec
with
a
larger
group
and
I'll
definitely
continue
to
continue
to
do
that
and
make
sure
that
every
api
change
or
thing
that's
relevant
to
the
spec.
I
mean
I'm
going
to
continue
to
defend
that.
B
So,
even
if,
even
if
I
don't
agree
with
the
spec,
it's
still,
you
know
it
is
what
it
is.
D
D
Okay,
it's
cool
thanks
carlos
just
yeah.
Let
us
know
how
it
goes.
Hopefully
it
goes
better.
If
it's
too
much
work
to
be
maintainer
of
both
groups,
we
will
see
we
will
see
how
it
goes
yeah
when
there
are
breaking
changes
or
important
changes,
don't
forget
to
poke
bogdan
and
me,
even
though
now
there
will
be
two
active
maintainers,
always.
B
Hey,
I
actually
had
a
couple.
I
had
one
thing
we
have
approvers.
We
have
at
least
one
approver
who
hasn't
even
been
involved
in
the
project
for
a
long
time.
Somebody
from
google-
I
don't
remember
his
name.
D
B
We
should
probably
have
we
should
probably
prune
those
approvers
down
to
people
who
are
actually
working
on
the
project.
D
You're
thinking
about
yang
song,
yes
yeah,
we
should
yeah,
he
actually
used
to
help
us,
but
he
changed
teams
within
google,
so
yeah
we
lost
him,
so
I
may
put
in
a
pr
to
remove
him
as
a
yeah.
We
should
do
that
in
in
the
entire
organization
like,
for
example,
isabelle
left
like
except
a
few
months
ago,
she's
seen
an
approver,
so
she's
not
involved
she's,
not
interested
so
yeah.
We
should
just
remove.
B
D
B
D
Him
because
when
he
we
have
needed
something
jager
related,
he
he
helps
yeah,
so
at
least
for
for
ga
and
a
little
bit
after
once
we
don't
require
to
support
jagger.
Then
we
can
forget
about
about
the
idea
of
needing
him.
So
we
can
ask
him
whether
he's
still
interested
or
not
anymore,.
B
So
do
you
think,
with
with
young
song,
should
I
reach
out,
or
should
I
we
just
put
in
a
pr
to
remove
him?
What
do
you
think.