►
From YouTube: 2022-08-31 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
There
has
not
been
an
update.
No,
I
created
a
cncf
ticket
for
it
and
have
not
gotten
a
response.
I
will
ping
the
ticket
right
now
just
to
ask
what
the
update
is
on
that.
A
C
Yeah,
because
I'm
thinking
that
we
are
going
to
have
to
add
the
contrib
repo
to
this
merge.
So
if
there's
any
bots
that
have
done
any
commits
in
in
country
but
will
have
the
same
problem
too
so.
B
B
B
B
I
guess
we
could
discuss
here
as
long
as
we're
already
on
this
topic.
I
will
throw
it
on
the
agenda.
Let's
see
commit
in
history
without
cla
authorization,
so.
B
So
one
thing
we
could
do,
and
it's
it's
painful
and
not
not.
My
first
choice
would
be
that
we
could
rewrite
the
history
of
the
existing
main
repository
to
re-author
that
commit
by
someone
and
then
every
single
person
who
has
cloned
the
repository
would
need
would
would
then
have
their
their
history
broken.
B
The
extremely
impactful,
I
guess
is
all
I'm
getting
at.
Can
anyone
think
of
any
other
solution
other
than
that.
C
B
B
Okay,
I
will
reach
out
to
amy
directly
because
she's
our
cla
contact
and
like
the
the
service
desk
ticket
is
obviously
going
nowhere,
so
I'll
reach
out
to
her
directly
on
slack.
I
think
she's
in
california,
so
her
day
should
just
be
starting.
B
I
mean
I
guess
beyond
that.
We
can't
can't
really
make
any
decisions
here.
B
B
So
I
guess,
let's
move
on
to
mark
your
first
issue
here.
Do
you
want
to
talk
about
this.
D
D
If
we
want
to
integrate
that
into
the
the
api
repo
that
is
currently
separate,
and
if
we
also
want
to
integrate
it
with
the
api
package,
that
is
there,
I
think
I'm
I'm
not
sure
if
we
kind
of
want
to
take
another
approach
with
this
to
kind
of
reduce
bundle,
size
and
yeah,
possibly
split
that
up
into
a
trace
package
and
the
metrics
package
and
have
one
I
have
the
the
current
api
package
just
re-export
these
things
yeah.
C
C
C
It
could
be
exported
out
of
the
same
npm
package,
but
not
the
the
core
one
that
you
use
for
trace
today.
So
maybe
you
have
a
api
dot
metric
and
if
you
don't
reference
metric,
then
it
should
get
three
shaking
out.
But
if
you
put
it
on
the
api
namespace,
then
it's
going
to
be
referenced
and
not
always
be
included.
C
B
Separate
from
that
api
variable
that
gets
exported
correct,
so
one
thing
that
we
could
do
is
right
now
the
trace
context
and
propagation
apis.
I
believe
that's
it
are
all
in
oh
and
the
that
logger
are
all
in
the
same
package.
B
B
C
That's
one
of
the
minification
things
that
when
I
eventually
get
to
the
sandbox
I'll
be
doing
that
like
as
well
as
dealing
with
all
these
know,
what
pieces
that
you
either
have,
or
you
don't
so
anyway,
random.
B
I
mean
that's
kind
of
a
large
body
of
work.
Is
that
something
that
we
want
to
take
on
right
now?
We
one
one
option
is
to
just
keep
it
as
it
is
right
now,
like
the
api
is
already
the
metrics
api
is
a
separate
package
already.
B
The
main
api
is
one
big
integrated
package,
but
it's
probably
not
a
big
problem
to
just
have
those
continue
to
be
two
separate
packages.
I
haven't
heard
people
complaining
that
the
metrics
api
is
not
integrated
in
the
main
api
package.
I
haven't
heard
of
people
being
confused
by
that
distinction
or
anything
like
that.
B
B
B
In
web,
we're
trying
to
just
reduce
the
bundle
size
as
much
as
we
can
so
if
we
add
metrics
into
the
api
package
the
same
way
that,
like
trace
and
context,
are
then
it's
difficult
for
tree
shakers
to
properly
minify.
The
package.
A
I
think
it's
a
quite
a
small
package
right.
Do
you
think
the
impact
is
so
big
that
we
need
to
do
all
this
effort.
C
C
I
I
think
for
now
keep
the
api
package
separate
and
then
once
we
get
the
sandbox
going
up,
maybe
we
do
play
with
that
in
option
one
and
see
how
well
it
works.
A
B
B
One
related
thing
that
I
wanted
to
bring
up
here.
We
recently
added
a
couple
of
like
convenience
methods
to
the
api
and
some
things
like
that
and
we're
taught
we
we've
at
least
had
discussions
about
adding
some
additional
context.
Api
methods,
prototyping
new
api
methods
in
the
sdk,
is
really
difficult
right
now,
because
learner
doesn't
link
anything
together
because
it's
not
one
repository,
is
it
worth
considering
moving
the
api
back
into
the
main
repository
in
order
to
help
with
that
process?.
B
C
I
guess
that's
one
of
the
main
reasons
why
the
sandbox
is
dragging
in
api
for
that
exact
purpose.
Another
option,
if,
if
that
one
gets
voted
down,
would
be
once
the
sandbox
is
running,
we
use
the
sandbox.
As
you
know,
we
create
branches
in
there
to
effectively
prototype
everything
and
when
it's
ready
we
then
push
the
back
out
to
the
main
repo,
which
is
the
whole
point
of
the
sandbox.
We
don't
actually
deliver
anything
directly
from
it.
C
That
way,
you
could
actually
code
it
all
up
in
the
sandbox
and
then
once
you're
happy
with
it.
It's
all
working.
You
then
push
it
back
to
the
main
repost,
but
that
still
means
you've
got
to
like
you
know,
push
out
the
api
and
release
it
first
before
you
can
then
push
out
to
the
js
repo,
which
is
the
main
problem.
B
B
B
A
A
Very
careful
not
to
like
publish
it
with
the
wrong
version
or
add
something
to
it.
Unintended.
B
It
sounds
like
nobody
has
any
strong
objections
to
this.
At
least
nobody
that's
on
the
call.
I
will
create
an
issue
for
this,
particularly
because
some
of
the
other
maintainers
don't
get
to
attend
to
this
meeting
regularly,
and
they
may
be
surprised
so
I'll,
create
the
issue
and
I'll
tag
them
on
it.
B
C
Yeah,
I
I
don't
think,
there's
actually
too
many
of
us
on
the
call
who
made
that
original
call
so
yeah
I'm
in
favor
of
moving
it
back
like
we
made
it.
So
we
didn't
break
anything
moving
into
ga.
So.
B
C
A
B
B
So
I
think
he
decided
not
to
open
that
pr,
because
there's
no
point
in
duplicating
this
work
in
the
contributory
bow,
which
is
already
difficult
to
maintain,
because
it's
so
large,
so
we
don't
want
to
unnecessarily
do
unnecessarily
duplicate
any
work.
B
I
think
nev
and
anyone
else
that
works
in
the
the
sandbox
or
the
web
environment
regularly
may
be
interested
in
this.
Actually
just
from
a
technical
learning
standpoint,
even
if
you
don't
use
fastly.
B
I
don't
really
have
much
else
to
say
about
that,
since
it's
kind
of
just
closing
out
a
topic
in
terms
of
the
the
metric
ga,
we
still
have
the
same
milestone
I
did
create.
We
were
putting
issues
into
this
milestone
that
weren't
really
blockers
for
the
ga.
B
So
I
created
a
another
milestone
for
topics
to
do
after
ga,
so
we
can
move
those
in
there
so
that
we
can
just
track
topics
that
are
blocking
the
ga.
B
B
Some
of
the
aggregation
temporality
changes,
while
we
wait
on
guidance
from
the
spec,
which
makes
this
pr
a
little
bit
more
straightforward
to
review,
but
I'm
probably
only
gonna
wait
another
day
or
so
before
merging
this
so
yeah
we've
been
waiting
for
reviews
for
a
while,
so
now's
the
time
to
review
it.
If
you,
if
you
have
time,
but
if
not
it
probably
will
be
merged
fairly
soon,.
A
B
Some
people
may
have
noticed
that
that
contribute
repository
has
had
some
ci
changes
here,
both
by
nev
nav.
I
assume
that
you
found
these
while
considering
moving
the
contrib
repository
into
the
sandbox
repo.
C
No,
no,
I
I
think
I
think
amir
pinged
me
on.
We
had
someone
else
doing
a
a
contrib
to
document
load.
I
think
it
was
and
that
they
were
having
issues
with
tests.
Failing
when
I
investigated
I
found
it
was
the
webpack
upgrade
that
did
it,
at
least
in
my
local
environment,
and
for
them
the
main
ci
test
still
passed
for
the
web.
C
So
really,
this
is
just
doing
that
this
dns
one,
I
think,
is
probably
almost
specific
to
my
environment
because
effectively
I
have
a
cop
machine
sitting
in
my
office
here
at
home.
So
it
has
all
the
dns
servers
from
the
corp
machine
as
well
as
all
the
dns
servers
from
my
local
environment,
which,
when
you
try
and
look
up
something
that
doesn't
exist,
takes
a
long
time.
B
Oh,
I
got
it
it's
the
test
for
something
that
doesn't
exist,
so
it
checks.
All
of
I,
okay.
I
misunderstood
what
was
going
on
here.
Yeah.
It
looks
like
it's
gotten
some
approvals,
but
the
tests
are
all
failing.
C
Yeah,
if
you
look
at
the
tests,
there
are
mongodb
so
there's
the
mongodb
owner
has
actually
got
out
two
pr's
one
to
add
themselves
as
an
owner
and
the
other
one
to
address
that
typing
issue.
I've
approved
both
of
those
already
he
put
them
out
this
morning.
A
C
So
yeah,
I
think
the
mongodb
is,
is
the
issue
that
was
causing
a
lot
of
failures,
and
then
mine
was
specific
to
not
everyone's
web
environment,
and
the
dns
is
definitely
not.
Everyone's
environment
could
almost
be
specific
to
me
that
one.
B
Okay,
so
I
guess
these
are
all
mostly
handled,
but
in
in
the
process
of
being
handled
right
now,
so
for
anyone
that
this
is
these
are
affecting.
This
will
be
hopefully
solved
by
the
end
of
the
day.
B
Martin,
I
know
that
we
every
week
we
talk
about
your
logs
api
pr
and,
and
I
asked
for
an
update
and
it's
always
kind
of
the
same
thing.
Yes,
we've
been
working
on
it.
I
see
that
you've
had
a
lot
of
changes.
There
have
not
been
a
lot
of
reviews
on
this,
though,
so
I
want
to
encourage
people.
To
I
mean
there's
been
a
lot
of
comments,
but
not
a
lot
of
approvals.
B
I
want
to
encourage
people
once
once.
All
of
your.
Your
comments
are
addressed
and
things
like
that
to
please,
if
you're
happy
with
it
or
prove
it,
because
I
know
that
it's
frustrating
having
a
pr
sit
for
a
month
and
a
half
and
not
get
merged.
A
B
C
Yeah
I
had
a
couple
of
minor
comments
this
morning.
Probably
the
only
one
that
may
need
to
be
addressed
is
the
the
naming
of
the
interface.
C
So,
instead
of
calling
it
event,
we
call
it
a
log
event
or
logs
event
or
something
like
that,
simply
because
events
already
defined
in
typescript.
So
you
could
end
up
with
people
having
issues.
A
B
Okay,
that
was
the
last
that
I
had
of
the
the
main
topics.
A
Yeah,
I
saw
the
comment
that
you
made
on
it
yesterday:
okay,.
B
Then
I
guess,
let's
triage,
I
think,
there's
two
new
issues
here,
mainly
across
origin
net
request
network
timings.
So
this
is.
B
Creating
event
data
with
a
time
of
zero,
I
believe-
and
this
user
is
asking
us
to
not
include
these
events
in
the
output
because
they're
confusing
to
back
ends.
I
think
I
saw
this
person
was
on
the
call.
Am
I
correct
about
that?
Yeah
t2,
t2.
B
Telemetry
data
that
doesn't
make
sense-
I
guess
the
question
here
is:
if
we
stop
admitting
those
events,
do
we
consider
that
to
be
a
breaking
change,
because,
most
of
the
time,
if
we
change
what
the
instrumentation
is
outputting,
we
would
consider
that
to
be
breaking,
but
I
think
because
these
events
are
meaningless,
anyways
that
I'm
okay
with
that
does
anyone
else
have
a
differing
opinion.
There.
C
I
I
guess
I
started
up
a
discussion
on
this
function
as
well,
that
I
think
we
should
deprecate
it
because
the
way
they
add
the
events
is
wrong.
It
should
be
a
single
event
with
multiple
fields,
but
that
would
definitely
be
a
breaking
change
if
we
defecated.
So
that's
a
much
larger
discussion.
C
No,
the
way
that
ad
network
event
spans
works
so
that,
though,
I
I'd
spam
network
events,
the
function
on
the
top
there
yeah
effectively,
what
it
does
is
adds
a
span
event
for
every
single
field,
for
every
property
of
the
performance
object
where
really,
what
it
should
be
doing
is
adding
a
single
event
and
that
event
contains
the
individual
properties,
but
we're
still
in
the
as
part
of
the
rom
sig.
C
We're
still
defining
well,
actually,
martin's
done
a
good
job
of
defining
what
they
are,
but
we
haven't
actually
written
that
down
to
say
this
is
exactly
what
it
is,
but
that's
a
much
larger
thing,
and
because
this
function
is
in
the
js
repo,
it
is
already
ga.
So
any
changes
is
problematic,
even
if
it's
only
used
by
experimental,
instrumentations.
C
Which,
I
think
is
the
suggestion
I
had
in
the
in
my
discussion.
Yeah.
B
That
makes
sense
to
me.
I
guess
we're
all
happy
with
priority
two
here
then
t-t-u-t-t,
I'm
sorry,
I
don't
know
your
name.
Would
you
like
to
be
assigned
this?
Are
you
going
to
work
on
this.
B
C
Maybe
a
way
to
do
this
without
breaking
anyone
who
might
be
relying
on
those
events
to
be
there
is
add
a
an
additional.
I
think
it's
a
third
parameter
to
specify
whether
to
ignore
zero
ones
and
then
have
a
propagate
from
the
instrumentations
that
are
using
it,
so
they
can
pass
true
or
false,
based
on
a
config,
just
a
thought.
B
Yeah,
I
think
I
would
probably
support
that
and
then
especially,
if
we're
just
going
to
deprecate
this
method
and
make
a
new
one,
I
don't
really
mind
adding
a
second
or
adding
a
third
parameter
to
it,
and
you
know
moving.
A
A
B
And
then
we
have
prometheus
laxair
handling
can
cause
the
application
to
crash
if
the
port
is
already
in
use.
So
this
must
be
during
startup.
D
B
D
Yeah,
that
would
probably
be
a
good
idea.
I'm
I'm
not
sure
how
how
useful
that
will
be
for
people.
I
I
think
we
would
have
to
kind
of
just
produce
an
error,
lock
and
and
hope
people
will
see
it.
Yeah.
A
D
Yeah,
that's
true,
but
maybe
we
could
kind
of
return
some
kind
of
error
when,
when
creating
the
export
or
something
I.
B
Don't
think
you
can,
because
if
you
like,
you
can't
return
anything
from
it's,
the
export
is
created
with
the
new
exporter.
If
you
have
start
server
true,
then
there's
nowhere
to.
B
So
I
will
handle
that.
I
already
assigned
myself
here,
it's
p1,
so
it
definitely
needs
to
be
done.
B
And
that
was
it,
anyone
have
anything
that
they
want
to
bring
up
before
we
move
on
jamie.
I
did
want
to
quickly
mention.
I
did
hear
that
the
cncf
reached
out
to
github
about
the
rate
limiting,
but
has
not
heard
back
yet
last
that
I
heard
so.
I
guess
we're
just
waiting
for
corporate
communication
channels
that
we
don't
really
have
a
lot
of
insight
into
at
the
moment.
A
B
The
release
manually
until
we
hear
back
from
it,
it's
not
going
to
block
releases
or
anything
like
that,
it's
just
a
little
bit
more
annoying
to
actually
cut
them.
Yeah.
A
A
Okay,
I
have
one
last
thing:
daniel's
kind
of
part
of
triage.
I
just
I.
I
tried
to
work
through
some
of
the
the
older
issues.
While
we
do
the
newer
issues
on
the
call
and
I'll
paste
it
here.
Oh,
I
wanted
to
propose
closing
this
issue,
since
it's
a
feature
request
that
I
think
belongs
in
the
spec.
B
Yeah,
it's
super
old.
It
was
created
by
somebody
that
has
not
been
around
now
for
more
than
two
years
and
yeah.
I
also
don't
think
it's
js
specific.
I'm
happy
closing
this.
That's
fine.
A
B
I
guess
we'll
give
everybody
25
minutes
back
and
I'll
talk
to
you
next
week,
thanks
for.