►
From YouTube: CNCF OpenTelemetry Meeting - 2019-9-24
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
OpenTelemetry SIG: specifications
A
B
B
E
F
The
open,
telemetry
public
calendar
yeah
share
my
screen.
E
G
E
F
F
F
B
B
Is
still
in
PR,
so
basically
what
happened?
Is
it's
been
a
little
bit
too
much
time
on
configuring
zoom
rooms,
but
now
we
have
three
zoom
rooms.
They
all
start.
Recording
catamites
place
is
blinking.
The
coursing
light
when
you
join
so
join
host
is
not
required
to
join,
but
the
only
problem
is,
and
there
is
no
limit
for
40
minutes
that
we
used
to
happen
have
before
so
yeah.
The
only
problem
is,
you
can't
have
two
meetings
in
the
same
room
at
the
same
time,
so
you
need
two
so
I
suggest
to
call
color
code.
B
F
B
F
Just
FYI
Sergei
since
you're
looking
at
this
stuff,
there's
been
something
going
on
where
the
meetings
have
been
like
disappearing
from
the
calendar,
and
we
haven't
been
able
to
get
to
the
bottom
of
like
why
that
was
happening.
Who's
either
people
updating
the
meetings
and
maybe
not
like
forgetting
a
couple
when
they
updated
them
or
maybe
like
there's
the
degree
to
which
this
stuff
might
be
attached
to
like
some
Google
room,
calendaring
stuff,
or
something
like
that.
Where
there's
some
automated
system
that
might
be
mucking
with
them.
H
F
F
F
Just
got
back
from
the
woods
so
I
don't
have
an
agenda
for
this
meeting.
I
can
throw
some
things
on
the
agenda
and
I
know.
There
is
definitely
some
spec
work
in
flight.
At
the
moment
that
imagines
some
people
are
going
to
talk
about
I.
Think
both
of
you
right,
yeah
baktuns.
Here
we
got
Josh
here
we
good.
We
got
the
whole
crew
here.
F
B
B
D
Are
also
sort
of
reviewers
and
approvers
in
the
go
repo
like
there's
only
two
or
three
active
approvers
right
now
and
Ted's,
like
practically
not
involved
but
has
been
like
helping
out
by
approving
things
when
I
Knight
him
so
I'm
trying
to
get
more
people
there
as
well
and
Paulo,
and
someone
I
don't
even
know
are
like
listed,
but
not
not
present.
So
we
got
to
get
more
people
in
there.
Okay,.
D
B
I
F
Yeah-
and
that
may
be
a
reminder
in
general,
because
we've
got
some
sigelei
ders
here
consider
it
may
have
been
a
while,
since
people
in
your
group
were
nominated
to
be
approvers
or
maintain
errs,
or
something
like
that.
So
if
you're
leading
a
cig
think
about
whether
there's
people
who've
been
contributing
lately,
who
could
be
added
to
those
ranks,
so
you
can
kind
of
broaden
access,
yeah.
E
B
And
to
remind
everyone,
in
order
to
to
add
someone,
you
have
to
do
a
PR
on
the
community
at
the
person
to
the
list
of
contributors
with
the
status
that
you
are
proposing
and
put
there
the
links
to
the
PRS
and
work
that
they
did
and
try
to
match
the
requirements
that
are
defined
in
the
community.
Emotion,
sweet.
F
There's
a
related
thing
just
around:
we
don't
have
to
talk
about
it,
a
lot
right
now,
but
trying
to
help
out
with
just
sort
of
backlog
triaging.
In
general
we
have
some
people
who
could
be
helping
more
with
just
like
project
management
and
backlog
management.
It
seems
like
it
would
be
nice
to
have
some
kind
of
role
that
was
like
a
community
manager
role
or
a
triage,
a
role
where
it
would
be
possible
to
get
backlog.
F
Access
like
across
the
organization,
I
think
there's
like
actually
a
triage
or
github
level
that
lets
you
do
things
like
set
and
remove
labels
and
manipulate
issues
and
PRS,
but
you
can't
merge
or
do
some
of
the
other
things.
So
that's
another
way.
We
might
be
able
to
get
some
more
help
on
this
project.
If.
F
Or
we've
got
a
Midori
here
on
the
call
who's
joined
just
joined.
My
team
at
light
step
should
be
doing
a
lot
of
engineering
management,
which
will
include
a
lot
of
like
open
telemetry
project
management.
Okay,
so
she
can
definitely
help
with
that.
But
I
don't
know
if
we
had
like
a
concept
for
this
kind
of
access
that
we
wanted
to
add
to
the
community
Rico.
That's
something
people
have
been.
B
J
F
We
have
a
couple
other
people
who
can
help
out
in
this
regard,
but
yeah
I,
don't
know.
We
don't
necessarily
have
a
dedicated
community
manager
person
over
here
just
to
be
clear,
but
we
do
have
like
another
Amelia
who
is
like
Director
of
Marketing
here
and
doing
a
lot
of
open
source
work
and
getting
involved
with
open
telemetry.
She
might
she's
gonna
be
helping
out
more
to
around
stuff
like
the
website
and
things
of
that
nature,
so
we'll
be
looking.
F
B
B
J
B
So
yeah
we
all
talking
about
alpha
release,
so
you
know
we
already
shipped
beginning
of
summer.
We
shipped
API
proposal
and
after
that
we
have
established
a
chap
press
process
and
we
immersed
couple
chips
proposals
already,
so
we
have
a
protestin
at
hand
how
to
go
forward
and
move
this
procedure
forward.
Now
we're
talking
about
alpha
release
and
when
I
came
back
from
parentally.
If
everybody
saying
like
often
used
to
happen
this
month,
however
I'm
talking
many
people,
I
realized
there
is
no.
The
commutation
is
not
complete
for
what
you
want
to
call
alpha.
B
So
even
if
language
will
ship
alpha
specification
is
not
there
yet
and
I
think.
Basically,
we
can
try
to
get
API
spec
2
alpha
release
like
this
week.
If
you
all
work
hard
and
like
we
will
nourish
matrix
purple
so
completely,
we
will
merge
couple
more
pull,
requests
and
fight
it.
Maybe
we
can
hit
this
date
and
then,
after
that,
I
think
in
one
week
optimistically
again
we
can
do
SDK
spec.
That
will
include
some
Zipkin
in
EUR
and
parameters.
Datum,
I,
think
I
noticed
somebody
already
started.
B
Zipkin
data
mapping
and
it's
really
cool
I,
mean
implemented
in
different
languages
and
then
languages
I
mean
a
basically
like
people
can
like
a
Python
group
recently
met
and
I
talked
to
them,
and
there
is
a
good
chance
that
they'll
finish
everything
this
big
ish,
so
like
a
specifications
update,
they
say,
probably
can
update
what's
the
shipping,
so
maybe
they
even
ship
like
the
same
date
10-4.
But
realistically
you
need
to
give
a
good
time
of
cooking
up.
So
maybe
10
11
is
a
possible
date
date
for
alpha
and
I.
B
Think
together
what
Alfie's
release
is
about
and
I
know
there
is
a
agenda
item
about
like
a
Alpha
and
where
the
definition,
so
maybe
this
I
want
to
talk
about
spirit
of
alpha
I,
think
spirit
like
we
want
to
get
alpha,
so
we
can
GMO
something.
So
we
can
start
showing
it
to
people.
We
can
give
it
somebody
in
flavors
and
try
out
some
information
adapters
implements
and
data
collectors
are
trying
out
in
applications,
so
it
should
be
dimmable
kind
of
product
yeah.
H
B
I
B
Then,
for
beta
release
looking
at
days,
sorry
for
what
a
whiteboard
but
which
we
have
like,
if
you
finish
10
11
4,
on
the
line
like
alpha
version,
we
only
have
one
two
three
four
five
weeks
before
cubic
on
and
if
you
will
target
our
beta
releases
proposed
in
a
chap
to
be
very
stable,
almost
like
released
kanji.
That
kind
of
quality
of
AP
is
then
we
probably
exercise
all
those
five
weeks
to
get
to
this
level,
so
I
think
anyway,
I
just
got
this.
B
B
F
F
Just
realistically
the
amount
of
exercise
this
stuff
is
gonna,
get
the
being
able
to
like
get
it
feature,
complete
I
think
we
can
definitely
do
that,
but
you
know
there's
like
that.
Last
mile,
from
feature
complete
to
you
know
something
that
we're
saying
is
going
to
be
stable
with
some
long
term
support
guarantee,
or
something
like
that.
So
this
makes
me
feel
more
confident.
F
My
one
concern
is
just
like
November
December
I
think
are
going
I
predict.
Those
two
months
will
just
be
a
total
wash
because
we've
got
Q
Khan
we've
got
Thanksgiving
and
then
all
the
Christmas
vacations,
so
I
think,
like
the
number
of
actual
work
weeks
in
those
last
two
months
will
be
like,
like
one
or
two
weeks
or
something
crazy
small
like
that.
B
F
F
F
F
So
some
qualification
I
I've
liked
that
having
these
these
deadlines
have
like
I
agree.
Vague
pushed
us,
but
I've
also
had
some
other
interactions
with
people
who,
for
whatever
reason,
they
were
really
baking
into
their
plans.
They
were
going
to
get
some
stable,
open,
telemetry
thing
in
the
next
couple
of
months,
so
we
all.
B
B
F
F
C
Once
again
increases
we
overhauled
the
proposal
recently
and
just
day
and
the
next
days
we
operated
the
last
feedback.
We
got
from
you
guys,
especially
from
baktun
Andy
and
Yuri,
and
I
just
wanted
to
ask
if
you
could
have
another
look
at
it
and
and
see
if
your
concerns
have
been
addressed,
hopefully
so
that
we
could
probably,
if
I,
only
get
into
getting
into
a
proposed
site.
F
B
F
Propagation
object
that
contains
these
kinds
of
correlations
and
namespaces
and
resources
and
stuff
like
that
seems
like
would
be
the
better
place
to
put
this
so
that
all
these
different
kinds
of
observability
can
have
access
to
this
information,
because
it
seems
like
you
want
to
know
what
metric
like
if
a
metric
is
in
a
component.
You
want
to
know
that
too.
B
F
If
we're
saying
that
we're
we're
adding
context
so
that
people
can
can
correlate
information
later,
and
so
we
are
adding
something.
That's
like
a
component
level
context
where
we're
saying
there's
a
set
of
resources
and
any
observation
that
comes
out
this
part
of
the
program
can
be
correlated
with
this
set
of
resources
right,
so
it
might
be
spans
that
are
coming
out
of
a
component.
Have
these?
F
You
know
component
resources
on
them,
but
also
seems
like
if
you
were
making
a
metric
in
that
component,
you
know
doing
a
count
or
gauge
you
might
want
to
use
those
resources
to
correlate
those
counts
or
gauges
in
some
way,
and
so
there's
just
a
question
of
like.
Is
that
our
metrics
being
correlated
by
traces
or
all
of
these
things
using
some
shared
way
of
correlating
each
other
similar
to
like
the
distributed
context,
stuff.
B
Right,
it's
not
like
that.
First
of
all,
we
do
not
want
to
correlate
every
event
so,
for
example,
we're
not
gonna
we're
not
gonna
know
we,
we
know
only
when
the
metrics
is
created
or
a
span
is
created.
The
component
correct
when
you,
when
you
do
add
one
attribute
to
a
span.
We
do
not
know
that
that
attribute
was
added
from
this
component
much
from
the
other.
B
We
cannot
attribute
everything
to
the
to
the
component
that
started
at
span,
because
that's
the
only
operation
for
spans
that
happens
on
the
tracer,
all
the
other
operations
are
happens
on
the
span,
so
we
assume
that
everything
belongs
to
that
span,
so
so
in
it's
true
for
metrics
as
well.
So
with
these
components
we
just
mark
the
creation
of
a
trace
of
a
span
or
a
metric
with
the
component
that
created
them
correct.
It's
so
we're
gonna,
we're
not
gonna
correlate.
B
F
B
C
That's
the
last
piece
put
incorporated,
so
we
were
talking
about
using
resources
earlier
but
as
it
looks,
like
resources
are
going
away
from
the
API
surface.
So
we
back
a
little
bit
here
and
basically
creation
mechanism
is
to
trace
a
name
and
an
optional
version,
but
that's
it.
So
that's
all
the
context,
information
you
would
get
out
from
the
creation,
patient,
I'm
yeah
right.
C
B
Away,
it's
just
moving
to
the
SDK
and
they
hide
so
we
will
use
them
to
describe
the
process
and
the
overall
service
the
binary
that
is
running.
We
will
still
do
the
same
thing,
but
we
we
believe
that
the
API
level
people
will
not
know.
Where
do
you
run
or
things
like
this
so
except
the
component,
which
is
one
small
thing
that
people
may
know
at
the
compilation,
time
or
sorry,
not
at
the
computation
time,
but
at
the
library,
the
instrumentation
of
the
instrumentation
time
they
will
know
which
component
they
are
in.
D
Personally
feel
this
is
a
little
too
restrictive,
but
I'm
happy
to
go
forward
with
a
restrictive
proposal
like
I.
Do
think
that
there
are
attributes
that
belong
on
the
static,
tracer
or
slash
meter,
slash
implementation
that
an
implementation
might
want
to
vary
inside
of
a
process
that
are
not
dynamic
context,
so
it's
equivalent
to
a
component
or
a
service
label,
but
they're
sort
of
effectively
resources
but
I'm
totally.
Okay
with
us
punting
on
that
discussion,
yeah.
H
C
Guess
the
reason
why
I'm
leaning
a
little
bit
into
having
a
separate
tab
for
metrics
and
for
logs,
because
probably
these
arguments
you
supply
at
creation
time
day
they
could
vary
and
we
have
to
think
for
the
for
the
other
use
cases.
And
if
you
have
a
working
proposal
for
for
traces,
we
have
reduced
focus
reduced
scope.
So
it
would
be
easier
to
to
think
all
the
collocation
through
and
I
think
we
should
do
the
same
screaming
me
for
metrics
at
Locksley.
B
I
I
would
feel
very
bad
having
completely
different
api's
to
get
a
tracer
versus
a
meter,
because
that's
what
you
are
proposing
right
now,
I
mean
you
are
proposing
changing
the
way.
How
I
get
access
to
a
tracer
and
four
meters
will
be
different
and
that's
very
bad
experience.
So
so
we
either
have
a
consistent
way.
We
try
to
keep
them
because
very
consistent
having
them
completely
different
ways
to
act,
the
tool
to
get
a
info
so
for
tracer
meter,
it's
probably
a
bad
evening.
So
you
are.
B
F
I
don't
have
a
strong
proposal
for
that,
but
it's
more
perhaps
a
plea
for
consistency
and
simplicity
on
this
front
like
the
way
that
I
go
about
getting
a
meter-
and
you
know
saying
it's
in
this
component
or
its
correlated
with
this,
or
that
hopefully,
is
similar
to
how
like
get
a
tracer
and
interact
with
that
or
get
some
longer
thing.
If
that
shows
up
later
yeah.
B
B
So
things
like
this,
we
I
don't
need
to
teach
everyone
in
the
world,
so
only
people
who
are
like
gonna
configure
this
need
to
understand
all
these
things.
I,
don't
know
that
was
my
mind
like
I'm,
trying
to
limit
the
amount
of
information
that
people
need
to
learn
in
order
to
use
this
API
and
then
yeah.
In
order
to
configure
Iranian
production,
you
will
need
to
learn
a
bit
more
with.
F
This
this
did
come
up
in
open
tracing.
We
didn't
have
this
concept
of
resources
or
component
and
in
fact,
in
general,
because
it
was
just
an
API.
You
know
when
you
initialized
your
SDK,
whatever
that
was.
That
would
be
the
place
where
you
would
stick
all
this
resources.
So
this
proposal
of
moving
the
resources
back
to
the
SDK
rather
than
the
API,
looks
very
much
to
me
like
using
Yaeger
with
open
tracing.
You
know
that
was
or
using
up
the
light
step,
tracer
with
open
tracing
and
it
worked
fine.
F
It
actually
avoids
some
awkward
issues
around
initialization,
potentially
I
just
want
to
say
the
one
thing
though,
but
people
did
actually
miss
having
some
more
standard
way
to
like
talk
about
that
information,
because
it
wasn't
part
of
like
the
open
tracing
API.
There
was
no
way
to
the
same
over
forming
semantic
conventions
and
stuff
around
yes,.
B
The
difference
now
the
difference
now
Ted
is
we
do
gonna,
have
semantic
conventions
for
this,
because
it's
part
of
our
SDK
and
as
part
of
our
SDK,
we
do
provide
semantic
conventions
for
this
and
everyone
who
is
using
the
SDK
as
the
as
the
core
implementation
for
the
for
the
exporting
like
for
for
lies
that
if
you
are
using
this,
you
will
have
the
same
resource
as
somebody
who
is
using
for
exhibiting
or
for
for
for
yoga.
So
at
least
we
are
sure
consistency,
even
though
it's
not
in
the
API
it's
in
the
SDK.
F
F
So
I'm
fine,
but
I
just
want
to
note
that
yet
people
did
miss
not
having
some
way
of
describing
this
stuff
through
the
API
when
they
were
using
open
tracing.
Maybe
it'll
be
fine,
because
we've
got
a
more
standardized
SDK
now,
so
people
won't
feel
like
it's
as
weird,
but
that
was
a
feedback
that
we
got
from
open
tracing
Josh.
D
Yeah,
okay,
I
think
it's
really
complicated
this
issue
and
I
and
I
think
we
should
just
settle
it.
We're
gonna
be
conservative
and
go
with
the
minimum
at
this
point.
I
I
do
think
that
users
are
going
to
want
to
have
an
SDK
independent
way
to
add
resources,
but
we
can
wait
on
this.
It's
very
complicated.
The.
D
F
D
And
Ted
you
and
I
have
discussed
how
there
that
there
might
be
this
thing
which
is
sort
of
like
shared
by
both
the
meter
and
the
tracer,
which
gets
your
resources
for
you
and
it
sort
of
represents
an
SDK.
The
hardest
part
was
putting
a
name
on
that
and
I
don't
even
want
to
have
the
discussion
right
now.
Yep
cool.
C
G
H
C
C
F
D
Ran
into
this
question
in
the
bridge,
so
the
open
tracing
bridge
has
a
semantics
convention,
declared
called
span
kind,
and
if
somebody
sets
an
attribute
on
an
open
tracing
span
span
that
kind.
How
do
we
represent
that
enough
to
climb
a
tree?
It
gets
back
to
the
same
thing.
You
just
said,
though,
job
yeah.
C
I
C
B
F
But
I
definitely
think
it
should
be
there
one
way
or
the
other
is
an
option
during
span
creation,
I
guess
that's
what
I'm
trying
to
say
if
it
ends
up
being
on
the
span,
object,
and
you
know
it
would
have
been
cleaner
to
put
it
as
an
attribute
I.
Don't
think
that's
actually
a
big
deal
in
the
long
term.
F
Proposal
to
separate
context
propagation
from
observability,
this
is
my
garbage
that
I
have
to
update.
This
is
just
trying
to
get
a
very
high-level
description
in
there
about
context,
propagation
and
the
way
you
could
have
several
different
systems
using
context,
propagation,
so
an
observability
system
and
then
a
baggage
system,
that's
separate
from
it.
The
main
idea
here
is
to
figure
out
what
actually
needs
to
be
shared
between
these
different
systems.
F
So
I
need
to
take
another
pass
at
this
today
to
add
in
feedback
from
people
I've
been
talking
to
over
the
past
week,
but
if
people
have
any
general
feedback
like
what
the
is
this
thing
or
anything
along
those
lines
like
please,
please,
let
me
know
I've
positive
feedback
that
this
has
helped.
People
wrap
their
heads
around
like
the
general
shape
of
this
project,
so
I
think
it
would
be
useful
to
go
into
either
the
spec
of
the
website
in
some
form
like
that.
F
D
All
right
so
I
posted
a
large
specification
draft
on
Friday
and
it
has
received
several
people's
feedback
already.
My
I
wanted
kind
of
had
a
medical
issue
here,
because
it's
not
to
get
down
to
the
details,
but
the
question
I
have
is
sort
of
like
this
there's
already
too
much
feedback
for
any
one
person
except
me,
perhaps
to
follow
in
this
PR.
D
It's
going
to
get
out
of
control
very
fast,
so
I
think
like
in
the
hotels
repo,
where
we
kind
of
had
a
practice
of
merging
PRS
and
then
getting
fresh
PRS
to
start
to
start
new
discussions
to
kind
of
keep
everyone
synched
up
with
the
current
state,
I'm
wondering
if
we
should
have
a
practice
there
for
the
specification
repo
or
whether
I
should
kick
this
back
into
au
temps
and
sort
of
like
create
a
no
chap
that
says.
Here's
this
draft
for
a
new
metric
specification
in
its
full
form.
D
D
L
My
question
for
the
group
I
think
I
think
there
do
things
here
one
is
it
there's
like
a
different
kind
of
feedback
on
the
the
spec
and
a
note
EPS
like
a
lot
of
the
feedback
on
the
spec?
Is
not
you
know
about
about
the
ideas
and
the
attempts
and
whether
you
should
approve
them,
but
like
at
least
a
lot
of
my
feedback
on
the
metrics
spec
TR
was
about
the
wording
and
the
presentation
of
the
ideas
and
things
that
are
left
out
but
described
in
the
yeah.
D
L
Of
this
okay,
so
I
think
this
procedure
that
we've
got
now
and
the
oat
EPS
repo
just
doesn't
work
because
we're
emerging
things
in
and
then
there's
not
really
any
nice
workflow
for
commenting
on
like
on
documents
that
have
been
submitted
and
not
approved
so
I
think
everybody
has
this
nice
workflow
for
PRS
right
where
we
can
comment
on
a
proposed
document.
But
you
know
we
have
a
procedure
that
doesn't
actually
match
the
github
workflow
right
now,
where
we're
supposed
to
comment
on
proposed
Docs
and
even
in
the
Oh
tips
like
repo
right
now.
D
F
I
was
just
gonna
kind
of
plus-one.
What
Chris
said
is
I
think
the
original
proposal
here
was
yeah.
We
would
quickly
merge
these
in,
so
people
could
see
the
proposals
and
maybe
issues
to
discuss
this
stuff,
but
yeah.
The
way
github
actually
works.
All
of
all
of
your
commenting
and
review
tools
are
kind
of
on
the
PR
I'm.
F
H
F
Have
a
review,
and
then
you
know
it
gets
approved
as
part
of
the
PR
or
if
it
can't
get
approved
in
that
set,
then
you
know
you
go
back,
make
an
update,
make
a
new
PR
reference,
the
old
one,
and
then
we
use
like
the
the
pull
request
history
to
track.
You
know
what
happened
to
the
various
proposals,
and
so
what
actually
gets
written
in
to
the
repo
are
submitted,
PRS
that
have
only
things
that
have
actually
been
vetted
and
approved.
D
F
See
a
funny
thing
happening
where
you
get
your
RFC's
approved,
and
then
you
bring
it
over
to
the
specification
and
there's
a
certain
amount
of
like
review
about
how
it
does
the
wording
work
at
that
stage
and
I
think
that's
totally
fine,
but
we
should
probably
be
worried
about,
may
be.
Relitigated
issues
like
I
wouldn't
want
the
the
meaning
to
change
between
like
the
RFC
and
what
goes
into
the
spec.
There's.
D
There's
a
temptation
to
changed
names,
though,
because
people
are
finally
seeing
everything
put
into
one
document
and
it's
very
like
as
I
say
it's
hard
for
people
to
follow
these
lengthy
individual
RFC
s
so,
for
example,
Michael
who's
on
this
call
got
to
reviewing
the
specification
yesterday
has
raised
some
things
that
could
have
been
discussed
in
the
FCS
but
just
kind
of
weren't.
So
my
question
now
is
like
are
weary
litigating?
Should
we
go
back
to
the
design,
drawing
board
I,
don't
think
we
should
but
I
mean
I've
always
believed
that
we
were
not
gonna.
B
B
Then
I
think
that
that
is
a
separate
issue
and
I
think
we
should
create
an
issue
for
that
and
discuss
it
separately.
So
I
think
comments
about
hey.
This
should
not
like
something
that
I
committed
there
like
try
to
not
put
implementation
details
necessary
into
the
into
this
thing.
This
can
be
resolved
because,
like
literally,
we
try
to
keep
a
standard
of
what
is
in
the
API.
What
is
in
the
SDK
and
stuff
like
that
or
somebody's?
Just
like
hey
better
to
say,
we
will
express
more
relevant
things.
B
I
think
this
should
be
fixed
but
comments
not
necessarily
about
changing
the
decisions
that
we
had
documented
in
the
object.
I
think
they
should
be
created,
separate
issue
me.
We
should
not
ignore
them.
We
should
create
separate
issues
and
we
say
hey.
This
means
the
discussion
about
it
is
where
do
you
think?
Where.
D
Do
you
think
those
issues
should
be
filed,
respect
okay,
yeah
so
like,
for
example,
the
the
major
one
that
was
raised
is
one
that
has
been
discussed
like
there's
history
here,
but
it's
sort
of
like
about
how
you
configure
your
aggregations
and
so
I'm
I'm
going
here.
Maybe
we've
just
like
we're
only
halfway
there
in
the
sense
that
we've
designed
and
or
specified
the
API,
but
we
haven't
talked
at
all
about
how
the
SDK
gets
configured
and
like
what
you
might
do,
or
this
mythical
views
API
or
something
like
that.
My
home
yeah.
B
I
also
posted
in
one
of
the
issue
in
Java,
something
related
to
that
I.
Think
I.
Think
you
just
quickly
issue
and
I
will
also
add
more
comments
there,
but
but
for
this
kind
of
things
you
should
you
should
encourage
people
either
you
create
the
issue
copy,
basing
their
comments
and
stuff
or
you
ask
them
to
hey,
move
these
to
an
issue
whatever
you
feel
comfortable
with,
but
I
think
this
kind
of
relevant
for
your
me,
I
I.
L
Think
what's
gonna
happen,
I
think
we
already
see
this
happening
like
in
the
JavaScript
repo
is
that
people
use
the
spec
as
justification
for
implementation
decisions
and
they
don't
check
the
history
to
see
if
something
in
the
spec
is
like
still
employ
or
well
defended,
or
has
some
open
issue
so
I
think
anything
that
actually
goes
into
the
the
specs
repo
that
gets
committed.
People
are
going
to
start
implementing
and
so
I
think
we
should
be
very
careful
about
what
actually
goes
into
specs
yeah
yeah.
D
The
most
substantial
question
that
Michael
raised
was
really
about
how
you
configure
aggregations
and
I.
You
know,
I
personally,
think
would
be
nice
if
you
could
specify
options
for
aggregation,
just
sort
of
specification
in
the
metric
instrument
as
you
declare
it,
but
is
something
that
could
be
added
as
an
option
later.
It's
not
a
requirement
to
do
this.
I
know.
L
F
C
B
F
Related
to
that,
we
have
not
up
til,
now
been
explicitly
versioning
this
specification,
given
that
we're
moving
closer
to
like
an
alpha,
a
thing
I
think
there's
going
to
be
a
need
very
soon
to
be
able
to
express.
You
know
the
tracing
stuff
we
have
is
this
version
of
the
spec,
but
we
haven't
updated
the
metric
stuff.
Yet
so
it's
at
you,
tracings
at
1.1
metrics
at
1.0,
or
something
like
that.