►
From YouTube: 2022-02-23 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).
B
I
think
it's
because
morgan
switched,
they
switched
it
back.
A
Okay,
not
a
long
agenda
today,
so
we'll
probably
get
through
it
fairly
quickly.
So
if
anybody
has
anything,
they'd
like
to
bring
up
feel
free
to
add
it
to
the
agenda,
first
thing
that
I
wanted
to
talk
about
was
the
refactoring
of
the
metrics
export
data
structure,
something
we
talked
about
last
week
and
seen
kalas
took
that
over.
I
got
an
update
from
him
this
morning.
That
said,
he
expects
to
have
a
pr
open
for
that
this
afternoon
or
tomorrow.
So
hopefully
that
will
be
ready
for
review
soon.
A
A
So
I
am
working
this
morning
on
updating
that
I
hope
to
have
a
pr
ready
for
that.
I
was
hoping
to
have
it
done
before
the
call,
but
I
didn't
have
time
I
will
open
the
pr
as
quickly
as
possible
and
probably
paste
a
link
to
it
into
the
slack
channel
just
so
that
we
can
get
as
many
reviews
on
it
as
possible
quickly
because
I'd
like
to
release
the
exporters
soon.
A
Another
issue
that
I
found
is
that
the
grpc
and
proto
exporters
depend
on
the
http
exporter,
but
they
actually
depend
on
the
0.27
version.
So
if
you
update
them
to
depend
on
the
local
versions
or
the
1.0
versions,
the
build
breaks,
because
there
was
a
breaking
change
between
0.27
and
1.0,
the
is
shutdown
was
removed.
A
I
could
go
either
way.
We
just
need
to
make
a
decision
so
that
we
can
get
these
done
as
quickly
as
possible.
A
Actually
sure
it's
probably
not
too
hard
to
find
out
when
it
happened,
though,.
A
A
A
I
thought
it
would
be
more
obvious
from
the
names
I'm
not
sure
why
it
was
removed.
I
think
it
was
done
in
this
one
actually.
A
Yeah,
so
it
was
just
removed
as
part
of
the
updating
the
exporters
to
use
that
like
bind
once
future
method.
I
guess
when
he
removed
the
private
is
shut
down,
meth
property.
He
probably
just
didn't
notice
that
there
is
a
protected
one.
A
A
A
So
if
nobody
has
an
objection
to
that,
I'll
just
include
that
as
part
of
my
pr
updating
the
proto,
because
that
already
affects
all
three
exporters
and
I
need
them
to
build
together
anyway.
So
I
need
that
to
fix
the
build.
A
Okay,
if
nobody
has
any
questions
about
that,
we
can
move
on
to
the
next
point.
D
D
Yes,
I'm
just
curious
about
this
recent
change
through
the
spec
sig,
to
rename
instrumentation
library
to
instrumentation
scope,
at
least
in
terms
of
like
the
the
json
exporter
like
if
we
were
to
release
one
with
the
currently
existing
photos
where
that's
named
instrumentation
library,
and
then
you
know
in
a
month
or
two
release
that
with
the
name
change.
D
Would
that
be
breaking
or
is
there
something
we
should
do
to
kind
of
work
through
this
situation.
A
Yeah,
I
hadn't
even
thought
of
that.
Actually,
I
think
if
we
look
at
the
specification.
D
Yeah,
I
think
that's
what
that
means.
It's
I
don't
know.
I
find
it
a
little
bit
frustrating
that
this
is
still
unstable
and
that,
like
he,
I
don't
know.
I
guess
I
understand
why
it
is,
but
it
would
be
nice
to
have
json
support.
B
Hey
so
it
looks
like
there's
a
pr
open
to
the
proto
repo
still
for
that
change.
B
B
For
metrics,
there
was
something
similar
and
I
think
we
left
behind
a
message
and
then
said
hey.
This
will
put
a
comment
like
this
will
be
deleted
in
six
months.
Send
both
of
these
et
cetera
so.
A
Okay,
we
definitely
should
aaron.
Do
you
want
to
make
that
comment
on
that?
Pr
and
I'll
give
a
thumbs
up
to
your
comment,
sure
I
can
do
that.
A
I
do
think,
though,
until
the
json
protocol
is
marked
as
stable,
we
should
not
release
the
exporter
as
1.0
either
way
I
mean
it
is
a
relatively
stable
exporter.
It
doesn't
get
changed
that
often,
and
I
I
know
that
it's
being
used
in
some
fairly
large
deployments,
so
stability
is
important
for
us
anyways,
but
I
just
don't
think
that
until
we
can
absolutely
guarantee
there
will
be
no
breaking
changes
and
that
the
specification
isn't
going
to
break
us
by,
for
example,
renaming
something
I
don't
think
we
can
go
to
onenote.
A
A
lot
it's
the
only
way
to
use
the
browser.
It's
the
only
way
to
get
anything
out
of
the
browser.
D
Yeah,
that's
that's
definitely
true.
I
know
at
lifestyle
we've
been
trying
to
kind
of
support
this
as
an
ingest
mechanism
for
customers.
It's
been
kind
of
a
nightmare
with
changes
such
as
these,
especially
using
this
protobuf
trans
building.
I
think
we
end
up
having
like
there's
like
four
or
five
copies
of
protos
that
have
been
renamed
in
weird
ways,
just
to
be
able
to
support
this,
and
it's
been
a
bit
of
a
pain,
yeah.
A
I
think
that
it's
been
adopted
fairly
widely,
considering
it's
experimental
and
the
specification
treats
it
like
it's
experimental
and
they
can
break
it
when
they
want
and
for
actual
implementations.
It
doesn't
work
that
way.
All
the
time
like
your
users
are
not
going
to
be
happy
with
you,
if
it
just
breaks
all
the
time
yeah.
We
at
dynatrace
solved
this
by
not
supporting
the
json
transport,
which
has
its
own
problems,
but
we
we
say:
if
you
want
to
use
json,
you
should
send
it
to
the
collector,
which
will
handle
the
conversion.
A
Yeah,
I
think,
as
javascript
we
have
requirements
that
the
other
sigs
really
don't
have
specifically
around
bundle
size
and
not
wanting
to
bundle
grpc
into
the
browser
and
transports
in
the
browser
being
only
having
limited
functionality
for
good
privacy
reasons,
but
they're
very
limited.
A
I
think
we're
the
only
ones
that
care
about
json
at
all,
and
if
we
don't
make
noise
about
it,
I
don't
think
anyone
will.
So
I
think,
probably
it's
time
it's
been,
it's
been
too
long,
it's
been
experimental
and
I
think
the
specification
was
they
can
they'll
kick
the
can
down
the
road
on
on
stability
for
it
because
they
didn't
know
how
to
solve
like
things
like
the
renaming
issue,
but
I
think
that
the
answer
has
got
to
be
you
just
can't
rename
things
anymore.
A
I
I
do
normally
join
the
spec
sig,
so
I'm
happy
to
bring
this
up
in
the
next
spec
meeting.
I
know
matt,
you
at
least
sometimes
join.
Are
you
planning
on
being
there
next
week.
D
A
D
D
That
I
think
that
was
the
main
main
discussion.
I
was
just
trying
to
kind
of
lobby
from
the
jazz
perspective
that
people
in
the
that
want
to
send
spans
from
the
browser
would
need
it,
but
that
was
mostly
conversation.
I
do
think
so.
The
later
conversation
was
coming
in
maybe
more
on,
like
this
file
format
and
some
questions
going
on
here.
B
Yeah,
I
was
going
to
say,
there's
a
pr
open
to
the
spec
repo
for
a
json
lines,
serialization
format
for
for
like
streaming
otlp.
B
B
Lines
pr,
I
think,
tigran
actually
made
the
issue
that
hey.
We
need
like
some
sort
of
format
for
serializing
to
disk.
E
Yeah,
I
have
a
question
when
we
export
it
to
the
collector
there's
a
in
the
end
point.
We
have
slash
v1
slash
place
right,
so
isn't
it
meant
to
support
breaking
changes
like
if
we
want
to
break
something
we
can
bump
it
to
v2
and
then,
like
users,
will
just
send
to
the
to
the
endpoint
that
supports
the
current
version
like
if
I
thought
that
was
the
whole
point
of
having
this
v1
to
support
breaking
changes.
So
it
is.
A
A
So
none
of
these-
I
don't
think
they
are
considering
you
know,
breaking
changes
they
also
with
json,
explicitly
marked
as
experimental
when
they
break
the
json
protocol.
They
don't
consider
that
a
breakthrough
change
so
in
the
in
the
future
yeah
that's
for,
but
I
think
they're
reluctant
to
start
incrementing.
That
number.
A
It
would
also
mean
that
any
receivers
would
need
to
maintain
parallel
versions,
which
the
collector
definitely
doesn't
do
right
now,
and
I
think
that
they're
trying
you
know
eventually
it'll
have
to
happen.
E
A
Yeah,
well,
we
kind
of
I
think,
made
this
worse
on
our
own
too,
because
we
haven't
updated
the
proto
in
our
javascript
exporters
in
so
long
that
a
lot
of
people
are
using
older
versions
of
the
collector
because,
like
I
know,
starting
with
version
40
of
the
collector,
there
started
to
be
some
problems
with
it
actually
receiving
some
of
the
fields.
A
So
I
know
at
least
the
user
that
I
was
talking
to
decided
to
just
stay
on
the
older
version
on
version
39,
but
that's
obviously
not
a
good
long-term
strategy
and
we
need
to
support
the
latest
collectors.
I
think
they're
on
version
44
or
45
now
and
eventually
we
we
have
to
even
aside
from
the
instrumentation
scope
change.
A
Compatible
so
that
should
be
okay,
but
I
I
think
that
advocating
for
some
backwards
compatible
or
some
json
compatible
change
for
this
instrumentation
scope.
Change
is
a
good
idea
to
at
least
make
noise
about
it.
It's
it's
one
thing.
If
they
say
we,
we
considered
your
opinion
and
we're
going
to
do
this
anyways
it's
different.
If
we
never
say
anything,
and
then
you
know
down
the
line,
we
can't
complain
about.
You
know
there's
when
we
complain
about
something
else.
They'll
say
this
wasn't
a
problem
before.
B
Yep,
I
I
actually
took
another
look
at
that
pr
and
I
think
somebody
opened
a
comment
thread.
Isn't
this
a
breaking
change
already
and
at
first
tiger
was
like
json
form,
format's
not
stable,
but
then
anthony
called
out
that
this.
This
also
breaks
all
the
generated
code.
When
they
do
this
because
you
know
like
when
when
go
or
whoever
regenerates
their
code,
they
have
to
update
because
the
name
will
change
in
in
their
usages,
even
though
it
doesn't
break
the
wire
protocol.
B
A
A
So
I
guess,
as
far
as
what
we
can
do
right
now,
we
should
stay
on
top
of
this
change
and
if
we
can
get
it
done
in
a
backwards
compatible
way,
that's
ideal.
If
not,
then
at
least
we
made
our
voices
heard,
I
suppose,
but
as
far
as
what
we
can
do
right
now,
I
think
we
have
to
hold
back
the
json
version
of
the
exporter
from
going
to
1.0.
A
I
don't
hear
anyone
disagreeing
with
that,
so
I'm
going
to
assume
that
that's
okay,
I,
like
I
said
I'm
already
very
far-
along
and
updating
the
proto
on
our
existing
trace
exporters.
So
I
will
try
to
get
the
pr
open
for
that
today
to
get
us
at
least
up
to
version
13
of
the
proto
which
gets
us
in
line
with
the
latest
collectors
and
stuff
like
that.
So
if
we
do
have
to
make
a
breaking
change,
it'll
be
as
small
as
possible.
A
Okay,
moving
on
to
the
next
item,
there's
a
pr
open
by
legendicus
to
support
multiple
async
callbacks.
I
think
he
opened
it
about
two
weeks
ago
and
it
hasn't
hasn't
gotten
any
reviews,
including
from
myself.
A
So
I
please
review
this.
If
you
have
time,
this
is
a
fairly
important
part
of
the
metrics
sdk,
which
is
nearing
a
usable
state.
So
it
would
be
nice
to
be
able
to
to
have
a
beta
of
the
metrics
in
the
next
few
weeks
here,
and
this
is
one
of
the
things
blocking
it.
B
Yeah
I
took,
I
took
a
quick
look
and
I
didn't
see
it
actually
updating
the
api
to
accept
multiple,
multiple
callbacks,
which
I
think
is.
Okay,
maybe
maybe
there's
going
to
be
a
few
pr's,
but
I
was
wondering
if
you
had
any
idea
what
the
api
change
is
going
to
look
like.
Are
you
going
to
add,
like
a
add,
a
bad
callback
methodology
meter
or
any
ideas.
A
Yeah,
I
think
there
will
be
an
ad
call
back
about
that
on
the
instrument.
If
you
look
at
the
specification,
that
is
actually
an
optional
method,
but
I
think
that's
the
most
obvious
implementation.
A
The
specification
allows
you
to
either
when
you
get
the
instrument
in
the
first
place
when
you
like,
when
you
create
the
counter
to
pass
multiple
callbacks
to
it
or
you
can
have
a
register
call
back
on
the
instrument
itself,
but
actually
both
of
those
things
are
optional.
The
only.
B
Yeah,
so
there's
also
the
multiple
multiple
instruments
for
a
single
callback
thing.
I
don't
know
if
you
remember
that
one,
but
the
example
is
like.
I
want
to
scrape
a
bunch
of
things
from
proc
file
system,
but
I
only
want
to
do
it
once
and
I
want
to
report
against
a
bunch
of
instruments.
B
I
think
I
think
josh
macdonald
was
thinking
you
could
use
the
same
api
for
the
add,
multiple
instruments
for
a
single
callback
and
add
multiple
callbacks
for
a
single
instrument.
But
I
see
what
you
mean
it
does
make
more.
It
does
seem
to
be
more
ergonomic
to
just
have
like
an
ad
call
back
on
the
instrument.
A
B
A
I,
if
there's
a
major
advantage
to
having
those
be
one
api,
I
don't
see
it
and
it
seems
seems
fairly
obvious
to
me
to
have
them
just
be
separate
concepts,
but
maybe
I
I'm
not.
I
haven't
followed
that
part
of
it
as
closely
as
some
other
people
have.
So
I
maybe
just
don't
have
the
context
to
understand
why
that's
an
important
change
or
why
it's
important
for
those
apis
to
be
the
same.
A
A
When
what
es2015
was
added,
the
goal
was
to
have
a
target
that
doesn't
do
any
polyfills,
which
I
think
is
this
issue
yeah,
so
esm
build
results
in
polyfills
for
a
weight,
but
actually
targeting
es2015
does
still
have
some
polyfills
so
targeting
yes,
next
is
the
only
way
to
ensure
that
there's
actually
no
polyfills
in
the
generated
code,
so
he
updated
it
to
from
es2015
to
esnext.
A
A
A
F
Yeah
yeah
the
the
they're
like
based
on
general
usage,
not
documented
of
the
thing
I
agree.
If
someone
is
using
and
targeting
es
esm
2015,
it's
gonna
be
a
problem.
I
I
don't
think
we
have
any
metrics
to
make
that
call
in
terms
of
how
many
people
we're
gonna
break
upgrading
depending
on
what
the
rest
of
their
system
is
using
upgrading
for
me
from
2015
to
next
may
not
be
possible,
depending
on
what
other
packages
that
they've
they've
got
and
why
they're
dragging
it
in
that
way.
A
Yeah,
so
I
think
we
have
two
options
here.
We
can
keep
the
2015
target
and
add
the
next
target
which
increases
our
like.
You
know
the
bundle
size
in
terms
of
like
what
we
actually
upload
to
npm,
but
I
think
does
it
shouldn't
affect
any
actual
browser,
builds
or
anything
like
that,
but
it
is
like
just
kind
of
an
unfortunate
bloat,
a
little
bit
of
the
of
the
package.
F
A
Right
or
we
can
just
update
it
and
say
we
never
made
any.
You
know
stability
guarantees
on
this
anyways
and
then,
if
a
user
opens
an
issue
or
complains
or
whatever,
then
they
have
two
options.
They
can
either
use
es
next
or
revert
to
an
older
version
which
would
potentially
have
more
polyfills
but
be
a
slightly
bigger
bundle.
A
Yeah
we
could,
I
I
just
mean
in
terms
of
like
how
to
get
someone
you
know,
working
by
the
end
of
the
day,
yeah
an
immediate
fix
for
them.
Obviously,
if
somebody
says
I
need
2015
and
has
a
good
reason
for
it,
it's
definitely
something
we
could
add
back,
but
in
terms
of
like
the
day,
they
open
the
issue
or
make
a
comment
in
slack,
I'm
broken.
What
can
I
do
here?
F
A
C
A
A
A
Es
next
will
slightly
reduce
that
bundle
size
by
removing
power
pills.
E
A
A
I
don't
think
many
people
care
that
much
about
it,
but
if
we
continue
to
bloat
it
50
k
at
a
time,
it'll
get
pretty
big,
pretty
fast,
we're
already
a
quarter
of
a
mag,
and
you
know
it's
it's
not
something,
that's
necessarily
important
to
keep
as
low
as
possible
like
very
strictly,
but
I
also
don't
want
it
to
explode
and
get
really
huge.
E
Okay,
I
know
that
node
models
is
usually
like
tens
and
hundreds
of
megabytes,
so
reducing
50k
is
out
of.
It
is
really.
C
A
E
C
A
So
I
guess,
let's
on
this
pr:
let's
try
to
keep
both
of
them
would
not
release
this
yet.
So
I
don't
think
so.
A
Yeah
we
have
so
this
has
been
released
I'll
I'll
comment
on
his
issue
to
to
summarize
our
conversation
here.
He
doesn't
join
these
meetings
because
the
time
zone
is
not
very
convenient
for
him,
but
I
think
I
think
we
should
probably
not
remove
that
2015
target,
because
I
agree
it's
a
it's
a
potential.
C
A
Okay,
in
addition
to
what
we've
already
talked
about
as
usual,
I
have
a
list
of
prs
that
need
reviews,
so
please
review
them
or
if
you
have
a
pr
that
needs
reviews
that
we
didn't
start
to
talk
about,
feel
free
to
add
it
to
the
list.
E
I
added
the
rabbit
mq
instrumentation,
which
is
waiting
for
like
two
weeks.
Yes,
I
know
it's
a
big
piece
of
code
and
it's
a
bit
frightening,
but
it's
only
an
app
store
from
an
existing
code
base
and
this
code
was
running
in
production
for
a
long
time.
A
I
think
we
need
a
better
process
for
that
type
of
I'm
for
when
you're
upstreaming,
something
that's
already
in
production,
because
when
people
review
that
they
don't
necessarily
know
that
and
when
they
request
changes,
they're
requesting
changes
to
something
that
you
already
have
running
in
production
right.
So
this
may
be
more
difficult
to
incorporate
those
changes
and
keep
your
existing
users
in
mind.
So
maybe
we
need
that
specifically
for
up
streaming.
E
A
A
Okay
have
a
good
week,
and
I
will
talk
to
you
all
next
wednesday.