►
From YouTube: 2022-04-20 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Amir
did
you
remove
the
topics
that
you
had
at
the
at
the
top?
There.
C
Yeah,
I
think
it's
it's
trivial,
maybe
I
will
do
it
at
the
end.
If
there
will
be
time.
B
Okay,
then
I
guess
we
can
probably
get
started.
Let
me
chair
here.
B
B
This
has
already
had
a
fair
number
of
reviews
and
has
been
open
for
a
bit,
but
amir,
you
were
questioning,
I
guess,
kind
of
the
strategy
of
this
pr.
Not
necessarily
the
execution
was
the
explanation
given
here
sufficient
for
you,
or
do
you
think?
That's
more
work
still
needs
to
be
done
here.
What
would
your
desired
outcome
be?.
B
Yeah,
so
I
think
probably
we'll
have
them
separated
forever.
I
know
that
this
affects
things
like
bundle
size,
and
you
can
do
stuff
like
tree
shaking
and
stuff
like
that
to
to
minimize
that.
But
some
like
bart
commented
here
and
actually
gave
an
example
in
lambda.
B
They
have
overall
bundle
size
restrictions
and
not
everybody
that
uses
lambda
is
using
webpack
and
stuff
like
that,
so
they
may
not
be
doing
tree
shaking
so
whatever
we
can
do
to
keep
it
small
is
probably
a
good
idea.
I
would
not
be
opposed
to
having
a
separate.
You
know,
a
package
that
kind
of
merges
them
together
so
that
you
don't
have
to
depend
on
all
the
signal
packages
like
if
you're,
if
you're
trying
to
export
with
grpc,
you
shouldn't
necessarily
have
to
depend
on
trace
and
metrics
and
logs
exporters.
C
B
A
C
Could
be
missing
something
also,
but
anyway,
I
will
read
it
later
and
comment
thanks
for
pointing
me.
D
Okay
mark,
do
you
have
any
thoughts
here
or
do
you
wanna
yeah,
it's
just
the
logs
sdk
that
will
come
up
in
the
future.
We
will
also
probably
want
to
have
those
exporters
separate.
Then,
if
we
had
the
the
matrix
exporter
separate
right
now,
so
probably
if
we
would
merge
them
together
again,
with
these
base
packages
also
included,
we
would
kind
of
end
up
at
the
same
place
that
we
did
before
where
we
have.
D
For
example,
the
logs
exporters
depend
on
metrics
and
traces,
which
I
think
is
something
that
we
would
want
to
avoid
in
the
future
as
well,
regardless
of
bundle
size.
If
we
want
to
keep
it
in
experimental.
It
would
then
depend
on
on
these
stable
exporters
as
well,
which
might
cause
some
issues
that
we
had
before
for
logs
once
we
once
we
work
on
them.
B
Yeah
I
mean
one:
one
potential
strategy
would
be
to
if
we
wanted
them
to
be
in
a
single
package
to
just
export
it
under
some
experimental
namespace
from
that
package.
So
even
if
it's
a
stable
package,
I
know
some
other
languages
are
doing
that,
but
we
haven't
really
done
that
in
any
of
ours.
So
I
think
that
that
might
be
confusing
for
some
people,
but
it
would
be
a
possible
solution
to
this.
E
Yeah,
I
I
think
that
there's
two
different
competing
requirements
here.
One
is
the
the
size
of
the
package
like.
If
you
you're
not
using
metrics,
then
you
only
want
traces.
Then
you
only
want
the
tracer
exporter.
If
you
are
using
both,
then
you
probably
want
it
to
effectively
have
a
single
set
of
batching.
So
therefore
having
them
together
would
be
another
one
and
in
terms
of
like
bundle
size.
I
know
in
the
the
client,
the
the
rum
sig
we're
actually
talking
about
putting
all
the
events
on
logs.
E
So
therefore,
you
may
not
have
traces.
Well,
definitely
won't
have
metrics,
but
you
may
not
have
traces
we
we
may
just
do
it
with
logs
and
peds
are
brought
up
a
couple
of
times
now
that
where
we
actually
may
come
back
to
this
group
and
go
okay,
we're
going
to
go,
go
off
and
create
a
minified
browser-based
sdk
version
for
pure
lightweight
purposes.
That
only
includes
the
stuff
that
a
basic
browser
would
need
an
entirely
separate
sdk.
E
Is
that
what
you're
saying
yep
so
we'd
effectively
try
and
reuse
the
the
api,
but
then
have
a
browser
sdk
rather
than
the
approach
we
have
at
the
moment
where
we've
got
like
base
and
then
node
and
web,
which
ends
up
with
extra
stuff
that
you
you
know
the
browser
doesn't
really
need.
Now,
there's
a
few
optimizations,
we
can
start
to
do.
B
E
Yeah,
so
you
could
say:
well
the
grp,
the
grpc
exporter
includes
everything,
because
it's
only
going
to
be
used
in
the
back
end.
So
therefore
the
size
isn't
an
issue
and
you
can
take
advantage
of
of
a
single
lot
of
batching,
so
yeah
there's
a
bunch
of
optimizations
but
yeah.
For
now,
I
think,
while
it
will
be
a
bigger
bundle,
size
and
as
mark
suggested
like
when
the
when
the
logs
exporter
comes
in,
it's
going
to
be
experimental.
B
Okay,
one
thing
that
I
think
worth
mentioning
mark:
you
said
that
the
new
logs
exporter
would
be
experimental.
B
Depend
on
stable
packages,
that's
actually,
okay,
and
now
that
we've
merged
the
the
learner
repositories
together,
I
think
the
development
experience
for
that
is
a
little
bit
simplified,
so
that
shouldn't
be
a
problem,
but
I
guess
it
is
something
to
keep
in
mind,
so
we
have
to
make
a
decision
how
we're
going
to
go
forward
with
this
pr,
because
this
pr
adds
some
base
packages,
assuming
that
we're
going
to
keep
exporters
split
by
signal.
B
C
If
we
want
to
split
the
signals
for
the
ltlp
exporters,
then
we
will
have
to
split
this.
This
package
as
well
right.
D
Yes,
so
right
now,
because
the
otp
transform
might
depends
on
sdk
metric
space
and
sdk
trace
base,
so
that
would
basically
undo
everything
that
that
this
br
is
trying
to
do
by
splitting
stuff
up
and
making
sure
that
the
metric
stuff
doesn't
depend
on
the
trace
stuff.
B
B
I
mean
personally,
I
would
rather
have
a
single
like
one
grpc
exporter,
which
does
all
of
the
signals.
I
think
it's
it's
a
much
simpler
experience
and
it
simplifies
our
our
package
structure,
but
I
think
right
now
we
have
already
gone
pretty
far
down
this
path
and
to
to
reverse
force
on
that
now.
I
think
which
will
delay
our
our
metrics
release.
B
I
think
in
the
interest
of
getting
something
released,
we
should
move
forward
with
this,
but
we
can.
We
can
merge
them
into
a
single
package
later
once
once
we
have
metric
stable
or
does
that.
C
I
think,
if
the
motivation
to
split
it
is
the
bundle
size,
then
it
could
be
nice
to
understand.
What's
the
impact
on
the
bundle
size
like
what
will
be
the
difference
before
we
take
this
decision,
but
we
can
always
revert
it
in
the
future
if
we
want
to
so,
if
it's
local
for
now,
because
everything
is
experimental
right.
So
we
can
always
change
our
mind
if
we
reach
another
conclusion
so
not
against
merging
it,
but
I'm.
I
think
we
should
take
a
decision
based
on
the
data
like
what's
the
bundle.
A
C
C
B
B
Okay,
so
I
guess
we'll
move
forward
with
this
pr
for
now,
but
the
next.
When
we
go
to
use
the
otld
transformer
package,
we
should
try
to
do.
I
guess
two
parallel
versions
and
see
which
one
like
how
big
is
the
bundle
size
difference?
B
B
B
Let's
see
the
code
coverage
paths
were
incorrect,
so
I'm
not
sure
if
people
had
noticed
or
not.
But
when
you
look
at
the
coverage
files,
all
of
the
packages
were
listed
under
packages,
including
the
ones
that
were
in
experimental.
B
So
when
you
clicked
on
packages
and
then
you
clicked
on
an
experimental
package,
there
were
coverage
issues
where
it
was
not
correctly
detecting
the
files
and
coverage
was
being
reported
incorrectly.
So
this
is
just
a
quick
fix
for
that.
The
the
short
change
was
that
in
experimental,
the
project
group
was
wrong,
so
it
just
needed
to
be
changed
to
be
the
real
project
group.
So
I
think
that's
fun
controversial
and
just
please
take
a
look
and
and
review
that
so
that
it
can
get
merged
is
severn
on
the
call.
B
Today
it
looks
like
no
okay
for
those
that
have
not
seen
he
started
working
on
sort
of
like
an
agent-like
experience
where
you
can
have
a
more
simplified
startup,
configured
with
environment
variables
and
and
so
on,
without
having
to
make
code
changes
in
order
to
get
tracing
in
your
app
there's
been
quite
a
bit
of
discussion
on
here
in
the
last
couple
of
days,
so
I
would
encourage
anyone
that
has
not
seen
this
to
take
a
look
at
it.
B
I
won't
really
summarize
all
of
the
discussion,
but
the
outcome
is
that
we're
probably
going
to
have
two
separate
like
dash
r
flags
required,
one
will
load
instrumentations
and
the
other
will
load
the
sdk,
because
it's
so
important
that
the
instrumentations
be
loaded
first,
but
we
don't
want
to
require
all
of
the
instrumentations
in
the
sdk
package.
B
So
I
think,
adding
a
quick
register
file
to
the
meta
packages
and
one
on
the
sdk
is
a
reasonable
way
to
solve
this,
which
also
would
allow
for
end
users
to
use
a
custom
set
of
instrumentations
if
they
need
to
or
a
custom
exporter
and
some
stuff
like
that.
B
C
Instrumentation,
a
file
which
would
need
to
be
required.
Is
it
something
that
the
user
has
to
write.
F
No,
it
would
be
in
the
so
if
we.
B
Yeah
part
of
the
auto
instrumentations
package,
so
this
first
require
would
register
all
the
instrumentations
and
then
this
second
one
would
actually
set
up
the
sdk
and
the
exporter
and
stuff
like
that.
B
But
if
you
did
not
want
to
use
all
of
the
instrumentations
in
auto
instrumentation
or
something
like
that,
then
you
would
create
your
own
file
instead
of
this.
This
would
just
be.
If
you
want
to
use
everything
and
then
I
think
he
was
also
thinking
of
having
one
like
register
all
that,
if
you
do
definitely
want
everything,
then
have
a
single
register.
Call
that
does
everything
if
you
don't
care
about
bundle
size
and
you
just
want
it
to
work.
B
B
So
when
you
start
the
sdk,
if
you
have
a
trace
started
in
the
first
like
couple
of
milliseconds,
you
might
miss
that
trace,
which
I
think
is
probably
going
to
be
somewhat
common
in,
like
lambda
scenarios,
but
also
container
based
scenarios
and
stuff
like
that.
B
One
solution
to
that
would
be
to
make
our
resources
synchronous,
which
would
definitely
simplify
startup.
But
we
already
have
a
handful
of
asynchronous.
B
Lambda,
you
didn't
have
all
of
the
resource
attributes
available
at
startup,
but
I
think
the
most
recent
specification
has
actually
removed
those
because
other
languages
are
having
similar
problems,
and
I
think
the
ones
that
are
not
available
at
startup
have
now
been
moved
to
span
attributes
for
the
most
part,
I'm
not
entirely
sure
that
they
all
have.
B
B
So
I
mean
there's
a
couple
of
ways
we
can
solve
this.
We
could
create
a
new
synchronous
resource
detector
that
runs
parallel
to
the
other
resource
detector,
or
we
can
make
them
so
that
they
could
return
a
promise
or
return
a
resource
and
sort
of
extend
the
existing
interface.
B
I'm
not
sure
what
I
would
prefer,
but
I
think
that
this
is
a
change
that
I
support.
I
just
think
it's.
It
might
be
difficult
to
do
in
a
backwards
compatible
way,
so
I
haven't
done.
I
haven't
thought
about
this
too
much,
because
this
issue
is
just
kind
of
created
this
morning,
but
if
anybody
has
any
thoughts
on
this,
please
comment:
when
you
have
time
or
at
least
read
through
this
issue,
does
anyone
have
any
questions
about
that
right
now,.
G
Hey
this
is
this
is
aaron
from
google,
so
I
think
I
think
most
of
our
resource
attributes.
They
come
from
the
metadata
server
and
they
should
be
pretty
quick
to
resolve
since
it's
sort
of
like
a
local
server,
and
we
just
hit
it
on
the
on
the
network
and
it
shouldn't
really.
B
G
Go
very
far
the
when
you
say
synchronous,
resource
detector:
do
you
mean
it
would
block
the
startup,
or
do
you
mean
it
would
like
use
synchronous,
synchronous
apis?
In
node
I
mean
it
would
use
synchronous
apis.
B
I
mean
it
would
also
block
startup,
but
because
it's
synchronized
it
would
be
faster,
and
you
know
things
like
environment
variables
and
the
os
module
and
stuff
like
that
would
be
the
only
ones
really
available.
Yeah.
G
Then
obviously,
right
so
I
mean
ideally
like,
I
think
the
only
thing
we
really
need
to
get
for
serverless
environments
from
the
metadata
server
is
potentially
like
the
project
id.
If
it
completes
within
a
few
milliseconds,
would
it
be
okay
if
we
wrote
a
synchronous
detector
with
the
synchronous
node
apis,
assuming
that
it
completes
really
fast,
it
would
block
the
thread
for
a
little
bit,
but
it
seems
like
like
an
okay
trade-off.
There
right.
E
G
Okay,
yeah
I'll
look
into
it
a
little
bit.
I
think
for
most
of
our
serverless
stuff,
like
like
you
said.
If,
if
the
entire
you
know
process
is
only
going
to
last
a
second
or
something
like
that,
it's
it's
problematic,
so
I
think
we
would
want
to
do
this
with
environment
variables
yeah.
G
The
only
other
thing
I
could
think
of
is
like
having
a
startup
having
a
script
that
starts
up
the
actual
application
and
injects
the
resource
attributes
as
the
environment
variable
the
hotel
resource
attributes,
environment
variable
that
would
sort
of
let
you
do
everything,
synchronously
and
but
you'd
have
to
have
like
a
wrapper
script.
Essentially.
B
Yeah,
I
think
so
I've
definitely
seen
it's
possible
to
make
a
synchronous
web
request,
but
it
is
the
way
that
I've
seen
it
in
the
past
is
a
huge
pain.
Essentially,
you
have
to
launch
a
sub
process
because
there
are
synchronous.
Sub
process
calls,
so
you
launch
a
sub
process
that
makes
the
web
request
and
waits
for
its
result,
which
is
you
know,
returned
by
standard
out
or
whatever
you
know.
However,
you
want
to
do
that,
but
certainly
that
won't
work
in
all
environments.
B
You
know
I
mean
in
lambda
and
in
cloud
functions.
You're
definitely
hopeless,
like
I
don't
think
you're
gonna
be
able
to
to
do
that.
Oh
maybe
I'm
wrong,
but
I
would
be
really
surprised
if
that
worked
everywhere.
But
as
far
as
I
know,
there's
no
official
api
for
synchronous,
http
calls.
B
Yeah,
please
take
a
take
a
look
through
this
right
now
we
sort
of
assume
that
resources
are
asynchronous
by
default
and
almost
all
of
our
you
know,
all
of
our
resource
detectors
use
the
async.
You
know
they
return
a
promise,
but
as
far
as
I
know,
all
of
them
accept
the
google
one.
Don't
actually
do
any
async
work,
they
just
return
a
promise
directly.
B
So
I
guess
we,
we
kind
of
designed
the
api
around
what
I
kind
of
consider
to
be
an
edge
case,
not
that
google's
an
edge
case,
because
it's
a
pretty
big
platform,
but
almost
all
of
the
other
resources
don't
require
async
work.
So
it's
kind
of
it's
kind
of
a
bummer
that
it
the
startup,
is
so
complicated
because
of
that.
A
B
A
B
Yeah,
I
think
aws
though,
for
the
lambda
resources.
If
you
look
at,
if
you
look
at
the
semantic
inventions,
I
am
99
sure
that
they
changed
the
ones
that
you
can't
get
at
startup
to
be
span.
Attributes.
B
Yeah,
so
the
name
yeah
so
that
the
ar
the
the
this
one
you
definitely
cannot
get
at
startup
in
aws.
I
don't
know
about
gcp
yeah,
I
I
don't
remember
off
the
top
of
my
head,
which
ones
you
can
and
cannot.
G
B
Okay,
I'm
sure
that
there's
a
good
reason
for
that.
I
don't
need
to
get
into
that
right
now.
I
guess,
since
you
have
more
certainly
more
familiarity
with
the
google
environments
than
I
do,
can
you
please
take
a
look
at
this
issue
and.
B
It's
fine
if
we
have
to
have
two
different
methods
of
startup
or
something
like
that.
If
we,
if
we
need
to
have,
if
we
need
to
do
that-
or
I
don't
know
I
I
just
feel
like-
we
should
be
able
to
start
up
synchronously
most
of
the
time.
B
Anyone
else
have,
I
guess,
matt
since
you
already
spoke
up,
and
I
know
you're
here,
do
you
know.
A
A
A
It
introduces
this
complication
and
I
think,
like
you
know,
in
addition
to
like
landlord
cloud
functions,
you
have
like
ec2
and
other
things
like
that,
and
a
lot
of
a
lot
of
the
the
resource
metadata
just
comes
from
these
network
calls,
which
is
unfortunate,
but
I
am
definitely
thumbs
up
on
if
we
can
find
some
way
to
make
resource
resolution
at
least
appear
synchronous,
because
it
is
a
huge
pain.
B
B
B
And
synchronous-
that's
obviously
not
ideal.
It
would
be
better
to
have
only
a
single
method
of
startup,
but
if
we
can't,
then
we
can't
or
a
way
to
make
the
asynchronous
resource
detection
more.
A
simpler
startup
experience,
I'm
not
sure.
G
Yeah,
I
I
was
wondering:
do
we
expose
so
I
assume
somewhere
there's
a
promise
that
gets
awaited
and
then
until
that
point,
there's
basically
no
resource.
Is
there
any
chance?
We
could
expose
that
or
another
promise
to
the
user
so
that
they
could
sort
of
like
block
their
program
until
the
resource
detection
is
done.
B
Yeah
so
right
here,
this
sdk
start
returns
a
promise
which
resolves
when
the
resources
are
detected.
So
then
this
is
where
you
would
like
require
your
own
code
yeah.
B
But
if
you're
just
using
like
the
dash
r
flag,
then
obviously
you
can't
like
if
we
can't
customize,
you
know
what's
what's
done
here
then
like
the
user's
code
will
start
and
any
traces
that
should
be
started
before
this
promise
resolves
will
just
be
dropped,
which
is
unfortunate.
Obviously,.
B
Yeah,
I
mean
one
possible
way
to
do.
It
would
be
to
have
like
almost
I
guess,
a
command
line
utility
that
runs
the
asynchronous
resource
detectors
and
adds
them
to
the
environment
variables
and
then
launches
the
user.
You
know
the
the
rest
of
the
process,
but
I'm
not
sure
how
I'm
not
sure
how
I
feel
about
that.
C
B
C
B
A
I
detected
while
we're
on
this
topic.
I
I'll
mention,
I
think,
bart
or
somebody
a
long
time
ago,
looked
into
just
propagating
the
resource
as
a
promise
through
like
the
pipeline
to
the
exporter
and
letting
it
resolve
there.
A
I
don't
know
if
that's
ringing
a
bell
for
anyone
who
is
around
in
in
those
days.
You
know
it
seemed
kind
of
complicated.
So
I'm
not
sure
if
that's
a
good
idea,
but
I
was
gonna,
bring
it
back
up
because
it
was.
It
was
something
that
was
explored
if
people
are
going
to
be
thinking
in
this
area
and
then
the
only
other
thing
I
had
to
add
was.
A
I
know:
ted
was
in
last
week
talking
about
like
if,
like
right
now,
resources
are
technically
kind
of
like
set
in
stone
at
startup,
but
we're
talking
about
like
what,
if
resources
are
still
immutable,
but
they
can
be
changed
if
if
their
reference
can
be
changed
at
runtime
like
does
that
open
up
any
doors
to
possibly
improving
this?
I
know.
B
Yeah,
I
mean
it
definitely
so
yeah
bart
and
I
both
separately
tried
to
propagate
the
promise,
which
sounds
like
a
simple
solution,
and
then
it
turns
out.
It's
not.
B
I
would
be
happy
to
see
a
pr
which,
which
does
that
successfully.
The
one
issue
with
it
is
that
the
readable
span
interface,
which
is
passed
to
the
on.
B
Let's
see
the
on
end
of
the
processor
and
the
writable
span.
Interface,
which
has
to
be
on
start,
are
both
supposed
to
be
able
to
access
the
resources,
so
it
needed
to
be
essentially
a
weighted
in
the
tracer.
When
you,
when
you
start
a
span,
you
would
need
to
await
the
resource
before
calling
the
span
processor
with
and
that's
where
sort
of
the
complexity
was
introduced.
B
And
then,
if
you
were
running
more
than
one
resource
detector,
the
merge
of
the
the
separately
resolved
resources
needs
to
happen
somewhere.
Also,
so
the
the
tracer
itself
was
overly
complicated
and
that
so
that
was
what
I
was
trying
to
do,
and
I
mean
it
worked,
but
it
was
just
a
lot
of
overly
complicated
code
in
the
tracer.
B
In
my
opinion,
in
what
should
be
a
fairly
tight
loop
and
then
bart
tried
to
do
it
in
the
the
span
processor
so
that
it
would
resolve
before
it
called
the
exporter
and
then
one
way
that
we
also
talked
about.
But
I
don't
know
if
anyone
ever
made
a
prototype,
would.
B
Allow
the
promise
all
the
way
through
and
to
await
it
in
the
exporter
itself.
At
this
point,
the
biggest
problem
is
that
we
have
stable
exporters
that
don't
expect
that.
B
E
Yeah,
I
I
guess,
as
t2
t2,
I
don't
know
how
you
pronounced,
but
anyway
just
dropped
in
into
the
chat
in
the
the
rum
sig,
we're
talking
about
introducing
a
resource
provider
interface
so
effectively,
as
well
as
resources
for
backward
compatibility,
you'd
have
a
resource
provider
and
technically
effectively.
The
effect
of
the
resource
providers
only
have
a
single
method.
You
know
get
resources,
so
that
could
be
done
asynchronously
and
it
could
be
done
lazily
depending
on
your
implementation.
E
E
B
B
I
guess
there's
probably
nothing.
We
can
really
decide
on
right
now.
This
is
a
draft
pr
anyway,
but
in
order
to
move
it
forward,
I
think
this.
This
synchronous
versus
asynchronous
startup
thing
is
important
and
has
been
a
a
perennial
source
of
confusion
for
new
users.
B
A
B
One,
I'm
not
sure
who
this
person
is
or,
if
they're,
on
the
call
but
yeah
once
they
resolve
the
the
last
comment.
I
think
this
is
going
to
be
merged,
so
I
was
just
hoping
to
see
him
on
the
call
he's
not
here
similar,
there's
a
pr
here
to
clean
up
the
api
dependencies.
B
But
I
think
that
this
will
also
merge
fairly
quickly
this
one
here,
so
we're
waiting
on
reviews
here
so
metric
aggregation,
temporality
controls.
I
know
that
you
guys
are
all
probably
pretty
sick
of
hearing
me
say:
please
review
metrics
prs,
but
I'm
going
to
say
it
again.
Please
review
this
pr.
It
is
important
for
metrics.
B
It
is
one
of
the
last
really
important
changes
in
metrics,
it's
fairly
fundamental,
but
it's
not
a
huge
pr,
so
it
should
be
relatively
simple
to
review,
but
please
take
a
look
at
that.
One.
B
I
don't
think
valentine's
on
the
call
here,
so
maybe
we
should
skip
this
next
one.
I
added
this
here
valentine
tried
to
to
make
a
pr
to
add
support
for
esm
and
ran
into
a
couple
of
issues
and,
honestly,
I'm
just
not
familiar
enough
with
esm.
B
B
I
suspect
that
nev
would
be
very
happy
to
see
esm
support,
but
there
he's
certainly
not
the
only
one.
There
are
others
and
it's
something
that
I
just
don't
have
a
lot
of
experience
with,
and
I
I
don't
know
how
to
help
them
here.
B
If
not,
I
will
try
to,
on
my
own
time,
learn
more
about
it
and
and
see
if
I
can
help,
but
in
the
interest
of
getting
this
done
sooner
rather
than
later.
I
would
appreciate
it
if
anyone
could
please
take
a
look
at
that.
H
And
I
I
think
one
of
the
the
main
open
questions
is
whether
more
tests
should
be
added
to
ensure
compatibility
with
esm
along
with
cjs,
because
right
now,
it's
hard
to
test
for
both.
H
Testing
to
make
sure
everything
works
so
like
one
of
the
one
of
the
reasons
why
this
pr
was
held
up
and
liz
also
had
had
one
for
a
while
was
because,
when
it
transpiles
it
works
differently
like
there,
it
transpiles
into
something
different,
like
I
noted
on
liz's
pr
and
it's
hard
to
test
that
so
basically
it
broke.
H
It
broke
some
tests
which
are
really
obvious
to
see,
but
it's
hard
to
see
what
would
break
with
es
modules,
because
most
of
the
tests
are
just
testing
for
common
js,
which
is
good,
but
I
think
that's.
The
main
question
is
if
an
incorrect
type
is
used
and
it
would
ultimately
be
broken
if
someone
was
using
it
as
an
es
module,
there's
not
an
easy
way
to
see
that
with
the
tests
written
as
they
are
today.
H
B
H
Yes,
I
think
I
think,
that's
generally
the
question,
and
if
so,
how
far
do
you
go
into
it
right,
like
you,
don't
want
to
duplicate
everything.
That's
there
is
there
an
in-between
way
of
being
confident
and
changes
made,
won't
break
things
for
esm.
That
they'll
continue
to
work
going
forward
and
not
not
really
sure
how
to
do
it.
I
think
he
had
mentioned
on
there
that
it
was
very
difficult
with
the
current
setup.
B
Got
it
okay,
I
mean,
like
I
said,.
A
H
B
So
the
next
item
I
have
here
was-
I
just
wanted
to
to
list
out
some
things
that
we
need.
I
I
put
before
release
here,
but
it
doesn't.
B
Have
to
be
done
before
the
release,
but
I
think
we've
done
a
lot
of
good
work
on
the
metrics
sdk,
but
we
have
done
almost
no
like
documentation.
The
examples
are
not
updated
and
some
things
like
that.
So
there's
a
lot
of,
I
think
low
hanging
fruit.
B
That
needs
to
be
done
certainly
before
we
have
ga,
because
if
we,
if
we.
B
Ga
and
someone
comes
to
the
repository
and
the
examples
are
all
pointing
towards
a
six-month-old,
metrics
sdk
everybody's
going
to
be
confused
and
angry,
and
I
I
don't
think
that's
what
we
want.
So
we
have
roughly
a
month
before
the
expected
announcement
that
you
know
rcs
are
available
and
stuff
like
that
at
kubecon
and
in
the
in
the
time
between
now
and
then
I
would
really
like
to
see
the
examples
get
updated.
The
new
metrics
sdk
to
be
documented
and
those
types
of
things.
B
So
I
don't
have
specific
work
items
or
issues,
but
if
people
are
looking
for
for
things
to
do
or
ways
to
get
involved
in
the
project
or
if
you
have,
you
know
people
at
your
companies
that
are
looking
for
stuff
to
do.
I
think
this
is
a
great
way
to
to
get
involved,
but
also
it
just
needs
to
be
done.
So
I
guess
I'm
just
if
anybody
has
extra
time
extra
cycles.
B
B
I
think
I'm
going
to
cut
or
not
cut
a
release
but
create
a
release,
pr
that
will
release
the
new
metrics,
sdk
and
hope
to
get
that
merged
and
released
this
week
if
we
can,
if
there's
no
blocking
issues
or
prs
or
anything
like
that,
so
I'll
probably
do
that
this
afternoon
and
if
anybody
does
have
any
issues
or
pr's
that
they're
aware
of
that
block
the
release.
Just
please
comment
on
the
on
the
release.
B
I
don't
think
it's
completely
finished
and
polished
and
all
of
that,
but
I
think
it's
at
a
place
where
we
can
release
it
as
sort
of
an
alpha
release
and
let
people
start
testing
it
with
real
collectors
and
stuff
like
that
and
try
to
get
some
some
feedback
before
we
cut
a
more
stable
release
candidate.
B
B
Okay,
I
wanted
to
sort
of
to
the
end
of
the
meeting
here.
Do
some
issue
triage?
There
have
been
a
bunch
of
issues
that
that
have
been
opened,
and
I
know
I
haven't
been
that
great
at
looking
at
issues,
I
tend
to
look
more
at
prs
and
if
nobody
has
any
additional
topics,
I'd
like
to
start
going
through
these
issues
and
I'd
probably
like
to
do
this
more
regularly
at
the
meetings.
B
G
I
have
a
quick
question:
daniel
yeah,
on
the
on
the
metric
stuff.
You
mentioned
kubecon
and
I've
like
heard
this
in
the
last
week
or
so
in
the
python
metrics
work
as
well.
Are
you
planning
to
do
a
stable
release
for
kubecon
and
is
there
some
sort
of
announcement
planned?
There
is
an
announcement.
B
Planned
at
least
java
and
net
are
planning
to
announce
stable
releases
and
I
think
they're
trying
to
include
as
many
languages
as
possible
as
like
release
candidates.
I
don't
think
we're
gonna
be
at
a
point
where
we're
stable
in
a
month.
I
don't
know
how
you
all
feel
about
that,
but
it
seems
to
me
like
that's
an
unreasonable
target,
but
we
could
get
to
a
point
where
we
have
a
relatively
you
know:
usable
beta
release,
candidate
phase
but
yeah
that
that's
what
the
the
target
is.
I
don't
know.
G
Yeah,
I
know
I've
heard
something
similar
and
it's
also
a
tight,
a
tight
deadline
for
us,
but
it's
good
to
know
what
you,
what
you
all
are
planning
so
that
that's
all
I
had.
B
B
It
does
not
require
a
ticket
to
open
source
summit.
So
if
you
only
want
to
attend
the
community
day,
that
is
just
fine
and
there's
also,
I
believe,
a
20
virtual
option
and
then
I
also
have
for
those
who
are
interested
in
speaking
or
running
a
workshop
or
anything
like
that.
There
is
a
submission
for
submission
form
for
workshops
and
talks.
B
B
All
right
so,
which
we
have
seven
minutes
left.
So
let's
try
to
do
some
of
this
issue
triage
if
we
can.
B
Okay,
so
let's
see
default
instrument
unit
does
not
comply
with
the
spec.
This
is.
A
B
Mark
the
other
day,
essentially
right
now,
if
you
use
undefined
or
null
as
the
unit,
it
sets
it
to
the
string
one.
But
if
you
set
it
to
the
empty
string,
it
retains
the
empty
string
and
in
the
spec
it
says:
if
the
unit's
not
provided
or
no,
it
must
make
sure
the
behavior
is
the
same
as
the
empty
string.
B
So
I
think
what
I
would
prefer
would
be
to
use
just
the
empty
string
if
the
user
provides
null
or
undefined
should
be
a
relatively
simple
fix.
This
one
is
up
for
grabs
and
I
think
is
a
good
first
issue
for
those
looking
for
something
to
do.
Does
that
seem
like
a
reasonable
solution
to
everybody
thumbs
up?
Yes,.
B
Resource
attributes
type
does
not
comply
with
the
spec
again.
I
think
that
this
one
is
a
relatively
simple
fix.
Amir
opened
this
yesterday,
I
will
also
label
this
as
good
first
issue.
B
I
think
the
solution
to
this
is
just
to
add
the
missing
types
to
the
resource
attribute
type.
So
right
now
we
have
like
the
basic,
primitive
values,
but
it's
supposed
to
also
allow
an
array
of
primitive
values,
so
this
should
be
as
simple
as
changing
the
type
and
probably
the
handling
in
one
or
two
of
the
exporters.
But
I
would
expect
that
it's
relatively
simple
and
straightforward.
C
C
Attributes
because
we
can't
use
the
attributes
because
it
will
not
compile
with
one
zero
zero
yeah.
B
B
B
B
My
my
gut
feeling
is
to
say
that
this
is
not
something
we
want
to
support,
but
particularly
the
other
maintainers,
but
really
anyone
is
that.
B
Do
you
guys
feel
differently
about
that
or
you
know,
I'm
I'm
not
sure
that
this
is
a
use
case
that
we
really
want
to
support
for
now,
because
once
we,
if
we
allow
request
headers,
then
people
are
just
going
to
ask
to
have
it
extended
with
a
bunch
of
other
things.
I
would
rather
point
this
user
to
the
specification
and
say
if
this
is
something
you
really
need,
you
should
have
it
specified.
B
B
And
we're
out
of
time,
so
I
would
like
to
do
this
sort
of
issue
triage
more
regularly
at
meetings.
I'm
not
gonna
run
over
the
time
on
it,
though,
but
just
so
you
guys
know
you
could
probably
expect
to
have
some
boring
issue
triage
at
the
end
of
each
meeting.
Sorry,
and
with
that
I
have
a
hard
stop,
so
I
have
to
let
you
guys
go,
but
thank
you
for
your
time,
and
I
will
talk
to
everybody
soon
next
week
before
that
who
knows.