►
From YouTube: 2020-09-22 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
C
C
D
E
F
F
A
G
H
With
this,
this
is
like
our
only
big
big
high
priority
issue-
that's
outstanding
for
metrics,
so
this
is.
This
is
probably
a
p1
by
the
definition.
I
This
this
doesn't
impact
the
metrics
api
at
all,
though
right,
so
that
I
think
that,
because
it's
not
an
api
trying
to
change,
it
would
be
down
to
p2
correct.
H
K
H
G
Yeah
anyway,
p2
area,
sdk
android,
is
the
most
focused
of
these
okay,
okay,.
D
Yeah,
so
that
one
is
a
bit
unclear
to
me
if,
because
it
specifies
an
environment,
variable
called
hotel
exporter,
but
it
doesn't
really
say
what
it
does.
There's
a
default
value
otlp,
but
I
I
can't
tell
if
if
this
does
something
by
itself,
because
from
from
reading
it,
I
have
the
feeling
as
if,
if
you
don't
specify
anything,
this
will
set
up
a
pipeline
with
that
exporter
being
set
up,
and
I'm
not
sure
if
that's
intended.
So
we
should.
We
should
clarify
this
before
g8
yeah.
I
think
it's
a
p2.
G
D
And
the
next
one
is
no,
that's
the
wrong
one.
A
Yes,
and
so
now,
I'll
go
on
to
the
next
part
about
giving
status
of
where
we
are
in
terms
of
the
spec
burn
down
as
of
this
morning
from
the
numbers
we
have
so
just
a
reminder,
this
is
the
project,
that's
tracking,
what's
to
do
what's
in
progress,
how
much
we've
done.
A
Overall,
for
all
the
issues
tagged
for
ga
required
for
ga,
we
have
62
we've
knocked
out
net,
one
of
them
four
in
progress.
74
are
done,
so
we
well
over
the
numerical
hump
and
of
the
ones
we
are
concentrating
on.
First
to
get
done
for
p1
to
freeze
the
trace,
spec,
I'm
bringing
over
this
format
from
the
maintainers
meeting.
We
have
three
to
do
six
in
progress.
A
A
I'd
like
to
say,
the
community's
actually
been
progressing
quite
well,
so
I
I
think
everyone
is
trying
to
trying
to
get
to
the
finish
line,
which
is
which
is
fantastic.
Okay.
This
is
the
point
I
want
to
make
from
the
open
telemetry
specification,
repo,
there's,
eight
open
and
we've
got
assignees
for
all
of
them,
which
is
great,
open,
pr's
for
a
crapload
of
them.
So
that's
like
so
that's
five
out
of
eight
of
them
are
in
progress
which
is
fantastic.
A
Okay,
if
you'd
like
a
separate
time
for
that,
so
this
is
just
in
the
different
repo
that
was
marked
as
p1
as
well,
okay,
and
from
the
maintainers
meeting
yesterday,
we
talked
about
timelines
specific
timelines
on
how
many
weeks,
how
many
days,
how
much
work
we
have
left
towards
our
stake
in
the
ground
of
trying
to
hit
kubecon
north
america's
date
of
november
17th.
A
We
had
a
discussion.
The
summary
of
it
was
for
trying
to
get
our
most
immediate
goal
of
freezing
the
trace.
Spec
decision
is
substantial,
p2s
and
p3
changes.
We
marked
as
postga
during
this
friday's
bug
scrub,
so
our
concentration
truly
is
on
these
nine
remaining
issues
and
to
follow
on
the
next
step
of
what
we
have
to
do
after
the
trace
spec
has
been
frozen.
A
We
also
need
to
solidify
what
parts
of
the
compliance
matrix
do.
The
language
6
need
to
satisfy
in
order
to
be
considered
implementing
the
trace
spec,
so
we
talked
about
which
tables,
of
course,
the
trace
table,
but
we
also
have
to
figure
out
by
the
end
of
this
week
whether
all
these
rows
lined
up
with
everything
that
we
need
resources,
context,
propagation
error
handling,
which
of
which?
What
of
what?
In
order
to
be
able
to
say
it's,
been
implemented
so
that
we
can
move
on
to
the
next
milestone,
which
is
the
metrics
api.
A
So,
let's
just
peek
into
our
direction
for
this
week
and
beyond.
F
D
D
For
anyone
who
doesn't
know
what
this
is
about,
we
have
a
current
definition
that
says
for
languages
that
have
nine.
If
you
try
to
pass
it,
then
this
will
just
remove
the
attribute
if
some
attribute
was
previously
set
with
that
key,
and
this
is
was
actually
not
intended
as
a
delete
attribute
feature
or
something
like
that.
But
since
we
don't
distinguish
between
null
and
not
set,
because
it's
just
a
fine
nuance
with
zero
to
with
almost
no
semantic
difference,
we
said
that
the
error
handling
in
that
case
would
be
to
remove.
D
But
in
the
discussion
it
sounded
like
we
would
want
to
preserve
now
and
otlp
has
some
support
for
it.
So
we
would
be
able
to
do
so,
but
only
without
a
type
and
now
we
are
discussing
if
we
should
preserve
9
or
run
or
not.
E
I
think
having
null
support
is
useful,
but
if
there
are
concerns
about
how
exactly
the
api
should
allow
specifying
it
then
yeah.
I
think
it's
fine.
If
we
don't
support
it
right
now.
The
part
that
I
don't
like
with
the
current
spec
is
where
it
says
the
the
attribute
will
be
deleted.
If
you
pass
an
all
value
when
you're
calling
the
setup
that
I
don't
like,
I
don't
like
that
magic
value.
I
don't
like
that
behavior.
E
So
I
suggest
that
if
we,
if
we
don't
have
a
consensus
of
what
the
behavior
should
look
like,
the
behavior
with
setting
actual
value
is
going
to
look
like
in
the
api
or
whether
it's
going
to
be
even
a
separate
api
call.
E
I
suggest
we
delete
the
requirement
that
calling
set
out
to
be
with
null
value
deletes
an
existing
attribute,
and
if
we
care,
we
may
even
say
that
if
you
do
so,
it's
an
undefined
behavior
right,
don't
do
that
right,
explicitly,
call
it
out,
and
then
that
leaves
the
possibility
of
adding
that
functionality
in
the
future
later.
E
G
So
so,
for
me,
for
me,
for
me,
is
this
difference
of
if
user
intended
to
put
a
string
attribute
and
in
languages
like
java,
where
string
can
be
null
as
they
they
pass
null?
They
get
a
completely
different
type
of
the
attribute
that
that
was
for
me,
the
the
the
the
clashing
point
where,
where
I
couldn't
I
couldn't,
I
couldn't
understand
how
and
where
how
to
implement
this.
So
so
the
fact
that
is,
we
support
null.
G
It's
it's
fine
and
I
think
josh
also
had
a
point
that,
in
order
to
be
json
complete,
we
need
to
support
now,
which
is
fine,
but
the
way
how
how
right
now
in
languages
where,
for
example,
strings
are,
are
possibly
to
be
null.
The
fact
that
you
have
an
attribute,
you
have
an
api
that
says,
set
string
attribute
which
accepts
a
key
and
the
string,
value
and
user
pass
null
to
that
and
we
dropped
the
information
that
actually
user
wanted.
A
string,
not
a
null
per
se
was
was
was
the
problem
for
me.
G
Maybe
I'm
overthinking
this,
but
in
java
after
this
change,
we
will
have
three
apis
that
allow
you
to
set
null
values.
So
you
can
set
known
values
via
as
explicit.
G
If
we
have
that
an
explicit
api
that
says
sets
null,
we
will
have
a
possibility
to
set
null
via,
let's
set
string
attribute
which
pass
now
and
we'll
have
a
possibility
to
set
now
via
a
set
array
where
I
pass
null
for
the
array,
because
that's
that's
java
and
for
me
for
example,
this
is
inconsistent
with
gold.
For
god,
there
is
no
such
thing
as
meal
stream
and
in
goal
the
set
string
attribute
will
never
be
able
to
produce
null
value
will
always
produce
default
empty,
and
I
think
I
think
that's
the
time.
Yeah.
E
For
some,
it's
it's
natural
right
if
you're
using
javascript
null
is,
is
a
built-in
concept
there
right,
and
so
the
set
attribute
can
work
nicely
here
for
some
others,
like
java
or
or
even
for
c,
plus,
plus,
it's
even
worse
right.
You
can't
even
pass
a
null
std
string
if
it's
an
std
stream,
there
is
no
way
to
pass
them
out
there
right,
so
it's
considered
equivalent
to
an
end
to
an
empty
string.
So
you
would
need
to
support
some
definitely
the
different
api.
G
E
Correct
in
go
actually
we
have
set
attribute
which
accepts
interface,
so
there
you
can
pass
a
needle
and
that
works
as
well.
But
again
it
depends
on
what
the
specific
api
in
a
particular
language
looks
like,
and
we
may
not
need
to
to
to
specify
the
specific
way
of
expression
in
the
specification.
It
may
need
to
be
left
for
the
language
maintainers
to
figure
out.
What's
the
right
approach
for
that.
G
E
G
E
If
people
undefined
behavior
do
whatever
you
want
to
do,
the
spec
does
not
define
it.
We
have
millions
of
places
where
the
spec
does
not
tell
you
precisely
what
happens
if
you
call
that
that's
undefined
behavior,
maybe
in
java
implementation,
your
residential
pointer
exception,
if
you
receive
that
so.
B
E
C
B
Yeah,
I
I
think
that
part
is
the
minimum
thing
that
we
should
clarify.
For
example,
if
people
said
no,
they
have
no
string
and
they
have
now
something
else,
and
we
should
tell
them
they
should
expect
from
the
consumption
side.
There
is
no
good
way
to
distinguish
that
now
versus
this
now
it
will
be
just
now.
E
G
B
B
B
In
my
personal
opinion,
then
there
is
a
problem:
if
we
allow
now,
then
what
should
they
expect
from
the
exported
results
and
people
will
assume
like
in
some
protocol,
they're
able
to
restore
the
type
in
other
protocol.
They
cannot
and
then
we're
creating
this
confusion.
Literally,
we
want
to
change
it'll
be
too
hard.
E
When
you
say
when
you
say
the
behavior
is
undefined,
you
you
tell
in
the
spec,
don't
call
this
function
with
a
null
value.
Don't
right!
If
you
do,
who
knows
what
happens?
Nobody
guarantees
anything.
So
just
don't
do
that
right
on
the
receiver
end,
if
you're
implementing
the
protocol
receiver,
the
the
the
specification
of
the
protocol
clearly
tells
what
to
expect.
That
is
there.
But
it's
in
the
protocol
specification
not
in
the
api
specification.
B
E
Yes,
yes
in
the
in
the
in
the
specification
we
we
should
add,
we
can
add
right
that,
if
that's
desirable,
another
sentence
so
delete
the
sentence
which
says,
if
you
call
with
null
it
deletes
the
the
attribute.
Instead
of
that,
we
can
add
another
one
which
says,
if
you
call
with
now,
the
behavior
is
undefined.
Don't
do
that.
D
Yes,
so
I
personally
don't
care
about
knight
valleys
at
all.
So
if
it's
nine
for
me
as
a
consumer,
this
is
equivalent
to
not
being
set.
I
would
I
am
strongly
against
using
an
empty
string
or
another
default
value,
because
this
has
the
expression
I
looked
for
it.
I
looked
it
up.
I
checked
something
and
the
value
that
I
received
is
an
empty
stream.
It
is
empty,
but
if
it
is
yeah
keep
in
mind.
G
Whatever
it's
a
language
dependent
thing
there,
but
so
so,
then,
then
you
as
a
consumer
in
the
back
end
when
you
receive
anti-stream,
you
don't
know
if
it
came
from
goal,
or
maybe
you
know
from
from
different
attributes
that
it
came
from
go
and
in
goal.
You
will
not
know,
for
example,
that
that
was
empty
for
sure
or
was
empty
as
a
default
value.
For
that.
D
Yeah
I
see,
but
what
I
don't
like
about
the
making
it
undefined,
on
the
other
hand,
is
that
this
is
having
null
is
something
that
is
likely
to
happen
and
and
especially
in
java,
you
might
get
nine,
and
if
you
don't
explicitly
do
a
knife
check
and
call
it
with
knife,
then
I'm
not
sure
if,
if
we
should
say
yeah,
this
is
undefined
behavior.
We
will
have
to
make
that
very
clear
that
this
should
never
ever
be
knife
in
order
to
be
able
to
make
it
undefined.
E
The
purpose
of
declaring
it
undefined
is
twofold:
one.
You
signal
to
callers
that
this
is
prohibited.
You
should
not
do
that.
The
second
purpose
is
you
keep
the
behavior
open
possible
future
behavior
open
you
keep
the
options
open
right.
You
can
then
go
ahead
and
define
a
behavior
and
by
doing
that,
you're
not
breaking
anything,
because
previously
it
was
undefined.
Nobody
was
supposed
to
call
it
and
if
somebody
did
and
that
behavior
changed,
that
is
fine.
You
did
not
break
anything
because
you
did
not
promise
that
the
behavior
was
something
special
in
the
past.
G
I
think
I
think
personally,
I
prefer
to
do
what
protobuf
did,
which
was
new
as
empty
stream,
for
example,
for
streams,
because
because
for
one
reason
that
gives
you
consistent
consistency
across
language
so
for
languages
that
do
not
support
new
screens
and
there
is
no
way
to
pass
another
stream.
So,
even
if
you
come
even
in
two
months
and
you
define
null
stream
there
as
one
of
the
behavior,
how
we
are
you
gonna
implement
that
in
in
goal
are
you
gonna
accept
the
string
pointer,
no
you're,
probably
not
gonna.
Do
that.
E
L
L
H
I
want
to
say
that
I
support
tigran's
position,
I'm
on
record
in
this
issue
saying
I
think
that
we
should
take
the
json
position
and
be
null
as
an
explicit
value
as
in
its
own
type,
meaning
that
the
any
value
one
of
would
contain
a
null
value
struct
that
had
no
fields
just
saying
I'm
null.
D
Right
yeah,
I
draft
the
second
proposal
removing
the
the
implicit
deletion,
because
that's
something
we.
We
mostly
agree
that
we
don't
want
to
have
it
because
it's
it's
at
least
very
fine
behavior,
but
not
the
least
surprising
one.
So
it's
not
preferable
and
define
it
as
undefined
explicitly
so
that
we
are
future
proof
here
and
then
we
can
discuss
on
both
requests
when
we
know
how
it
looks
like
which
one
we
prefer.
D
B
D
Yes,
the
companion
attribute
use
case
that
we
explicitly
mentioned
in
the
in
this
deck.
I
left
that
one
untouched
and
we'll
also
leave
it
untouched
for
the
other
one,
because
we
define
areas
as
homogeneous
and
therefore,
if,
unless
it
is
entirely
empty,
we
know
that
that
the
other
attributes
would
be
a
string,
and
that
would
that
would
work.
If
you
pass
an
idea.
D
G
B
No,
I
I
I
think
that
didn't
answer
my
question.
My
question
is:
do
we
allow
an
array
with
only
one
element
that
is
now
and
I
think
from
the
spike
perspective,
it
looks
like
we
have
to
make
that
undefined
behavior
as
well.
E
That's
that's
specifically
called
out
for
the
cases
of
the
two
arrays
where
you
have
to
keep
indexes
parallel
right.
That's
that's
that's
an
exception
of
says:
null
is
important
there.
If
you
can
represent
it
represent,
if
you
cannot
replace
it
by
something
else.
The
reason
is
that
don't
don't
remove.
Basically
right,
don't
ignore
the
value
it's
important
and
that
does
not
require
a
new
api.
D
Okay,
but
this
is
fine
in
my
opinion,
by
the
way,
because
either
you
have
define
a
semantic
convention
that
says
it's
an
area
of
string
and
then
you
know:
okay,
yeah,
it's
it's,
it
would
have
been
a
string,
but
it
is
nine,
and
so
you
don't
you
most
probably
won't
care
anyway,
or
it
is
a
attribute
that
you
don't
know,
and
then
you
wouldn't
make
anything
of
that
information
anyway,
you
wouldn't
say
yeah,
I
I
didn't
get
a
value.
I
got
nile,
but
just
fyi
the
value
would
have
been
a
boolean,
for
example.
D
I
F
Okay,
very
good.
Thank
you.
I
think
we
find
an
agreement
yeah
I
mean
please
work
on
that
pr
and
please
everybody
review
that
so
fast
after
finding.
Finally,
an
agreement
there
next
item
bogdan
spans
parent,
must
be
passed
as
context
instead
of
spam
context.
Yes,
I'm
I'm
very
confused.
G
Why
why
we
still
dropped
this
so
for
me
for
me,
to
be
honest,
I
think
I
think
we
all
agree
that
having
allowing
to
pass
context
as
parents
is
useful
for
not
only
for
this,
but
also
for
for
baggage
correlation
and
a
bunch
of
other
cases.
Probably
the
only
unknown
thing
is.
Is
this
good
enough
or
do
we
also
need
to
allow
passing
the
spam,
which
is
an
addition
to
this
api?
So
that
being
said,
I
think
I
see
no
reason
to
block
this
pr
for
the
moment.
G
G
F
Okay,
yeah
yeah.
We
just
wanted
to
prove
that
it's
working
all
fine,
but
what
about
we
do
this?
What
about
you
know?
So
we
have
java
prototype
in
go
it's
a
de
facto
prototype.
Math
did
prototype
for
ruby
and
it's
working
well,
so
we
were
just
waiting
for
prototypes
in
python
and
erlang.
So
what
about
we
merge
this
pr?
G
Yeah,
that's
my
point
like:
let's
merge
it
because
we
know
for
sure
we
want
this.
If,
if
we
want
extra
things,
we
can
consider
and
argue
about
that,
but
we
know
for
sure
we
want
this.
So.
F
Let's
yeah,
my
point
is
that
I
I
still
would
like
to
have
the
prototypes
in
the
other
languages
just
to
be,
you
know
sure
I
mean
they
will
come
and
even.
G
Even
if
they
come
after
ga
adding
a
new
api
is
backwards
compatible,
so
adding
the
new
api
to
allow
parent
to
be
spam.
So
I
don't
think
you
want
to
remove
this
api,
no
matter
what
that's
my
point,
the
the
point
is
you
always
want
this
api?
You
may
want
an
extra
api
sure,
but
I
think
you
always
want
this
api.
So
that
being
because
of
that,
I
think
we
can
just
merge
this.
F
G
F
I
was
waiting
for
one
more,
but
it's
fair,
okay,
but
fair
enough.
Let's,
let's
go
ahead
and
merge
that,
hopefully
we
will
have
prototypes
just
to
ultra
verify
that
this
all
is
fine.
So
I'm
fine
with
that.
Anybody
else
has
any
opinion
against
this,
or
is
everybody
good
with
it.
F
G
Next
one
is
mine,
header
name,
so,
first
of
all,
there
is
right
now
for
for
for
the
baggages,
we
still
use
ot
correlation
as
a
header
name
in
the
specs.
So
my
pr
was
initially
changing
that
to
update
the
name,
because
it's
no
longer
called
correlation.
So
I
propose
to
change
it
to
hotel
baggage,
also
also
updating
using
hotel
instead
of
opti,
because
we
agreed
on
that.
G
But
I
also
marked
as
fixed
another
issue,
879,
which
I
mean
pointed
that
this
may
not
resolve
that
issue,
because
that
initial
issue
was
suggesting
to
use
directly
the
baggage
name,
which
is
the
w3c
name,
and
my
concerns
of
using
that
right
now
is
in
in
a
very.
G
Small
possibility
that
the
the
w3c
breaks
compatibility
will
be
screwed
so
because
of
that
I
was
I
was
thinking
of
using
our
private
name
for
the
moment
and
deal
with
deprecation
and
everything
I
need
to
hear
others
opinion
on
this.
D
So
your
pr
per
se
is
perfectly
fine,
because
the
old
name
ot
correlations
is
wrong.
Now,
that's
something
we
all
agree
on.
As
for
the
as
for
using
the
official
baggage
header,
I
have
no
idea
because
I'm
not
part
of
the
of
the
correlation
context,
w3c
group,
so
I
don't
know
if
there
are
any
any
changes
to
be
expected,
but
well.
J
There
are
no
changes
that
are
expected.
The
other
thing
is
that
the
the
group
of
contributors
is
effectively
all
from
open
telemetry.
So
I'm
not
too
worried
about
a
change
coming
in
there.
D
J
And
when
I
say
majority
I
mean
it's
effectively
entirely
open,
telemetry
contributors
right.
It's
like
myself,
sergey
kansalev,
daniel
from
dynatrace
and
a
few
others.
Two
day
names
yeah
daniel
dylan
and
daniel
actually
they're.
Both
there
yeah
yeah.
G
Anyway,
so
what
what
is
the
path
forward?
Should
we?
First
of
all,
I
think
this
pr
should
be
merged,
because
it's
a
it's
a
problem
in
the
current
specs.
Second,
there
is
the
problem,
as
armin
pointed
of
using
or
not
using
the
official
name.
I
I
don't
have
a
strong
opinion
if,
if
everyone
agrees
with
with
this,
especially
I
I
would
like
to
hear
from
daniels
and
from
sergey
morgan,
I
heard
your
opinion,
but
I
would
like
to
hear
others
opinion
as
well
to
see
yes.
G
To
see
what
what
what
do
they
think
if
they
are
on
the
call,
I
don't
know.
C
M
So
I
do
want
to
ask
the
question,
though,
right
now
like,
if
there's
a
third
party
software,
that's
currently
using
the
baggage,
encoding
or
header
right,
open
telemetry
doesn't
participate
in
that
because
we
use
a
different
header
right.
K
M
Like
I
don't
know
like,
I
think
it's
pretty
important
that
we
try
to
try
to
be
part
of
that
baggage
propagation
in
the
in
the
real
world.
As
we
go
forward,
I
mean
I
get
the
idea
that
like,
if
especially
when
this
originally
was
decided
that
the
w3c
baggage
specification
was
really
tentative,
especially
in
the
format,
and
that
there
was
like
a
compatibility
issue.
We
wanted
to
just
get
something,
but
I
kind
of
thought
that
that
was
attempt
to
get
like
a
stub,
essentially
something
that
we
could
all
agree
on.
M
G
Yeah,
my
my
personal
opinion
is
we
start
with
this
custom
game
and
once
the
wtc
declares
that
stable,
which
we
started,
switching
and
and
all
the
process
to
start
accepting
the
new
name
and
so
on.
So
that
was
my
my
idea
and
we'll
have
to
deal
with
the
deprecation
that
that
would
have
give
the
global
an
ability
to
break
changes
if
they
want
or
whatever
until
they
declare
the
header
table.
M
Well,
I
mean
isn't
that
us
like
we're
using
something:
that's
not
stable
and
we're
trying
to
use
that
and
then
build
it
into
a
stable
api.
M
G
G
So
so
we
are
defining
an
api
and
we
we
we
define
a
stable
api
for
ourselves.
Now
now
is
the
problem
of
the
what
we
put
on
the
wire
between
processes
and
what
we
said
was
tentatively.
We
have
two
options:
we
either
go
and
say:
okay,
we
gonna
use
the
header
called
baggage
and
with
this
format,
which
means
if,
in
the
future,
this
this
format
changes.
M
We
want
to
include
in
a
ga
release
of
our
apis
right,
but
my
question
is
is
like,
if
right
now
we're
not
participating
any
sort
of
baggage
propagation
we're
not
using
the
right
header
right.
We
have
our
own
format
right,
so
we're
essentially
like
outside
of
that
entire
propagation
and
if
other
app
or
other
applications
are
included
in
that
right.
M
Now
they're
they're
going
to
be
having
to
go
through
that
same
transition
phase
if
they
have
some
sort
of
editor's
draft
that
they're
actually
following
right,
and
so
my
question
is
like:
if,
if
we
want
to
be
a
part
of
that
and
call
it
running
order
like,
I
think,
that's
fine.
But
I
don't
think
you
could
call
the
baggage
api
a
stable
api,
and
if
you
want
to
call
it
a
stable
api
and
say
that
it's
going
to
be
actually
the
hotel
baggage,
then
that's
a
completely
different
standard.
It
feels
like.
G
J
M
J
C
G
Okay,
without
without
this
morgan,
we
cannot
call
g
because
will
not
be
backwards,
compatible
without
open
tracing
and
will
not
be
backwards,
but
the
consensus
of
the
metric
side,
which
is
intact,
yeah,
yeah,
okay.
So
yes,
we
can
declare
that,
but
that
fails
one
of
the
main
goal
which
is
yeah
and
you
have
full
full
replacement
for
open
tracing
which
will
not
be
able
to
to
be
because
they
already
have.
This
concept
of
baggage
and
opposition
has
attacked
so.
C
G
J
J
Let's
sing
on
this
one
next
week,
we'll
talk
about
at
the
w3c
meeting
today
to
be
clear,
I
don't
think
there
are
any
changes
expected
to
come
in
we're
just
going
through
the
the
rigmarole
of
becoming
like
a
going
editor's
draft
to
the
more
formal
standard,
and
then
we
can
catch
up
next
week.
G
Good,
so
in
the
meantime
I
would
suggest
we
merge
this
for
the
moment,
because
it
was
suggesting
to
use
ot
correlation,
and
I
will
not
mark
that
that
issue
as
fixed
and
next
week,
we
we
we
have
to
reevaluate
based
on
tyler's
feedback
and
and
stuff.
Maybe
maybe
the
right
solution,
as
tyler
proposed
is
delayed
a
bit
the
ga
of
the
baggages
and
just
say
that
everything
else
is
ga.
We
are
not
yet
fully
compatible
with
open
tracing
and
so
on,
but
we
are
working
towards
that.
It's
it's
a
reasonable
thing.
G
Yeah,
okay,
perfect!
I
will
make
the
the
right
changes
to
the
pr
to
not
to
just
update
the
the
thing
and
add
a
change
log
to
to
be
able
to
merge
the
pr
okay.
Next,
I
think
we
have
the
prototrace
package.
Oh
yes,
this
one,
I
I
started
to
look
at
this
sounds
amazing
on
the
paper,
because
we
called
logs,
we
called
metrics,
but
we
call
trace
without
an
s
at
the
end,
the
package
and
on
paper
it
sounds
amazing.
We
should
we
should
make
this
change
there
are
there
is.
G
G
If
I
change
that,
if
I
add
the
s
at
the
end
in
the
in
the
again
in
the
collector,
so
not
not
the
main
protos,
because
we
have
them
split,
we
have
the
main
protos
and
the
rpc
definition
of
the
protos.
So
so
I
can
change
the
main
protos
to
be
with
the
s,
but
the
grpc
pack,
grpc
definition.
I
cannot
change
to
have
it
with
the
s
so
now
what
to
do?
G
E
My
opinion,
I
think
we
should
make
the
change
the
changes
which
are
not
resulting
in
breaking
the
wire,
make
changes
to
the
combination
that
is
visible
in
the
in
the
apis
right
internally,
but
don't
make
changes
which
which
are
any
which
break
anything
on
the
protocol
level,
because
we
declared
it
stable
already.
E
G
E
I
mean
we
do
a
we,
we
do
a
backwards
compatibility,
that's
that's
still
a
breaking
change.
What
you're
suggesting
is
how
you
handle
the
braking
change.
Yes,
unless,
unless
people
upgrade
to
the
latest
version
of
the
collector
first,
they
will
have
a
problem
if
they
use
the
newer
version
of
the
client
library.
They'd
have
a
problem
which
is
not
what
we
promised
in
our
stability
guarantees.
G
G
E
Maybe
then
you
will
need
to
say
that
don't
use
this,
don't
call
this.
I
don't
know
it's
not
don't
call
it
it's
just
like
you
can
do
that.
You
can
do
that
in
the
future
as
well
right.
If
what
you're
suggesting
is
an
additive
change,
that's
what
you're
saying
you
keep
the
old
one
and
introduce
a
new
grpc,
which
is
exactly
the
same
thing,
but
has
a
different
name.
You
can
do
that
later.
You
don't
have
to
do
it
now.
E
G
G
M
It's
maybe
just
be
unfortunate,
but
I
don't
know
it
seems
kind
of
like
I
hear
what
you're
saying
like
you
could
add
another
one
where
it's
a
plural,
but
then
yeah
it's
an
additive
change,
but
it
also
backwards
incompatible.
So
you
can
say
somebody
new
is
using
the
new
plural
and
or
yeah,
using
the
new
plural
in
the
backwards.
C
E
If
you
want
to
add
that,
in
a
backwards
compatible
way,
you
have
to
specify
the
behavior
on
the
client,
which
is,
if
you
call
the
the
plural
version
and
it
fails,
then
you
have
to
fall
back
to
the
old
version.
That's
how
you
would
you
have
to
specify
yeah
behavior,
which
is,
I
think,
we're
just
over
complicating.
J
F
E
I
understand
perfectionists
in
in
all
of
us.
Want
that
to
be
perfect,
I
understand
I
want
that
to
be
perfect
as
well,
but
I
don't
think
it's
worth
the
effort
in
my
opinion,
then
I
can
close
the
the
the
thing,
but
you
can
either
close
or
just
do
the
part
that
you
already
did,
which
is
partial
renaming,
I'm
fine
with
either
approach
honestly,
no
strong
opinion
here,
I
think
either
way
works.
If
we
do,
the
partial
people
will
come
and
blame
on
us.
Why.
J
G
Especially
when
you
are
when
you
are
at
the
beginning
of
the
project
and
stuff
and
deal
with
that
soon,
because
because
to
be
honest,
we
we
have
probably
three
four
months
until
ga
we
can,
we
can
say,
for
we
do
the
change
right
now.
We
we
do
the
what
you
suggested
fall
back
to
the
other
one,
but
when
we
ga
ga
we
can
remove
the
fallback.
We
say
you
know
what
you
had
three
months
to
update
you
upgrade
for
this.
E
F
G
For
me
for
me
again
for
me,
there
are
two
options:
don't
do
anything
to
leave
as
but
do
partial
changes
feels
a
bit
worse
like
changing
only
the
proto
but
don't
change.
The
grpc
feels
feels
a
hybrid
where,
where,
where
I
feel
uncomfortable
to
be.
M
Yeah,
I
don't
have
a
strong
opinion
as
well.
I
think
a
tigran
actually
kind
of
brings
up
a
good
point
in
I
don't
know
if
it
was
a
comment
or
what
it
was
or
a
good
joke,
but
I
think
that
it
actually
might
be
a
useful
exercise
to
see
like
what
our
backwards
compatibility
story
is
going
to
be
the
longer
long
term
and
seeing
if
this
is
going
to
be
a
problem
that
we're
going.
E
To
I
mean
right:
if
you
want
to
actually
do
a
change
like
this,
you
do
it
that
way.
Right
you,
you
do
you,
you
declare
that
that
behavior
on
the
client
side
should
be
done
in
a
way
that
the
client
is
responsible
for
dealing
with
two
different
versions
of
the
server
right,
so
the
client
needs
to
be
able
to
detect.
If
it's
talking
with
a
newer
version
of
the
older
version,
it
needs
to
fall
back.
That's
how
you
do
the
changes
in
the
protocol.
E
J
F
E
G
F
Well,
we
only
have
one
minute
left,
so
so,
oh
there
you
are,
we
are
over
time
now.
Well
anyway,
it
was
a
very
nice
conversation
today.
Thank
you.
Everybody
please
review
and
help
us
to
close
as
many
issues
as
possible
this
week.
See
you
next
time
thanks.
Everyone.