►
From YouTube: 2022-11-29 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
C
D
Looks
like
we
might
have
enough
people
I
could
probably,
let's
see
figure
out
how
to
share
my
screen.
We
can
get
started
here,
yeah
if
you
have
haven't
already,
and
you
want
to
add
something
to
the
agenda.
Please
do
so
we
can
jump
in
a
second
also,
if
you
haven't
added
your
name.
A
To
the
Indies
list,
please
do
so
as
well.
B
I
don't
know,
that's
me:
oh
okay,
yeah,
instead
of
my
name,
I,
don't
know
which
is
easier.
No.
D
D
Cool
so
yeah
jumping
in
then
Mike
I'll
hand
it
over
to
you
a
question
about
merging
this
BPF
to
go
files.
B
Yeah
I
just
wanted
to
Ping
and
poke
on
this
to
see,
if
there's
anything
else
that
we
need
for
it.
It's
just
basically
committing
the
generated
yeah
BPF
to
go
files
that
are
needed
for
the
project
to
you,
know,
compile
in
the
IDE
or
anything.
So
it's
been
a
week
or
two
so
just
want
to
see.
If
there's
anything
else,
I
need
for
this
or
if
this
is
good.
D
This
looks
good
to
me.
I'll
pause
just
in
case.
It's
got
two
approvers
from
two
different
people
with
different
companies.
It's
usually
a
standard
I,
don't
remember
if
we
have
the
contributing
guidelines
here,
but
that
meets
the
qualification
has
been
open
for
a
day.
So
I'll
pause
just
a
second
yeah
that
looks
good
to
me.
Okay,
cool
solve
that
one
next
up
is
adding
a
launcher
and
so
another
another
one
from
you,
Mike
yeah.
B
So
I
ran
into
this
issue,
trying
to
actually
run
the
instrumentation
and
I.
Think
I
saw
that
Dinesh
might
have
two
mentioned
it
on
slack
at.
B
Yeah
so
I
mean
Eden
can
probably
explain
it
a
bit
more,
but
my
understanding
is
that
go
programs
either
need
to
explicitly
allocate
some
memory
for
the
auto
instrumentation
to
work,
or
there
is
a
small
launcher
program
that
you
have
and
I
was
just
wondering
what
we
could
do
to
try
to
contribute
that
launcher
to
this
project.
F
Some
way
to
actually
use
the
binary
as
it
is
now,
but
they
still
have
to
to
do
a
producers
to
the
launcher
code.
F
I
have
to
do
it
today,
maybe
tomorrow,
let's
start
something:
let's
just
you
know
make
some
some
directory
with
with
the
launcher
code
and
the
think
of
a
better
way
to
package
it
later
or
something
like
that.
Basically,
I
can
elaborate
a
little
bit
of
what
this
thing
is
doing.
So,
basically,
because
the,
why
is
the
instrumentation
works?
F
We
actually
generate
the
price
ID
and
spend
ideas
if
it's
not
something
that
we
got
from
headers
and
the
incoming
requests,
that's
something
that
we
actually
like
in
the
start
of
the
chain.
So
in
order
for
the
for
the
go
application
to
be
able
to
use
those
values
and
insert
it
to
the
to
the
relevant
headers
or
whatever
I,
don't
know
connection.
F
That
is
that
it's
making
and
we
actually
need
to
to
put
it
inside
of
the
of
in
an
area
where
this,
the
global
application
can
read
it
so
like
the
way
that
I
thought
about
it.
F
For
now
is
that
so
it's
basically
two
ways
we
can
achieve
it
either
and
at
this
area
of
memory,
is
of
Heap
and
is
not
affected
by
the
garbage
collector,
and
any
of
that
is
like
just
a
blob
bytes
that
the
instrumentation
at
the
the
irrelevant
press
against
that
lady
and
basically
there's
two
ways
you
can
do
it.
You
can
either
manually
allocate
this
area
via
code
call,
for
example,
the
the
M
map.
This
call,
or
you
can
I
wrote
a
little
program
called
the
launcher
which
basically
do
it
for
you.
F
It
allocates
this
area
of
memory
and
then
starts
the
process,
so
yeah
I,
I'm,
hoping
to
finish
opening
this
PR
today
or
tomorrow,
Max
and
yeah.
It's
probably
made
a
bit
of
more
explanation
than
that,
but,
as
I
said,
there
is
a
walk
around
that
I
posted
in
snack.
Where
you
come
there
just
get
the
launcher
apart
from
now
and
try
and
test
it.
F
E
F
Think
yeah
yeah
sure
if
you
want
to
send
me
this,
like
the
simple
applications
which
you're
investing
it
I
can
also
look
on
it,
but
yeah
I
hope
to
finish
this
broadcast.
D
So
Dinesh,
can
you
make
sure
to
just
comment
in
this
issue?
That's
already
open
kind
of
like
your
experience
in
slack
that
you
posted,
but
also
like
the
the
attempted,
workaround
I,
know,
Eden's
working
on
a
pull
request.
I
just
want
to
make
sure
it's
documented
for,
like
future
cases
that
it's
kind
of
hard
when
things
are
in
slack
ends
in
the
GitHub
issues,
so
just
consolidate
into
one
place.
I
think.
D
Yeah,
just
for
the
off
chance
that
maybe
these
are
two
separate
issues
also
like
I,
think
it's
good
to
make
sure
we
have
them
in
the
in
the
same
conversation
then,
and
then
Eden
is
there
anything
you
need
from
anybody
else
on
the
call
to
help
unblock
that
PR
or
is
it
just
time
on
your
side?
No.
F
D
Okay,
I
think
that's
covers
that
agent
item
next
step.
Is
the
ownership
model
follow-on?
Let
me
share
my
screen
again.
A
C
Yeah
yeah,
so
so
two
weeks
ago
we
had
a
discussion
about
that
and
we
know
that
this.
It
takes
a
lot
of
time
to
to
Define
this
ownership
model.
So
the
process
it
seems,
is
slow
and
there
was
decision
to
to
join
the
go
meeting.
The
the
general
one
so
I
joined
that
meeting,
but
there
were
only
three
people
and
there
was
decision
that
we
cannot
move
it
forward
without
Tyler
and
Aaron.
So
we
are
still
blocked
and
what
can
do
about
it
and.
C
D
So
yes,
let's,
let's
dive
into
this
one,
then
a
I
think
this
is
one
where
we
need
to
get
community
engagement,
I
think
on
this,
and
so
we
need
to
essentially
build
a
list
and
see
if
we
have
volunteers
that
want
to
take
ownership
of
particular
instrumentation
packages
and
other
detectors
and
propagators
and
Samplers
and
things
in
here
as
as
an
ownership,
so
I
think
if
that's
something
that
needs
to
just
be
done.
A
D
I
guess
we
want
to
get
buy-in
for
people
and
and
to
see
who
wants
to
own
it.
D
I
think
that
this
is
something
that
is
going
to
be
something
we
need
a
time
limit
on.
So
I
would
probably
recommend
something
like
a
two-week
cycle
that
way
it
can
be
posted
here
as
well
as
in
the
gosig
twice.
It
really
is
unfortunate.
It's
happening
right
at
the
end
of
the
year
when
there's
very
low
attendance,
but
I
think
the
next
step
will
kind
of
help
it's
a
reversible
step.
D
So
that
makes
sense,
but
essentially
what
you
want
to
do
is
we
want
to
get
buy-in
as
to
who
can
own
these
things?
I
definitely
am
I'm
open
to
owning
a
few
things
in
this
repository,
but
I
think
at
the
end
of
the
two-week
cycle
for
things
that
are.
A
D
This
inventory,
provided
potential
owners
also
is
like.
We
also
need
a
maintainer
for
the
project
to
have
an
ownership
as
well.
So
that's
a
good
question.
Can
a
maintainer
also
be
an
owner
yeah?
Okay,.
D
Yeah,
okay,
cool
but
yeah.
There
definitely
needs
to
be
two.
That's
something
we
talked
about
in
the
the
go
seg,
okay,
so
from
there,
then
we
would
deprecate
all
the
modules
that
don't
have
an
owner
and
for
the
modules
that.
A
Do
have
owners
up.
D
I,
don't
know
if
we
like
permission
wise,
like
it's
just
going
to
require
those
code
owners
to
review
those
PRS.
If
there's
any
changes
to
those
files
in
that
like
a
directory,
we
don't
I,
don't
know
if
there's
any
like
permissions,
we
can
initially
give
and
I.
Don't
think
that
we
need
to
solve
that
problem
in
this
in
this
issue,
but
I
think
we
could
probably
do
better
going
forward.
D
So
the
the
downside
is
this,
for
anything
that
doesn't
have
an
owner
will
get
deprecated
I,
think
that
might
actually
be
a
good
thing
one,
because
it's
reversible,
you
can
take
a
project,
that's
deprecated
and
undeprecate
it
that's
not
hard,
that's
not
impossible
and
then
it'll
also
for
any
user
in
the
community
that
finds
the
package
that
they're
using
it
becomes
deprecated
may
make
them
reach
out
and
ask
if
you
know
why
that
happens.
So
we
may
find
a
potential
owner
faster.
D
D
C
So
without
this,
these
things
that
we
have
to
resolve,
we
cannot
open
the
pr
right,
because
my
goal
would
be
to
open
a
PR
and
the
the
one
thing
that
I
don't
know
where
I
should
put
this
tool.
D
Yeah
I,
don't
either
I
do
think.
That's
a
good
question.
There's
this
instrumentation
I
think
it
would
fit
in
this
directory.
Yes,.
D
However,
It
also
says
this
contains
transportation
for
third-party
go
packages
and
some
packages
from
the
standard
Library,
so
maybe
also
we
could
create
another.
D
Think
Instagram
would
be
a
great
one.
It's
like
straight
out
of
the
90s,
but
yeah.
A
D
It's
more
scripts
and
stuff
for
the
rest
of
the
requester
yeah
I
mean
we
have
I.
Think
it's
building
something
on
the
top
level
similar
to
like
the
Z
pages,
makes
sense,
because
it
is
kind
of
like
a
standalone
thing.
It
isn't
really
for
a
third-party
Library.
It
helps
you
auto-generate
I.
Do.
D
Which
is
fine,
that's
how
this
is
all
structured,
so
these
are
all
themselves
modules.
So
as
long
as
there's
no
import
from
these
modules
into
this
Auto
generation
code,
there's
will
be
an
import
cycle
so
having
whatever
this
package,
this
module
or
package
created
here
won't
won't
cause
any
problem.
There
I
mean
we
you'll
notice
in
a
lot
of
the
go
mod
files.
D
There's
a
lot
of
replaces
to
to
do
exactly
that,
we'll
see
if
there's
one
here
actually
yeah,
so
there
isn't,
but
normally
we'll
just
put
like
a
local
replace
for
things
that
get
changed
prior
to
like
a
major
release.
So
that's
something
we've
solved
before
in
these
kind
of
situations
to
having
multiple.
D
That
should
be
a
problem,
but
that
being
said,
I
think
having
an
ownership
model.
The
the
end
goal
is
to
eventually
have
go
mods
with
a
cone
rotors
file
to
identify,
like
the
ownership
of
that
file.
I,
don't
see
why
we
couldn't
just
open
the
pr
with
some
sort
of
ownership
here.
I
think
I
mean
I'm
guessing.
D
If
you
want
to
sponsor
this,
which
I'm
guessing
is
the
case,
you
would
be
one
of
the
the
owners
and
then
I
I'm
happy
to
sponsor
it,
as
well
as
the
maintainer
of
the
repository
as
well
and
saying
that,
like
those
would
be
the
two
owners
for
that
new
directory,
so
I
think
we
could
probably
open
a
PR
for
this.
While
we
work
on
this
part
in
parallel,
if
that
makes
sense,.
D
Okay,
Aaron:
how
about
you
does
that
make
sense:
okay,
thumbs
up
yeah.
Okay,
then
I
think
this
is
a
good
way
to
move
this
forward.
I
think
that
this
also
kind
of
gives
a
good
the
the
thing
I
I,
don't
want
to
happen
is
that
we
have
one
directory
that
has
an
owner
and
all
the
other
ones.
Don't
so
I
think
that
we
need
to
make
sure
that
we
prioritize
this,
but
that's
more
of
a
ghostly
problem,
not
necessarily
A
co-instrumentation
sake
problem,
so
I
think
that
makes
sense
to
me.
D
Okay,
then
yeah,
okay,
I'm
glad
we
got
some
way
to
go
forward
on
that.
I
think
that
I
I
don't
have.
Let's
see,
do
we
have
an
owner
to
this?
D
G
I'll
start
by
getting
us
a
list
of
high
level
modules:
yeah
I
can
get
that
out
and
then
we
can
start
advertising.
We
need
owners
for
these
or
deprecate
yeah.
D
That
sounds
per
yeah.
You
can
do
that.
Aaron
that'd
be
great,
especially
if
we
could
get
that
done
by
Thursday.
Hopefully,
then
we
could
try
to
communicate
that
in
the
go
Sig
but
yeah.
Just
an
inventory
would
be
a
great
first
step
right
because
then
you
can
have
like
a
people
can
come
into
this
issue
and
say,
like
I,
want
to
take
X,
Y
and
Z,
or
something
like
that.
D
C
D
Yeah,
that's
good
I,
don't
I
mean
I
like
I
I,
literally
just
came
up
with
like
instrument
which
kind
of
comes
from
yeah
like
this.
This
kind
of
is
I
I.
We
made
this
name
up
for
some
semantic
conventions
and
it
turned
out
I,
don't
know,
I
really
like
it
after
a
year
or
two
of
having
it
like.
D
The
package
structure
is
a
whole
different
thing,
but
like
the
I
really
like
the
name
just
like,
because
no
one's
ever
gonna
name,
a
variable,
simcov
and
I-
think
Instagram
kind
of
fits
in
that
category.
It's
still
clear
what
it's
like.
If
you
understand
like
the
component
parts
and
like
the
English,
you
know
bundling
of
the
two
things.
D
It's
somewhat
short.
That
being
said,
I
bet,
there's
maybe
better
names
so
like
I
I
have
no
problem
like.
If
you
want
to
open
it
and
there
could
be
a
little
bike
shed
in
there
saying,
like
you
know,
do
we
want
to
rename
this
but
like
I
would
put
it
in
another
directory
at
this
top
level,
and
then
the
pr
can
have
a
discussion
around
like
renaming
their.
A
D
Also
been
speaking,
a
lot
of
other
other
people
have
other
ideas
like
speak
up,
yeah
I
mean
I
I
spent
all
of
30
seconds.
Thinking
of
that
name,
so
like
there's,
probably
improvements
to
be
had
foreign,
okay,
but
yeah
I
would
just
start
there.
That
sounds
like
a
great
place,
and
then
we
couldn't
talk
about
like
really
psychospheric
versioning
and
that
kind
of
stuff,
but
the
first
goal
is
to
get
it
in
there.
D
Okay,
cool
there's,
nothing
else
on
the
agenda,
so
I'll
pause
here,
stop
sharing,
screen
and
open
it
up
to
the
group.
If
somebody
wants
to
talk
about
something,
that's
not
on
the
agenda.
D
Well,
cool
I
do
notice,
Dinesh
and
Mike
you.
We
were
both
starting
to
use
some
of
the
evpf
automation,
rotation,
I,
know
Dinesh,
you
didn't
get
it
working,
it
sounds
like,
but
I
I
love.
Maybe
in
like
the
next
meeting,
we
could
kind
of
talk
about
some
use
cases
I
think
as
well
like
those
are
have
been
really
fruitful
in
the
past,
so
yeah
I'm
looking
forward
to
maybe
discussing
that
a
little
bit
more
too
so
yeah
just
kind.
E
D
Yeah
I
agree:
we
do
something
similar
well,
almost
all
repos
do
something
similar
to
that.
So
maybe
Dinesh,
if
you
wouldn't
mind,
creating
an
issue
in
the
repo
for
that
I,
think
it's
just
to
track
something
we
want
to
work
on
in
the
long
term,
once
we
have
something
yeah.
E
I
think
we
discussed
few
other
items
last
segmenting
as
well,
because
should
create
issues
for
all
of
them.
Actually,
we'll
do
that.
D
That
doesn't
sound
great
okay,
I'll
I'll
go
ahead
for
recording
I,
think,
okay,.
D
Cool
okay
last
chance
for
anybody
bring
up
some
topics.
D
Well,
cool,
then,
let's
end
it
here
we
can
all
talk
asynchronously
and
let's
pick
me
up
some
new
action
items
to
move
forward,
see
you
all
in
two
weeks
same
place:
bye.