►
From YouTube: 2022-06-14 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
Yeah,
I
can
speak
a
little
bit
about
this.
I
mean
I
think
it's
generally
agreed
on
the
the
only
question
left
in
there.
As
far
as
I
know
is
the
error
message
string
and
whether
it
should
be
optional
or
not.
There
was
some
talk
about
like
structured
errors,
so
that
the
client
could
know
what
to
do.
B
B
B
Yeah,
it's
not
really
a
question.
I
was
just
summarizing
the
current
state
of
this
issue,
we're
talking
about
the
partial
response.
B
I
believe
the
only
question
left
on
that
is
whether
or
not
the
error
string
should
be
optional,
but
it
doesn't
seem
like
most
people
that
were
commenting
on
the
issue
feel
very
strongly
about
it.
One
way
or
the
other.
I
was
decided
to
leave
structured
errors
for
potentially
future
enhancements
yeah,
so
that
the
error
string
is
the
only
the
only
real
question
left
and
currently
it
looks
like
it's
required.
C
B
C
Okay,
I
will
I'll
comment
them.
A
Yeah
other
than
that
it
looks
good.
He
has
three
approvals,
one
of
tigrano,
one
from
jim
mcd,
so
we're
in
good
stay
there.
Let's
just
wait
that
the
the
final
issues
are
solved.
Otherwise
it
looks
great.
I
will
review
that
myself
again
later
today.
A
Okay,
thank
you
so
much
for
that.
Let's,
let's
move,
please
merge,
adopt
attribute
requirement
level.
Systematic
conventions.
Are
you
here.
D
C
C
But
I
didn't
do
it
armin
did
it
three
minutes
ago.
A
A
Perfect,
the
next
one
is
about
specking
consistency
with
proto-definition
of
attributes,
never
your
round.
I
think
you
mentioned
that
at
the
end
of
the
meeting
last
week,
yeah.
E
Yeah,
this
fell
off
last
week's
one,
so
there's
effectively
an
inconsistency
with
the
definition
of
attributes.
We
already
know
that
logs
can
handle
nested
attributes
and
I
just
want
the
spec
cleaned
up
and
defined
properly.
Proto
supports
necessary
attributes
for
everything.
E
E
So
any
more
comments
on
that
issue
would
be
good,
and
I
plan
to
start
creating
a
pr
this
week
for.
A
Yeah
tigran
is
not
in
the
call
today
but
yeah.
I
think
that
he
was
asking
something
regarding
handling
there
like
sorry,
the
reasons
why
this
is
intentional,
so,
let's
yeah,
let's
hope
that
he
answers
soon.
This
one.
E
Yeah
yeah
I've
been
talking
to
the
logs
thing.
This
is
primarily,
I
found
this
as
part
of
the
the
rum
sig,
because,
as
part
of
our
events,
we
we
need
support
for
nested
attributes,
which
is
why
we're
using
logs
as
the
transport.
A
Perfect:
okay,
if
there
are
no
comments
on
that
one
for
now,
let's
move
to
the
next
one,
which
is
more
if
you
needed
for
a
pull
request
right,
spanx
exporter,
concurrency,.
F
F
For
your
information,
it's
a
very
small
pr,
but
it
touches
the
exporter
contract.
So
previously
the
exporter
spec
were
written
in
a
way
that
it
doesn't
really
allow
any
concurrency
and
expire
has
to
return
success
or
failure
indicating
whether
the
data
is
sent
to
the
backend
or
not.
So
this
pr
tristan
was
trying
to
clarify
that
actually
there's
a
way
to
make
concurrent
call
if
you
want
to
obtain
and
also
change
the
semantic
a
little
bit
regarding
the
return
value
from
exporter.
F
A
Okay-
I
don't
see
tristan
here,
so
thank
you
for
explaining
that
one
yeah,
let's,
let's
take
a
look
at
that:
okay,
the
next
one
that
I
put
out
myself
there.
This
is
regarding
me
making
otlp
stable.
A
We
talked
about
that
in
the
past.
There
was
some
initial
discussion
there,
oh
well,
then
I
saw
that
you
just
commented.
Thank
you
for
that.
It
feels
that
we
need
a
champion
or
somebody
that
helps
drive
this.
Otherwise
you
know
we'll
just
be
doing
a
best
effort
thing
which
may
not
be
fast
enough.
You
know
I.
C
I
think
I
think
tigran
is
willing
to
do
that,
but
we
did
not
provide
enough
feedback
to
to
him
on
that
issue.
I
mean
he
is
driving,
he
wrote
the
issue,
so
I
don't
think
we
are
looking
for
that.
We
are
looking
actually
for
people
to
to
make
decisions
there
here
and
yeah.
We
are
very
bad
of
making
decisions.
That's
a
separate
question.
A
Yeah,
I
think
that
one
thing
that
we
still
need
to
do
just
in
case
is
what
daniel
mentioned
in
the
issue,
which
is
just
trying
to
find
or
identify
changes
that
may
affect
you
know
that
may
break
just
to
understand
them
and
try
to
provide
a
better
insight
or
can
kind
of
promise.
So
I
don't
know
how
to
call
it.
You
know
basically
have
proper
expectations
for
the
users,
and
somebody
has
to
do
that.
B
I
think
everything
is
pretty
generally
agreed
on
this.
The
only
question
is
and
bogdan,
it
looks
like
you
just
commented
on
it
a
minute
ago
and
you
suggest
we
only
make
the
identifiers
of
an
enum
like
that.
The
number
representation
stable
and
not
the
actual
string
name
of
it
do
you.
Can
you
give
me
a
quick
summary
of
of
why
you
don't
want
to
make
the
string
stable,
because
in
my.
F
B
We
can't
really
guarantee
that,
like
you
know,
some
third-party
service,
like
a
database,
may
export
otlp
natively
and
decide
to
use
strings.
You
know
that
there
could
always
be
we.
We
can't
force
others
to
do
things
and
as
a
receiver,
you
have
to
handle
the
case
anyways.
B
C
B
Yeah
I
mean
if
you
publish
a
proto,
if
you
publish
a
protobuf
definition,
and
somebody
uses
some
library
and
that
library
happens
to
use
strings
there.
It
doesn't
matter
if
we
put
in
in
the
pros
that
we
say
not
to
do
this.
People
are
going
to
you
know,
maybe
do
it
anyways
and
they'll
be
confused
when
it
doesn't
work.
B
C
It's
for
me
for
me
to
understand
where
I'm
sitting
like
if
we
are
making
exceptions,
why
would
not
consider
this
I'm
by
the
way,
I'm
not
saying
to
to
use
numbers?
I
was
just
saying:
do
we
consider
this
yeah
and
the
argument
of
not
considering
because
it's
against
proto
doesn't
stand
to
me,
because
we
already
have
an
exception
that
that
doesn't.
G
Make
it
doesn't
follow
right,
just
because
there's
one
exception
doesn't
mean
that
all
exceptions
based
on
that
assertion
are
valid.
It
may
have.
There
may
have
been
a
good
reason
to
have
an
exception
for
the
the
hex
trace
id
and
span
id,
but
not
a
good
reason
to
have
an
exception
for
numeric
infinite.
C
One
exception,
therefore:
we
need
to
allow
all
exceptions,
I'm
not
saying
to
make
any
session
I'm
saying
to
discuss
if
this
can
be
an
exception,
and
we
should
do
this,
I'm
not
saying
that
we
should
do
it
right.
It's
just
an
idea
that
I
was
trying
to
discuss
and
you
are
just
against
me
and
you
are
not
trying
to
have
a
discussion.
C
C
That's
that's
one
thing
the
other
one
is
there
are
concerns
right
now,
in
my
opinion,
on
the
names
that
we
choose
even
for
for
a
future.
If
we
accept
strings,
we
should
probably
have
a
pattern
of
choosing
the
strings.
That
is
not
that
necessary
that
long,
and
so
so
the
size
of
the
string
will
become
another
problem,
for
example,
or.
B
B
B
So
so
because,
particularly
with
json,
I
I
know
a
lot
of
people
like
json
because
of
the
human
readability
of
it,
and
if
it's,
if
the
enums
are
used
as
numbers,
you
completely
lose
that
and,
as
far
as
I
remember
the
initial
discussion
from
like
the
trace
id
and
span
ids
being
in
hex,
that
was
to
preserve
the
human
readability
in
the
json
as
well.
That's
why
we
didn't
go
with
base64,
which,
for
the
record,
I
would
have
preferred
to
go
with
base64
back
then,
but
that
decision
is
long.
B
But
that
I,
like
the
human
readability
argument
of
the
of
at
least
allowing
strings,
and
then,
if
somebody
is
trying
to
reduce
their
payloads
using
the
number
identifiers,
obviously
makes
sense.
Okay,
I'm
fine.
C
I'm
fine
also
so
so
we
we
should
document
this
and
and
move
forward
and
say
we
accept
strings
as
well,
and
here
are
the
reasons
the
last
one
that
I
I
can
think
of
related
to
to
protobuf
is
the
the
field
names.
I
think
protobuf
allows
you
to
have
the
field
names
in
two
ways.
It's
is
the
the
the
camel
case
or
the
or
the
sneak
case.
I
think,
if
I'm
not
mistaken,
I
can
double
check.
But
if
I
remember
correctly,
you
can
have.
B
C
B
Yeah
I
mean
in
my
mind
I
would
prefer
we
just
do
what
the
protobuf
website
says,
because
people
who
are
already
familiar
with
protobuf
will
will
be
expecting
that,
but
I
don't
feel
particularly
strongly
about
that
one.
I
guess.
C
Okay,
these
are
the
two
things
and
I
there
is
another
question
of,
but
that's
separated
and
then
our
thing,
which
is,
should
our
c
expose
generated
code
publicly
or
not
or
what
are
the
guarantees
of
the
generated
code?
We
are
giving
to
the.
B
Users,
so
I
think
from
a
proto
perspective,
we
can't
really
you
know
I
would
prefer
to
say
these
are
the
things
that
are
stable.
So
we
say
the
identifiers
are
stable.
B
The
enum
names
are
stable,
the
you
know,
whatever
we
decide
like
all
of
these
things
are
stable
and
then
it's
up
to
the
consumer
to
you
know
if
they're
going
to
use
a
code
generator
to
understand
whether
or
not
changes
are
breaking
or
not,
but
we
should
make
as
many
things
stable
as
possible
in
order
to
have
the
best
chance
of
a
code
generator
also
being
stable,
but
do.
C
H
Fine,
but
I'm
asking
I
don't,
I
don't
think
we
can
right
now,
just
like
there's,
there's
a
couple
sigs
that
actually
do
custom
protocol
buffer
serialization
for
optimization
purposes.
H
So
if
we
do
expose
something
it'd
be
something
we
don't
even
use
in
some
of
these
things,
I
don't
think
that's
I
don't
think
that's
actually
a
benefit.
I
think
that
that
would
actually
be
possibly
harmful
because
there'd
be
this
thing.
No
one
internally
to
us
uses
right
that
we're
giving
to
clients.
B
C
So
so
should
we
document
then
that
our
sig
should
not
expose
this
publicly
because
having
another
inconsistency
where
some
sigs
expose
this
and
some
don't
will
also
confuse
people,
because
they
will
come
and
say:
hey
java,
do
this
for
me,
because,
because
node.js
does
it,
so
you
should
also
do
this.
I.
G
B
We
can
maybe
document
that
this
is
not
a
requirement
if
it
comes
up
as
a
question
very
often,
but
for
example,
javascript
does
not
publish
a
package
like
this,
and
I
don't
often
hear
about
people
asking
for
it.
We've
had
a
couple
of
questions
here
and
there,
but
it
hasn't
been
a
problem
for
us
to
just
say:
sorry:
we
don't
do
this
generally
people
just
say
okay,
so
I
think
we
don't
need
to
head
off
a
problem
before
it
happens.
B
If
we
suddenly
start
seeing
a
lot
of
requests,
we
can
always
address
it.
Then
I
think
I
saw
a
lot
of
requests.
That's
why
I'm
asking
for
this
I
mean
I
just
sold
it.
Maybe.
C
B
C
Okay,
talking
about
that,
can
we
then
recommend
users
one
way
or
the
other,
or
we
don't
care
even
about
that.
B
H
So
like
what
what's
that
use
case,
is
that
use
case
like
advanced
vendors,
that
are
trying
to
implement
their
own
ingestion,
or
is
it
folks
who
can't
use
the
sdk?
So
I
don't
know
I
would
push
on
like
push
on
what
the
use
case
is,
so
we
can
address
it
directly,
whatever
that
use
case
happens
to
be,
and
if
we
don't
know
what
the
use
case
is,
let's
find
it
out
the
use
case.
H
Yeah,
I
guess
what
I'm
suggesting
is.
I
I
envision
two
usages
of
this
right.
I
envision
a
vendor
who
wants
to
consume
an
otlp,
in
which
case
we
can
say,
you
know,
feel
free
to
build
your
own
stubs
and,
and
that
you'll
probably
be
better
off
figuring
out
how
to
ingest
this
yourself.
For
let's
say
it
is
an
existing
system
that
produces
telemetry
that
wants
to
export.
H
In
that
case,
it
might
be
worthwhile
for
us
to
expose
a
helper
library
that
is
hyper
optimized
at
writing,
telemetry
very
quickly,
similarly,
to
what
we
do
in
our
own
ltlp
exporters
right,
but
like
that's,
why
I'm
asking
about
the
use
cases
that
people
need
this
for
because
in
the
one
case
I
would
do
one
recommendation,
the
other.
I
would
actually
think
about
potentially
adding
a
new
feature,
not
immediately
right
or
not
in
a
not
like
urgently
just
yet,
but
like.
I
would
think
about
adding
that
eventually.
C
Yeah,
it's
interesting.
The
second
use
case
that
you
mentioned.
Why
would
they
not
use
the
sdk
directly
that
that's
for
me?
I
would
like
to
understand
if
that
use
case
exists
right
now
and
and
it
will
be
good.
H
Yeah,
I
think
that
that's
why
I
understand
the
use
case
is
important
because
it
could
it
could
be
that
we
need
to
expose
something
in
the
sdk
for
direct,
and
we
actually,
I
specifically
mentioned
that,
because
I
know
from
metrics,
if
you're
trying
to
do
a
direct
metric
to
metric
connection
with
open
telemetry.
There
is
a
missing
api
that
we
need,
but
that's
anyway,
that's
a
different
story.
B
H
J
Maybe
we
can
get
concrete
for
a
second,
so
there's
a
there's,
a
java
proto
repository
open,
telemetry,
proto
java
that
publishes
these.
This
code
generated
this
generated
code
from
the
protos,
and
so
the
use
cases
for
that.
J
J
I
I
I
agree,
but
so
I
don't
think
that
there's
a
strong
reason
to
keep
these
around
for
the
vendor
use
case.
So
but
you
know
eat.
Let's
say
that
we
do
go
1.0
1.0.0
with
the
protos.
Would
we
would
we
mark
the
generated
java
classes
as
stable,
and
I
think
the
answer
would
be?
J
No,
so
you
know
just
be
because
you
know
the
utility
of
it
is
for
test
cases
and
for
vendors,
and
so
we
don't
really
have
an
incentive
to
stabilize
that,
and
so
you
know
like
I
guess
my
initial
perspective
would
be
to
leave
it
as
as
alpha
as
long
as
we
can
get
away
with
that.
If
we
were
to
continue
to
publish
it.
H
Yeah
another
way
to
phrase
this
jack
is
like.
I
don't
think
we
should
force
you
as
a
maintainer
to
have
to
maintain
that
client
library,
if
you're
not
actually
using
it
in
your
role
as
maintainer.
If
your
sig
decides
yes,
we
want
to
provide
this
to
people
because
we
see
enough
requests.
I
still
think
that
sig
by
sig,
that
can
be
a
decision
that's
made
and
and
like
we,
we
can
look
at
demand
for
it
and
understand
it,
because
I
do
think
it
will
vary
by
language
right.
H
I
don't
think
I
don't
think
the
demand
will
necessarily
be
the
same,
and
I
think
it's
okay
to
allow
that
at
the
sig
level.
At
this
point,
I
don't
again
that
level
of
inconsistency
as
a
thing
where,
like
some
cigs,
can
provide
that
client
library
and
some
cigs
don't
have
to.
I
think
we're
still
talking
advanced
use
cases.
I
don't
think
we're
talking
everyday
users,
so
I
don't
think
it's
a
a
big
deal.
Okay,
but
what
I'm
hearing.
C
We
need
to
guarantee
that
we
need
to
guarantee
stability
of
that,
because,
if
one
of
our
seeds
I
mean,
unless
I
want
to
break
one
of
our
sigs,
but
if
one
of
our
sikhs
expose
this
publicly
and
we
allow
that
as
one
of
the
possibility
to
do
this,
it
means
we
need
to
to
put
all
the
restrictions
on
this
repo
that
are
coming
from
from
that.
Supporting
that.
B
I
don't
think
necessarily
because
the
the
sigs
that
are
that
are
publishing
these
client
libraries
for
one
thing:
if
they're
publishing
it
for
their
own
internal
use
cases,
it's
a
it's
an
implementation
detail
and
if
there's
a
breaking
change,
they
can
always
just
bump
the
version.
It's
not
it's,
not
the
sdk,
so
it
can
be
version
bumped
and
there
can
be
breaking
changes
in
there
as
long
as
the
sdk
itself
remains
stable.
C
Correct,
but
I
don't
think
the
goal
has
this:
they.
They
cannot
do
this
because
they
expose
it
publicly,
for
example-
and
I
will
give
you
another
case
where,
where
I
don't
know,
if
generated
code
should
be
or
not
be
stable,
but
one
of
the
thing
is
making
a
field
optional.
For
example,
it's
it's
breaking
change
on
the
wire.
J
I
think
what
you're
getting
at
bogdan
is
that
all
of
these
different
types
of
changes
that
are
possible,
we
should
we
should
assert
what
what
our
position
is
on
each
of
them,
so
that,
if
you
are
publishing
an
artifact
that
does
code
generation
based
on
them,
you
can
know
whether
or
not
there
are
likely
to
be
breaking
changes
in
the
generated
code.
C
J
But
I
I
just
I
do
want
to
reiterate
what
daniel's
point
was,
though,
so
you
know
you
know,
even
if
even
if
we
don't
make
those,
even
if
we
don't
document
what
allowable
changes
are
and
some
generated
code
breaks,
you
can
do
a
major
version
bump
of
that
without
impacting
the
sdk,
because
you
conversion
that
independently
and
so
but
do
we
do
we
do
a
otlp
to
v2.
C
J
B
Would
say
anything
that
affects
wire
backwards
compatibility,
including
json,.
H
Okay,
would
you
explain
is:
is
the
point
you're
getting
at
that
the
version
of
generated
code
should
not
be
the
same
as
the
version
of
the
binary
protocol,
because
that
I
would
agree
with
right.
If
we
make
these
generated
code
artifacts,
there
should
be
a
separate
version
number
to
denote
the
stability
of
the
generated
code
separately
from
the
binary
protocol,
because
we
know
that
those
will
be
different.
Yeah.
B
G
Don't
think
just
because
of
the
way
that
some
of
the
generated
artifacts
have
been
exposed
and
v2
are
separate
packages
modules
from
v1.
B
G
So
my
my
view
of
the
stability
guarantee
that
we
should
make,
I
think,
is
what
I
said
on
the
ticket.
We
should
guarantee
that
we
will
not
cause
backwards,
incompatible,
changes
in
generated
code
assuming
the
same
version
of
the
code
generator,
so
user
has
know
v1
of
1.0
of
proto.
We
go
to
v
1.1.
We
make
something
that
wasn't
optional
optional:
they
don't
change
their
proto
generator.
It
results
in
different
incompatible
generated
code.
We
should
not
do
that
even.
B
That,
though,
is
very
code
generator
dependent
because
for
in
javascript,
for
example,
even
non-optional
fields
result
in
everything
is
optional
in
the
generated
code,
and
if
you
don't
provide
it,
it
just
puts
a
default
a
default
value
in
so
that's
not
breaking
for
the
javascript
generated
code.
So,
like
I
said,
I
think
we
need
to.
Instead
of
saying
the
generated
code
is
stable.
We
need
to
say
field.
Optionality
is
stable
right.
We
need
to
define
the
various
things
that
are
important
to
us.
C
I
I
think,
to
be
honest,
my
two
cents
here
I
think
protobuf
is
not
very
well
suitable
for
this,
for
two
reasons,
and
in
general
I
think
we
have
to
decouple
the
binary
version
or
the
wire
version
with
the
generated
code
version.
I
I
kind
of
agree
with
joshua
on
that,
and
I
think,
because
of
this
repo,
we
are
tying
them
together,
which
I
don't
think
we
should.
G
G
G
G
B
C
But
it's
not
in
the
sdk.
To
be
honest,
it's
in
one
of
the
exporter
correct,
anthony,
it's
not
the
whole
sdk
that
exposes
this
correct,
so
so
it's
more
than
that
daniel!
It's
not
even
the
ezekiel.
It's
one
of
the
exporter
that
has
this
problem
well,.
H
So
I
have
a
peanut
gallery
comment
for
go,
which
is,
if
you
did
manage,
to
make
these
all
separate
packages
based
on
the
code
gen.
It
would
make
all
of
the
performance
work
we
did
for
otlp
like
tigran's
repo.
That
would
be
way
easier
to
deal
with,
because
that's
basically
what
we
had
to
do
to
make
that
thing
work
and
compare
different
code
gen
to
check
performance
of
like
sterilization.
H
H
H
What
I
would
say
instead
is
if,
if
the
go
sig
is
willing
to
maintain
enforcement
in
the
proto
repository
around
gocogen
to
solve
this
problem,
that's
fine,
but
that
means
that
we
need
to
understand
as
proto
maintainers
that
there's
an
aspect
of
this
that
relies
on
go
sig,
maintenance
and
that
that
is
an
explicit
dependency,
and
I
think
that's
ok
again,
because
we
should
allow
the
go
sig.
This
is
a
problem,
that's
very
ghost
specific
and
we
should
let
them
make
the
best
decision
for
users.
C
To
be
honest,
is
not
a
goal
problem,
it's
a
decision
that
was
made
in
this
way
I
mean
they're,
they
could
have
done
different
design
and
not
have
to
expose
this.
It's
so,
and
there
is
a
solution
to
not
exposes.
Is
there
was
a
decision
made
so
so?
What
I'm
trying
to
say
here
is
they
can
do
by
doing
a
version
bump
on
that
artifact
on
the
on
the
exporter
that
exported
they
can
remove
this
and
make
it
an
internal
package,
and
nobody
will
will
complain.
C
G
A
B
B
B
If
we
say
it
does
not
mean
stability
for
generated
clients,
that
does
create
a
problem
for
go
in
my
mind,
not
a
completely
unsolvable
one,
but
it
also
means
that
then
nobody
will
be
able
to
publish
a
client
library
that
is
completely
stable.
If
there's
a
proto
change,
you
need
to
bump
the
version
of
that
client
library.
In
my
mind,
that's
not
necessarily
a
problem.
I
don't
think
it's
a
problem
that
you
know.
B
Exporter
version
1.0
depends
on
client
label
library
version
2.0,
like
that's
in
my
mind,
totally
fine
others
may
disagree,
you
know
is
as
long
as
you
can.
You
can
version
that
package.
The
issue.
The
reason
we're
talking
about
go
is
because
it
sounds
like
go,
cannot
easily
version
that
package
separately
right
now
with
their
current
design,
but
they
could
always
rev
their
their
exporter.
To
the
next
version,
but
I
don't
know
if
they
can
do
that
separately
from
the
sdk
either
I'm
not
familiar
enough
to
go
publishing.
J
H
I
really
really
really
think
we
do
not
want
to
tie
the
client
library
version
number
like
I.
I
agree
that
we
should
try
to
keep
the
generated
client
libraries
as
stable
as
possible,
absolutely
but
that's
different
than
versioning
them
the
same
as
the
proto
that
that
I
absolutely
am
against
just
fundamentally
from
how
like
protocol
buffers
and
protocols
evolve.
H
Right,
like
you,
can't
change
the
code
of
that
client
library,
hardly
at
all
in
any
kind
of
improvement
way
for
users,
if
you
lock
those
two
versions
together
and
they
don't
need
to
be
tied
right,
like
you,
can
completely
reimplement
that
client
library
to
be
ten
times
more
efficient,
and
then
that
would
be
a
breaking
change
from
a
code
perspective,
but
not
from
a
protocol
perspective
right.
So
what
what
we
see
a
lot
is
in
other
cigs
is
like
the
they
actually
version
the
package
with
the
protocol
name.
H
You
you,
the
package
name
almost
needs
to
include
the
version
number
so
that
you
can
have
multiple
of
these
at
play
at
a
given
any
given
time
right
and
that's
that's
a
that's
an
inherent
thing
of
protocols
really,
if
not
that
we're
ever
going
to
have
a
version
two
of
this
protocol
at
least
I
hope
that
we
never
have
to
have
one,
but
if
we
were
to
have
one
you
would
need
to
have
version
one
and
version
two
live
at
the
same
time
likely
in
many
scenarios.
H
C
100
with
you,
by
the
way
for
versioning,
we
already
have
version
in
the
package
name
for
for
the
proto
and
in
the
directory
paths.
So
so
you
will
be
able
to
to
have
both
versions
in
the
same
time
and
even
in
the
grpc
endpoints
or
http
endpoints.
So
everywhere
we
have
a
v1
directory
there
in
part
of
the
path
as
part
of
the
path.
So
so
we
are
good
on
the
version.
I.
B
Don't
think
he's
saying
for
the
proto
package,
I
think
he's
saying
for
the
client
library,
if
you
if,
if
proto
repository
revs
to
v2,
you
make
a
client
library
with
v2
in
the
name
so
that
you
can
use
both
client
libraries
side
by
side.
I
see
I
see,
make
sense
thanks,
josh
correct
me.
If
I
misunderstood
that.
B
That
is
one
way
of
solving
the
versioning
issue
that
anthony
just
brought
up
where
all
all
client
library
packages
are
assumed
to
be
proto
v1,
regardless
of
their
major
version.
And
then
when
proto
v2
comes
out,
client
libraries
would
have
a
name.
B
J
Has
somebody
done
the
analysis
on
the
go
code
generation
to
see
which
types
of
changes
are
allowed
and
not
allowed,
and
you
know
so
we
can
see
to
what
extent
they
disagree
with
the
types
of
changes
we
want
to
be
able
to
make
to
the
to
their
protocol.
The.
B
One
right
now
that
we're
that
specifically
spurred
this
argument
was
field
optionality
which
is
not
breaking
on
the
wire
but
he's
breaking
in
their
code
generation.
So
the
question
is:
what
did
what
denotes
a
breaking
change
for
the
protocol,
and
I
said
my
my
argument
was
anything
that
breaks
the
wire
format
and
then.
J
B
Said
that's
breaking
for
our
generated
code
and
that's
what
would
spur
the
argument
between
or
not
argument
is
probably
the
wrong
word.
But
between
do
you
have
the
version
of
the
protocol
separate
from
the
version
of
the
client
library
which
solves
that
problem
and
josh
and
myself,
and
I
think
bogdan
all
were
saying
that?
Yes,
you
do
have
separate
versions
between
the
protocol
and
the
client
library.
So
if
field
optionality
has
changed,
the
protocol
version
is
not
bumped,
because
that
is
backwards
compatible
on
the
wire,
but
the
generated
code.
J
C
J
I
think
it'd
be
interesting
to
look
at
that
and
see
which
well,
we
need
to
understand
that,
first
of
all,
so
that
when
we're
making
changes
to
protos,
we
don't
break
wire
compatibility
and
then
it'd
be
interesting
to
compare
on
a
case-by-case
basis
where
the
go
code
generation
tool
is
incompatible.
C
The
message
name,
for
example,
the
message
name.
I
think
that's
also
not
a
breaking
change
on
the
wire
because
they
are
not
put
on
the
wire.
B
C
B
I
think
we
should
make
stability
guarantees
on
as
many
of
these
things
as
we
can,
but
we
may
always
miss
something,
and
if
we
miss
it,
then
we
have
to
know
when
we
catch
it
in
the
future.
Like,
oh,
we
want
to
change
this
thing.
Can
we
change
it?
Can
we
not,
I
think
the
guiding
principle
should
be.
Does
it
change
the
wire
if
it
changes
for
generated
code,
then
you
know
that
will
be
something
to
consider
at
that
time,
but
not
necessarily.
C
Yeah
the
other
example
which
tigran
had
in
that
issue
by
the
way
is
you
can
have
some
helpers
and
gnomes,
for
example,
and
we
do
have
some
helper
animals
which
are
we
are
not
using
on
the
wire
it's
just
helper
there
to
for
us
to
do
some
beat
operations
for
flags
okay,
so
there
are
essentially
there
are
some
masks
there
that
we
can
use.
C
A
Interface,
sorry
guys,
for
the
second
time,
let's
keep
conti
discussing.
I
think
we
are
discussing
details
at
this
point.
So
let's
continue
that
and
hopefully
we
can
come
to
an
agreement,
but
I
think
that
the
main
stuff
has
been
discussed.
So
thank
you
for
that
and
sorry
for
interrupting.
We
have
only
eight
minutes.
We
have
two
items,
one
of
them
we
cannot
discuss
much,
which
is
about
library,
specific
metric
conventions,
tigran
and
dan
are
not
here.
A
K
Yeah,
what's
up
everyone,
my
name
is
ryan.
I
have
been.
I
was
working
with
like
morgan
and
I
guess,
like
a
couple
other
people
from
the
hotel
committee
on
moving
this
issue
forward.
K
I
put
a
link
to
the
initial
issue,
but
basically
we
for
those
who
are
at
the
hotel
meeting
profile
was
discussed
as
one
of
the
sort
of
like
priorities
that
people
were
interested
in
moving
forward
and
that
being
supported
by
otel
as
sort
of
an
official
event
type,
and
so,
as
of
a
couple
weeks
ago,
we
kind
of
kicked
off
the
effort.
We
had
a
kickoff
meeting
with
about
like
40
people
who
showed
up,
and
basically
we
started
discussing
sort
of
just
from
a
high
level.
K
You
know
what
people
were
interested
in
and
how
they
wanted
to.
You
know
what
they
were
hoping
to
get
out
of
hotel
supporting
profiling.
There
were
people
from
a
lot
of
different
groups,
whether
that
be
like
apm
providers,
open
source,
maintainers
language
maintainers.
K
There
were
some
people
from
hotel,
a
lot
of
different
groups,
and
so
so
yeah.
I
just
kind
of
wanted
to
propose
to
this
group
just
one
to
make
you
all
aware
that
this
is
an
effort
that
has
started
one
of
the
things
that
tigrun
said
when
when
we
were
meeting.
K
One
of
the
points
he
made
was
that
there
were
a
lot
of
new
people
who
have
not
been
involved
in
other
hotel,
related
efforts,
and
so
one
of
the
things
that
he
was
pretty,
I
guess
like
adamant
about,
was
that
we
make
sure
that
we're
not
sort
of
like
building
whatever
we
ultimately
come
up
with,
for
this
supported
event,
type
that
we're
not
doing
it
in
a
vacuum
and
that
it's
consistent
with
the
other
sort
of
event,
types
and
specifications
and
that
kind
of
stuff
and
and
so
yeah.
K
I
wanted
to
present
it
to
this
group,
obviously
even
just
today's
discussion,
there's
kind
of
a
lot
of
these
sort
of
like
nitty-gritty
details
that
we
want
to
make
sure
we
get
as
right
as
we
can
from
the
beginning,
and
so
so
yeah,
basically
our
next.
Our
second
meeting
is
this
thursday:
it's
already
on
the
hotel
calendar
at
8
a.m.
K
Pacific
time
and
the
the
sort
of
most
high
level
goal
of
that
meeting
is
to
get
the
ball
rolling
on
an
official
document
of
a
specification
for
profiles
that
we
ultimately
hope
to
present
to
this
sig
and
and
kind
of
go
from
there
so
yeah.
I
think
that
is
everything
just
kind
of
wanted
to.
Let
you
all
know
also.
K
If
anybody
has
any
thoughts,
suggestions,
recommendations,
tigran
gave
us
a
bunch
of
sort
of
resources
as
to
other
kind
of
signal
types
for,
like
metrics,
logs
traces
that
we
can
sort
of
use
as
a
foundation
for
this
effort,
but
yeah.
If
anybody
here
has
any
thoughts
that
you
want
to
add
would
love
to
hear
them.
Otherwise,
we'd
love
to
have
you.
C
Two
things
I
would
suggest
you
to
bring
one
tc
member
to
this
meeting
that
will
be
involved
and
is
interested
into
into
supporting
this
effort.
The
reason
you
will
simplify
your
life
a
lot
and
and
things
will
move
faster
second,
is-
I
would
strongly
suggest
to
if
you
didn't
do
already-
to
talk
to
to
google
people,
because
they
have
huge
experience
in
profiling
and
they
have
the
april
format
and
stuff,
and
it
will
be
extremely
valuable
to
have
a
discussion
with
the
with
those
folks.
K
K
There
he's
good
yeah
yeah,
so
he's
involved
yeah.
We
have
yeah
people
from
google
elastic
the
prod
filer
people.
We
have
some
like
ebpf
people,
yeah
splunk,
new,
relic
pixie.
C
Honeycomb
yeah,
and
now
you
need
the
tc
member
morgan
is
not
morgan
is
in
gc.
He
doesn't
have
the
the
power
to
merge
things
and
to
move
things
fast.
So
so
I
would
strongly
encourage
to
to
maybe
talk
to.
I
don't
know
carlos
george
me
or
tigran
tigran,
maybe
if
he
wants
theirs,
make
sure
you
communicate
with
him,
and
you
ask
him
to
sponsor
you
and
to
to
work
with
you
closely,
because
that
that
will
that
will
make
things
move
faster
for
you.
K
Okay
sounds
good
thanks
for
the
feedback.
Yeah
tigran
was
there
as
well
and
has
been
yeah.
He
was
the
one
who
kind
of
gave
us
the
the
the
resources
to
kind
of
of
things,
to
look
at
to
make
sure
we're
not
building
it
in
a
vacuum,
as
I
mentioned,
but
yeah
thanks
for
the
feedback,
anybody
else
have
any
thoughts.
I
know
we're
coming
up
on
time
here.
K
All
right
awesome!
Well,
thanks
for
letting
me
pop
in.