►
From YouTube: 2022-06-22 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
C
Okay,
I
guess
we
can
get
started.
A
First
thing
I
wanted
to
bring
up
was
the
the
metrics
ga
most
of
the
people
here,
probably
seen
the
milestone.
I
brought
it
up
a
few
times,
but
I
wanted
to
draw
everybody's
attention
to
these
four
pr's
that
are
all
open
and
waiting
for
reviews
and
are
required
for
the
metrics
ga
so
right
now
these
are
the
most
important
prs
to
review.
A
I
would
also
draw
your
attention
to
the
events
and
logs
api
otep
martin
brought
this
up
in
a
couple
of
different
meetings,
but
they're
looking
for
reviews
from
as
many
different
cigs
as
possible,
and
if
you
think
this
is
interesting
for
you,
please
go
take
a
look
at
it.
A
Okay,
the
first,
I
guess,
controversial,
possibly
topic
of
the
day,
is
dropping
support
for
old
node
runtimes.
A
For
anybody
that
is
on
old,
node
versions-
please
be
aware
of
this,
as
it
is
not
necessarily
going
to
stop
working
right
away,
but
we
are
no
longer
testing
for
old
node
versions.
So
please
take
a
look
at
that.
I
review
it.
If
you
have
concerns
on
there,
please
make
comment,
but
if
people
don't
raise
concerns
that
will
be
merged
fairly
soon,.
A
Nope:
okay:
the
next
item
in
the
list
is
something
we've
talked
about
a
couple
of
times,
but
it's
always
been
sort
of
a
prototype
or
a
draft.
A
Now
it
is
ready
to
be
reviewed
so
allowing
resources
to
be
created
while
having
some
attributes
resolve
asynchronously
and
some
synchronous
attributes
in
order
to
allow
the
node
sdk
package
to
initialize
in
a
synchronous
manner.
Aaron
abbott
has
been
doing
the
work
on
this
and
we
appreciate
it.
Aaron
is
there
anything
you
want
to
say
about
this
pr
before
I
move
on.
E
Not
so
much
I've
been
looking
at
the
review
comments
and
I
think
I
agree
with
you
on
the
breaking
change
thing.
If
anybody
has
like
suggestions
on
how
to
do
this
in
a
way,
that's
not
not
a
breaking
change.
I'd
I'd
definitely
be
open.
There's
like
a
few
things.
E
I
was
thinking,
but
without
adding
too
much
sort
of
like
tech
debt,
it
might
be
difficult,
but
of
course
you
could
add
like
an
entirely
new
code
path
for
for
sort
of
like
the
new
way
of
doing
things,
but
I
don't
think
I
don't
think
that's
worth
worth
doing
so.
A
Yeah
I
mean
there's
a
there's,
a
couple
of
ways
that
we
could
potentially
do
it.
A
The
most
obvious
would
be
to
just
rev
the
version
of
the
resource
package
to
version
two,
I
don't
see
any
of
the
other
maintainers
on
the
call
today
so
obviously
can't
commit
to
something
like
that
without
input
from
them
and
probably
would
want
to
talk
to
like
ted,
to
make
sure
that
that's
something
that
we're
allowed
to
do,
I
think
it
is
since
it's
not
really
like
it's
not
breaking
for
like
the
sdk
components.
A
You
know.
I
know
that
they're
trying
to
keep
a
major
version
revs
to
a
minimum,
but
I
think
just
for
one
sub
package,
it
might
be
okay.
A
Another
option
would
be
to
instead
of
having
the
detect
resource
method,
return
a
new
type.
I
don't
see
it
instead
of
having
it
change
its
return
type.
It's.
A
Yeah
so,
instead
of
adding
a
resource
here,
we
could
have
like
a
detect
synchronous,
optional
function
in
the
interface,
which,
I
guess
is
what
you
were
referring
to
when
you
set
an
entirely
separate
protocol
right.
E
Yeah
we
could
do
that
and
make
it
optional
and
prefer
the
new
variant.
I
also
didn't
update
any
of
the
existing
detectors
to
to
do
this
in
this
pr
because,
like
you
said
it
would
be
a
breaking
change.
E
So
I
I
don't
know
I'm
happy
to
add,
like
a
second
a
second
method
and
add
some
sort
of
like
dynamic
check.
If,
if
the
new
one
is
available,
use
that
otherwise
use
the
old
one.
A
Yeah
yeah
personally,
I
think
making
these
detectors
asynchronous
in
the
first
place
was
a
mistake,
but
it's
one
we
have
to
live
with
now,
yeah.
I
think
if
you
go
back
and
look
at
the
blames,
you'll
find
out
that
it
was
my
mistake.
So.
E
Yeah
I
mean
it
was
pretty
tricky
to
to
sort
of
accomplish
this,
because
it
did
make
a
lot
of
the
testing
like
a
lot
of
the
tests,
rely
on
the
behavior,
where
the
they,
basically,
you
know,
expect
the
exporter
to
be
immediately
called
and
adding
like
a
promise
in
there
made
it
difficult.
So
I
understand
why
it
was
done.
A
Another
way
that
this
is
breaking
is
that
it
requires
anybody
who
wrote
a
spam.
Processor
now
has
to
await
these
async
resources
before
calling
the
exporter
right.
If
you
don't,
then
you'll
miss
out
on
them.
E
Yeah
I
mean
so
I
did
want
to
discuss
that
like
if
they
don't
do
this
for
the
first
few
export
cycles
or
or
potentially
none
of
them,
there's
basically
going
to
be
some
missing
attributes
from
the
asynchronous
parts.
E
Once
the
sdk
has
been
running
for
long
enough
that
all
the
resources
have
finished,
all
the
resource
detectors
have
finished.
It
shouldn't
shouldn't,
be
a
problem
like
it
shouldn't
break
any
of
the
existing
exporters,
but
it
will
look
like
the
resource
changed,
which
we
also
discussed
as
potentially
a
breaking
change.
Yeah
like
there's,
also
no
reason
that
this
couldn't
be
passed
through
and
then
the
expo
could
be
the
exporter's
responsibility
to
to
await
this.
But
there's
obviously
like
a
lot
more
exporters
than
there
are
resource
detectors
or
sorry.
A
A
I
know
that
we
have
a
couple
of
resource
detectors
that
do
asynchronous
work,
but
I
believe,
if
you
look
at
the
semantic
conventions
for
resources,
the
only
ones
that
have
been
specified
are
ones
that
can
be
detected
synchronously
specifically
because
of
these
types
of
problems.
A
E
Yeah,
I
was
thinking
if,
if
it
was
revved,
then
sort
of
the
issue
is,
I
mean
correct
me
if
I'm
wrong,
but
I
believe
most
of
the
packages
that
are
using
resource
are
expecting
it
to
be
the
same
version
so
like
when
you
know
you
have
the
sdk
package
and
maybe
like
the
like,
an
exporter
package.
E
If
they're
expecting
different
versions
of
a
resource,
then
then
typescript
is
probably
going
to
complain.
So
in
terms
of
like
supporting
older
sdk
versions,
which
are
still
major
version
one.
I
think
we
would
have
an
issue
there
like
it.
Wouldn't
it
wouldn't
be
possible
to
use
the
older
sdk
versions
with
the
newer
resource
package
which,
which
I
guess
is
okay.
I
don't
know
what
you
think.
A
Yeah,
I
guess
so.
The
resource
detector
itself
is
the
only
thing
that's
currently
asynchronous.
The
resource
object
is
not
so
I
guess.
If
I
was
going
to
do
it,
I
would
probably
not
deprecate
the
existing
resource
detector
immediately,
but
would
just
add
a
new
synchronous,
resource
detector
or
something
along
those
lines,
and
then
I
would
make
it
so.
A
The
node
sdk
uses
that
instead
and
then
anyone
that
wants
to
use
an
asynchronous
resource
detector,
I
would
be
kind
of
on
their
own
in
terms
of
awaiting
that,
before
starting
the
sdk
or
potentially,
we
could
have
some
some
api
to
swap
out
the
resource
once
once
that
async
work
is
done.
You
put
that
more
on
the
user.
A
A
Yeah
makes
sense,
so
it
would
be
more
about
introducing
a
new
type
of
resource
detector
and
then
the
the
aws
or
the
not
bws.
The
node
sdk
package
would
depend
on
that
asynchronous
resource
detect
around
that
synchronous
resource
detector.
It
would
be
breaking
for
that
package,
but
that's
an
experimental
package
right
now.
Anyways.
A
I
can
write
up
a
summary
of
that
after
the
meeting
here
since
the
other
maintainers
aren't
here
and
I'm
sure
they'd
be
interested
in
those
in
those
options,
and
we
definitely
want
to
do
an
audit
of
the
existing
resource
detectors
and
how
many
of
them
are
actually
doing
asynchronous
work.
And
what
specifications
says
about
the
semantic
invention,
attributes
that
they're
using.
E
Okay,
yeah.
That
sounds
good
I'll,
probably
reply
to
comments
here,
but
I'm
not
gonna
make
any
code
changes
until
we
until
maybe
the
maintainers
make
a
decision
on
this
yeah.
That
makes
sense.
D
Was
just
accepting
the
blame
for
for
having
an
async,
detect
method?
I
think
the
first
resource
detector
that
we
had
was
for
gcp
and
that's
one
of
the
ones
that
has
to
call
out
to
a
to
an
end
point
and
get
back
some
json
to
to
populate
his
fields.
So
that's.
A
A
Gcp
and
aws
lambda,
as
I
remember
correctly,
we
could
not
get
the
whatever
it
is.
The
arn
the
the
function
id
is
not
available
at
the
startup
of
the
lambda.
It
comes
in
on
the
first
request
right,
but
I
think
that's
actually
been
changed
to
be
a
span
attribute
now
in
the
specification
I
don't
know
how
any
of
the
gcp
stuff
has
been
handled,
though
I
know
we
certainly
need
an
option
for
asynchronous,
but
I
think
the
general
the
happy
path
for
most
users
is
synchronous
resources.
A
I
don't
know
if
the
blame
is
on
any
one
person
here,
but
it's
it
certainly
has
caused
a
lot
of
pain
over
the
last
year,
or
so
it
would
be
nice
to
resolve
it.
D
Yeah,
I
definitely
recognize
the
pain
like
it.
I
feel,
like
I
don't
know,
is
ec2
not
in
the
same
boat.
It
just
seems
like
these
cloud
provider
cloud
provider
metadata
often
comes
from
hitting
like
a
a
local
endpoint
and
there's
like
a
descriptor
of
what
you're
running
on,
and
I'm
just
wondering
like.
D
If,
even
if
we
kind
of
change
this
on
our
side,
if
that
spares
users
from
still
having
to
somehow
figure
out
how
to
await
a
a
resource
that
they're
running
in
a
in
a
cloud
which
they
probably
are.
A
A
A
There
are
if
we
decided
to
go
with
synchronous
resource
detectors.
There
are
tricks
you
can
do
to
make
asynchronous
calls
synchronously,
but
and
by
tricks
I
mean
definitely
tricks
like
there.
You
can
call
a
sub
process
synchronously,
so
you
could
run
the
asynchronous
work
in
a
sub
process
and
call
that
synchronously,
but
that's
obviously
extremely
hacky.
A
It
has
a
non-zero
resource
footprint
and
all
sorts
of
things
like
that.
But
if
these
endpoints
are
as
fast
as
aws
and
google
claim
they
are,
then
maybe
it's
okay
and
I
know,
there's
also
been
somebody
just
posted
a
notes
app
in,
but
there's
been
efforts
to
be
able
to
have
places
where
you
can
have
attributes
where
it's
not
the
resource.
It's
not
guaranteed
to
not
change.
A
A
There
are
already
scopes
specific
attributes
and-
and
things
like
that,
so
maybe
yeah
I
have
to
look
into
the
spec,
I'm
not
sure
of
these
asynchronous
properties
or
asynchronous
metadata
properties.
How
many
of
them
are
actually
specified
as
resource
semantic
inventions?
I'm
I'm
not
as
familiar
with
that
as
I
should
be
yeah.
F
Sorry
I
I
pasted
that
in
while
I
was
still
the
other
meeting
ran
over
so
effective.
That's
ted's
proposal
for
effectively
session
ids
from
our
perspective
for
the
rum
is
where
this
will
live.
So
this
is
the
concept
of
bringing
the
concept
of
permanent
versus
ephemeral,
changeable
resources.
F
So
that's
why
I
pasted
it
in
there
it
seemed
to
be
related,
and
I
agree,
there's
probably
some
asynchronous
ones
would
just
still
be
permanent,
so
once
they're
set
they're
set
and
that's
it
so,
but
I
thought
that
was
probably
related,
so
that
will
just
bring
everyone's
attention.
A
E
From
the
gcp
perspective,
with
the
metadata
server,
I'm
gonna
say
the
line
that
you
said
it
should
be
pretty
fast.
It's
like
a
local
thing.
I
was
gonna
call
out
for
the
kubernetes
there's
like
a
spec
for
the
kubernetes
resource
detector
or
there's
an
otep,
I'm
not
sure
if
it
was
merged
and
it
basically
relied
on
passing
the
resource
attributes
that
would
need
to
be
like
gotten
from
the
kubernetes
api
server
through
that
resource
attributes.
Environment
variable.
E
So
it
ends
up
sort
of
being
part
of
the
config
and
passes
an
environment
variable,
so
that
was
sort
of
like
the
other
option.
If
we
couldn't
figure
out
how
to
make
this
like
late
arriving,
async
promise
thing
work
is
potentially
trying
to
inject
the
the
things
into
the
process
into
the
node
process
and
again
in,
like
other
languages,
it's
possible
to
block.
So
it's
not
such
a
big
deal.
Assuming
that
the
metadata
server
is
quick.
E
A
Yeah,
I
I
don't
have
a
lot
else
to
say
about
this
without
the
other
maintainers
here
I
I
will
create
an
issue
or
there
might
already
be
one
I'll
summarize
some
of
the
discussion
and
some
of
the
options
that
we
have
here.
A
If,
if
we're
going
to
consider
revving
the
version
of
of
the
resource
or
introducing
a
synchronous
resource
detector,
we
need
to
consider
what
the
options
are
for
asynchronous
and
how
how
likely
or
unlikely
you
know
what
percentage
of
users
needs
an
asynchronous
resource,
because
if
it's
30,
then
we
probably
don't
want
to
make
that
feel
like
a
second
class
citizen.
A
But
if
it's
two
percent
or
one
percent
or
less
then
maybe
it's
okay
to
say.
If
you
have
asynchronous
work,
you
need
to
figure
out
how
to
do
it
before
launching
the
sdk.
F
One
thing
that
ted
zotep,
like
I
haven't,
read
through
it
yet
either,
but
he
gave
a
summary
in
the
previous
meeting
is
rather
than
setting
the
attributes
up
front
is
a
case
that
there
would
be
a
resource
provider.
That's
actually
passed
around,
so
in
theory
you
could
have
an
asynchronous
resource
provider
that
can
block
you
know
actually
doing
the
export
until
the
finish
of
resulting
stuff.
So
that's
potentially
another
way
that
this
could
be
achieved.
A
Okay-
I
don't
have
much
else
to
say
about
this.
If
anyone
else
does
now's
the
time.
A
Okay
mark
would
you
like
to
talk
about
the
fetch
instrumentation.
B
Yeah,
so
this
is
just
a
very
small
question
and
I
will
keep
it
short.
So
basically,
there
was
this
pr
and
I
figured
out
that
in
the
fetch
instrumentation
we
don't
create
multiple
spans
if
there's
redirects
for
each
request-
and
I
was
just
wondering
if
anybody
who
knows
more
about
this
about
fetch
than
I
do
knows
if
it
is
even
realistic-
to
implement
creating
multiple
spans
for
the
redirects
when
follow
is
on
and
it's
not
being
done
manually
yeah.
This
is
just
so
that
I
know
before
I
create
an
issue.
B
A
I
mean
I
think
we
should
probably
create
an
issue
either
way.
Even
if
it
ends
up
not
being
possible,
then
we
have
somewhere
to
point
people
in
the
future.
If
they
ask
about
it
all
right,
so
I
I
would
probably
create
an
issue
either
way.
A
A
Yeah,
that's
sort
of
what
I
expected
so
I
mean
I
guess
the
spec
says
you
have
to.
But
if
you
can't,
then
I
think
that's
a
pretty.
B
Good
reason
now
yeah,
I
was
just
looking
for
a
reason.
So
thank
you
for
the
answer.
Then
I
will
just
write
that
down
and
then
we
have
something
to
point
people
to
if
it
ever
comes
up
again.
B
D
Yeah,
I
was
just
gonna,
ask
a
few
questions
while
we're
all
here,
but
it
looks
like
there's
been
a
lot
of
work
on
this
this
week
and
even
today,
but
yeah
it
appears
with
some
of
our
instrumentation
if
the
exported
type
kind
of
uses
an
underlying
an
underlying
type
as
like
a
generic,
it
ends
up
being
a
an
issue
where
your
application
needs
to
have
those
types,
at
least
like
as
a
dev
dependency,
or
something
like
that.
D
I
think
that's
what's
actually
happening,
and
if
you
get
rid
of
this
generic
replace
within
any
things
seem
to
work
and
that's
what
this
pr
is
is
doing
it.
Let's
get
held
up
for
a
little
bit,
but
then
I
gotta
be
ignited,
and
now
it's
held
up
slightly
again
with
aws
yeah.
I
was
just
going
to
see
if
my
understanding
of
this
is
this
is
correct,
a
and
then
b
it
sounds
like,
or
it
looks
like
this
pr
is
kind
of
like
fixing
the
immediate
problem,
but
it
seems
like
there
might
be.
D
The
long-term
fix
might
be
to
like
remove
that
generic
from
like
the
instrumentation
base.
It
should
always
kind
of
just
be
an
any,
and
you
would
avoid
this
problem.
A
Yeah,
I
think,
if
that's
a
reasonable
understanding
for
those
that
that
are
not
familiar
here,
I
can
give
a
little
bit
more
context.
It
used
to
be
that
typescript
didn't
have
as
much.
A
Type
checking
of
your
dependencies,
which
was
bad
in
some
ways,
but
for
us
it
was
good
because
it
meant
we
didn't
have
to
ship
those
dependencies.
We
would
use
the
typings
in
our
code
and
if
we
compiled,
then
we
could
ship
it
and
our
our
end
users
didn't
have
those
type
checks
happen
when
typescript
started
getting
as
typescript
got
better
support
for
library,
type,
checking
or
dependency
type
checking.
A
We
had
to
then
include
the
types
as
dependencies
to
our
packages
at
that
time,
when
that
was
happening,
most
packages
had
their
types
declared
in
definitely.
D
A
So
you
had
like
the
app
types
dependency,
and
that
was
fine,
because
it
was
types
only
it
would
be
compiled
away.
Nobody
really
cared
that
much
that
it
was
a
dependency
and
then
recently
and
within
the
last
I
don't
know,
six
months
to
a
year,
I've
seen
a
huge
acceleration
in
this.
A
lot
of
packages
are
vendoring
their
own
types,
so
they're,
either,
whether
they're
written
in
typescript
or
whether
they're
writing
their
own
types
and
just
shipping
them
directly
in
the
package.
A
They
are
including
the
types
in
their
package.
So
then
the
the
definitely
type
definitions
just
become
a
stub,
but
they
tell
you
to
install.
You
know
that
types
come
from
directly
from
the
package
and
all
that
and
from
a
user.
A
That's
great,
but
for
us
it
means.
If
we
want
to
then
ship
those
types
we
have
to
have
a
dependency
on
the
module
itself
so
like
for
graphql,
for
example,
instead
of
depending
on
the
graphql
types,
we
now
depend
on
and
ship
graphql
within
the
graphql
instrumentation,
which
is
something
that
we
don't
want
to
do
and
the
more
that
this
happens,
the
more
that
we're
motivated,
essentially
to
not
depend
on
any
types
at
all
in
the
instrumentations.
A
D
A
Types
within
the
instrumentation
so
to
ship
just
the
types
which
is,
I
believe,
what
this
pr
is
doing.
At
least
it
was
split
off
of
this
pr
and
that's
what
it
was
doing
here.
So
I
assume
it's
the
same
here,
but
then
we
run
into
potentially
legal
questions.
Shipping
code,
owned
by
aws
as
part
of
our
modules,
is
something
that
I
don't
want
to
do
without
very
tight
checks
and
controls
and
approvals
from
cncf
legal
teams,
and
things
like
that.
So
those
are
the
two
options
we
have.
A
There
is
that's
a
summary
of
the
the
current
state
of
what
we're
doing
matt.
Do
you
have
any
particular
question,
or
s
or
solution
around
that,
or
are
you
just
trying
to
make
sure
that
there's
attention
is
being
drawn
to
this
or
what
was
your?
What's
your
goal
here.
D
Yeah,
I
was
mainly
trying
to
figure
out
exactly
what's
happening,
so
your
your
description
has
answered
all
of
my
questions
and,
and
then
some
so
I
think
my
I
think
I
only
understood
about
50
of
the
problem.
Actually
so
yeah
it
sounds
like
this
problem
is
recognized.
Wheels
are
in
motion
to
try
to
fix
it,
but
for
now
it's
like
we
kind
of
end
up
depending
on
the
instrumented
library,
in
some
cases,
which
is
unfortunate
and
and
not
ideal
in
the
long
run.
A
Yeah,
it's
not
great.
I
think
this
is
something
that's
been
building
over
a
long
period
of
time
and
unfortunately
I
would
say
it
caught
us
unaware,
but
we've
been
aware
of
it
the
whole
time.
You
know
it's
like.
If
you
build
your
house
on
a
on
a
beach
that's
eroding
every
year
it
gets
closer
and
you're
aware
of
that.
But
then
one
year
it's
too
close
and
it's
too
late.
So
this
is
something
that
we
definitely
have
to
fix
and
we've
been
motivated
to
fix
it
recently.
A
If
anybody
else
has
additional
questions
or
contacts,
they
want
to
add
here.
That
would
be
welcome.
F
Maybe
a
stupid
question,
but
looking
at
the
the
pr,
why
is
the
base
modules
using
typo
rather
than
an
interface
assuming
like
the
mysql
types,
is
not
an
interface?
We
just
want
something
that
looks
like
that,
which
is
how
the
type
checking
works
as
long
as
it
can
be
coerced
because
it
implements
the
same
fields
versus
type
of
means.
It's
got
to
be
one
of
it's
got
to
have
that
in
its
base
class,
and
then
I
guess
in
the
underlying
definition.
We
could
still
have
type
and
say
that
defaults
to
any.
F
Yeah,
as
opposed
to
just
a
cassandra
driver,
it's
probably
because
of
the
way
cassandra
drive
is
defined.
I'm
gonna
guess.
A
Yeah,
that's
that's
mostly
the
answer
like
that's
that
there
are
many
many
ways
to
to
define
types
and
using
this
type
of
is
the
one
that
works
in
most
cases
to
have
types
be
as
correct
as
possible.
A
A
lot
of
them,
don't
don't
export
an
interface
or
a
type
that
we
can
just
use
directly,
so
a
lot
of
them
export
like
name
spaces
or
things
like
that,
a
function
whatever
it
is.
So
this
is
just
what
what
works
in
most
cases.
A
So
typeof
does
I
mean
it
does
essentially
take
you
know
whatever
module
you
have
use,
use
it
as
a
type
or
an
interface.
It
doesn't
have
the
same
problem
that
if
we
had
used
like
a
direct
class
definition,
then
we
would
have
a
lot
of
like
versioning
conflicts
and
stuff
like
that,
if,
like
private
properties,
got
updated,
this
does
avoid
most
of
that
headache.
A
I
think
the
the
real
solution
if
we
want
to
have
typings,
is
for
us
to
define
our
own
types
within
the
instrumentation
module,
but
then
it
drifts
from
the
you
know.
If
we're
maintaining
types
outside
of
cassandra
driver
and
it
hasn't
drift
at
all,
then
we
potentially
run
into
problems
because
you're
you're,
happily
coding
along
using
auto
completion
from
our
types
that
are
drifted
from
from
reality,
and
then
you
run
into
bugs
that
you're
not
expecting.
F
Yeah,
it's
probably
a
case
of
the
way
I
would
do
it
would
be
like
the
cassandra
driver.
Instrumentation
would
declare
its
own
interface
definition
that
it
was
to
play
with
and
then,
if
the
actual
driver
version
changed
to
be
incompatible,
then
it
would
have
to
update
it.
But
if
it
wasn't
incompatible,
then
it
should
be
fine.
A
A
Or
something
like
that,
and
we
don't
notice
our
types
would
be
wrong
and
there's
no
easy
way
for
us
to
check
that,
because
if
we
want
to
have
that
type
checking
with
cassandra
driver,
then
we
have
to
imp.
We
have
to
introduce
it
as
a
dependency
in
some
ways.
A
A
A
Right
there
are
no
stupid
questions,
anyone
else
have
questions
or
contacts
there.
A
Matt,
I
hope
I
sufficiently
addressed
your
concern.
I
know
that
rauno
has
been
has
had
a
a
particularly
big
headache
over
this
for
the
last
couple
of
weeks
he's
not
in
the
meeting
today,
but
if
you're
looking
for
ways
to
help
out,
I
would
maybe
reach
out
to
him
on
slack,
as
I
think
he
would
appreciate.
D
Yeah
thanks
for
the
description,
it's
definitely
something
I'm
interested
in
I'll
see
what
I
can
do
about
finding
some
time
and
talking
to
ronno.
D
F
Yeah,
this
is
really
just
a
status
update,
so
everyone
knows
what's
happening
with
this,
so
I
merged.
I
think
it
was
the
1.3
release
in
so
I've
now
got
a
subset
of
the
packages
compiling
and
running
tests,
I'm
using
rush
instead
of
learner,
because
it's
a
much
more
simpler
way
of
doing
stuff
and
I'm
very
familiar
with
rush.
F
I
also
tried
using
karma
typescript
instead
of
webpack,
because
karma
types
has
when
you
run
tests,
it
actually
packages
each
individual
test
so
that
there's
definitely
zero
interaction
between
tests
where
webpack
creates
a
bundle,
so
there
could
be
interactions
except
that
failed
because
of
the
way
we
have
platform
node
and
browser-
and
we
say
in
the
package
json
for
browser-
you
should
be
using
these
definitions.
F
F
Not
every
package
runs
browser
tests,
so
I'm
trying
to
make
it
so
when
you
say
rush
test,
which
is
the
same
as
saying
npm
run,
run
test
from
the
root.
It
actually
runs
all
node
and
browser
tests
at
the
same
time.
F
How
small
is
it
going
going
to
be
so
we
can
then
start
playing
with
minification
techniques
and
then
looking
at
the
output
of
the
the
bundle
once
the
bundle
gets
created,
I
was
going
to
create
tests
based
on
know
size
based
tests
to
say
it's
getting
too
big
or
it's
getting
too
small.
That
is
perfectly
my
target
for
the
first
implementation,
which
does
leave.
F
You
know
it's
all
very
manual
merging
over
primarily
because
I'm
renaming
every
putting
a
sandbox
dash
on
the
front
of
every
package.
So
it's
all
self-contained
the
the
build
changes.
So
hopefully
there's
no
package.
Json
changes
have
to
merge.
It
should
just
be
code
moving
forward
and
I'm
also
restructuring
the
the
tree
structure.
So
it's
a
little
bit
more
logical
and
not
quite
so
long
to
avoid
the
long
path
issues
that
people
do
get.
F
So
that's
where
it's
at
I'm
hoping.
I
know
I
hope,
there's
not
a
plan
as
a
manager
used
to
tell
me
to
get
a
pr
out
for
this
this
week.
So
that's
my
focus
for
this
week.
I'm
trying
to
avoid
getting
sidetracked
with
being
on
call
for
internal
stuff,
but
it's
I'm
only
partially
working
working
on
that,
so
so,
hopefully,
by
friday,
I'll
have
a
pr
so
that
we
can
all
look
at
it
and
make
comments
and
figure
out
the
stuff
that
I
broke.
F
F
And
then
we
use
branches
for
minification.
So
it's
really
just
the
the
the
major
changes
of
of
maine
will
be
the
fact.
That's
using
roll
up
and
it's
gone
out
today,
rush
and
run
running
all
the
tests.
So.
A
Yeah,
I
know
that
roano
did
some
work
to
try
to
use
rush
and
pnpm
in
the
existing
repos,
particularly
the
contrib
repo.
I
think
everybody
here
is
aware
that
it
takes
an
extremely
long
time
just
to
build
it.
So
I
I
don't
remember
specifically
what
issues
he
ran
into
there,
but
it
might
be
worth
reaching
out
to
him.
F
Yeah
he
pinged
me
yesterday,
which
is
what
reminded
me
that
I
probably
should
put
the
status
here.
He
was
trying
to
selectively
compile
some
stuff
which
I've
never
had
to
worry
about,
because
I
always
make
everything
compatible
but
yeah.
So
I
told
him
when
I
was
working
on
having
this
use
rush
and
maybe
that
would
form
a
basis
of
how
we
do
or
don't
move
it.
So
because
it's
the
sandbox
for
cleaning.
C
Just
a
quick
question
this
is
in
relation
to.
I
think
you
had
a
thing
about
the
events
api
at
the
top.
I
was
I
joined
late
yeah,
we're
working
on
the
events
api
and
I
have
started
working
on
a
prototype.
C
The
events
api
has
has
shifted
to
basically
can
combine
api
for
both
events
and
logs,
and
since
I'm
I'm,
I
want
to
work
on
the
prototype
and
I
wanted
to
ask
like
when
do
you
think
where
work
will
be
like
planned
out
for
logs
in
general?
And
if
I
do
work
now
on
the
prototype
like?
How
would
that
be
useful
for
for
planning
that
you
know
once
you
want
to
once
you
plan
implementing
logs.
A
Yeah
I
mean
I
guess
I
would
say
right
now.
I
don't
have
a
plan
exactly
for
each
previous
signal.
We've
sort
of
had
one
person
who
coordinated
most
of
the
work
for,
for
instance,
for
metrics
it's
been
legitimacus
and
for
tracing.
I
did
most
of
the
coordination
for
that
and
we
haven't
really
had
anyone
step
up
to
say.
I
would
like
to
to
own
the
logs
topic
in
javascript,
if
you'd
like
to
that,
there's
definitely
room
for
someone
to
to
be
that
person
here,
that's
important
to
you.
A
I
haven't
really
spent
a
lot
of
time
thinking
about
logs,
just
because
I
think
if
I
spread
myself
too
thin,
nothing
gets
finished.
So
I'm
working
on
getting
metrics
over
the
finish
line
before
focusing
on
logs,
which
was
a
lesson
that
we
learned
when
trying
to
get
traces.
Ga
everybody
was
excited
to
move
on
to
metrics
and
it
was
great,
but
it
delayed
the
trace
ga
by
months
at
that
time
and
I'm
trying
to
avoid
that.
C
Yeah
understood
yeah,
I'm
asking,
I
think
if
vlog
events
is
going
to
be
very
important
for
the
browser
instrumentation
that
we're
working
on
and
it
just
happens
to
overlap
logs.
So
I
think
that's
something
we
would
you
know
sub
me
or
in
combination
from
people
from
the
client
side,
that
we
would
definitely
want
to
push
that
along.
A
Yeah,
of
course,
as
I
understand
it,
the
existing
specification
does
not
have
a
logs
api
right.
It's
just
like
the
logs
appenders
correct,
correct.
C
Yeah,
but
this
events
api
tab,
that's
out
there
that's
proposing
an
api
for
logs
as
well.
A
C
A
What
yeah
you
jinx
this
yeah!
I
know
I
know
I
I
shouldn't
say
it,
but
I
did
so
too
right
now,
but
in
terms
of
just
implementing
the
exporter
right
now,
it's
just
a
matter
of
waiting
to
see.
If
someone
has
time
to
do
it
just.
A
Don't
have
the
time
right
now,
but
if
you,
if
you
want
to
do
it,
it
would
be
welcomed
with
open
arms.
C
Great
okay,
that
that's
that's
what
I
wanted
to
get
to
like.
I
have.
I
have
time
to
work
on
it,
but
I
wanted
to
know
like
if
you
do
work
on
it
now
like
is
it
gonna?
Is
it
gonna
be
put
aside
until
you
know,
other
things
are
finished
like
metrics
or.
A
Yeah
I
mean-
I
guess
for
myself-
I
wouldn't
say
I'll
put
it
aside,
but
if
I,
if
it
comes
down
to
how
can
I
split
my
time
and
metrics
and
I
have
a
lot
of
things
to
do
on
metrics-
that's
going
to
be
my
focus.
That
said,
it's
an
open
source
project.
Everybody
has
their
own
priorities.
None
of
you
work
for
me
and
someone
else
may
say
logs
is.
A
And
they
may
you
know
you
may
find,
as
if
people
are
interested
you
may
find
it.
I
think
people
will
be
more
ready
to
review
logs
pr's,
just
because
I
think
they'll
be
probably
easier
to
review
in
a
lot
of
cases
as
well.
A
I
can't
tell
you
for
certain
that
it
will
be
looked
at
very
quickly
right
away,
but
I
can't
tell
you
it
won't
either
so.
D
A
Thanks
for
the
feedback,
I
would
maybe
sync
with
mark.
He
has
done
a
lot
of
work,
refactoring
our
exporters
for
metrics
and
traces,
and
I
don't
know
if
there's
any
additional
work
or
ongoing
work
that
he's
planning
on
from
in
in
that
perspective.
Okay,
because
our
our
exporters
were
all
kind
of
dependent
on
each
other
before
and
that's
improving,
but
I
think
they
still
depend
on
each
other
a
little
bit
and
that's
not
ideal.
B
Yeah,
they
still
depend
on
each
other
a
little
bit,
but
right
now,
there's
there's
nothing
bland
for
the
exporters
to
for
them
to
change
soon,
so
that
should
basically
stay
the
way
it
is
the
yeah.
The
proto
is
updated
to
the
newest
version
already,
so
it
should
be
all
the
log
stuff
should
be
there.
B
A
A
F
Sorry,
just
me
again
so
for
this
bug
that
I
raised,
I
have
a
spec
pr
which
would
address
that.
If
I
can
just
find
it
again,
I
was
going
to
place
it
in
there,
so
it
really
it's.
F
Currently
the
spec
says,
span
level
attributes
can't
have
nested.
A
F
Yeah,
so
this
spec,
it's
inconsistencies
for
attributes
in
general,
but
yeah
in
the
case
of
the
span
definition.
The
way
we've
defined
it
in
the
javascript
api
is
span.
Attributes
can
have
nested
attributes.
That's
what
the
bug
is
saying
because
we
said
span
attributes
is
now
an
alias
for
attributes
which
supports
that
so
that
that's
what
the
javascript
bug
is,
and
the
spec
thing
is
saying
this
is
inconsistent
with
protobuf,
because
protobuf
supports
it.
F
So
I'm
trying
to
say
yes,
it
can
have
it
because
we
need
it
for
for
logs,
specifically
because,
as
part
of
the
attributes
for
logs
for
events,
we
need
nested
attributes.
So
that's
where
it's
all
coming
from,
so
I'm
just
putting
it
in
here
as
from
a
documentation
perspective.
A
Yeah,
I
don't
remember
who
specifically
were
the
the
blockers,
so
this
is
something
that's
been
asked
for
in
the
past
to
have
the
nested
span
attributes,
and
I
don't
remember
who
specifically
was
against
it.
It
was
a
long
time
ago
at
this
point.
F
F
Is
the
other
discussion
yeah?
So
this
is
the
ongoing
one
subject.
So,
as
part
of
the
spec
pr,
I've
tried
to
take
both
sides
and
walk
the
middle
ground
based
on
what
protobuf
does
and
say.
This
is
what
we
can
do,
but
it's
not
a
mandatory.
Must
it's
a
this
is
how
we
should
deal
with
it.
So
yeah,
that's
what
that's.
That
is
therefore
yeah
and
I'm
hoping
we
can
then
just
say
that
that
bug
from
the
javascript
side
for
the
api
just
gets
resolved
because
it
becomes
okay.
F
D
A
Yeah,
okay,
I
guess
I'll
I'll
just
wait
and
see
what
happens
in
the
specification
agreed
yeah
thanks
for
bringing
that
up.
D
I
was
definitely
one
of
the
people
who
were
opposed
to
having
nested
maps
as
as
attribute
values,
mainly
just
because
I
think
most
tracing
back
ends.
Don't
really
know
what
to
do
with
those
like
at
best.
D
You
would
kind
of
end
up
with
a
a
very
long
dotted
kind
of
key
for
four-year
value,
so
that
was
kind
of
my
my
reasoning
for
being
against
it,
but
I
think
others
were
kind
of
in
the
same
boat
for
for
similar
reasons,
just
because
I
don't
think
we
identified
any
tracing
back-ends
that
actually
kind
of
support
that
natively,
but
it
did
seem
like
logs
somehow
this
works
out
in
the
logs
world
and
that's
why
why
they
exist?
They
were
kind
of
introduced
for
for
logging,
yeah.
F
Yeah
and
as
part
of
my
spec
pr,
I
haven't
mandated
how
the
flattening
occurs.
I
just
said
there
should
be
a
strategy
so
whether
that's
creating
a
long
dotted
name
or
converting
to
json,
which
was
already
there
for
non-supported
objects,
so
yeah
I
left
that
open,
so
it
could
be
up
to
the
exporter
the
sdk,
the
language,
whoever
needs
to
do
whatever
they
need
to
do.
A
A
Well,
I
guess,
if
that's
it
that
takes
us
to
our
time.
Thank
you,
everybody
for
your
for
your
time.
Please
review
prs,
there's
a
handful
of
new
pr's
in
here
in
need
of
reviews,
a
handful
of
old
ones
and,
as
I
said
at
the
beginning,
prs
that
are
important
for
the
metrics
ga
which,
if,
if
logs
is
important
to
you,
then
maybe
moving
metrics.
A
Ga
along
can
be
important
to
you,
so
I
will
talk
to
you
all
next
week
and
yeah
hope
you
have
a
good
rest
of
your
day.