►
From YouTube: 2020-10-12 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
A
Thanks,
I'm
actually
in
a
lobby,
I'm
out
of
town,
but
want
to
jump
on
this
call
in
order
to
interested
in
the
agenda
items.
D
E
E
E
E
G
A
Sure,
okay,
I
will
give
an
update
on
the
latest
movement
on
our
p1
issues,
we're
tracking
for
traced,
spec
freeze.
We
have
four
items
in
to
do
and
three
in
progress.
The
search
query
I
have,
if
you
bring
this
up,
I've
been
using,
is
excluding
the
metrics
label.
So
you
see
three
and
three
here,
but
there's
actually
a
fourth
one
that
we're
going
to
be
discussing
at
the
spec
sick
tomorrow
related
towards
attributes
and
labels
and
such
so
it's
not
included
in
here.
But
that's
like
the
fourth
one.
A
That's
that's
in
the
to
do
well,.
B
A
Okay,
oh
this
one
got
a
pull
request:
okay,
okay,
I've
moved
in
progress
if
it's
got
a
link,
pull
request.
A
E
A
So
that's
where
we're
at
with
that
the
done
we've
got
31
items
in
that
column,
two's
closing
this
last
update,
so
there
have
been
movements
on
on
pr's
in
general
about
a
week
less
than
a
week.
If
pr
gets
up
like
I
saw
one
go
through
in
like
like
a
matter
of
a
few
days,
so
we've
got
velocity
there.
We
just
have
to
come
to
resolution
as
to
what
the
decision
is.
A
C
A
Leave
this
one
tyler
had
input
on
this.
This
might
affect
other
languages.
H
H
Is
that
this
is
trying
to
add
a
new
method
to
the
api
right
now,
and
I
think
if
there
was
a
a
question
if
that
was
actually
used
in
the
api,
but
it
was
up
for
debate,
I
think,
was
the
idea,
mostly
from
the
fact
that
it
was
already
implemented
in
other
sdks.
I
think
the
issue
we
wanted
to
kind
of
highlight
here
in
this
meeting
today
is
that
it
was
tagged
as
required
for
ga.
The
thing
is
this
word
with
just
coming
to
that
decision.
H
I
think
prior
to
g,
but
I
don't
think
that
we're
trying
to
add
any
other
features
to
the
api
after
this.
So
this
was
kind
of
a
special
case,
given
that
it
had
some
precedence
already
existing
in
the
sdk.
It
was
whether
it
should
exist
in
the
api,
but
I
think.
H
E
I
I
completely
agree
with
you
and
also
if
you
read
the
the
discussion
down
the
the
comments,
the
guy
who
one
of
the
person
who
is
supporting
s,
that
h
was
discussing
a
lot
about
the
sdk
functionality
that
is
available
in
co
and
I'm
like.
Are
you
sure
we
are
talking
about
the
api.
H
Yeah,
that
looks
to
be
the
case.
I
think,
there's
probably
just
a
confusion.
There
yeah
the
specific
issue
itself
I
can
probably
try
to.
I
could
do
a
better
job
pointing
in
on
this
but
yeah.
I
think
that
just
for
the
maintainers,
we
were
trying
to
address.
Oh
closed.
It
that's
right.
G
I
H
Think
we
can
probably
talk
a
little
bit
more
about
this.
I
know
anthony's
also
on
the
call
from
the
go
sdr
from
the
go
sig
as
well,
so
we
could
probably
address
this.
I
think
in
our
go.
C
I
C
Okay,
so
it
sounds
like
we'll
talk
a
little
talk
about
this
tomorrow,
the
specs
meeting
and
presumably
move
it
over
as
an
sdk
issue,
rather
than
an
api
issue.
Sweet
awesome
all
right,
thanks
for
highlighting
that
andrew.
C
No,
I
will
start
sharing,
so
this
is
gonna
be
an
interesting
discussion
for
everyone.
So
we
decided
last
week
during
this
meeting
that
the
tracing
spec
is
effectively
locked,
modulo,
the
two
or
three
p1
issues
that
are
still
open
being
fixed
right
now,
but
those
will
be
the
as
far
as
we
know,
those
will
be
the
last
things
that
go
into
the
really
first
release
candidate
of
the
spec,
which
means
that
sdk
groups
and
other
sigs
within
open
telemetry
can
start
building
against
the
majority
of
the
tracing
spec.
C
C
Last
week
there
was
the
sort
of
open
governance
meeting
that
anyone
anyone
could
join
and
some
of
the
folks
from
I
think,
new
relic
and
amazon
and
some
other
places
that
said
hey
you
know,
are
we
going
to
announce
this
sometime
soon,
so
I've
started
writing
up
a
draft
blog
post
for
the
announcement
of
the
rc
of
the
tracing
specification
and
and
then
announcing
that
the
rcs
for
the
sdks
and
rc's
for
the
metric
spec
will
be
coming
shortly.
Of
course,
the
sdk
is
arrived
before
the
metric
spec.
C
I
anticipate
that
we
want
to
post
this
to
the
open,
telemetry
blog,
probably
sometime
early
next
week,
and
then,
if
there
are
other
contributors
who
want
to
you,
know
repost
it
retweet
it
write
their
own
blog
posts
that
mention
it
do
whatever
they
want.
They
can
use
an
opportunity.
They
can
use
this
as
an
opportunity
to
do
that.
D
C
Exactly-
and
this
is
exactly
what
I
had
in
mind
so
like
if
there
are
vendors
who
want
to
cross
post-
and
this
is
exactly
what
we
did
for
the
beta,
where
we
had
the
main
blog
post
on
the
projects-
medium
blog
and
then,
if
there
are
vendors
or
contributors,
because,
of
course
not
all
the
contributors,
even
vendors
like
if
bob
at
mailchimp
or
or
the
folks
at
shopify,
for
example,
wanted
to
post
about
their
progress
on
their
engineering
blog.
C
I'm
sure
this
is
a
good
opportunity
to
do
that,
and,
and
so
typically,
what
we
did
in
the
beta,
which
I
think
was
effective,
was
that
the
cross
posts
would
usually
contain
the
text
or
link
to
the
medium
post
for
the
project
and
then
have
their
own
introduction
written
by
whoever
wanted
to
write
it
at
that
group.
C
C
C
So
if
everyone
is
agreeable,
I'd
recommend
that
we
post
this
either
next
week,
monday
tuesday,
just
explaining
the
status
of
the
release
candidate,
that
the
tracing
specification
is
effectively
locked.
If
one
or
two
of
those
issues
that
are
still
around
are
still
open,
then
we'll
make
sure
that
that's
reference
to
those
last
things
to
go
in
and
then
lay
out
the
progress
for
the
sdk
sdk
release
candidates
that
those
will
come
shortly
and
they'll
have
their
own
small
announcements.
C
That
will
then
be
shifting.
Our
focus
to
the
metric
specification
then
followed
by
metrics.
Release
can
followed
by
release
candidates
for
the
sdks,
including
the
metrics
functionality,
followed
by
an
eventual
ga
once
we're
satisfied
that,
with
the
quality
of
everything,
that's
in
those
sdks,
I've
posted
oh,
go
ahead.
Bob!
I
don't
want
to
open
a
can
of
worms,
but
what
happens?
C
If
we
go
into
these
release
candidates-
and
we
find
a
large
regression-
then
we
got
to
fix
it
and
it'll
be
a
breaking
change
and
I
was
going
to
put
that
in
the
blog
post,
like
this,
isn't
a
promise
of
like
zero
breaking
changes.
This
is
a
promise
of
unless
we
find
something
that
is
awful
and
makes
us
cry
and
breaks
everything
no
breaking
changes,
but
we
reserve
the
right
to
fix
anything
like
and
I
that's
the
whole
point
of
a
release.
C
C
J
C
Yeah,
so
I
was
thinking
early
next
week.
Is
there
any
feedback
from
the
folks
on
this
call
about
like?
Do
we
think
we're
ready
for
that,
like?
I
suspect,
the
answer
is
yes,
and
secondly,
like
do
we
aim,
like
are
people
okay
of
like
monday
or
tuesday
or
wednesday,
or
something
like
that
next
week,.
A
I
got
a
question
about
like
the
timings
you're
desiring
to
put
in
the
blog
posts
after
the
trace
spec
freeze,
like
saying
when
things
will
be
implemented
for
the
sdk
and
also
the
metrics
api.
My
concern
is
yeah.
I
I
saw
I
just
had
a
very
quick
look
at
the
draft
yeah
just
this
morning
and
it
mentions
like
desired
north
korea
by
kubecon,
which
is
november
17th
right.
That's
like
one
month
plus
five
days.
Perhaps
yeah
for
ga
is
it
I
is
it.
I.
C
C
I
think
we
want
something
to
announce
during
the
open
telemetry
community
day.
That
might
be
a
full
ga.
Yes,
at
this
point,
I
kind
of
doubt
it
to
be
honest,
could
be.
C
It
might
be
might
be
that
all
the
sdks
are
tracing
in
them.
I
think,
will
easily
hit
that
tracing
rc
for
most
sdks
or
might
be
something
in
between
where
we
say
the
tracing
sdks
are
rc.
The
metric
spec
is
rc,
and
maybe
one
or
two
of
the
sdks
also
the
metrics
rc.
C
It's
more
that
I
it's
less
about
tying
certain
specific
releases
to
the
open
telemetry
community
today,
but
rather
saying
hey.
We
should
have
something
to
show
off,
even
if
it's
literally
just
the
the
tracing
sdks
being
rc
quality.
A
All
right
because
the
as
it
pertains
towards
the
languages
that
were
mentioned
in
your
older
blog
posts,
yeah
I
mean
there
was
just
a
general.
We
talked
about
this
before
in
the
maintainers
meeting,
there
was
a
general
yep
raf
off
estimates
like
four
weeks
for
implementation.
I
don't
know
whether
that's
the
same
for
every
single
language
yeah.
I
don't
know
whether
that
makes
it
for
being
able
to
have
that
whether
we
want
to
have
guidance
on
that
or
get
estimates
from
the
maintainers
first.
For
that.
C
And
that's
that's
what
I
was
actually
looking
for
here
so,
like
I,
I
think
everybody's
probably
confident
in
that
the
the
tracing
specification,
rc
modulo,
those
like
two
issues
or
three
issues-
is
pretty
good
to
go
as
an
rc
just
for
the
spec.
But
I'm
curious,
like
in
this
blog
post,
we're
gonna
spell
out
for
the
community,
the
timelines
of
when
we
think
the
next
things
are
gonna
happen.
We
don't
need
specifics,
but,
like
you
know
like
I,
I
do.
C
C
Do
we
do
we
expect
that
the
metric
spec
will
be
locked
on
the
order
of
weeks?
I'm
guessing.
We
far
less
confidence
in
that
just
because
we
haven't
really
applied
the
same
focus
to
metrics
that
we've
done
for
tracing
the
last
few
weeks.
A
D
C
Do
this
yeah,
and-
and
we
can
do
that
this
week
before
we
post
this,
the
the
main
purpose
of
posting
this
by
the
way
is,
is
a
little
bit
to
rally
people
around
open,
telemetry
and
show
progress,
and
all
of
that,
a
lot
of
it's
also
like
we
have
various
people
who
don't
always
come
to
the
maintainers
meeting
in
the
community
already
or
or
people
who
are
making
small
contributions
through
saying
hey.
When
are
you
going?
C
When
are
you
going
ga
the
last
time
you
sent
out
an
update
was
months
ago,
and
so
a
lot
of
this
is
just
to
fill
people
in
on
where
we
are
as
a
project
the
milestones
we've
hit
and
when
we
expect
the
the
next
milestones
to
be
because
I've
definitely
gotten
feedback
from
people.
Even
inside
of
google
saying
hey,
we
haven't
really
had
a
status
update
in
several
months
like
where
are
you
what's
going
on.
A
I
A
C
D
Morgan,
maybe
it's
a
good
idea
to
actually
level
set
in
this
post
that
there
will
be
multiple
rc's
before
a
ga
right,
because
I
mean
that's
the
life
cycle
of
a
project
and
yes
to
not
commit
necessarily
that
you
know
hey.
Ga
is
going
to
be
by
this
a
few
weeks.
C
C
D
C
Sitting
and
working
on
rc's,
quite
happily
for
quite
a
while
yep
and
so
we'll
make
sure
I'll
make
sure
the
focus
is
around
that.
Regarding
timing,
the
post,
I'm
just
looking
at
my
calendar-
I
recommend
next
week,
wednesday,
so
that's
october
21st.
That
gives
us
time
to
write
it.
That
gives
us
also
two
days
after
next
week's
maintainers
meeting,
to
make
any
changes
or
adjustments
that
we
want.
Alternatively,
we
could
do
the
20th
kind
of
different
between
those.
C
The
21st
gives
us
an
extra
day
for
tweaks,
just
because
I
know
some
not
so
much
at
google,
but
some
places
the
the
their
cross
posts
might
be
locked
within
24
hours
of
prior
to
posting.
D
D
I
would
say
a
tuesday
we
target
tuesday
morning.
C
D
D
Yeah,
that
sounds
good.
That
sounds
good
and,
and
the
other
question
I
had
in
relationship
to
that
is
the
you
know.
Rc
is
the
next
set
of
rc
artifacts
available.
D
For
you
know
the
relatively
stable
languages
like
javascript
java
is
that
is
there
a
at
least
an
anticipation
of
when
these
artifacts
would
be
available.
E
C
E
C
C
J
F
C
F
C
C
D
But
does
does
that
need
to
be?
Is
that
a
must-have
andrew
for
on
the
next
rc.
A
So
that's
one
of
the
outstanding
questions
is
like
what
on
this
table
needs
roads
to
be
able
to
say.
Yes,
we've
defined
everything
on
the
trace,
spec
api.
We
want
to
freeze,
of
course,
the
trace
table,
but
are
there
any
like
dependencies
blockers
on
baggage
on
resource
on
errors
down
below
that?
Like
are
strongly
tied
towards
the
trace
table.
A
C
C
E
C
B
B
C
A
C
E
C
Like
we've
got
a
bit
of
time-
and
I
you
know
we're
so
close
to
to
sort
of
both
announcing
and
starting
to
cut
releases
that
it's
it's
worth
going
over
item
by
item
here
like
things
that
we
think
can
be
excluded.
Let's
focus
on
the
exclude
list
because
I
think
the
majority
of
items
are
already
done
and
includable.
E
C
B
B
D
This
thing
right
so
I
mean:
doesn't
that
align
with
bogdan's
suggestion
of
you
know
clearly
calling
out
what's
in
the
api
versus.
B
D
B
No
strong
opinion,
my
my
worry
is,
for
example,
like
at
link.
We
know
that
api
has
to
exist
and
also
that
api
has
to
be
a
no
hop
in
api
package
and
in
sdk
it
has
to
be
a
bonded
like
array
or
like
collection
or
something,
and
then
we
have
to
split
that
into
like
two
two
items:
one
for
the
api
table,
another
for
the
sdk
table.
It
seems
extra
work,
working.
E
B
I
I
see
so,
for
example,
if
we
have
a
add
link
here,
like
the
downline
tell
tell
us
like,
we
have
the
add
link
api
implemented,
but
it
is
okay
for
the
for
the
individual
sdk
to
say
we
don't
have
the
actual
implementation,
we'll
just
drop
the
data
on
the
floor.
E
I'm
not
saying
that
that's
fine,
I'm
just
saying
that
maybe
we
should
track
it
separately
like
do
you
have
the
api?
Do
you
have
the
that
includes
the
default
implementation
which
is
not,
and
then
we
do.
You
have
the
sdk
implementation
of
that.
B
Have
it
I
want
to
avoid
the
situation
where
we
have
the
ad
link
in
the
api,
but
not
in
nice.
You
can
create
a
like
a
limbo
state.
C
One
procedural
thing:
andrew:
do
you
want
to
continue
leading
this
discussion?
I
suddenly
started
feeling
very
nauseous
and
I'm
gonna
hop
off
the
call
because
I
feel
very
sick,
sure
sure.
E
A
Okay,
let's,
ultimately,
if
I
can
propose
something
that
would
help
with
the
blog
post
and
also
set
direction
for
the
future
is
clearly
what
has
been
accomplished
for
the
trace,
spec
api
freeze
and
if
we
got
this
exception,
like
it
sounds
like
with
bogdan's
boarding,
there's
one
or
two
issues
on
the
exception,
what
those
are
that
is
like
excluded
for
that,
so
that
we
know
that
is
like
the
primary
focus
for
it
and
then
a
path
towards
what
the
languages
need
to
implement
for
the
next
milestones
coming
up
in
order
to
satisfy
the
trace
api,
the
metrics
api
and
stuff
like
that.
A
A
Like
initially
put
this
together
right,
yeah
for
the
stuff
he's
not
on
the
call,
we
can
take
this
to
this
spec
stick.
So
we
have
all
the
proper
audience
in
order
to
be
able
to
specify
this.
But
as
long
as
we
have
the
timeline
that,
like
whatever
we
need
to
do
in
order
to
clear
this
up,
so
that
way,
we
have
confidence
behind
the
blog
post
of
where
we're
trying
to.
B
E
B
E
I
think
we
need
a
bit
more
attention
on
this
if
we
want
to
track
using
these
metrics.
I
think
somebody
has
to
go
over
these
metrics
and
do
the
the
changes
to
to
update
with
the
latest
version
of
the
spec,
especially
now
now
that
we
almost
freeze,
we
have
only
one
or
two
changes
in
the
pipeline,
but
I
think
it
needs
a
revisit
the
whole
matrix
and
maybe
maybe
removed
a
bunch
of
classes
and
asked
people
to
re-add
them
just
to
to
double
check
the
the
things
yes.
B
H
Just
just
to
keep
it
in
mind,
all
the
maintainers
are
on
this
call,
so
I
mean
I
think,
everyone's
hearing
it
right
now.
I
think
that
everyone
understands
that.
I
also
think
that
it's
probably
something
that
should
be
like
the
final
checklist
that
everyone
goes
through,
as
they
say
that
they're
ready
for
an
rc.
E
Do
we
want
to
put
on
every
of
these
titles,
like
the
tracer
provider?
Tracer
span
context,
all
the
titles
in
the
table.
Do
we
want
to
put
do
we
want
to
put
a
rc
requirement?
Is
this
rc1
rc2,
or
something
like
that?
E
Okay,
so
I
will
take
as
an
action
item
this
today
to
revisit
the
matrix
and
try
to
update
it
and
clear
all
the
pluses
just
for
for
for
I.
I
know
I'm
gonna
generate
more
work
for
you
maintainers,
sorry
for
that,
but
I
think
it's
it's
good
to
double
check
all
the
pluses
and
minuses.
D
So
bogdan,
is
it
also
possible
once
you
get
feedback
from
all
the
maintainers,
on
your
updates
to
kind
of
also
have
some
guidance
on
the
languages
that
are
going
ready?
First,
the
language
sdk
apis
yeah.
E
I
think
I
think
I
think
we
need
to
ask
everyone
in
terms
of
languages,
I
mean
we
can
go
over
everyone
and
based
on
their
current
understanding
of
the
specs.
How
much
work
do
they
feel
it's
left?
We
can
do
this
experiment,
we
have
couple
of
minutes,
so
maybe
we
start
in
the
order.
Like
the
goal,
I
think
tyler
you
are
here
correct,
yeah
how
how
much?
What
do
you
feel
is
left
for
for
go
to
to
finish
this.
H
Way
to
put
me
on
the
spot,
man-
I
I
I
don't
know,
I
have
to
look
through
this
again.
I
filled
this
out
a
while
ago,
but
I
I'd
have
to
validate
each
one
of
these
things
like
you're,
saying,
like
some
of
the
stuff,
has
changed
in
the
specification,
but
I
we're
getting
pretty
close
to.
H
E
Okay,
do
I
I
mean
based
on
this
answer,
I
would
suggest
every
maintainer
for
the
next
week
to
prepare
a
better
understanding
of
these,
so
I'm
I'm
committed
to
do
the
matrix,
but
everyone
else,
based
on
the
new
matrix
and
based
on
maybe
rechecking,
all
the
specs
and
stuff
have
an
estimate
that
we
can
work
with
and
alolita
can
have
an
answer
for
this
as
well,
and
everyone
can
understand
better
of
the
status.
Is
that
reasonable
to
have
next
week,
maybe
andrew?
E
E
Trace
table
context
table
if
there
is
one
context
propagation
table
that
one
yeah
in
the
and
that's
it.
These
two
are
the
main
two
things
in
my
opinion.
E
Let's
focus
on
these
two
tables
first
matt
and
then
because
I
think,
in
order
for
us
to
be
called
rc1,
I
know
you
need
to
have
exporters
to
be
able,
but
I
don't
think
you
need
all
the
exporters
in
rc1.
If
you
have
one
of
them,
it's
probably
good
enough
for
people
to
start
playing
with
this
and
in
a
more
stable
thing
and
just
for
rc1.
I
would
call
only
that
those
two
tables
that
I
mentioned
as
critical
and
required
and
for
rc2.
Indeed
I
will
add
baggages
and
I
will
add
the
exporters
table
as.
L
Like
you
know,
rc2rc3
are
like
bug
fixes
on
the
original
rc
until
no
more
bugs
have
been
found.
This
is
my
you
know
traditional
view
of.
K
L
D
Mean
usually
matt,
I
mean
I've
seen
no
more
than
three
rc's
right
so,
but
you
can
have
two
at
least.
K
Yeah,
it
would
be
fine
with
a
couple
of
rc's
if
we
find
defects
that
need
to
be
addressed
in
an
rc,
but
I
wouldn't
call
something
that
is
not
feature
complete
and
ready
to
ship
an
rc,
because
if,
if
we
don't
find
any
defects,
rc1
could
become
the
ga
release
that
same
commit.
E
D
E
Then,
let's
not
call
them
rc's
call
them
milestone,
one
whatever
for
for
the
languages,
but
I
still
think
if,
if
I
would
have
to
prioritize
something,
if
I
were
one
of
the
segmentainer
in
any
of
these
languages,
I
would
prioritize
that
these
two
tables
that
we
discussed
first
and
then
the
rest
of
the
world,
so
maybe
maybe
not
call
it
rc1
or
whatever,
maybe
call
it
milestone,
one
for
implementation
towards
irc
or
whatever
we
call
it,
but
I
think
I
still
think
that's
the
priority.
E
D
So
andrew,
would
it
be
like
my
beta
my
milestone,
one
milestone,
two,
I'm
just
trying
to
understand
the
convention
so
that
we
can.
You
know.
A
I
think
beta
gives
us
more.
Flexibility
is
be
able
to
define
what
to
expect
and
then
leads
on
to
the
normal
convention
of
rc,
and
all
that
I
agree
with
all
those
points
I
suggest
we
take
it
towards
the
feedback
of
the
draft
blog
post
that
morgan's
putting
together
first,
so
you
can
put
together
the
first
draw
man
and
then
we
can
like
tweak.
It
he's
like
he's
saying
rc
all
over
the
place
he's
not
here,
but
let's
then
bring
it
there
as
a
comment
like
hey
instead
of
rc,
we
talked
about.
A
Let's
talk
about
like
milestone.
Instead,
we've
got
like
at
least
a
week
in
order
to
be
able
to
work
on
that
type
of
wordsmithing,
and
then.
A
So
trying
to
get
to
a
trace,
spec
freeze,
however,
we've
been
defining
that
right
as
a
thing
of
like
no
more
breaking
changes.
You
can
add
editorial
changes
and
such
like
that,
which
is
why
I've
been
very
careful
to
use
the
word
trace,
spec
freeze.
In
all
the
times,
I've
been
talking
about
the
p1
issues.
K
Yeah
and
I
I
think
for
the
spec
that
that
means
that
those
are
rc's
and
unless
in
implementing
these
milestones
for
the
individual
implementations,
we
find
something
that
causes
us
to
go
back
and
change.
The
traceback,
though
those
spec
rcs,
become
ga.
Once
we
hit
rc's
with
all
of
the
implementations
and
are
comfortable
with
the
spec.
H
Just
a
real
nitpick
thing,
we're
technically
already
in
beta,
so
we'd
have
to
be
going
and
releasing
a
gamma
just
yeah.
H
E
A
E
A
I
D
E
No,
I
mean,
let's
not,
I
don't
know,
what's
the
terminology,
but
I
think
we
should
follow
some
kind
of
milestone.
Some
some
schedule
here
and
I
think
the
the
proposed
one
is
good
enough
in
terms
of
names.
I
don't
care
you
guys
who
want
to
publish
this.
You
can
use
whatever
names
you
want
as
long
as
they
are
fine
and
accepted
by
the.
J
I
would
suggest
that
that
there's
some
consistency
in
naming
this
I
mean
if
it's
like
rc
one
milestone,
one
that
seems
you
know
better
than
candidate
candidate
and
if
and
if
we
can
get
agreement
in
this
meeting,
I
think
that'll
ease
the
communication
between
language
communities
and
this
group.
K
Yeah,
I
think,
if
we're
talking
about
milestones
on
the
way
to
an
rc,
that's
that's
what
yeah!
That's
where
we're
at
right,
so
the
the
trace
and
contact
propagation
are
the
first
milestones
ensuring
that
those
are
in
place
and
then
the
next
milestones
are
the
baggage
and
exporters
resources
and
all
of
those
yeah
yep.
J
The
other,
the
other
thought
I
had
about
you
know
relating
these
milestones
to
the
blog
post,
I
think
from
from
the
blog
post
readers
point
of
view,
a
lot
of
times,
they're
just
going
to
be
like
I'm
a
php
developer,
I'm
reading
the
blog
post,
I
want
to
know
when
php
is
going
to
ga
or
how
close
it
is
so
I'll
make
the
suggestion
in
the
blog
draft
doc
as
well.
M
Hey
this
is
josh
sorett,
I'm
I
work
with
morgan,
so
I'm
trying
to
fill
in
a
little
bit
while
he's
out
sick.
The
most
important
thing,
I
think
from
our
standpoint,
is
that
there's
a
clear
definition
of
what
the
milestones
are
and
include,
as
opposed
to
the
actual
name,
I'd
encourage
using
milestones
just
because
we
keep
saying
that
same
word
over
and
over
and
saying
we
don't
want
to
use
milestone,
but
then
we
keep
using
the
word.
M
So
I
would
recommend
that
since
everybody
seems
to
know
what
it
means,
but
that
said,
the
most
important
thing
is
just
that
you
clearly
define
this
is
milestone
one.
This
is
milestone
two
and
then
milestone
whatever
is
released
right.
That's
the
release
candidate.
So
as
long
as
it's
clear,
that's
the
important
bit,
everything
else
is
kind
of,
like
you
know,
word
wrapping.
D
L
I
have
one
other
question
as
as
we
ga
and
we're
talking
about
like
versioning,
it's
we're
kind
of
like
gaying,
a
signal
at
a
time,
so
we're
really
just
gaying
like
tracing
initially.
Would
that
go
under
a
1.0
or
would
this
be
like
pre
1.0
until
we
ga
like
metrics
and
in
the
future
logs,
or
has
anybody
kind
of
thought
about
the
the
larger
scheme
of.
K
So
I
can't
speak
for
everybody,
but
my
thinking
with
the
go
sdk
has
been
that
we
would
be
1.0
when
traces
and
metrics
are
in
a
stable
state
logged
in
we've,
always
discussed
as
being
post.
D
K
So
I
think
that,
even
when
we're
stable
with
traces,
we
would
probably
not
yet
be
1.0,
because
we
have
traces
and
metrics
in
the
same
api
package
and
backwards
incompatible.
Changes
to
metrics
would
then
require
us
to
jump
to
2.0.
E
D
Working,
I
think,
worked
in
that
works,
except
that
we
just
need
to
somehow
allude
to
the
phases
in
the
blog
post
next
week.
That's
all.
J
Yeah,
I
think
what
constitutes
1.0
ga
is
an
important
thing
to
have
in
the
blog
post.
I
asked
this
question
at
the
community
meeting
last
thursday
and
ben
and
morgan
both
said
that
definition
of
ga
should
be
both
metrics
and
traces
that
it's
not
going
to
be
staggered
for
ga.
It's
only
staggered
for
these
release.
Candidate
milestones.
D
A
A
If
not,
I
know
there
are
some
other
maintainers
that
hadn't
made
this
call
today,
just
like
18
or
20
on
the
line
so
I'll
post
in
the
spec
sick,
getter.
Sorry,
the
spec
getter
channel
a
summary
in
order
to
set
expectations
for
what
we're
trying
to
shoot
for
next
week.
For
estimates
of
the
trace
table
contacts,
propagation
table
and
such.