►
From YouTube: 2022-08-17 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
B
A
A
Maybe
we
should
skip
that
until
he
joins.
Maybe
let's
have
a
look
at
the
second
one,
the
instant
exporter
sponsorship.
D
Yeah
yeah,
so
I'm
working
with
the
instant
folks
on
this
so
yeah.
I
can
maintain
it
and
I'll
work
with
them
and
and
yeah.
C
I
don't
know
josh
sorry
for
for
your
comment
so
back
to
this.
I
I
want
to
make
sure
that
we
are
not
exposing
something
and
then
they
come
and
say
hey
what
the
heck
are
you
doing?
This
is
not
what
we
wanted
or
whatever.
C
Yeah,
let's
make
sure
that
somebody
from
istana
says:
yes,
we
want
to
have
this
and
we
are
working
with
you
martin
to
maintain
this,
and
then
we
have
a
process
for
every
for
every
vendor.
We
have
a
process
which
is
we
go
around
robin
so
if
nobody
volunteers
to
be
a
sponsor
in
a
week
or
something
like
that,
we
go
around
robbie
because
we
said
that
we
accept
all
the
vendors.
C
So
because
of
that,
is
it
anyway
we'll
do
round
robin?
If
and
we
have
a-
I
think,
I'm
the
first
one
or
the
second
anyway,
we
will
see
who
is
who
is
next
yeah.
D
So
I'll
I'll
ask
someone
from
inside
come
on
next
week,
if
that's
okay
and
they
can
robertson,
but
so
just
to
be
clear.
They
someone
in
our
company
wrote
it
initially
and
I'm
just
taking
it
and
helping
them
to
to
get
it
out
there
and
stuff
like
that.
So
when
I'd
be
pushing
in
the
pr's
and
counting
the
stuff,
I'd
be
I'll,
be
caution
and
the
focus
that
we're
involved.
D
E
Some
more
issues
were
added
to
the
milestone,
so
I
just
wanted.
I
was
asking
for
an
update.
Essentially
you
know
we'd
like
to
get
everyone
like
to
get
the
collector
to
1.0
state
p
data
was
our
first
target.
We
kind
of
had
to
end
the
summer
target
sounds
like
we're
not
going
to
hit
that
anymore.
I
just
wanted
to
hear
thoughts
about
that.
C
C
So,
let's
let's
go
through
the
issues
then
so
first
one
was
the
flags.
We
still
haven't
finished
that
you
know
you
know
we
just
did
the
change
for
vlogs
and
I
need
to
go
through
the
deprecation
thing
it's
gonna
take
us,
I
think
one
or
two
versions.
We
have
to
finish
that.
Then
there
is
the
severity
anoms,
which
I
figure
out,
that
the
names
are
capitalized
upper
cases
and
it
was
inconsistent
with
all
the
other
anoms.
So
it's
just
a
rename
of
the
new
values.
C
One,
the
5859-
I
I
just
figure
out
while
changing
usages
to
the
new
immutable
slices
thing
that
they
they
are
causing
lots
of
allocations,
and
you
can
see
the
examples
we
are
talking
there
in
the
issues
and
there
are
some
options
there
to
maybe
go
on
the
other
path
or
whatever.
C
That's
that's
what
we
are
discussing
there.
We
can
close
it
and
we
can
say
yeah
sure
we
that's
it
it's
very
expensive
to
to
work
with
this
or
we
we
can
fix
this,
and
there
are
two
two
issues
related
to
insert
and
then
update
to
the
map
and
that's
something
that
somebody
has
to
champion
and
get
make
a
decision
on
both
of
these,
because
they
are
very
related.
C
A
A
it's
about
the
fact
that
we
return
essentially
reference
data
types
from
get,
and
then
any
mutation
actually
invalidates
that
reference.
I
don't
know
what
can
we
do
here
because,
because.
A
C
One
of
the
option
is,
I
mean
if
we
change
the
way,
how
we
represent
the
one-off,
that
we
have
there
right
now
we
do
two
allocations
inside
the
one-off.
We
can,
I
think
we
can
use
one
of
this
allocation
to
put
it
in
the
slice
and
then
we'll
no
longer
have
this
problem
anyway.
There
are
options
for
us
to
to
fix
this,
but
I
don't
know
if
we
want
to
fix
it
or
not,
and
somebody
has
to
to
own
it.
B
I'm
talking
about
the
issue
when
we
delete
mutates
the
result
of
the
gate
yeah.
I
still
don't
suggest
that
if
we
want
to
move
to
the
new
to
the
last,
maybe
it
will
solve
the
problem
right.
Maybe
we
can
just
revert
the
optimization
for
now.
C
A
Just
just
to
make
it
clear,
we
return
a
reference
to
to
inside
the
slides
right.
We
return
a
reference
to
the
element
of
the
slice
instead
of
through
the
message
itself,
because
the
message
is
now
embedded
in
the
slice:
it's
not
a
pointer
data
type
anymore.
A
C
Let's,
let's,
let's,
let's
somebody
who
whatever
who
wants
to
own
these
issues,
I
think,
should
should
analyze
a
bit.
What
can
we
do
in
the
future?
How
how
this
data
structure
can
look
in
the
future?
C
If
that
new
look
will
fix
this
problem
with
no
performance
penalties,
we
can
revert
this
temporary
performance
and
aim
for
the
the
the
final
thing,
but
let's,
let's
analyze
a
bit
that
this
will
not
stop
us
to
do
the
the
performance
improvements
that
we
are
talking
about
when
when,
for
example,
using
the
lazy
proto
frequency
are,
we
sure
confident
that
we
will
not
have
problems,
and
we
don't
miss
any
optimization
here.
Because
of
this
I
don't
know
somebody
has
to
do
that
on
our
list.
B
Okay,
so
we,
but
we're
still
not
hundred
percent
sure
that
we
are
moving
to
lazy
proto
like
I
can
do
that
analysis
and
I
just
will
check
that
possible.
Switch
to
that
lazy
protocols
of
the
problem
right
will
give
performance
to
the
same
performance-
optimization,
okay,
yeah.
I
can
do
that.
A
That
possibly
we
will,
but
maybe
we
will
not
right
so
whatever
we
do,
it
still
needs
to
be
reasonable,
and
even
if
we
move
to
lazy
product
maybe
far
in
the
future
right,
so
it
has
to
work
properly
until
we
do
that,
so
it
shouldn't
be
a
huge
performance
regression.
I
think
it
will
not
right.
We
had
it
that
way
before
the
change
before
the
optimization
and
it
seemed
to
work
reasonably
well,
even
though
it's
not,
it
was
suboptimal.
A
A
With
lazy
proto,
the
slices
are
slices
to
pointers
to
messages,
so
essentially
it
is
exactly
is
going
to
be
exactly
the
same
semantics,
so
it
will
no
longer
be
a
problem,
but
it
doesn't
have
the
performance
penalty
because
it
uses
the
memory
pulling.
So
it
doesn't
do
allocations
for
all
of
those
elements.
Although
they
are
pointers,
they
are
not
allocated
on
every
unmarshalling.
A
A
C
Exactly
and
then,
and
then
we
can
do
the
smart,
we
can
have
still
have
a
pointer
there
or
or
if
we
have
an
inter
whatever
we
implement
there,
but
we,
I
think
we
will
get
even
more
improvements
and
still
keep
the
behavior
anyway.
Let's
analyze
that,
let's,
let's
make
that
as
another
option,
that
we
we
analysis
and
based
on
the
results
we
make
the
decision
yeah
for.
A
C
A
B
A
A
B
A
B
A
C
I,
to
be
honest,
I
don't
think
that's
a
blocker
for
one
zero.
I
mean
it
is
somehow
because
we
change
the
behavior,
but
we
we
kind
of
relax,
relax
the
behavior
in
that
way,
because
right
now
is
more
stricter,
the
image.
So
that's
a
relaxation.
So
but
let's,
let's
aim
to
finish
that
before
declaring
once.
B
A
Program
has
a
good
point.
I
would
keep
the
warning
there.
Actually,
I
would
keep
the
warning
that
says:
the
references
returned
by
get
function
can
be
invalidated
by
the
mutations
of
the
slice
so
that
whoever
is
using
it
doesn't
try
to
try
to
kind
of
explode
the
fact
that
we're
using
pointers
internally-
let's,
let's,
let's
keep
the
warning
there,
even
though
it
so
we
will
provide
stronger
guarantees
after
reverting
this
change,
so
the
mutations
will
no
longer
invalidate
the
returned
references,
but
I
wouldn't
make
it
part
of
our
contract
in
the
api.
A
C
C
A
C
Good,
that's
the
status.
Any
other
comment.
C
Oh-
and
I
have
another
item
to
add
to
that
milestone-
tyler
will
be
happy
on
me,
but
that's
that
can
be
done
later,
dimitri.
This
is
for
you,
the
the
alice's
helped
us
a
lot,
while
transitioning
from
the
model
to
p
data
and
and
a
bunch
of
other
things
that
we
did,
but
I
they
they
are
horrible
for
godok.
I
don't
know
if
you
saw
that
our
go
dog
right
now,
it's
horrible
yeah.
You
cannot.
B
C
I
don't
think
we
can
do
it
in
big
common
easily.
Yes,
everywhere
else,
we
can
do
it
and
I
think
we
should
do
it,
but
that
can
be
done
after
once,
but
but
I
would
do
that
and
I
will
file
an
issue
today
assigned
in
that
milestone.
We
can
comment
that
later,
but
I
would
like
you
to
to
do
that.
So
we
improve
the
goal.
Dogs.
B
E
I've
got
another
potential
breaking
change.
I
guess
I
noticed
last
week
that
we
removed
the
string
function
for
the
flags.
There
are
some
other
string
functions
exposed
in
p
data
right
now.
We.
C
E
E
E
B
C
E
No,
I
think
we
should
keep
it
for
names.
I
just
wanted
to
make
sure
that
the
statements
that
were
made
around
this
the
flags
one
was
because
it
wasn't
in
the
noon.
I
guess
correct.