►
From YouTube: 2020-10-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).
B
B
C
D
No,
I
was
about
to
actually
send
you
a
dm
being
like.
What's
up
john
yeah,
I
was
I've
been
having
some
family
stuff,
so
I've
been
out
for
past
two
weeks,
but
now
I'm
back
sweet
good
to
have
you.
D
E
F
E
Come
on
all
right,
oh
go
ahead!.
H
A
Latest
update,
we've
had
a
very
productive
issue,
scrub
issue,
triage
meeting
on
friday,
where
we
took
stock
off
the
latest
p.
Once
some
of
them
got
close,
some
of
them
got
de-prioritized.
A
We
brought
in
a
few
net
net.
We
got
still
three
two
items
and
to
do
one
item
in
progress
specifically,
let
me
see
this
burn
down.
Chart
shows
the
one:
that's
in
progress
is
the
api
behavior
of
baggage.
A
This
one
got
assigned
to
carlos
on
friday
is
the
one
that
has
yet
to
have
pr
open
for
it,
and
then
we
also
have
one
more:
that's
not
on
this
chart
and
it's
because
it
overlaps
between
metrics
and
tracing
and
it's
this
one,
which
is
ongoing
discussion
on
the
spec
sig
meeting
in
order
to
resolve
the
naming
labels
versus
attributes.
C
So
just
my
the
one
on
baggage
in
the
api
has
three
approvals
at
the
moment,
so
other
main
other
spec
approvers.
Please
look
if
we
want
to
get
it
approved.
A
I
also
have
other
items
on
the
agenda
which
carry
over
from
last
meeting
and
then
also
items
leading
into
the
ga
planning
list
that
could
be
considered
for
the
blog
post.
I
saw
there's
some
activity
on
the
blog
post
morgan
that
you
you
worked
on
the
drop
since
last
week
and
then
I
also
have
a
15
minute
time
box.
This
can
go
at
the
very
end
actually
before.
I
F
Way,
yeah
yeah
tigran,
because
you
know
we're
we're
also
building
some
components
based
on
the
assumptions
that
are
ongoing
in
the
thread
and
other
threads
tigran,
where
you're
you've
responded,
specifically
building
out
processors
for
handling
labels
right.
I
J
So
I'd
like
to
speak,
so
this
is
a
science
to
me
and
I
haven't
had
a
chance
to
to
write
a
summary
of
what
we
discussed
in
the
last
meeting
on
friday.
I
see
you're
very
concerned
about
tigran,
and
I
want
us
to
want
to
soothe
your
concerns
that
we're
not
talking
about
changing
away
from
the
word
attribute
anymore.
J
There's
no
there's
nobody
who's,
proposing
that
what
we
are
talking
about
is
a
change
of
the
word
label
for
the
metric
spec,
which
shouldn't
be
a
concern
for
for
the
compatibility
guarantees
for
tracing,
but
it's
still
a
pretty
big
change
to
sell
to
the
metrics
group.
So
we
can't
just
rush
this
through.
I
I'm
concerned
that
we're
rushing
something-
and
I
think,
there's
a
way
to
do
this
by
only
changing
words
in
our
specification,
but
bogdan
objects.
J
I
Okay;
okay,
in
that
case,
can
we
let's
say
that
we
are
not
changing
the
attributes?
We
keep
the
attributes,
and
that
means
that
nothing
changes
for
traces,
whatever
we
will
change,
will
affect
metrics
only
so
in
that
case,
this
is
not
a
problem
that
can
prevent
us
from
declaring
the
traces
portion
at
least
frozen,
but.
J
On
the
other
hand,
I'm
not
willing
to
change
the
metrics
protocol
at
this
point
because
we're
using
it
as
well.
So
I
think
that's
why
I'm
trying
to
propose
that
this
can
be
a
words.
Only
change
we'll
start
calling
labels
attributes
and
not
change
the
protocol,
which
means
that
labels
or
attributes
are
string
valued
in
metrics
and
and
not
otherwise,
and
that's
okay.
I
I
understand
I
understand
josh,
so
what
you're
saying
is
a
is
a
much
safer
change
right,
but
I'm
also
saying
if
you
don't
want
to
rush-
and
I
agree-
let's
not
rush-
can
we
at
least
declare
that
we
decided
that
if
we
want
to
make
the
change
it's
going
to
be
a
change
in
the
metrics
portion,
so
labels
will
become
attributes,
but
we're
not
going
to
change
anything
in
the
traces
portion.
Attributes
will
remain
attributes
which
means
that
we're
free.
I
J
I
I
will
but
I'd
like
to
hear
if
anybody
here
in
this
meeting
objects
to
that
any
other
objections.
J
I
Okay,
and
if
we
do
that,
the
remaining
sorry
andrew
candy,
can
you
go
back
to
the
remaining
two?
Yes,
so
this
one,
I
think,
is
okay.
This
is
assigned
to
carlos
scarless
and
nicole
yeah.
L
We
already
required
that
trace
context
propagator
exists,
but
it
needs
to
be
clarified
because
now
we
are
using
a
may,
but
this
may
is
about
the
fact
that
trace
propagator
trace
context.
Propagator
may
exist
in
the
api.
L
L
I
Small
change
right
I
agree
and
the
last
one
is
and
you're
sorry
can
you
go
back
to
the
last
one
api
behavior?
This
is
signed
to
john
john.
What's
what
do
you
think
about
this
one?
So
this
I
guess
the
only
one
remaining
in
that
case
yeah.
C
As
I
said,
I've
got
the
pr.
I
L
I
I
A
Okay,
so
if
we
can
move
on
the
other
items
that
I
brought
up
morgan
you
might,
you
might
have
missed
the
last
portion
of
last
week's
meeting
where
we
went
on
to
take
a
look
at
the
compliance
matrix.
E
Yeah,
no
I'm
seeing
what's
right.
I
was
feeling
pretty
nauseous.
Last
we
get
food
poisoning.
Yes,
so
yeah
do
you
want
to
catch
me
and
everyone
else
up.
A
Yeah,
so
if
we
took
a
look
at
the
compliance
matrix
and
in
order
to
do
the
estimates
of
what
could
be
implemented,
it
was
proposed
that
perhaps
two
milestones
as
a
stepping
stone-
okay,
one
for
the
trace
and
context
propagation
table,
yep
and
another
submit
for
baggage
exporters,
resources,
environment
variable-
okay,
I
think,
is-
I
don't
know,
bargains
on
the
call
but
like
he
was
going
to
take
a
look
at
this
and
now
he's
an
uncle
and
was
going
to
have.
A
I
think
one
last
look
through
this
and
scrub
it
before
people
before
the
maintainers
were
to
do
estimates
on
what
were
the
remaining
items,
either
minus
signs
or
empty
boxes
in
order
to
have
at
least
some
idea
of
like.
Is
this
like
one
way
two
weeks
three
weeks
forward,
so
I
was
like
so
we
could
put
some
idea
of
what's
to
come
in
the
blog
posts.
A
Okay,
I'm
not
sure,
what's
the
best
way
to
collect
this
information,
so
I
just
created
this
list
here.
I
could
also
create
issues
on
every
one
of
the.
E
I
mean
we
also
just
maintainers
on
the
call
right
like
like
we
can
just
go
through
each
language
real
quickly
and
just
see
if
people
happen
to
have
estimates,
I
mean
if
they
don't
that's.
Okay,
but
like
do
we
have
any
java
maintainers
on
the
call
we
can
speak
to
how
long
they
think
it's
going
to
take
to
implement,
trace
and
context
propagation.
So.
C
I
spent
some
time
friday,
looking
through
the
matrix
and
was
going
to
update
it
and
realized
that
bogdan
had
not
gone
through
and
done
his
scrub
in
the
api
sdk
separation.
So
it
was
a
little
tricky
to
figure
out.
I
didn't
want
to
put
in
pr,
because
I
know
this
thing
is
going
to
change,
but
my
guess
is
once
we've
actually
got
spec
solidified
we're
talking
about
three
weeks
for
getting
to
release
candidate
and
that's
probably
that's
a
fairly
conservative
estimate.
I.
C
All
all
of
the
all
right,
I
above
the
low-
I
think,
the
long
pole
and
the
pin
at
this
point
we're
doing
some
kind
of
api
solidification
making
changing
a
little
bit,
but
it
doesn't
affect
any
functionality.
But
then
I
really
would
love
some
help.
If
there's
some
jaeger
folk
who
could
help
us,
we
don't
have
a
jager
propagator
and
the
eight
year
exporter
needs
some
work.
So
I'm
kind
of
making
a
call
for
someone
who
could
help
with
some
jager.
L
Sorry,
john,
I'm
working
on
that.
This
is
part
of
a
pr
that
I
prepared,
but
it's
not
still
finished
yeah,
so
that
that's
for
me,
do
you
think
you're
gonna
have
time
to
work
on
it
in
the
next
few
weeks.
Yeah
it's
like
it's
held
on
locally.
I
need
to
write
more
tests,
so
yeah.
M
I
mean
from
this
matrix
sorry
from
this
compliance
table,
but
yeah.
So
the
shutdown
is
it's
there.
You
can
call
the
shutdown
but
then
getting
the
active
spam
for
the
current
context.
I'm
afraid
this
is
not.
I
mean
for
the
active
context,
so
this
is
fine,
so
it
shouldn't
be
so
complicated
to
set
a
certain
span
for
the
certain
context.
M
E
E
Yeah,
okay,
do
we
have
anyone
from.
N
Python
yeah,
I
think,
for
the
trace
and
context.
We
said
two
weeks
for
that:
okay,.
P
Yeah
two
weeks
sounds
like
a
good
conservative
for
both
cool.
E
Q
Q
Q
E
I
E
F
A
Sure
so
I
I
also
want
to
highlight
this
list
that
we
created
a
while
back
for
open,
telemetry,
ga
planning
that
we've
been
working
towards
we've
been
hitting
some
of
the
items
on
here,
but
I
was
wondering
if
it's
worthwhile
in
order
to
revisit
some
of
these.
A
A
Like
yeah,
if
this
comes
up
this
comes
up,
maybe
it's
not
that
one
yeah,
the
integration
testing
one
like
there's,
already
been
work-
that's
been
put
onto
it
but,
like
it
closed
because
the
bottom
in
activity,
yes.
A
All
right,
so
I
okay,
two
questions.
One,
do
we
need
a
time
in
order
to
scrub
these
in
order
to
be
able
to
get
an
accurate
status
on
these,
or
maybe
just
you
know,
decide
do
we
really
want
some
of
these?
Like
there's,
no
owner
of
open
system
compatibility.
E
A
E
Will
haven't
we've
an
owner
from
google
I
can
put
on
it,
so
I
have
good
news
for
some
of
these,
like
certainly
for
like
performance
testing,
integration,
testing,
open
census,
compatibility,
we've,
we've
added
more
staff
to
our
open,
telemetry
team
at
google,
and
this.
These
are
the
sort
of
things
that
I
think
both
I
and
they
want
to
work
on.
E
So
we
will
have
we.
We
do
have
more
firepower
for
these
and
I'll
make
sure
they
start
joining
this
meeting
every
monday.
However,
you're
right,
we
haven't
gone
through
this
list
in
a
long
time.
I
doubt
that
much
progress
has
been
made,
if
only
because
we've,
like
correctly,
I
think,
being
so
focused
on
the
tracing
spec
rc,
do
you
think
it's
a
good
use
of
time
to
go
over
now?
I
suspect
it
is.
A
R
Progress
one
one
thinking
like
yeah,
the
tracing
part
in
this
bag
is
almost
done.
I
I
think
from
probably
for
integration
testing
we
can
focus
on
the
tracing
part.
I
can
probably
scrape
the
first
pr
just
to
cover
like
make
sure
we
have
the
minimum
integration
test
and
then
increase
from
that
base.
The
initial
problem
I've
seen
is:
we
want
to
have
some
like
proposal
that
covers
all
the
aspects.
R
E
And
this
is
for
surrey
riley,
I
just
sort
of
zoned
out
for
a
second.
This
is
for
for
integration,
testing,
yeah
yeah.
I
think
I
think
the
other
challenge
has
just
been
it's.
It's.
It's
been
a
little
early
right,
like
our
focus
has
just
been
on
the
spec
when
the
spec
is
changing.
E
E
F
And
mark-
and
we
can
also
help
here
because
we
have
been
building
out
integration,
test,
workflows
for
metrics
and
and
traces
specifically.
Q
E
Okay,
perfect,
okay,
so
riley
you're
on
point
I'll
get
our
folks
in
touch
with
you
elite.
Do
you
want
to
get
your
your
people
also.
H
E
Riley
can
take
it
there
from
there
with
the
group.
Yes,.
E
D
E
D
And
austin's
also
been
overhauling
the
website.
Yeah.
E
I've
been
meeting
with
them
every
two
weeks
about
that
yeah.
I
I
really
like
the
news,
then,
okay,
any
other
ones
here-
that
we
want
to
go
over
right
now.
Otherwise,
andrew
corell
meeting
to
go
over
the
stats
of
these
this
week
and
we'll
report
back
on
monday.
Q
F
We
did
you
know
again,
my
my
team.
I
did
look
at
and
evaluate
the
ci
cd
workflows,
initially
and
and
a
lot
of
the
work
has
been
completed
on
all
of
the
many
of
the
reapers
migrating
to
github
actions.
But
again,
at
this
point
in
time,
I
think
it
would
be
good
to
get
and
provide
an
update,
so
I
can
take
lead
on
that.
E
N
Hey
morgan,
I
also
talked
to
for
line
11..
I
talked
to
yusuke
a
couple
of
months
ago
and
then
I
think
he
said
he
doesn't
have
time
to
do
this
anymore.
E
Yeah
well,
he
also
changed
employers
and
changed
yes,
exactly
yeah.
So
I'm
not
I'm
not
surprised
about
that.
So
actually,
andrew,
I
think
you're
presenting
do
you
want
to
just
remove
you
suck
his
name
there.
I
assume
he's
not
working
on
this.
If
he
is
that's
great,
he
can
get
back
in
touch
with
us.
F
We're
gonna
have
a
question
on
that.
So
just
trying
to
understand
you
know
what
exactly
that
entails,
because
we
have
been
working
on
some
of
the
components
that
you
know
are
landing
in
to
contrib
or
just
structure
wise,
so
bogdan,
and
I
had
a
discussion
on
you
know
me
making
a
proposal
for
again.
What
made
sense
to
be
aware
is
that
related
to
this?
That's.
F
Yeah
yeah,
thank
you
because
I
I
will
file
an
you
know
issue.
I
have.
E
E
E
R
E
See,
I
think,
that's
the
the
assumption
many
people
have
is
that
any
breaking
changes
would
be
2.0
and
any
non-breaking
changes
would
just
get
folded
into
versions.
You
know
one
point
x:
we
have
not
actually
gone
and
clarified
this
or
really
written
it
down
anywhere
right
like
we,
we
haven't
really
landed
on
a
versioning
strategy
for
the
project.
I
think
we're
all
just
running
under
the
same
assumptions.
E
R
Because,
like
I,
I
have
those
questions
while
looking
at
some
of
the
spec
pr's,
I
think
they
mentioned
conversioning,
but
it's
not
clear
from
the
spec
perspective,
exactly
yeah
and
when
one
thing
I'm
worried.
For
example,
if
the
spec
has
1.3
are
we
going
to
call
the
sdk
1.3
something
just
to
match
with
the
spec
version
or
it's
totally
separate,
and
if
it's
totally
separate,
then
we
got
to
build
a
mapping
table
or
otherwise
it
will
be
very.
R
N
R
G
E
E
Andrew,
do
you
want
to
continue
on
with
your
items
in
the
agenda?
Sure.
E
Get
her
or
we
can
just
set
up
an
hour
either
way.
Okay,
probably
get
her,
because
I
think
this
is
going
to
touch
a
lot
of
people
like
because
there's
just
a
lot
of
names.
There.
E
And
I
think
next
week
we'll
have
a
because
the
blog
post
and
everything
will
be
out
we'll
have
a
shorter
agenda
anyway.
So
we'll
just
have
time
to
go
over
this
next
monday.
E
And
it's
yeah:
it's
in
the
dark,
we'll
go.
A
I
don't
know
whether
any
of
this
needs
to
be
touched
upon
in
the
blog
post,
but
I'm
not
sure
what's
running
around
in
maybe
the
progression
of
blog
posts.
Beyond
this,
maybe
we
don't.
Q
A
Talk
about
every
single
one
of
these
in
the
blog
post,
but
it
may
give
an
idea
for
the
progression
of
the
next
blog
post
update
that
relates
sources.
But
yes,
that
was
one
of
the
feedbacks
that
I
want
to
give
in
this.
In
the
blog
was
I
I
did
a
review
of
that
yep
and
I've
got
simple
copy
edit,
like
changes
grammars,
spelling.
E
A
For
sure,
but
I
also
was
hoping
that
this
does
not
give
the
impression
that,
like
oh,
this
is
the
only
thing
that's
going
to
be
worked
on
before
ga
that
the
other
thing
like
performance,
ci,
cd,
yeah,
the
versioning,
all
that
stuff
will
also
be
related
for
what's
coming
up
in
an
overall
timeline,
and
I'm
not
sure
I
can
help
with
that
wording.
If
you'd
like
sure,
please.
E
Yeah.
That's
a
it's
a
big
miss
on
my
part,
you're,
absolutely
right,
because
because
if
you
read
this
right
now,
it
just
seems
like
hey.
We
need
to
finish
the
well.
The
tracing
spec
is
done,
so
we
do
the
sdk
components
for
tracing.
Then
we
do
the
metric,
spec,
metrics
components
for
tracing
and
then
we're
ga
done
and
you're
right.
It's
not
as
simple
as
that.
A
Oh
yeah,
we've
got
a
few
other
things
in
order
to
connect
upon
yes
and
the
other
thing
that
might
be
interesting
for
other
maintenances.
A
All
they
care
about
is
like
what's
the
status
and
what's
coming
up
in
that,
we
can
leave
the
description
of
like
what's
a
p1
or
what's
the
labels
out
of
here,
just
saying
what
are
the
order
of
releases
coming
out,
and
maybe
we
could
make
a
pinned
issue
at
the
top
of
it
describes.
Q
A
Yes,
like
allowed
for
gm
into
this
required
j
means.
P1P2
means
this
spec
and
trace
issues
that
we
need
to
address
for
the
upcoming
milestones
and
the
blog
posts,
maybe
reference
that
so
that
way,
people
don't
have
to
like
contort
what
they
understand
like
what
yeah
it's
required
for.
Jay
allowed
for
j.
E
That
is
really
good
feedback.
I
will
move
that
to
a
pin
issue
today:
okay
and
I
created
a
section
down
below
called
productionization
and
ga
readiness
work
where
we
can
just
reference
the
the
table
and
just
talk
about
like
yes,
we
need
to
do
some
additional
sort
of
planning
and
design
work
to
kind
of,
like
our
ga
versioning
strategy
do
documentation
everything
else.
A
Then
the
only
other
thing
that
I
wanted
to
bring
up
was
in
relation
to
the
two
milestones
from
the
discussion
that
we
had
before
about
freezing
the
trace
related
spec
and
having
the
tables
be
having
the
first
milestone,
be
trace
and
context.
Propagation
freeze
that
one's
like
closing
in
then
baggage
exporters,
resource
environment
variables,
the
next
milestone
related
to
I'm,
not
sure
what
to
call
this
milestone.
This
is
related
to
trace
as
well.
A
Yeah,
okay,
great
because
there's
just
a
few
things,
that's
like
tpd
that
hasn't
been
filled
out.
Okay
in
some
of
these
issues,
some
of
these
tables
that
I'm
not
sure
whether
they're
related
to
the
trace
spec
that
needs
to
be
frozen
or
or
not.
In
error
handling
like
this
one
has
not
been
filled
out
either.
E
Yeah
the
error
handling,
I
don't
believe
we
need
for
tracing
rca.
I
think
ted
is
the
probably
the
most
knowledgeable
person
about
that
section:
error
handling
ted
we
need
for
ga,
but
not
rc.
Is
that
accurate
or
that's
wait?
No,
there's
nothing!
There's
nothing!
That's
j,
but
not
our
c
error
handling.
We
don't
need
for
the
tracing
rc.
Is
that
accurate.
D
I
think
we
do
this,
but
this
is
not
necessarily,
I
don't
think
it's
its
own
section.
Based
on
how
we
finalize
things,
it
was
just
a
change
to
the
status
codes.
D
This
is
done.
This
was
this,
was
this
was
added
to
the
spec,
I
don't
know
what's
been
implemented,
but
this
the
the
end
result
of
that
was
just
to
change.
Change,
reduce
the
number
of
existing
status
codes.
Okay,.
E
S
D
S
So
most
likely
most
likely
that
section
either
gets
removed
and
merged
into
trace
or
yeah
links
from
trace.
I
don't
know
it's
more
likely
just
to
restructure
your
things.
D
D
F
Yeah
I
thought
ted.
We
had
discussed
last
time
that
we
would
be
putting
in
a
paragraph
at
least
or
convention
following
us,
somewhere
somewhere.
F
D
Yes,
we
could
absolutely
do
that
you're
right,
that
I
believe
we
say
semver
in
the
spec,
but
we
don't.
This
is
related
to.
How
do
we
do
all
the
versionings
across
projects
right
yeah?
I
I
have
a
pretty
clear
idea
on
how
we
should
do
that.
So
I'm
happy
to
take
that
on.
I
would
love
to
pair
on
it,
though,
if
you're
you're
interested.
F
A
Knowledge
knowledge
on
the
call.
Is
there
anything
else
that
needs
to
be
scrubbed
on
this.
S
A
Sorry,
okay,
yeah.
Some
people
have
already
done
some
estimates
based
on
the
rows.
That's
available
there,
but
if
you
just
throw
away
an
apply
in
the
getter
that
that
be
able
to
sequence,
it.
A
Okay,
all
right-
and
so
I
guess
that
leaves
us
at
the
two
milestones
that
we
brought
up
just
to
be
clear,
because
I'm
still
a
little
bit
fuzzy
on
that
the
trace
and
context
propagation
tables,
that's
a
milestone
for
implementation
of
the
trace,
spec
and
then
everything
else
is
the
second
milestone
for
implementation,
and
that
will
be
the
guidance
for
how
we
talk
about
the
timelines
of
the
things
to
come.
A
For
the
next
releases,
the
languages
will
will
have
a
milestone
for
trace
and
context,
propagation
implementation
and
then
something
a
little
bit
further
on
for
the
rest
of
the
table.
Implementation,
okay,
I'm
seeing
nodding
heads
and
then
in
parallel,
we'll
have
something
described
by
like
oh
metrics-
is
still
also
ongoing
too.
As
soon
as
we
freeze
that
then
there'll
be
an
estimate
for
how
long
it
takes
in
order
to
implement
metrics
across
all
the
different
languages.
More
nodding,
heads,
okay.
A
S
S
A
Okay,
maybe
at
a
future
meeting
we
ought
to
talk
about
like
how
to
validate
the
adherence
to
the
spec
by
somebody
other
than
the
language
maintainers
or
the
language
signs.
That
way
there
can
be
a
double
check
on
like
yes,
we
actually
implemented
it,
and
another
group
was
like
yes,
yes,
I
can
see
that
it's
here
here
here
and
there.
E
I
think
the
next
item
is
layton
vendor-specific
components.
N
Yeah,
I
didn't
want
to
take
too
much
time
on
this,
but
I
think
we've
kind
of
gone
over
this
a
couple
of
weeks
ago
and
there's
also
a
spec
issue
out
here,
as
well
kind
of
decided
that
vendor-specific
propagators
were
allowed
to
like
include
them
in
the
contrib
repos.
N
I'm
just
wondering
if,
like
does
this,
extend
to
any
other
types
of
components,
I
know
like
we
have
some
aws
interns
who
are
trying
to
add
some
custom
like
a
implementation
of
an
sdk
and
including
the
contrib
repose.
N
It
sounds
like
a
cool
idea.
It's
just
that
you
know.
There's
always
the
kind
of
you
know
responsibility
of
like
maintaining
it
and
like
the
current,
maintain
maintainers
of
the
contra
repo,
it's
like
not
associated
at
all,
with
these
vendor-specific
components.
So
I
was
wondering
what
everyone
else
thought
about
this.
L
Actually,
I
have
an
action
item
about
that,
which
is
a
reverting
part
of
this
pr
which
I
didn't
do
by
the
way.
Sorry
apologies
for
that
and
then
lolita
will
do
a
follow-up.
If
I
remember
correctly,.
F
N
Awesome
cool
yeah,
so
I
guess
we'll
just
wait
for
that
before
we
review
anything
or
like
push
anything,
because
I
think
they're
already
starting
to
work
on
it
a
little
bit
so
right.
S
The
other
thing
is,
we
need
to
every
time
when
we
add
something
that
let's
say
it's
vendor
specific,
let's
assume
the
x-ray
propagation
for
traces.
We,
I
would
always
think
about.
Is
this
useful
for
for
maintainers
or
for
people
without
actually
using
x-ray,
and
sometimes
the
x-ray
propagation
may
be,
maybe
the
case,
because
they
may
want
to
tie
traces
with
amazon,
lambdas
or
whatever
aws,
lambdas
or
other
things
with
which
this
is
required
or
another
example.
S
Some
of
these
things,
maybe
arguably
that,
even
though
we
there
is
a
bit
of
vendor,
we
may
still
want
to
to
to
maintain
them
for
for
the
good
of
the
community
and
for
for
actually
for
our
own
good
as
well.
Probably
but
anyway,
it's
a
long
discussion.
I
was
just
trying
to
say
that
there
are
some
cases
where
these
components
can
be
used,
even
though
you
don't
use
that
vendor.
F
Yeah
bug
didn't
exactly
and-
and
there
are
you
know
again-
different
types
of
components.
So
the
idea
was
that
in
the
proposal
that
at
least
I
want
to
submit
as
an
issue
to
at
least
make
a
proposal,
and
then
you
know
have
a
more
focused
discussion
around
each
one
of
those
categories.
N
N
F
S
Yeah,
that's
why
it's
tough
as
lincoln.
F
S
F
S
S
S
B
S
Longer
discussion
and
I
think
we
need
to
to
ensure
that
we
don't
put
too
much
burden
on
maintainers
maintainers,
have
an
easy
way
to
remove
some
of
the
things
or
to
disable
some
of
the
things,
if
not
working
and
so
on.
So
it
needs
to
be
a
balance
here.
Agreed.
D
Everyone
this
actually,
I
had
had
added
a
line
item
about
distros,
but
I
think
it's
actually
relevant
here.
They.
D
Noticing
is
like
if
we
don't
have
a
compelling
way
to
let
people
package
up
their
own
open,
telemetry
distribution.
D
You
know,
with
their
own
presets
and
and
plug-ins
there's
going
to
be
huge
pressure
that
we
already
see
to
to
get
all
of
that
stuff
jammed
into
the
core,
because
otherwise
it's
like
kind
of
painful
compared
to
you
know
their
existing
solution.
Yeah
and
I
kind
of
feel
like
the
distro
solution-
works
better.
Just
because
shoveling
everything
into
core
doesn't
scale
right,
like
it'll,
be
agreed,
it'll
be
either
lopsided
towards,
like
you
know,
certain
large
vendors
or.
F
S
Yes,
let's,
let's
discuss
a
separate
meeting
and
probably
even
even
having
a
working
group
for
this.
I
feel
it's
it's
because
it's
a
huge
amount
of
chatting
decisions
and
stuff
that
we
need
to
do
and
probably
have
even
having
odd
tap
or
something
that
explains
the
entire
process
and.
F
F
S
This
is
a
huge
action
item
for
us
and
I
think
it's
very
important.
The
other
thing,
by
the
way
that
is
very
important-
and
I
did
not
see
anything
happening,
its
kind
of
relativities-
is
how
are
we
going
to
accept
changes
after
ga?
Same
same
policy
applies
right
now,
with
with
people
wanting
everything
in
core
people
want
everything
right
now
in
the
specs,
because
they
feel
like
after
the
g
after
the
freeze.
S
B
E
S
Don't
care
much
about
versioning
right
now,
I
care
more
about
having
a
small
process
and
telling
people
hey
everything
that
is
marked
after
j.
This
is
the
process
that
we
will
expect
from.
You
is
not
like.
It's
not
gonna
happen.
It's
not
like.
We
are
dropping
it,
but
this
is
the
the
process
that
will
happen
after
ga
and
I
think
it's
very
important
to
have
that
with
the
freeze,
because
otherwise
people
will
get
very
nervous.
Oh,
this
change
did
not
get
there
and
it's
the
freeze
time.
I'm
screwed.
F
P
F
I
see
I
see
I
didn't.
I
didn't
know
that,
but
we
you
know
we
are
the
happy
to
do
proposals,
because
we
do
that
internally.
You
know
for
ensuring
that
things
are
consistent
in
the
design
anyway.
So
totally,
if
there's
a
process
for
it
absolutely
communicate
and
use
that.
S
P
S
Let's,
let's
say
let's
say
for
spec:
I
don't
care
it's
not
that
much
to
maintain.
So
I'm
more
than
happy
to
have
another
directory
in
this
repo
country.
I
I
don't
think
it's
the
same
experience
as
the
the
main
repos,
where
I
need
to
wait
for
building
time
and
stuff
here
is
not
a
problem,
so
just
having
another
directory
called
contribute
in
the
spec.
S
Sense,
this
is
a
good
proposal
and
I
think
it
should
somebody
should
file
an
issue
explaining
what
is
the
purpose
and
look
at
the
readme
and
or
maybe
do
a
pr
with
exactly
the
readme
how
it
was
described.
What
is
an
experimental
feature?
We,
you
can
say
what
is
a
contrib
entry
and
stuff
and
explain
where
to
use
this
and
probably
more
than
happy
to
merge
that
and
to
start
having
this.
F
Now
bogdan
asked
us
to
file
an
issue
specifically
to
to
recommend
make
our
recommendation
on
having
a
spec
contrib
reba.
Okay,.
P
E
Cool
next
question
was:
what
is
the
version
numbering
plan?
I
think
the
answer
is
we
don't
have
one
yet
and
alittle's
working
on
that?
That's
right.
T
I
I
just
I
didn't
want
to
bring
up
something,
though
that
came
up
into
our
python
seg
meeting
last
week,
which
was
that
the
way
that
we're
currently
packaging
things
in
python
is
that
there's
an
api
package
and
there's
an
sdk
package,
and
I
was
curious
if
other
sigs
are
going
to
have
the
same
problem
where,
if
we
decide
to
declare
like
trace
1.0,
what
does
that
mean
as
far
as
releasing
new
versions
of
the
api
package,
and
is
everybody
else
just
putting
up
the
metrics
versus
the
traces
api
into
their
own
packages?
S
Alex
so
far,
we
decided
to
not
make
one
zero
until
both
metrics
and
traces
are
available
in
terms
of
calling
the
api
stable,
ready
stuff.
We
can
do
that,
but
but
we
said
one
zero
will
be
reserved
for
when
the
metrics
and
traces
are
ready.
So
that
means
I
don't
know
how.
At
least
that
was
the
initial
idea,
not
saying
that
is
the
right
thing
or
or
not.
But
that
was
the
initial
idea
and
that's
how
we
we
felt
about.
F
That
to
make
a
proposal,
and
then
you
know,
add
obviously
details
of
what
kind
of
changes
were
part
of
the
patch
versus
minor
versus
major.
You
know
versions.
D
Okay,
we
and
we
don't
have
time
to
get
into
it
now,
but
I
want
to
put
a
pin
in
this,
which
is
because
it
relates
to
a
package
organization
is
ga.
We
want
everything
to
be
backwards
compatible
for
you
know,
api
packages
that
have
1.0
what
backwards
compatible
means,
unfortunately,
is
somewhat
language
specific
right
like
the
nuance.
D
There
is
language
specific
and
I
think
so,
each
language
maintainer,
maybe
as
homework,
look,
look
at
your
current
package
layout
and
think
about
you
know
if
you
froze
these
things
and
needed
everything
from
this
point
onwards
to
be
backwards
compatible.
Is
this:
is
this
layout
appropriate?
I
don't
think
at
the
spec
level.
We
can
necessarily
issue
too
much
guidance
there,
but
that's.
S
You
know
the
other
thing,
at
least
in
my
mind.
At
one
point
I
had
this
idea
that
we
may
allow
breaking
changes.
Let's
not
breaking
changes.
We
may
allow
removing
things
for
after
two
years,
so,
for
example,
if
you
deprecate
something
in
five
major
or
ten
major
versions,
you
can
remove
that
or
something
like
that.
I
don't
know
if
we
want
to
do
that
or
not,
but
it
will
be
good
to
document
this
kind
of
things.
Google,
for
example,
has
a
18
months.
I
think
policy
for
backwards
compatibility
stuff.
F
Aws
has
long
term
compute.
D
F
And
I
mean
that's
directly
tied
also
bugged,
into
the
overhead
of
testing
that
is
maintained
by
the
project,
because
you
know
we'll
have
to
have
tests
both
unit
tests,
as
well
as
integration
tests
that
that
are
ensuring
backwards.
F
T
The
other
item
that
was
also
mine
in
here
is
I
just
wanted
to
bring
this
up
with
all
the
maintainers
is
that
there
is
a
pr
that
was
merged
into
the
spec
around
spine
references
replacing
the
name
for
spam
context,
and
I
just
wanted
to
to
highlight
that
there
has
been
some
some
questions
of
whether
or
not
that
was
the
right
change
to
do
from
some
of
the
pr's
that
have
been
opened
in
ruby
and
in
python.
T
So
maybe
just
wait
until
the
spec
call
tomorrow
to
merge
anything
like
that
in.
E
L
E
Cool.
Thank
you
very
much.
Everybody
and
we've
made
a
lot
of
progress
here.
Remember
the
the
blog
post
goes
live
wednesday
at
9.
00
a.m.
Pacific.
I
think
one
or
two
vendors
are
going
to
repost
it.
It's
it's
not,
as
you
know,
I
doubt
it'll
be
quite
as
big
as
the
the
beta
blog
post
or
any
like
sort
of
all
of
our
sdks
are
our
c
blog
posts,
but
still
it's
a
nice
accomplishment
for
the
community
and
we
should
celebrate
what
we've
done
so.
Thank
you
very.
S
Much
everybody
one
one
extra
thing
which
just
want
to
make
sure
everyone
knows
about,
and
please
please
don't
forget
about
this-
is
elections.
Elections
are
happening
right
now,
look
for
for
the
calendar
and
make
sure
you
announce
everyone
about
this.
That
you
know
has
voting
opened
yet
bargain.
I
forget,
I
don't
know
all
the
details.
I
just
shared
the
elections
thing.
Yes,
so
please
look
at
the
calendar.
Please
please.
S
Yes,
but
yeah
anyway,
just
one
everyone
know
review
the
candidates,
look
look
who
which
one
look
looks
the
best
and
vote
for
for
them
and.
E
E
Is
the
open,
telemetry
internal
governance
committee
elections?
There's
a
list
of
candidates
now
voting
begins
on
october
26th,
I'm
like
damn
bogdan.
E
We'll
give
a
reminder
next
monday,
as
well
once
the
voting
begins.
I
think
most
people
here
are
code
contributors.
If
you're,
not
a
code
contributor,
you
probably
won't
be
automatically
registered
as
a
voter,
there's
a
form
you
can
fill
out
now
that
will
allow
you
to
be
registered
as
a
voter
voter.
If
you've
made
significant
non-code
contributions
to
the
community.