►
From YouTube: 2021-01-19 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
B
C
Hey
hey
good
morning,
guys
or
good
afternoon
for
some
of
us
it's
three
minutes
after
the
start
time,
so
I
suggest
we
wait
one
two
more
minutes
for
some
more
people
to
join.
C
Meanwhile,
add
yourselves
to
the
agenda.
Do
that
in
this
list
first,
and
just
of
course
add
any
important
item.
A
I'll
start
sharing
just
to
get
visibility
into
the
items
on
the.
A
A
Okay,
so,
as
usual,
we
have
some
standing
agenda
items
we'll
start
by
going
over
the
status
of
the
ga
spec
burn
down
project,
that's
tracking
items
related
towards
open,
telemetry,
ga.
As
a
summary
of
how
things
are
progressed
from
last
time,
we've
got
23
in
the
to
do
issues
one
up
from
last
week.
Most
of
them
are
spec
related
spec,
metrics,
related
issues,
four
with
associated
prs
and
59
resolved
of
the
p1
issues,
the
link
oops.
A
Sorry,
the
link
here
will
take
you
to
the
project
here,
which
is
just
pretty
much
a
summary
which
is
pretty
much
breaking
down
everything
down
into
project
form.
A
Let
me
know
if
anyone
wants
to
dive
into
any
of
those.
Otherwise
I'm
going
to
move
on
to
the
next
agenda
item,
which
is
triaging
of
new
issues.
That's
coming
in
since
the
past
week.
Just
a
comment:
we've
had,
we
usually
have
like
two
three
hour
sessions,
one
on
the
spec
for
the
spec
issues
that
come
in
one
during
the
specific
meeting
this
meeting
and
another
one
during
friday.
It
hasn't
been
a
lot
so
on
the
friday
issue,
triage
meeting,
so
we're
kind
of
like
punting.
It
to
here.
C
Yeah,
that's
the
one
that
john
created
that
we
moved
from
the
community
repo
to
here.
I
think
it
looks
important
enough,
so
I
could
personally
go
with
require
4g.
A
And
because
this
p1,
we
would
like
to
choose
an
assignee.
A
Okay,
I
fouled
this
one
a
week
ago,
seeing
that
there
was
an
otep
that
alolita.
A
C
C
To
me,
it's
also
required
for
ga,
but
I'm
not
entirely
sure.
So
if
anybody
has
a
different
opinion,
please
jump
in
now
jump
in
now.
I.
D
Mean
it's
definitely
required
for
ga,
because
you
know
again
any
downstream
distribution
and
bundling
like
aws
distro
requires
this.
So
we,
you
know
it's
better
to
have
this.
You
know
instrumentation
of
scanning
and
using
the
tools
that
exist
on
the
repos
themselves,
rather
than
doing
it
again
elsewhere
right.
So
the
idea
is,
to
you
know,
continue
to
keep
ramping
up
any
of
the
security
scans
and
other
vulnerability
tracking
that
happens
on
the
project
itself,
rather
than
building
customer
trust,
rather
than
doing
it
in
a
scatter
shot
approach.
A
So
this
is
just
a
comment
on
I
put
this
as
area,
ga
tracking,
which
are
meant
to
encapsulate
high
level
issues,
not
specifically
for
the
spec
repos
code
base
exactly
but
track
across
things.
That
would
be
related
to
ga
that
is
kind
of
relevant
across
all
languages
and
such
yeah.
D
That
that's
exactly
what
it
is.
It
is
cross
language
cross,
reapers.
C
Yeah,
that's
an
interesting
one
and
actually
I
feel
an
issue
well.
An
item
for
discussion
today.
C
E
I
agree
we
do
need
to
discuss
what's
going
on
here,
because
I
feel
like
there's
not
there's
a
lack
of
clarity
on
what
is
required
to
be
implemented
by
every
language
and
what
is
just
like
if
a
language
happens
to
implement
this.
Here's,
how
you
specify
it
and
that's
kind
of
a
bigger
issue
than
just
this,
in
particular,.
F
E
This
is
a
significant
change
to
the
way
that
tracing
would
work.
C
Because
of
this
again,
this
is
not
a
strong
feeling.
It
feels
like
this
is
allow
for
ga
with
priority
three,
but
it's
not
a
strong
feeling,
probably
yeah.
I
don't
know.
C
I
don't
know
yeah
yeah,
no,
not
clear
to
me
what
things
could
be
done
now,
sdk,
please
thank
you.
A
Okay,
I
think
I'm
hitting
up
against
the
time
box.
We
got
three
left,
but
we
we
got
a
lot
on
the
docket
right
now,
so
I'm
happy
to
move
on.
We
can
continue
later
if
we
got
another
trio
session
on
friday,
if
it's
like
really
really
pretty,
I'm
also
happy
to
keep
sharing
if
in
order
to
help
show
some
stuff,
but
if
someone
wants
to
take
over
control
just
let
me
know.
C
C
One
of
them
is
just
to
remove
the
millis,
this
suffix
and
just
have
millis
by
default
for
all
of
them,
and
and
that
that's
all
for
now,
potentially
adding
in
the
specification
later
some
additional
parsing
that
good
build
on
top,
which
means
that
and
that
would
work,
because
if
you
have
millisecond
default
and
later
you
have,
you
know,
support
for
for
for
the
tech
for
detecting.
C
What's
the
actual
unit
through
you
know
like
us,
having,
for
example,
use
some
lower
case
character
at
the
end,
just
to
tell
what's
the
unit
that
would
work.
The
second
option
is
the
one
that
josh
proposed
here,
josh
from
google
regarding
defining
at
this
moment
the
duration-
you
know
the
duration
units
and
then
have
the
six
decide
when
to
support
this
like
this
is
optional
support.
So
those
two
are
the
options.
G
We
say
that
the
value
that
is
provided
is
a
number
in
milliseconds
in
the
future.
It
can
be
extended
to
support
units
as
a
suffix
of
the
value,
and
that's
all
right.
If
there
is
no
suffix,
then
the
value
is
in
milliseconds,
which
means
that
today,
the
the
sdks
are
only
required
to
implement
it
as
milliseconds
value,
which
is
trivial
and
which
is,
I
guess,
most
already
support
and
in
the
future.
G
C
G
C
B
If
you
get
just
a
raw
number
and
then
we
allow
parsing,
that's
that's
all
that
I
wanted
and
I
threw
together
a
pr
for
java
to
show
parsing's
relatively
easy
and
if
we
needed
another
sigs
more
than
happy
to
contribute
it,
it
was
like
30
minutes
and
50
lines
of
java.
I
think
it'll
be
a
lot
less
in
other
languages.
G
B
G
And
I
think
that
yeah
that
works
for
for
maintainers
the
best
as
well.
It
was
a
concern
that
this
arts
implementation
more
work
to
do
regardless
of
how
much
work
there
is
right.
Maybe
it's
it's
tiny
bit,
but
still
work
to
do
and
by
doing
what
what
we've
just
discussed,
we
remove
that
burden
from
the
maintainers
they
don't
have
to
internet.
They
may,
but
don't
have.
C
Yeah
and
just
to
be
clear,
then
it
would
mean
that
for
this
specific
pr,
we
will
remove
the
mention
of
any
units
at
all,
and
we
will
have
this
other
follow-up
issue
which
will
be
marked
as
allow
for
gi,
with
priority
2,
for
example,
and
then
we
will
by
then
we
will
discuss.
I
will
decide
to
merge
it
depending
on
how
many
6
had
the
chance
to
implement
that.
C
Hopefully,
as
josh
you,
you
mentioned
it's
not
actual
that
much
work
and
then,
of
course,
we
can
easily
then
just
go
and
merge
that
that
effort
as
well.
Does
that
sound
like
a
plan?
Is
that,
like
with
a
good
approach.
H
Yeah,
I
think
it's
good
only.
B
H
Small
card,
yet
for
everyone
to
understand
this
will
imply
a
bit
more
work
in
goal
because
if
they
use
directly
the
duration
parsing,
that's
not
going
to
work
because
they
need
to
have
the
default
case
without
the
without
any
suffix,
to
be
able
to
parse
as
many.
But
probably
it's
not
that
much.
C
H
Here
so
carlos
you
take
an
action
item
to
document
what
we
discussed.
C
Great
this
one
is
the
one
that
we
talked
before
we
mentioned
before.
That
john
also
made
a
remark
so
essentially
long
story.
Sheepkin
can
export
expands
using
a
few
different
formats.
So
you
long
story
short.
We
have
thrift,
proto
json,
and
so
it's
very
good
that
we
can
document
what's
the
format,
but
another
problem
shows
up,
which
is
the
fact
that
the
forensics
have
implemented
different
transport
transports.
C
So
we
can
specify
this,
but
what
is
going
to
be
the
default
value?
What
are
six
expected?
You
know
to
support.
Are
they
really
realistically
expected
to
support
all
of
the
transports?
What
if
java
supports
one
and
then
python
supports
another
one,
so
yeah?
That's
the
discussion.
John
may
have
more
details:
yeah,
okay,.
G
For
this
one,
I
believe
what
we
need
to
require
the
sdks
to
do
is
to
support
whatever
we
choose
as
a
default.
If
the
default
is
the
protobufs,
we
could
protobus
and
that
must
be
supported
so
that
when
it's
unspecified
it
behaves
the
same
across
all
languages
for
all
other
formats.
G
The
sdks
are
not
required
to
support
it
for
ga.
They
are
required
to
fail
if
they
see
an
unsupported
value
there
right
and
then
it's
up
to
this
sdks
to
support
any
additional
on
top
of
the
default,
whatever
they
may
be
already
supporting.
This
may
mean
that
some
of
the
sdks
need
to
do
additional
work
compared
to
what
they
do
now.
I'm
guessing
some
support
json
only
but
not
protobufs,
but
that
we
must,
but
if
the
default
is
a
specific
value,
that
it
must
work
uniformly
across
all
the
sdks.
H
H
E
H
C
Let's
confirm
that
that
sounds
also
that
I
think
that's
what
I
heard
as
well.
Well,
let's
confirm
that.
C
D
Yeah
yeah
carlos
anurag,
can
definitely
help
on
the
zip
can.
But
in
fact
please
ask
him
to.
G
G
E
Think
it's
less,
I
mean
it's
an
unknown
amount
of
work.
The
bigger
issue
is
that
we've
been
working
to
make
everything
stable,
and
this
is
going
to
destabilize
the
sdk.
Are
we
going
to
be
able
to
have
people
who
can
test
to
make
sure
this
works?
Who
can
test
that
this
is
you
know
doing
exactly
what
it
should
be,
do
should
be
doing
across
all
languages.
H
D
Okay,
I
think
I
think
I
would
suggest
at
least
john.
We
should
chat
with
anurag
to
see
if
we
can
scope
it
and
based
on
that,
we
can
take
a
call
as
to
whether
it's
yeah.
I
I
think
one
thing
we
want
to
look
at
with
these
exporters
is
that
we
have
some
amount
of
uniformity
in
the
sense
of
I
think
that
would
be
helpful,
but
I'm
not
sure
that
this
is
something
of
a
block
1.0.
G
I
agree:
it's
not
the
end
of
the
work
to
me
if
this
remains
unspecified,
and
even
even
if
there
is
no
uniformity
in
the
sdks,
if
they
choose
to
export
in
slightly
different
formats,
yeah,
it's
not
nice,
not
the
end.
All
the
word,
in
my
opinion,
we're
not
breaking
the
api.
If
we
make
changes
to
this
behavior
in
the
future,
after
the
ga.
E
I
J
J
K
On
that
note,
I
think
this
probably
varies
by
language
ecosystem,
but
I
know
in
in
js
when
we
have
multiple
packages
that
use
different
transport
formats
or
protocols.
Often
there's
like
a
separate
package
for
them,
so
these
environment
variables
aren't
all
that
useful,
because
it's
kind
of
the
package
that
determines
the
protocol
and
yeah
it's
just
not
something
that
that's
switchable.
K
E
I'm
going
to
ask:
does
the
collector
dipkin
receiver
what
what
protocols
does
it
support
at
the
moment.
H
B
Can
I
throw
something
out,
though,
like
I
think
maybe
for
ga
you
can
just
require
that
if
you
want
to
configure
the
output
format,
you
have
to
do
it
in
code
and
then
leave
open
post.
Ga,
you
can
specify
an
environment
variable
that
new
versions
would
make
use
of
if
it
exists,
but
don't
specify
the
default
at
all
and
never
specify
the
default
as
an
option
right.
So
everyone
gets
to
do
what
they're
doing
today.
We
just
tell
people
to
require
it
with
configuration
like
that.
B
You
know
per
sdk
and
then,
if
we
want
to
specify
an
environment
variable
later,
we
can
do
so
without
delaying
ga
and
it
should
be
fully
compatible
because
no
one's
relying
on
it
yet
right.
The
key
is:
don't
give
people
a
default
and
don't
specify
the
environment
variable.
Yet
we
wait
to
do
that.
Postga.
H
I
like
that,
that's
a
good
good
thing,
but
we
still
have
a
separate
problem,
which
is:
what
is
the
expected
formats
that
every
sdk
should
implement.
B
Right,
what
I'm
saying
is
we
don't
solve
that
problem?
Just
yet,
will
you
let
the
sdks
allow
configuration
within
the
sdk
as
appropriate?
You
allow
users
to
open
bugs
and
then
once
we
have
enough
information
after
the
release,
we
can
make
the
change
to
the
spec
and
fix
all
the
sdks
appropriately
each
sdk
would
by
default,
allow
it
to
be
configurable
at
some
point
right,
just
because
of
user
command.
B
So,
like
I,
don't
think
it's
something
you
have
to
specify
prior
to
ga.
I
think
it's
something
you
can
deal
with
post
ga.
It
is
a
little
wonky.
I
agree,
but
it's
something
you
could
deal
with
post
ga
based
on
how
many
users
ask
for
what
would
lead
us
to
understand.
What's
the
default
like
what?
What
really
should
be
the
default,
how
many
people
are
asking
for
things
right.
H
No,
no,
that's.
That's
perfectly
fine.
I
would
like
to
point
still
one
inconsistency
which
is:
we
do
define
an
hotel
export,
otlp
exporter
format,
which
probably
we
should
apply
the
same
logic,
and
we
should
remove
that
based
on
on
this.
If
this
is
the
right
path,
which
I
think
it
is,
we
should
remove
the
other
one.
D
E
Sorry
I
was
digging
into
the
zipkin
implementation
yeah.
H
So
so
the
the
resolution,
john,
is,
we
don't
define
this
environment
variable
for
the
moment
we
allow
users
to
choose
only
barcode,
whatever
exporter
and
format
they
want,
and
but
we
need
to
do
the
same
thing
for
otlp
and
remove
the
otlp
format.
Environment.
E
D
C
Yeah,
I
suggest
we
do
that.
It
seems
that
we
still
need
to
think
a
little
bit
more,
but
we
need
somebody
to
take
over
this
to
help.
You
know
driving
it
properly.
B
Me,
yes,
I
guess
my
main
question
is:
if
we
delay
this,
I
think
effectively.
That
means
we're
saying
we're
not
resolving
this
for
gda
or
for
1.0,
which
is.
D
B
I
Like
if
we're
gonna
make
it
required
implementation
for
1.0,
it
should
be
in
the
spec
when
we
call
it
and
if
we're
going
to
say
we're
going
to
punt
towards
after
that,
we
should
write
down
here.
This
will
come
after
1.0
we're
going
to
remove
it.
H
B
I
don't
agree
at
all,
I
think
with
otop.
It's
fine
for
us
to
be
to
have
a
format
and
say
this
is
something
we're
going
to
do.
I
think
it's
fine
to
tell
people.
We
will
provide
an
environment
variable
for
zipkin
in
the
future
as
like
a
plan,
but
we're
not
going
to
guarantee
anything
at
all
in
1.0
and
it's
okay
to
make
the
change
post
1.0
right.
This
is
a
discussion
about
what
are
we
going
to
do
in
1.0
and
release
the
stable
and
document?
And
then
what
are
we
going
to
do?
B
Post
1.0,
it's
okay,
to
make
change
post
1.0!
It's
totally
fine!
No
one's
gonna
hate
us
and
they
might
appreciate
it
if
we
make
things
better
as
we
go
right
so
like.
I
think
it's
fine
to
have
an
inconsistency
temporarily
with
a
plan
for
how
we
resolve
it
in
the
future
and
without
like
delaying
the
current
1.0
of
sdks.
I
think
that's
fine.
B
Okay,
yeah,
that's
a
great
question.
G
B
B
The
key
is
whatever
default.
The
sdks
have
implemented.
We
don't
change,
we
actually
can't
change
it.
Our
hands
are
tied
post
1.0,
because
it's
the
breaking
change
to
to
do
that.
What
I
my
suggestion
was
around
this
environment
variable
is,
in
the
absence
of
it,
there's
no
specified
default,
which
allows
us
to
release
what
we
have
today
and
then
add
this
as
a
configurable
thing
later
in
the
future
post
1.0
right
and
if
we
want
to
make
breaking
changes
on
a
per
sdk
basis
around
the
default
we
can.
B
H
That's
that's
what
I
think
I
think
we
should.
We
should
do
that,
but
that's
why
I,
I
hope
everyone
agrees,
but
I
think
we
have
these
two
solutions.
We
either
accept
both
or
remove
both
and
figure
out
later.
C
B
Correct
yeah,
I
can
drive
it.
The
thing
I
don't
want
to
do
is
delay
1.00
of
sdks,
like
I
want
to
understand
if
we're
making
that
decision
right
now
to
delay.
That
is
that.
H
No
we're
not
making
a
decision
to
delay.
We
are
making
a
decision
to
to
to
clean
up
things
that
we
are
not
sure
like
this
one.
Okay,.
H
H
But
john
or
tigran
tigran
you
mentioned
that
there
is
one
for
otlp
format.
G
H
D
I'll
also
ask
josh
I'll,
also
ask
andrag
to
sync
up
with
you,
so
just
just
to
make
sure
that
you
know
there's
there
wasn't
something
that
is.
B
A
Good
oops,
it's
not
this
one
service
name
handling.
C
C
Review
because
yeah
just
you
left
a
small
question
for
christian
on
the
related
vr,
okay,
so.
D
C
H
Okay,
I
will
take
a
look.
I
did
not
know
that
it's
blocking
by
me,
okay,.
C
I
also
put
this
one
there:
it's,
it
was
filled
by
anurag,
whether
you
know
we
talked
about
this
last
week,
but
there
was
no
action,
no
activity,
so,
of
course
we
don't
have
to
discuss
it
now.
We
already
discuss
it,
but
we
need
to
discuss
more.
You
know
like
to
spend
some
more
time
actually
thinking
or
somebody
needs
to
be
assigned
to
help
drive
this.
E
When
I
chatted
with
anarag
about
this
last
week,
he
said
that
he
would
he'd,
I
think
in
his
comment.
He
said
it's
okay
to
push
this
postga.
C
C
B
So
this
was
something
I
raised.
I
made
a
powerpoint
because
sorry,
everyone,
I
think
in
powerpoint.
I
guess
this
is
actually
google
sheets,
so
I
have
to
be
careful
not
to
call
it
powerpoint
that
could
be.
I
could
get
fired
anyway.
The
tldr
of
this
is,
I
wanted
to
make
a
proposal
because
I'm
having
trouble
understanding
how
close
metrics
is
to
completion,
what
the
two
dues
are
and
that
sort
of
thing
I
attended
the
metric
sig
and
there
are
two
important
parts
of
this
proposal
that
I'm
going
to
throw
out
there.
B
The
second
thing
is
to
basically
actually
specify
for
all
the
major
metric
formats
that
we
want
to
support
a
way
of
taking
the
metric
instrument
model
that
we've
defined,
going
from
like
prometheus
into
that
metric
model
and
then
back
out
into
prometheus
in
a
collector
right
and
make
sure
that
that
is
fully
specified
and
people
are
comfortable
with
that.
And
then
our
notion
of
done
is
effectively.
Can
we
have
an
api
to
collect
this
data
model
right?
B
Can
we
go
from
the
popular
formats
that
we
want
to
import
like
prometheus
d
whatever
and
go
into
our
model
and
back
out
in
that
same
format?
Okay
and
then
how
do
we
actually
do
this
as
a
process?
And
how
do
we
parallelize
it
so
that
multiple
people
in
the
community
can
take
a
particular
metric
instrument,
collate
all
of
the
ideas
and
concerns
and
then
give
us
kind
of
a
chewed
up
spit
out?
Here's
the
issues
around
this
particular
metric
instrument,
like
we
had
at
the
workshop.
B
Let's
discuss
this
for
like
an
entire
sig
meeting
or
an
entire
hour
or
two
right,
and
then
let's
focus
on
getting
that
data
model
correct
and
specified
so
yeah.
So
basically
we
go
through
this
four-step
process
of
let's
get
the
data
model
right
that
input
output.
Let's
get
that
all
specified
right.
Then
we
define
an
api
around
how
users
will
generate
it
in
our
language
sdks
then,
in
the
sdk
we
figure
out.
B
The
important
thing
that's
missing
here
is:
we
want
the
sdk
to
be
implemented
in
a
way
that
metric
instruments
can
be
added
post,
1.0.
Okay,
so
we
can't
just
hard
code
all
possible
metric
instruments
in
the
1.0.
We
need
some
kind
of
extensibility
thing
there
and
then
the
last
thing
we
do
is
talk
about
making
sure
the
collector
is
correct,
that
it
scales
that
it
can
do
push
versus
pull
all
that
kind
of
junk
right,
but
like
in
this
step,
and
then
I
have
some
ideas
thrown
out
here.
B
I
wanted
to
to
give
you
kind
of
the
overview
via
voice
and
let
you
kind
of
read
through
the
ideas
again.
This
is
my
bullet
point
form
I
think
in
powerpoint
and
bullets,
because
that's
the
only
way
I
get
to
communicate
generally.
So
if
that
is
unreasonable,
let
me
know
but
feel
free
to
take
a
look
at
this
and
I'm
curious
what
people's
thoughts
are.
H
So
I
think
I
think
I
saw
this
this
morning
or
something
like
that.
We
didn't
have
too
much
time
to
digest
it,
but
I
think
it's
a
good
step
forward.
Having
some
some
plan
is
great,
I
I
may
have
a
question
for
you.
Are
you
a
pm,
because
that's
the
only
people
that
are
doing
spreadsheets
so.
B
So
if
you,
if
you
I
worked
at
enough
startups,
where
I
had
to
be
pm
and
eng
at
the
same
time,
so
you
wear
multiple
hats
but
yeah.
So
this
is
actually.
This
process
is
taken
from
the
scala,
3.0
improvement
process
and
how
how
we
rolled
there.
Unfortunately,
a
lot
of
the
discussions
that
happened
were
in
private
instead
of
in
public,
which
I
think
was
the
main
mistake
that
was
made.
I
I
can
say
that
publicly.
B
I
guess
I
don't
know
anyway,
so
this
I
expect
the
discussions
to
be
in
public,
but
you
know
it's
decomposing,
a
really
really
hard
problem
defining
what
done
is
and
then
evaluating
like
piecemeal
the
issues
and
the
only
insight
here
is.
Maybe
the
metric
instruments
are
componentized
pieces.
We
can
evaluate
like
one
at
a
time
and
stabilize
that's
that's
the
primary
thing
here
and
then
the
second
part
of
that
is,
I
think
we
need
in
the
sdk
to
make
sure
we
can
add
metric
instruments
later
to
account
for
metric
instruments.
B
We
find
are
useless
and
we
never
use
and
we
want
to
make
a
new
version
of
them.
So
we
define
a
new
name
with
a
new
model
that
effectively
replaces
the
previous
one
right.
We
need
some
way
to
do
that
in
the
future.
We
need
a
way
to
have
made
mistakes
in
1.0
and
not
our
project.
So
I
don't
see
that
right
now,
so
I
think
a
that
needs
to
get
added
in
the
sdk
and
then
b.
B
H
Josh,
I
think
this
is
a
good
discussion.
Maybe
probably
you
should
go
to
the
metric,
sig
and
reserve
20
minutes
to
discuss
this
document
in
that
specific
group.
For
for
this,
it's
probably
a
better
place
to
discuss
it,
but
I
think
it's
it's.
D
H
D
I
agree
with
bogdan
josh
that
this
is
a
great
start.
I
think
there
are.
There
have
been
additional
discussions
and
there
I
think,
some
obviously
some
detail
here
that
that
could
be
better
tuned.
There
are
some
other
dependencies,
so
let's
discuss
it
in
the
metric,
sig
and-
and
you
know,
work
with
the
maintainers,
because
I
know
josh
as
well
as
others
have
had
you
know
had
and
us
our
engineers
also
have
been
having
discussions
on
these
areas.
J
J
This
was
what
the
plan
came
out
of.
Aolito's
group
is
to
say
that
we
need
a
phase,
one
that
does
all
that
data
model
and
the
conversion
to
and
from
and
gets
the
collector
to
work
and
I'd
be
happy
at
this
point
to
say
our
sdk
and
our
api
are
entirely
prototypes
and
I'm
comfortable
doing
that,
because
I'm
very
confident
in
them,
but
but
right
now
we
have
to
prove
the
data
model
and
that
we
can
do
compatibility
which
doesn't
require
an
api
or
an
sdk.
J
J
So
what
instruments
we
create
are
going
to
be
demand
like
based
on
demand
of
of
the
community.
As
you
said
josh,
I
love
the
idea
of
instrument
of
expecting
them
one
at
a
time,
but
there
are
more
fundamental
questions
related
to
resources
and
the
otlp
data
model
that
are
going
to
cross
instruments.
I
think
that
we
have
to
get
done
first.
B
Yep
right
so
so
I
think
I
didn't.
Maybe
if
you
look
at
get
the
model
right
on
slide
five
of
the
proposal.
The
third
point
is:
make
sure
that
collector
and
aggregation
semantics
work
on
the
data
model
so
yeah,
I
agree
with
you.
B
The
data
model
needs
to
come
first
and
the
collector
is
like
super
super
critical,
but
I
think,
like
step,
one
on
all
of
these
things
is
to
make
sure
the
model
is
correct,
that
we
have
input
output,
that
we
can
do
lossless
compliance
of
like
prometheus
and
otp
into
prometheus,
with
that
otlp
being
the
clicker
or
something
right.
All
of
that
green.
It's
more!
The
discussion
around
scaling,
the
collector.
The
discussion
around
you
know:
will
the
collector
shard
that
kind
of
stuff.
I
want
to
punt
that.
J
This
is
very
controversial.
I
mean
a
little
bit,
but
not
very,
and
if
we
wait
till
thursday
and
have
another
conversation,
you
know
thursday
afternoon,
I'm
not
sure
we're
making
enough
progress
here.
What
I
saw
on
thur
friday
last
week
was
we
could
we
could
use
a
weekly
two-hour
session
to
just
hammer
this
stuff
out
and
I
think
we
should
start
with
the
prometheus
stuff
conversion
to
and
from
and
I'd
be
happy
to
schedule
that
two
hours
right
now.
J
D
With
cool
cool
great
but
josh
good
start
on
this
presentation,
I
think
it
will
help
us
and
again
making
sure
all
requirements
are
captured.
I
mean
we
have
to
again,
as
you
said,
sharding,
etc
would
be
nice
not
to
have,
but
we
actually
do
need
it.
So
it
is
very
pretty
urgent.
B
B
J
Think
it's
important
to
remember
that
this
this
this
instrument,
design
we
have
with
the
six
instruments
right
now-
has
a
stuff
about
synchronous
versus
asynchronous
that
doesn't
enter
the
data
model
right
now
and
we
so
we
need
to
hammer
out
data
model
without,
like
the
a
lot
of
the
stuff
we
did
in
the
api
was
was
opinionated
in
a
way
that
the
the
data
model
doesn't
have
that
opinion
in
it.
So
we
have
to
focus
on
the
data
model.
D
B
And
so
I'm
clear,
this
sig
is
not
100
focused
on
metrics
now
post
trace,
1.0.
I
was
under
that
assumption.
For
some
reason.
Sorry,
okay,
that's
why
I
brought
it
here,
but
I'm
still
glad
I
brought
it
here,
but
I
will
move
to
metrics
as
well.
J
J
F
Okay,
I
just
added
it.
I
just
want
to
clarify
whether
the
tracing
apa
and
sdk
are
like
in
different
state,
because
the
api
specification
at
the
very
top
has
a
marker
which
says
stable,
but
we
don't
have
anything
like
that
for
sdk,
which
means
it's
it's
undefined,
but
the
blog
post
said
that
both
pricing,
api
and
spec
are
like
table.
C
Yeah,
the
sdk
is
taking
a
little
bit
longer,
but
as
you
as
you
may
have
heard,
during
this,
we
have
we
are
about
to
grab
this
up
the
sdk
portion
of
tracing.
So
hopefully
we
will
have
it
marked
as
stable
in
the
few
weeks.
F
I
see
so
like
just
to
confirm,
like
whatever
is
said
in
that
blog
is
technically
not
correct,
then,
because
it
says
it's
already
marked
as
feature
freeze.
C
No,
it's
it's
correct,
so
the
idea
about
that
block
is
that
we
wanted
users
of
you
know
consumers
of
open
telemetry
to
use
api
without
worrying
too
much
about
you
know
having
the
api
itself
change.
So
it's
correct,
but
probably
it
means
an
explanation
section
about
why
the
sdk
is
not
yet
frozen.
But
for
for
users
you
know
who
are
you
like
people
writing
instrumentation
for
libraries
like
django
in
python
or
spring
java?
They
should
be
in
theory,
ready
to
go.
You
know
with
the
api
because
that
part
is
stable.
F
But
how
about
the
language
owners
who
want
to
implement
the
sdk
spec
like?
Can
we
like
release
our
1.0
in
the
next
couple
of
weeks
or
do
we
need
to
like
wait
further
out?
I
think.
C
Yeah,
I
think
you
should
wait
like,
for
example,
I
think
that,
for
example
java,
I
know
that
john
is
here.
He
wanted
to
do
a
release
next
week,
but
still
waiting
on
a
few
things
that
may
change
on
the
sdk
portion.
So
yeah
I
mean
you,
can
you
can
start
working
on
that
or
if
you
have
something
working,
that's
great,
but
you
still
may
need
to
update
it.
F
F
F
I
Yeah,
nothing
to
say
just
once
again:
I've
resolved
all
the
comments
that
were
outstanding
here.
I
think
it's
ready
to
merge
personally.
If
there
is
any
final
tweaks,
I'm
thinking
their
surface
area
and
they
could
come
and
follow
up
prs.