►
From YouTube: 2020-07-16 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
A
A
A
A
A
A
I
don't
know
if
we
wanted
to
structure
this
agenda
a
little
differently.
I'm
gonna
go
over
specific
issues,
mostly
John
and
Emmanuelle
looks
like
you're
on
the
call.
I
don't
know
if
you
have
the
idea
of
maybe
timewise
how
long
this
would
take
or
if
you
didn't
want
to
sit
through
the
rest
of
that
it.
B
Really
depends
on
like
how
much
we
want
to
talk
about
it.
If
you
want
an
overview
and
follow
up
with
a
separate
meeting
that
could
be
like
you
know,
maybe
like
a
twenty
minutes
or
thirty
minute
would
be
good
enough.
Otherwise
it
may
take
a
while.
So
maybe
we
should
go
through
your
agenda
and
then,
if
you
know,
if
there's
like
30
minute
or
something
left,
we
can
switch
depends
on
how
we
wanna
do
this.
A
B
A
Up
the
actual
open
poetry
package-
currently
it's
Redis
package
started
to
implement
things
with
their
instrumentation
and
importing
the
until
Monsieur
package
itself
with
its
api's,
which
is
used
for
the
instrumentation,
and
it
doesn't
actually
require
any
of
that's
the
case.
But
since
it's
all
the
same
package
imports
the
SDK
as
well
eating
things
like
heard
above
arm.
Sorry,
GRDC,
library's,
another
big
library
is
er
being
included
in
the
binaries
that
are
being
built
from
this.
So
the
request
was
split
up
the
SDK
and
the
API
package,
which
seemed
reasonable
to
me.
A
A
I
think
was
the
question,
and
so,
based
on
that,
I
was
looking
at
our
trace
context,
implementation
again,
and
it
was
reminding
me
of
the
fact
that
we
had
this
open
issue
to
depend
on
external
w3c
propagation
library
and
when
this
I
think
more
full-featured
in
itself,
I
think
that's,
probably
something
we
should
prioritize
in
the
near
future.
Its
newest
thing
also,
we
are
doing
a
lot
of
what
the
specification
asks.
A
People
who
are
propagating
the
trace
date
to
do
or
any
sort
of
mutations
of
the
trace
date
to
do
and
there's
no
validation
on
it,
which
is
probably
not
a
great
idea.
I
haven't
looked
at
the
spec
in
a
while
for
the
w3c,
but
they
don't
think
that
that's
actually
fitting
the
specification.
So
we
should
probably
try
to
reprioritize
that
I
know
that
Josh
would
open.
This
is
probably
still
in
favor.
I
know
that
there
is
a
the
external
library
was
kind
of
in
a
weird
state.
C
A
That
was
the
next
thing.
I
noticed
was
that
it
only
it
doesn't
have
the
correlation
context
for
what's
being
called
baggage
now
from
w3c,
so
we
should
probably
it
might
be.
It
might
be
a
great
opportunity
for
us
to
just
kind
of
unify
on
that.
It
does
seem
like
it'd,
be
really
nice
if
we
can
put
it
in
an
external
repository,
but
that
has
had
zero
feedback
and
I.
Don't
think
that's
gonna
happen
so
day
is
just
worth
putting
in
our
own
package.
A
A
Otherwise,
I'll
probably
try
to
tackle
this
next
week,
because
the
idea,
then
the
last
thing
that
I
think
was
on
my
agenda-
was
Connor
figures
on
the
call
recognize
the
fact
that
we
aren't
actually
implementing
the
specification
has
written
for
the
spandex
border.
Currently
so
I
started
to
take
a
look
at
this
I
put
a
diff
of
a
proposal
for
the
rework
of
the
interface
here,
condensing
used
to
be
a
span.
Batcher
and
span
sinker
into
a
single
exporter
a
little
bit
more
comments
here.
A
Consolidate
some
efforts,
but
the
idea
is
I
was
gonna.
Call
it
a
exporter
instead
of
a
span
exporter,
as
the
specification
calls
it
not
normatively
just
to
match
our
existing
metrics
exporter,
which
I
think
is
a
better
name
anyways
and
then
one
of
the
other
things
that
I
was
kind
of
interested
in
people's
thoughts
on
where
the
file
or
function
signature
passing
at
context.
I
think
it'd
be
really
useful.
A
If
you
wanted
to
do
any
sort
of
timeouts
or
cancellations,
but
I
can
also
see
how
people
might
just
think
about
a
calling
to
shut
down
and
then
just
an
inking
process
itself,
because
that's
kind
of
what
the
halt
is.
It
is
coming
up
so
I'm
on
the
fence
as
to
whether
or
not
to
include
the
context
there.
A
But
if
you
have
really
strong
opinions,
I'm
open
to
hearing
them
I
was
not
going
to
include
any
sort
of
error
response
from
this,
because
I
don't
think
that
the
thing
that's
calling
this
is
going
to
do
anything
with
the
air,
so
I,
just
yeah
I'd
love
to
get
some
feedback.
If
you
have
any
feedback
on
that.
C
A
Small
enough,
but
a
big
enough
change
to
implement
the
proto
mm.
She
wrote
herself
in
our
library
and
building
our
repository
and
maybe
just
keep
some
form
in
cadence
I
tried
to
get
a
release
out
tomorrow,
I'm
guessing
it
was
kind
of
a
idea
unless
anybody
had
something
in
the
works
that
they
were.
You
know
quite
large.
A
B
Thanks
a
lot
for
your
work,
we've
been
actually
like
looking
at
the
libraries
once
a
while
so
like
our
feedback
might
might
not
be
super
comprehensive,
but
we
think,
like
it's
nice,
probably
to
start
at
some
point.
I
actually
am
going
to
share
a
document
with
you.
After
this
meeting
I
created
this
talk
as
a
personal
drop
internally,
so
I'm
very
sorry,
I'm
going
to
share
it
right
now,
but
I
can't
put
the
link
I'll
just
move
things
out
over
No.
E
B
But
we
also
realize
that
they're,
like
some
spec
changes,
you
know
there's
a
lot
of
things.
This
project
is
always
a
moving
target,
so
it's
very
hard
to
you
know
follow
up
with
all
the
concerns,
so
please
feel
free
to.
You
know
just
interrupt
and
say
something
if
I'm
saying
something
outrageous,
so
we
just
generally
wanted
to
split
our
feedback
in
multiple
categories.
We
think
that
you
know
there
are
some
structural
things
that
we
can
improve
and
then
they're,
like
some
package,
specific
things
that
we
can
improve.
B
The
first
I
think
that
I
actually
want
to
give
some
context
about
openness,
and
maybe
I
can
talk
a
little
bit
about
open
census
go
and
what
we
learned
from
that
experiment.
We
learned
that,
like
instrumentation
space
is
just
really
complicated
and
those
are
very
tiny
language.
You
know
it's
a
very
small
language.
B
People
are
its
users,
are
very
open
ADA
to
do
things
really
like
quickly,
simply
and
in
a
more
explicit
way,
and
even
though
the
languages
are
just
very
small,
like
we
I
think
there's
a
lot
of
like
oral
tradition
about
these
things
like
it's
just
sometimes
hard
to
find.
Really
good
guidance
about
things
and
given
the
space
instrumentation
space
is
just
way
too
complicated.
B
Already
it's
sometimes
hard
to
like
represent
some
of
the
concepts
you
were
well
in
go
or
it's
always
like
some
challenge
in
terms
of
an
API
designed
to
get
things
right,
because
it's
already
inherently
a
complicated
field.
So
talk
about
the
structural
issues
are
by
the
way
immanuel.
Are
you
here,
yep?
D
Man,
my
name
is
Emmanuel
a
decade.
I
worked
with
Jana
and
Morgan
and
open
sense
does
pretty
much
day
one.
We
worked
in
different
aspects
of
the
project:
specifications,
implementation,
the
agent
many
other
things,
and
on
top
of
that,
Jana
and
I
also
worked
and
the
goal
programming
language
itself.
So
we
work
in
the
core
of
it
as
well.
D
So
and
we've
collected
lots
of
feedback,
we've
been
through
numerous,
we
use
go
code,
api's
and
you
know,
if
you
don't
know,
Jana
again
and
pretty
much
one
of
the
best
API
engineers
you
have
a
nice
ship,
I've,
no
time
no
I'm,
not
flattering
her
record,
but
I
can
show
so
Yanis
work
and
I've
worked
beginning
time.
We
reviewed
lots
of
API,
so
the
feedback
that
we're
presenting
is
just
coming
from
the
perspective.
We
worked
an
open,
open
census,
so
we're
familiar.
We
understand
how
complex
things
are,
and
we
also.
D
B
Yeah
so
yeah,
that's
that's
really
a
good
thing
like
keep
things
I'll
just
start
with
the
main
going
by
issues
one
by
one.
As
I
said
like
there
are
two
sections.
The
first
one
is
the
structural,
the
things
that
we
think
that
we
can
improve.
So
one
of
the
things
about
go
is
like
just
like
a
lot
of
times.
People
think
like
the
top
level.
If
no
packages
in
go
are
extraordinarily
important
as
you
go
deep
in
it's
more
of
like
about
like
implementation,
details
and
so
on.
B
You
know,
you
wouldn't
split
the
header
files,
but
when
the
implementation
like
this
equals
or
like
a
ninja,
why
you
would
have
like
some
more
of
like
a
components,
representation
as
an
interface
and
then
like
you,
would
inject
the
actual
implementation
as
a
dependency.
So,
even
though
we
don't
have
this,
and
just
because
of
this
particular
reason,
people
believe
that,
like
maybe
API
package,
is
not
the
actual
interface,
they
should
be
working
on.
So
when
I
look
at
the
go
doc,
I'll
present
it
here.
B
My
browser
works,
but
people
generally,
like
generally
consider,
is
like
this
is
like
top
level
packages,
and
you
know
under
API
like
since
everything's
under
API.
It
kind
of
like
doesn't
really
give
people
enough
signals
that
they
are
the
entry
point
packages,
but
that's
like
one
of
the
structural
issues
that
we
would
think
that
there
is
so
if
it
was
a
top-level
liked
race
or
like
a
matrix
package,
it
would
be
more
explicit
and
also
you
know
in
the
description.
B
We
don't
really
necessarily
say
that
this
is
most
of
the
time
that,
but
the
users
aren't
going
to
be
engaging.
You
can
also
like
leave
some
documentation
around
this
saying
that
you
know
most
of
the
time
you
as
a
user
and
use
they
are
going
to
engage
in,
like
that.
The
other
structural
thing
that
we
realize
that,
since
we
do,
you
know
there
is
a
split
between
API
and
SDK.
B
The
way
that
it's
implemented
in
go
is
very
similar
to
how
we
would
implement
it
in
Java,
but
basically
there
are
api
packages
that
gives
you
a
lot
of
like
abstract
types
or
interfaces,
but
Ingle
like
we
generally
don't
Ritz
it
like.
We
generally
don't
start
with
interfaces,
even
if
we,
you
know,
switch
infer
to
a
different
implementation.
It's
usually
like
there's
a
concrete
type
and
people
still
write
against
it,
and
you
know
we
would
just
it
it
the
compile
time
just
infer
to
an
implementation.
B
Some
examples
of
this
is
like
the
sequel
package,
for
example.
So,
like
we
don't
give
people
a
lot
of
interfaces
because
you
know
ingo
interfaces
are
implicit,
so
you
don't
have
to
go
in
like
explicitly
ever
implement
an
interface,
so
the
provided
package
providers
doesn't
have
to
provide
interfaces
even
if
they
want.
You
know
to
the
user
to
be
able
to
switch
back
and
forth
the
does
that
make
sense.
So
far,
a.
B
Can
have
like
separation
of
concerns
without
human
interfaces,
I'm
not
sure
I'm,
not
quite
sure
if
this
is
a
follow
up.
This
is
something
they
should
follow
here,
but
in
go
like
riding
against
interfaces
is
like
less
of
a
thing,
because
you
know
you
as
an
implementer
can
actually
like
implement
the
same
thing
with
us.
I
mean
III,
don't
maybe
I
shouldn't
you
switch
to
a
different
topic,
but
when
we
are
trying
to
see
is
like
you
can
yeah
sorry.
B
C
If
I
understood
your
concern,
so
in
the
metrics
API
we
have
instrument
types
and
they
are
struct
and
they
do
present
an
interface
that
is
just
functions
on
the
astruc,
underneath
that
struct
is
a
single
interface
that
is
meant
for
the
implementer
to
use
to
totally
change
what
their
that
DK
does.
But
that's
an
implementation
facing
API
interface,
which
was
designed
with
the
implantation
in
minot,
with
the
user
in
mind,
I,
wonder
if
that's
an
example
of
what
you're,
after
what
you're
suggesting
that.
B
C
The
provider
may
fall
into
that
category
is
what
you're
saying
I
I
think
I
might
agree,
I'm,
not
sure
what
the
benefit
of
taking
away
the
interface
is
at
the
moment,
but
it
might
be
that
there's
some
common
implementation
machinery
that
helps
all
users
that
we
means
that
would
have
a
smaller
UK
I.
Think
that's
where
you're
going
after
yeah.
B
Also,
like
I,
it
also
depends
like.
Do
you
really
arbitrarily
care
about
extending
those
abstract
types
right
like
do
you
want
people
to
come
up
with
their
own
spend
types,
and
so
on
is
another
thing,
so
once
you
I
think
provide
an
interface,
it
changes
people's
opinion
about
like
how
extendable
these
things
are,
but
it's
also
like
in
physically.
You
are
actually
like.
B
Maybe
given
some
more
tips
of
the
user
to
extend
things,
one
example
is
in
go
if
I
see
an
interface,
I
sometimes
feel
like
okay,
but
I
provided
custom
increment
people
like
wrap
things,
for
example,
as
soon
as
they
see
an
interface,
they
might
be
like
causing
that
type
of
like
users,
but
this
this
might
be
a
separate
topic.
I
think
this.
This
particular
item
that
we're
discussing
is
a
really
huge
thing.
D
B
C
Was
an
issue
raised
months
and
months
ago?
I
think
it
was
195
asking
for
a
very
similar
request,
reduce
the
surface
area,
at
least
the
number
of
packages
at
the
time
I,
remember
being
involved
in
that
conversation
and
and
I
think
the
there
was
there
was.
One
argument
that
came
up
is
that
the
use
of
these
package
names
and
go
is
like
part
of
the
name
of
the
symbol,
and
so
it
can
be
part
of
the
readability
story.
C
B
C
B
C
Boys
are
played,
and
that's
definitely
a
problem,
but
it
has
to
do
with
only
what's
like
the
main
function,
so
I
think
most
of
our
effort.
You
know
a
photometry
has
been
to
study
the
API.
That's
the
users
are
gonna
use
instruments.
Their
code
I
agree
that
this
means
that
is
really
actually
very
bad.
One
of
the
things
that
opens
when
it's
relaxed
is
a
concept
that
unifies
the
SDKs
behind
a
single
thing
like
there's,
no
name
that
I
have
for
this
thing.
C
That
is
the
SDK
there's
two
different
things,
and
that's
why
you
actually
have
a
15
line
code
snippet
for
one
and
the
other
and
there's
not
really
any
sort
of
standard
pattern.
Saying
I
would
like
an
SDK
with
this
meteor
provider
and
this
trace
provider
and
all
these
other
defaults
that
are
set.
You
know
step
that
way,
so
I
sort
of
agree,
but
part
of
it
is
the
spec
says
we
don't
have
anything
named
SDK.
B
C
B
And
sizes,
we
also
do
very
verbose.
You
know
you
require
like
20
lines
or
whatever,
and
it's
been
very
difficult
for
people,
especially
like
if
they've
seen
a
problem
in
production
they
want
to
like
rebuild
and
push
like
that.
Would
it
was
a
major
problem
for
them
to
get
things
right.
So
I
think
it'd
probably
be
very
helpful.
If
you
know
there's
some
work
to
just
kind
of
make
things
easier.
C
There
have
been
requests
to
have
like
an
automatically
configurable
like
configure
an
SDK
automatically
and
but
unfortunately
that
doesn't
seem
like
there's
a
mechanism
and
go
really
this
quest
for
that
other
than
like
the
plug-in
package,
which
I
know
is
not
functional
and
on
certain
platforms
so
I.
So
it's
left
us
with
this
like
and
manual
initialization
problem.
It
doesn't
mean
we
need
a
15
ssin
though
I
I
totally
agree
to
that.
Hey.
D
C
And
could
that
could
be
a
standard,
but
I
think
for
the
actual,
like
tracer
itself
is
that's
where
it
becomes
hard
and
you
sort
of
want
to
say.
I
haven't
I
have
an
artifact
which
might
be
like
in
other
languages
like
a
shared
object,
or
you
know
some
distribution
that
I
unload,
which
is
my
SDK.
There
could
be
various
different
implementations
in
theory.
C
D
C
For
example,
I've
definitely
experimented
with
one
proposal
that
I
think
was
rejected
a
long
time
ago,
where
every
package
that
is
something
you
might
install,
has
a
sub
package
name
in
it,
and
then
you
just
underscore
something
package
flashing.
It
they
automatically
initialize
this
as
an
approach
that
it.
B
Also
became
like
a
little
bit
problematic
because
you
know
it's
just
like
it
does
a
lot
bunch
of
things
for
side-effect,
so
the
community
has
been
slightly
moving
towards
from
that
model.
Also,
you
know
people
are
allergic
to
the
local
state,
even
in
this
case
it's
just
hard
to
avoid
all
of
your
mistake,
so
people
have
been
moving
away
from
that
as
well,
because
it's
just
an
aside
you're
relying
on
side
effects.
A
A
B
Registers
the
driver
as
if
the
package
was
being
initialized
and
a
long
time,
so
what
the
package
driver
package
does
is
sequel
package
allows
different
drivers
to
be
registered
and
it
relies
on
the
register
drivers
for
implementation.
So
there's
this
init
function
and
go
that
allows
you
to
do
things
when
a
package
is
being
initialized
in
runtime.
B
If
I,
if
I'm
a
my
sequel,
for
example,
driver
I
can
go
in
register
myself
as
the
implementation
and
when
the
sequel
package
users
using
they're,
relying
on
that
library
implementation,
that's
the
model
that
the
sequel
package
uses,
but
that's
also
not
really
a
really
favorite
type
of
thing
to
do
this
nowadays,
because
a
lot
of
people
think
that
it's
nice
to
be
explicit-
and
you
know,
make
the
user
in
or
to
package
and
set
some,
you
know
implementation.
Would
you
just
go
online
and
so
on?
B
A
C
Seems
like
there
might
be
an
additional
requirement
that
the
user
still
makes
an
initialization
call.
So
I
may
have
all
my
dependencies
as
underscores
and
they
may
register
themselves
in
some
place.
But
there's
still
a
moment
where
I
say
at
this
point,
I
will
tell
you
all
of
my
dependencies
have
been
registered.
Now.
Please
initialize
yourself,
because
yeah
you
can't
just
like
automatically
start
initializing
the
SDK
when
it
when
it
itself
is
initialize.
Is
you
don't
have
any
way
to
ensure
that
the
exporter
husband
isn't
initialized
at
that
point?
A
And
and
so
kind
of
like
following
on
that,
it
seems
I,
love
suggestions
on
this
one,
because
I
I
hear
the
complaint
of
having
Global's
is
a
problem
for
people.
But
it's
also
like
it's
a
really
hard
problem
to
solve,
because
if
you
have
that
need
explicit
initialization
and
then
you
have
a
race
condition
where
you
have
instrumentation.
Are
you
sending
you
telemetry
prior
to
you
doing
the
initialization
like
that?
It
seems
like
a
problem?
I
I,
don't
know
if
that's
included
in
this
Hey.
A
Yeah,
imagine
like
you
have
some
sort
of
main
function
in
or
maybe
even
you
have
a
certain
all
instrumentation
right.
That
instrumentation
is
waiting
for
a
an
SDK
to
be
registered
in
a
proper
export
which
could
be
registered.
But
it's
not
it's
not
waiting
for
it
to
send
information
to
the
actual
instrumentation
it
just
it
loads
it
doesn't.
It
doesn't
know
if
anything's
actually
been
registered
and
since
it
loaded
it
and
it's
already
set
up
its
own
internal
library
structure,
it
starts
sending
telemetry
down
these
pipelines
where
it
starts.
A
D
A
B
I
think
one
thing
I
want
to
say,
like
number
of
different
concepts
that
people
need
to
deal
with
is
independent,
then
how
they
inject
the
SDK
right.
So
actually
they
are
two
different
things
that
we're
discussing,
because
Emmanuel's
actual
point
was
more
of
like.
Oh,
there
are
too
many
there's
like
components
that
they
need
to
deal
and
we
can
do
something
about
it
by
providing
some
opening,
like
helpers,
to
kind
of
like
set
the
right
SDK
and
the
user
can
just
call
it
in
the
beginning
of
main.
B
C
In
most
cases,
it's
like
I
have
an
environment
variable
or
a
file
on
the
mo
file,
or
something
that's
going
to
tell
you
what
we
need,
but
you're
going
to
need
to
figure
out
like
I'm,
going
to
use
a
Jaeger
exporter.
So
I've
got
one
of
those
underscore
dependencies
on
Jaeger,
so
the
configurable
SDK
can
find
it.
C
Otherwise
it
won't
be
even
linked
into
your
code
and
I'm,
not
sure
that
I
think
that's
where
we
should
be
registering
these,
but
hopefully
it's
just
a
configurable
SDK,
not
I,
think
that's
what
users
actually
want,
not
a
in
most
cases,
an
API
for
this
opinionated
startup,
or
something
like
that.
I
wanted
to
ask.
C
If
both
of
you
were
familiar
with
our
solution
that
we
came
up
with
for
especially
the
metrics
API,
this
global
package
works
around
a
problem
which
I
wrote
no
except
for
a
long
time
ago,
basically
saying
because
we
can't
control
the
order
of
startup
and
because
of
autonomous
tree
sort
of
spec
says
there
will
be
a
global
implementation.
We
need
to
be
supporting
the
case
where
a
user
construction
metric
instruments
before
using
the
global
instance
of
the
global
metric
implementation
before
the
SDK
is
actually
registered
and
it's
awful
code.
C
But
it's
sort
of
the
only
solution
that
we
came
up
with,
where
you've
got
to
defer
everything
and
then
have
this
sort
of
synchronized
check.
Am
I
registered
yet
okay
now
I'm
gonna
do
the
right
thing
as
opposed
to
do
no
doing
no
up.
I,
don't
love
it,
but
it's
because
of
the
dependency
injection
problem
and
the
only
other
solution.
I
was
aware
of
was
again
a
plug-in
based
solution
which
I
think
people
Nana.
B
B
D
A
B
D
D
Secondly,
there
doesn't
seem
to
be
a
definition
for
what
you
know:
how
to
create
an
export
like
there
isn't
a
concrete
definition
of
hey.
This
is
this
is
a
metrics
exponent
is
a
trace
exporting
so
and
that
that,
on
its
own
Stein's
adoption,
because
what
we're
doing
as
the
core
team
is
we
develop,
we
develop
the
infrastructure
that
then
companies
will
go
separately
and
implement,
against
all
say,
we're
implementing
an
exporter.
We
follow
this
definition,
so
this
is
one
of
the
things
that
were
able
to
bootstrap
lots
of
support
for
open
census.
D
Well,
we
just
made
a
clear
definition.
We
showed
people,
this
is
what
it
looks
like
I
know
in
the
standard
library,
there's
a
standard
output
trace
and
metrics
exporter,
but
you
know
when
you
open
them
to
take
a
look,
there's
so
much
stuff.
You
have
to
dig
through
that.
You
question
like
how
do
I
make
my
own
I,
don't
if
that
makes
sense,.
C
Yeah
it
does
in
the
metrics
in
the
metrics
world
I.
Think
maybe
part
of
the
source
of
confusion
would
be
that
the
sentence,
no
consensus
model
for
metrics
was
very
close
to
the
Prometheus
model
and
we've
expanded
the
source
scope
a
little
bit
to
cover
the
staffs
deep
type
of
use
case,
and
so
there
there
is
quite
a
lot
more
configurability
there.
It
doesn't.
C
D
It
would
be
you've
been
nice
to
have
the
kind
of
thing
that
in
fact,
not
change
that
you
mentioned
it
takes
out.
You
know
it
takes
out
the
burden.
Some
like
I
give
an
example.
There
of
you
know
it's
non
taking
in
July
2016.
They
just
launched
an
app
and
all
of
a
sudden.
They
receive
what
10
times
is
traffic.
They
anticipated.
D
If,
if
you
are
the
city
of
Niantic
and
you've
assembled
your
engineered
lady
meeting
you're
like
oh,
we
need
to
fix.
What's
going
on,
you
have
a
fire,
and
you
say:
ok,
let's
instrument
stuff
and
all
of
a
sudden
instrumenting.
You
know
about
push
versus
cool.
What
are
the
subtle
differences
and
all
that
become
so
difficult
if,
like
with
that,
one
line,
change
that
you
mentioned
I
mean
we
don't
need
too
much
magic,
but
something
that
abstracts
and
details
just
takes
the
burden
off
and.
C
B
The
next
three
things
it's
more
about
like
namings,
one
thing
that
we
were
looking
at:
it's
like
there
are
some
like
names
of
packages
like
if
you
know
KP
global
standard
that
overlaps
with
a
lot
of
like
other
packages
and
I
was
like
importing
some
of
them.
It
was
kind
of
like
struggle.
I
was
wondering
like
hey.
Is
it
better
to
make
critics
all
the
open
telemetry
packages
with
one
thing
like
hotel,
KP,
or
is
it
too
verbose,
or
you
know
what
aren't
different
options
we
have
I
came
to
make
them
like
more
explicit.
B
Basically,
except
I
mean.
Can
we
make
them
more
standing
out
also
from
a
readability
perspective,
cavies
everywhere
and
they're,
just
really
a
huge
struggle?
And
if
this
fermentation
is
also
going
to
be
everywhere,
you
know
so
people
will
be
already
have
some
cable
package
in
the
context
that
they
want.
It
is
really.
D
C
Yeah
I
notice
that
when
that
change
was
made,
it
was
actually
an
improvement
on
the
where
we
were
before
so
sort
of
like
my
ceiling
changed
to
approve,
but
the
value
directory
doesn't
need
to
be
there
mostly
because
users
almost
never
directly
name
that
type
but
I'm,
not
sure
exactly
why
that
was
done.
The
way
it
was
done.
Yeah.
A
C
They
were
in
the
same
package,
originally
I.
Think
that
was
done
very
personally,
but
actually
I
just
wanted
to
high-level
kV
is
not
great.
It
might
be
better
than
we
eliminated
the
core
package,
which
would
have
been
even
worse
and
according
to
this
analysis,
when
we
introduced
kV
and
it
sort
of
feels
like
better
just
to
say,
kV
key
value,
and
so
there
had
been
a
package
named
key.
So
it's
key
that
value.
That
was
not
even
I
thought,
but
but
but
it
was
also
missing
cuz.
C
B
Another
thing
is
like
the
testing
package
names
again
like
these
are
like,
unlike
by
chance,
but
you
know
we're
looking
from
the
perspective
external
user,
you
know
like
we
can
make
sure
that
everything
is
following
one
consistent
naming
pattern.
There
is,
for
example,
test
harness,
which
is
I
realize
that
collector
also
uses
this
may
be.
It
actually
has
a
significance,
but
you
know
them
better
is
like
test
arrays
and
then
there's
exporters
metric
test.
We
generally
like
to
you
know,
name
things
in
go
such
as
like.
B
B
The
other
name
mean
consistency
was
about
dislike
cold
bags
and,
like
hook
functions.
These
are
very
similar
things,
but
it
almost
looks
like
they
are
exclusive
name
differently.
So
you
know
I,
as
a
user,
don't
know
a
lot
of
context
about
Oakland,
telemeter
and
I.
Imagine
all
of
these
different
things,
because
you
know
that's
what
users
it
is
in
when
they
see
they
see
different
headers
and
different
usages,
so
I
wonder
like
hey.
Is
there
a
way
to
also
like
have
some
consistency?
B
B
This
is
this
is
like
the
gist
stuff.
Like
the
you
know,
some
of
the
few
things
that
you
know,
sorry
that
we
haven't
been
extraordinary
comprehensive,
but
you
know
in
terms
of
like
overall
structural
things,
it's
more
like
you
know,
consistency
issues,
there's
too
much
boilerplates.
You
can
improve
it.
Some
of
these
things.
It
will
be
super
nice,
and
then
we
tried
to
like
put
some
more
feedback
in
the
package
to
specific
issues,
and
these
are
I'm
not
sure.
B
If
we
have
times
like
go
over
any
of
these
things,
one
by
one,
some
of
them
are
again
about
you
know,
naming
some
of
them
are
about
like
usability.
Some
of
them
are
like
the
API
style.
Some
of
them
are
is
like
this
v3
propagator,
for
example,
in
the
epic.
Is
we
didn't
understand
why
this
one
was
about
the
open
census
we've
made.
This
mistake.
B
I
think
this
was
I
push
for
this
idea
that
we
should
both
have
like
start
function
and
you
know
convey
types,
but
now
it's
like
you
know,
what's
per
user,
what
is
the
actual
type
that
I
should
be
engaging?
The
put
some
you
know
additional
stuff
like
the
things
is
this
so
and
then
you
know
there
are
some
other
naming
related
suggestions
we
put
here.
We
didn't
take
too
much
of
the
metric
package
because
we
think
that
it's
you
know
it
has
a
lot
like
more
to
do
so.
B
C
C
Sorry,
we
don't
have
a
lot
planned
changes,
though
then
study
is
like
a
sort
of
up-to-the-minute
implementation
of
the
hotel,
metrics
spec.
So
any
changes
recommended
that
you
I
was
recommended,
be
very
appreciated.
I
didn't
have
any
planned
work
to
change
that.
Okay,
all
right,
I'm!
Sorry
enough!
Just.
A
To
kind
of
come
in
on
what
Josh
is
saying
like
it's
also,
there
are
some
ABC
convention.
Is
there
something
that
we
identified,
that
are
better
I?
Think
in
the
metrics
package
that
we're
kind
of
maybe
even
back
wording
a
lot
of
the
things
I
think
like
the
wrapping
implementation
stuff
we
were
talking
about
before
is
implemented
in
the
metrics
package,
you're
realizing
it
may
be
better
to
be.
B
B
Okay,
so
I
mean
there's
I'm,
not
sure
if
you
should
go
through
all
of
these
items.
I
think
one
thing
that
we
can
talk
about
is
like
how
you
know
we
can
conclude
like
or
how
you
know.
What
is
the
current
state
of
things?
Is
it
possible
to
very
anything
eyes
right,
like
what
is
what's
going
to
be
the
right
strategy
right
now,
if
we.
C
C
Some
confusion
like
at
the
top
of
the
screen
right
now,
I'm
looking
at
API
label
that
was
actually
just
recently
because
we
had
common
implementation
between
what
was
called
a
resource
and
I
was
called
a
metric
label
and-
and
it's
like
almost
identical
to
what's
called
span
attribute
in
hotel,
but
hotel
has
got
these
confusingly
related
similar
concepts
at
the
at
the
level
of
specification.
That's
leaving
us
with
some
sort
of
lack
of
clarity
in
the
actual
implementation.
C
So
actually
the
user
doesn't
care
about
API
label,
but
the
SDK,
the
API
implementation
resource
and
the
API
implementation
of
metric
label
need
it
to
be
the
API
package.
So
it's
sort
of
a
dependency
that
users
don't
really
need.
I
agree
with
a
to
me
that
sort
of
means
it
shouldn't
be
at
the
top
level,
but
that
was
a
pretty
key
important
aspect
of
the
performance
story
for
metric.
That
code.
B
C
That
seems
like
a
reasonable
idea.
However,
if
we
it
sounds
like
there's
at
the
beginning
of
the
meeting
Tyler
mentioned
this
request
to
split
the
SDK
and
API
packages.
If
we
done
that,
I
think
it
means
it's
impossible
for
the
FDA
okay
to
use
these
things
that
are
internal
and
it
is
at
the
moment
this
is,
unfortunately
a
part
of
HL.
That's
a
problem,
I
think
is
that
we
couldn't
get
resources
into
the
specifications
of
the
API.
That
was
a
concept
that
specified
only
at
the
SDK
level.
C
B
B
So
whatever
my
internal
is
like
in
the
internal
packages,
an
NGO
is,
if
you
have
an
internal
package
in
internal
directory
and
only
be
imported
by
the
package,
is
in
the
same
module.
So
it's
not
a
user's
external
cannot
import
that
in
like
for
internal
pages
with
normal,
don't
care
about
the
API
is
because
we
can
break
them,
because
you
know
third
party
users
will
never
be
able
to
import
those
there's
just
like
usable
to
put
those
type
of
stuff
to
the
internal
directory.
I
can
see
yeah.
C
A
A
D
B
So
so,
how
absolutely
work
on
this,
like
one
thing,
that
we
can
do
something
we're
going
to
share
the
dog?
What
was
the
best
way?
Do
you
have
any
been
into
it
to
work
on
this
or
you
know,
is
possible
to
you
know
work
on
the
AP
as
it
is
for
them.
We
don't
have
much
contact
so
they're
a
lot
on
here.
I.
A
Think
that
it'd
be
really
I
think
we
should
definitely
try
to
put
some
bandwidth
into
this
sooner
than
later.
Given
the
timelines
for
cheating,
piece,
libraries
I
think
that's
a
really
important
thing,
so
I
think
I
think
we
should
probably
get
after
it.
The
approach
I'd
love
to
get
a
good
cohesion
on
like
what
we
want
to
thank
for
the
restructuring
of
the
overall
packages,
especially
with
this
recent
user
story,
where
they
were
asking
for
a
separation
of
the
SDK,
an
API.
A
If
we
wanted
to
move
the
API
packages
in
a
particular
way
to
make
them
more
visible
or
more
accessible,
make
the
Marder
go
specific
I'd
like
to
get
that
kind
of
like
structurally
addressed,
and
they
kind
of
do
then
just
work
through
the
rest
of
these
items
and
making
issues
for
them
to
investigate
to
break
up
the
work.
I.
A
B
Thing
that
emmanuel
suggested
was
maybe
it
might
be
useful
to
start
with
the
prototype
somewhere
to
demonstrate
some
of
the
things
like
how
they
may
be
so
right
now
like,
even
if
we
agree,
you
know
they're
all
of
like
things
that
we
want
to
decide
on
like
it
in
terms
of
names
in
terms
of
how
it
will
be
structured
in
whatever
does
that
make
sense,
the
kind
of
like
you
know,
I
have
a
separate
track
for
somewhere
to
kind
of
represent.
This
could
be
this
structure
to
give
some
ideas
or
some
concrete
examples.
A
It's
more
controversial,
or
maybe
not
really
clear
issues
included
in
this.
Maybe
I
probably
want
to
read
through
the
stock
before
going
off
on
that,
just
to
kind
of
give
a
little
heads
up,
though
the
CN
CF
in
creating
your
repos
is
that's
all
controlled
by
the
medieval
poetry.
So
you've
it's
been
a
slow
process
if
it
ever
happens,
so
it
might
just
be
useful
to
do
this
in
a
branch
or
something
like
that.
Yeah.
B
A
Yeah
I
would
probably
I
feel
like
there
was
a
lot
of
stuff
in
here.
That
is
not
that
controversial
and
that
kind
of
stuff
could
just
get
really
quickly
into
issues
where
even
just
directly
the
TRS
but
yeah.
Maybe
after
reading
through
there's
going
to
be
some
bigger
structural
things
I'm
guessing
that
to
make
sure
that
we
have
yeah
I
am
worried,
like
I,
listened
to
what
you're
saying
that
I'm
also
not
sure
that
I'm
fully
understanding
all
of
the
points.
A
B
C
You
a
are
you
interested
in
I,
mean
actually
providing
resources
to
make
changes,
because
I
think
that
you'll
find
a
lot
of
agreement
if
you
make,
if
you
make
since
I
was
old,
but
but
actually
it
comes
down
to
a
bunch
of
work
that
might
be
designed
with
Tyler's
mentioning
with
splitting
these
repositories,
which
make
using
internal
packages,
maybe
harder
I,
don't
know,
like
there's
I,
think
reasonable.
Those
would
probably
be
very
welcome
so.
B
Emanuel
and
I
are
also
considering
tnow,
contribute
and
help
with
these
changes,
and
it
really
that's
why
we
wants
to
come
to
this
meeting.
Also
to
understand,
like
you
know
how
open
the
packages
are
for
change
and
so
on,
understand
and
that
when
I
said
like
it
was
not
conference
to
I
think
we
didn't
want
to
spend
a
lot
more
time
before
come
here
and
like
understanding,
also
your
opinions,
so
I
think
we
can
collaborate,
I'm,
not
sure
about
the
manuals
timeline,
but
I
will
be
able
to
definitely
spend
some
cycles
on
this.
C
D
Those
are
very
important
because
all
that
you
need
to
do
is
instrumented
stuff
once
for
your
company
or
your
server,
and
then
you
just
keep
extracting
the
value
from
it.
So
it's
pretty
important
that
perhaps
metrics
is
also
done
for,
like
G
RPC
and
HTTP
I
believe
the
last
time
I
checked,
though,
is
only
tracing
yeah.
A
C
C
Standardized
conventions
for
the
names
essentially
and
there's
also
some
work.
That's
what
led
to
some
confusion,
because
we
some
people
would
like
to
specify
how
to
construct
metrics
directly
from
spans,
rather
than
requiring
double
plugins,
but
I.
Think
the
real
problem
with
plugins
gets
back
to
the
question
of
Global's
and
how
you
decide
which
implementation
you're
using
when
you
want
to
install
a
plug-in,
and
so
is
it
easy
to
install
your
instrumentation
to
a
framework,
whereas
that
framework
can
use
the
global
and
instance
of
the
SDK
in
other
languages.
C
We
have
this
Auto
instrumentation
thing
and
there's
no
such
thing
as
adding
go
unless
you
consider
use
of
the
global
SDK
is
I
will
be
automatically
instrumented
as
soon
as
my
SDK
is
provided
for
me.
So
so
getting
plugins
like
easy
to
install
is
off.
Is
the
question
and
I
think
global?
That
global
question
is
what
we
really
need
to
answer.
A
Yeah
cool
I
think
we're
coming
up
to
time,
so
I
definitely
want
to
say
again
thanks
for
the
input
and
yeah
I
think
plugins,
like
you
said,
it's
definitely
something
as
we
go
to
GA.
That
needs
to
be
airtight
and
which
is
definitely
yeah
still
working
progress.
So
happy
too
happy
to
see
that's
recognized
not
only
in
ourselves.
Yeah
I
am
looking
forward
to
the
collaboration.
That's
it's
definitely
very
exciting.
C
A
Absolutely
okay,
yes,
I
think
we
have
three
minutes
left
and
it's
nice
to
have
a
little
bit
of
break
before
the
metrics
we
this
late
in
the
day,
so
yeah
that
sounds
good,
Jenna
I!
Don't
are
sorry
if
I'm
mispronouncing,
your
name
Donna
I,
think
is
that
Morgan
said
it
and
feel
free
to
reach
out
to
be
on
getter
or,
if
you
just
want
to
put
in
the
agenda
doc
I'll
link.
What's
this
does
get
released.