►
From YouTube: 2022-03-02 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
C
B
Yeah
well,
this
link
is
not.
This
is
back
to
the
old
style
link
that
we
were
using
before,
so
it
shouldn't
change,
and
that
means
we
can
put
it
back
in
the
document
instead
of
having
to
go
to
the
calendar,
which
is
nice
and
also
it
worked
for
a
long
time
before
so
I
don't
see
any
reason
it
should
break,
but
I
didn't
see
any
reason.
The
other
type
of
link
should
have
broken
either.
So
what
do
I
know.
B
I
have
a
lot
of
little
items
on
the
agenda
today.
I
don't
expect
many
of
them
to
take
very
long.
So
if
you
guys
have
anything
to
put
on
the
agenda,
feel
free.
E
I
just
wanted
to
say
hi
to
everyone
just
quickly
introduce
myself.
My
name
is
martin
and
I'm
from
new
relic
and
I'm
working
in
the
client
side
sig,
where
we're
trying
to
figure
out
how
to
improve
the
telemetry
for
for
client-side
applications
like
mobile
and
browser.
B
Yeah,
I
would
expect
there
to
be
overlap.
I
think
I've
seen
you
around
in
other
cigs
for
a
while,
but
it's
good
to
have
you.
E
D
I
am
kind
of
new,
I
recently
joined
shopify
and
am
the
manager
of
our
instrumentation
team.
There.
We
have
a
lot
of
contributors
more
on
the
side
of
hotel,
ruby
and
I'm
hanging
out
to
get
involved
more
on
the
js
side.
B
Can
you
see
it?
Yes,
okay,
yeah,
so
first
agenda
item
you
guys
all
obviously
know
by
now
the
meeting
link
is
working.
I
put
it
in
the
document
because
it
should
no
longer
change,
so
we
don't
have
to
go
to
the
calendar
every
time.
B
There
is
a
pr
open
for
the
for
refactoring
the
metric
export
data
structure.
He
just
opened
it
a
couple
of
days
ago,
but
this
is
a
fairly
important
pr.
That's
blocking
a
lot
of
the
things
in
our
metrics
export
pipeline,
so
it
blocks
the
exporters
from
being
updated
for
the
new
sdk
and
it
blocks
the
otl
t
transformer
pr
that
we'll
talk
about
in
a
little
bit
here.
So
I
would
appreciate
reviews
on
that.
If
people
have
time.
B
B
So
it's
like
a
an
object
of,
I
think
it's
called
instrumentation
library
metrics,
which
has
an
instrumentation
library
and
then
a
resource
metrics
object
and
that
resource
metric
metrics
object
has
a
resource
and
a
list
of
metrics,
because
the
data
structure
is
a
little
bit
more
close,
look
close
to
the
protocol.
It
should
be
easier
to
write
the
otlp
exporters
too,
which
is
nice.
B
There
is
a
release
pr
open
in
contrib.
I
would
have
already
merged
it,
except
that
I
can't
merge
it
without
a
without
a
review.
So
I
would
appreciate
it
if
people
could
give
that
a
review
and
we
can
release
can
drip
today.
B
B
Yep,
okay,
there
is
a
pr,
that's
actually
been
reviewed
for
the
amtp
lib.
It's
been
reviewed
by
a
couple
of
people.
I
know
amir
just
said
a
couple
of
days
ago
that
he's
gonna
leave
this
open
up
for
a
week
so
that
people
can
review
it
if
they
are
interested
and
have
time.
So
I
just
wanted
to
let
you
all
know
it's
there
if
you're
interested
in
amtp,
that's
probably
a
good
one
to
look
at
this
is
the
first
pr
that
I
have
questions
about.
B
B
My
question
is:
does
anyone
know
how
high
cardinality
that
would
be
expected
to
be?
I
don't
know
in
graphql
what
type
of
cardinality
field
names
are
expected
to
have
I
mean?
Are
you
saying
no.
F
B
Yeah,
so
I
asked
the
question
in
the
pr
here:
you
know
it's
18
days
old
and
hasn't
been
reviewed,
so
I
figured
we
need
to
at
least
you
know
acknowledge
it
to
this
author
and
then
the
same
thing.
This
issue
he
linked
is
a
really
old
issue.
It's
actually
been
marked
stale
and
then
unstale
twice.
B
B
Okay,
so
this
is
another
one
of
the
metrics
pr's
that
we've
been
working
on
for
a
while.
Phogenic
has
opened
this
about
two
weeks
ago.
I
I
reviewed
it
this
morning
and
it
looked
good
to
me,
but
it
is
a
fairly
large
change,
so
I
would
like
to
have
multiple
reviewers
review
it
if
at
all
possible,
I
understand
it's
large
and
complex,
so
I
know
that
not
everybody
feels
all
that
comfortable.
Reviewing
the
the
really
gritty
details
of
the
metrics
sdk,
but
I
would
appreciate
at
least
a
few
eyeballs
on
it.
B
This
timeout
pr,
I
believe,
is
svetlana
right
or
yeah
yeah.
I
was
just
asking
for
reviews
here
svetlana.
Do
you
want
to?
Let
us
know
what
sort
of
state
this
pr
is
in?
How
close
do
you
think
it
is
to
being
merged?
Well.
C
I
fixed
all
the
tests
yesterday
and
had
made
merged
into
this
branch,
and
I
guess
there's
just
one
test
failing
the
code
patch
test,
but
everything
else
is
ready
to
be
merged
unless
other
people
have
feedback.
First.
B
B
It
probably
just
means
that
something
that
you
added
doesn't
have
a
test.
Would
typically,
we
don't
block
prs
for
that
kind
of
thing,
unless
it's
really
bad
and
yours
seems
okay,
but
I'll.
Take
a
closer
look
at
that
after
the
call.
C
Okay,
I
did
have
a
kind
of
a
basic
question
about
tests,
so
I
was
fixing
a
bunch
of
tests
because
my
change
was
was
a
pretty
major
change
that
broke
a
bunch
of
other
tests,
and
I
saw
that
different
tests.
They
were
testing
different
pieces
of
the
exporter,
but
they
were
the
same
test
but
written
in
different
ways.
C
So
my
question
is:
if
you
see
that,
should
you
just
try
to
make
those
tests
the
the
same
way
so
so
they're
more
consistent
or
should
we
just
leave
it
as
is,
and
try
not
to
change
it,
because
then
people
are
just
going
to
keep
changing
it
back
and
forth.
B
I
don't
have
a
good
answer
for
that.
I
guess
they're,
probably
because
they
were
written
by
two
different
people
that
just
had
two
different
styles.
I
guess
can
you
point
me
to
exactly
like
an
example
in
here
of
what
you're
talking
about.
C
Yeah,
like
so
there's
a
test
in
the
proto
exporter,
I
believe
it
was
the
collector
trace
exporter
test
file
or,
if
you
could
do
it
like
a
page
search
for
it
for
that
file.
C
Yeah,
so
if
you
look
on
the
right
screen
line
152
I
mean
on
the
right
side
line
152.
It's
writing
a
test
that
way
stubbing
it
and
then
calls
fake.
So
that's
one
way
to
call
it
and
it
works
fine.
But
then
the
http
exporter
has
the
same
exact
test
except
it's
written
differently,
but
it's
testing
the
same
thing.
C
No,
I
just
I
just
wanted
to
check,
because
I
wanted
to
first
see
if
it's
worth
it,
because
I
don't
want
to
change
and
then
have
to
change
it
back,
but
the
same
test
file.
The
collector
trace
exporter
has
those
same
tests
in
the
http
exporter,
they're
they're,
just
written
in
a
slightly
different
way,
but
they're
testing
the
the
same
thing,
and
I
just
wondered
if
it's
worth
up
updating
those
tests
to
be
more
con
consistent
or
should
we
just
leave
them,
as
is
because
they
work
fine.
B
And
do
you
know
what
line
number
we're
looking
for?
Oh.
B
140,
oh,
I
see
you
yeah.
These
are
done
with
the
set
timeout
instead
of
the
sign
on
so
these
types
of
stylistic
things
I
don't
think
would
typically
block
a
pr,
and
if
you
updated
it
to
be
more
consistent,
then
I
don't
think
that
anyone
would
change
it
back.
You
know
I.
I
don't
think
that
that
would
be
a
worry.
B
Personally,
I
prefer
like
the
the
sign
on
test
style,
but
obviously
you
know
two
different
test
files
written
by
two
different
people.
They
just
had
a
different
style.
I
guess
I
would
say
it's
up
to
you.
If
you
want
to
update
it,
then
go
ahead.
I
don't
think
anybody
would
complain
about
that.
B
So
the
the
otlp
trace
exporters
we've
been
trying
to
release
as
1.0
for
a
while.
There
are
only
a
couple
things
blocking
it
right
now.
The
big
one
is
that
the
json
exporter
needs
to
be
moved
back
to
experimental
and
I
just
didn't
get
around
to
that
this
week.
So
I
will
try
to
do
that
this
afternoon,
but
I
think
we
also
in
this
otlp
transformation
pr.
B
We
need
to
determine
how
to
deal
with
this
changing
field
name,
because
if
we
release
this,
then
the
field
name
can
change,
and
then
we
have
to
bump
the
major
version
one
way
to
get
around.
That
would
just
be
to
release
this
as
experimental,
and
that
way
we
can
bump
the
version
more
easily
without
worrying
about
it.
But
then
the
stable
exporters
are
depending
on
a
experimental
package
which
we
have
tried
not
to
do.
B
I
don't
think
we
have
any
places
right
now
where,
where
1.0
packages
depend
on
any
experimental
packages,
I
don't
know
if
anyone
has
any
ideas
on
how
we
can
how
we
can
get
around
this,
or
I
guess
amir
you're,
the
only
other
maintainer
on
the
call
here.
How
would
you
feel
if
we
decided
to
have
the
exporters
depend
on
the
external
or
on
an
experimental
transformation
package.
A
F
Isos,
let's
see,
there's
a
link
to
it.
I
believe
in
here
I
checked
the
piano.
I
didn't
see
any
reference.
A
You
didn't
see
any
reference
where
actually
there
are
multiple
pros
for
that
and
I
checked
one
of
them
and
I
didn't
see
that
they
are
aware
of
the
problems
for
the
http
json
exporter.
So.
F
B
There
was
a
yeah,
so
this
thread-
let's
see
mad
viking
god
here,
I
guess
brought
up
that
it
might
be
a
breaking
change,
and
this
is
where
all
the
conversation
happened
was
in
this
thread.
Let's
see
aneurysm,
this
is
anthony
from
aws.
B
B
B
After
this
change
yeah,
so
this
name
change
is
going
to
happen
and
then
tigran
wants
to
go
through
one
more
round
where
he
looks
at
the
names
and
changes
any
names
that
that
don't
make
sense
or
that
need
to
be
changed
and
then
mark
it
as
stable
after
that,
and
we
can
wait
for
that.
But
then
we're
waiting,
probably
a
few
more
weeks
before
we
can
release
the
trace
exporters.
A
A
A
B
Yeah,
I
it's
been
reviewed
by
only
legend.
B
I
think
he
approved
it,
but
that
was
a
while
ago,
and
I've
made
some
changes
since
then
so
yeah.
Definitely
it's
not
a
complicated
pr.
It
is
fairly
long.
There
are
a
lot
of
files
and
such,
but
it
is
a
relatively
like.
Most
of
them
are
because
it's
a
new
package
like
it's
all
the
testing
files
and
the
karma
files
and
all
that
stuff
in
terms
of
actual
code,
there's
only
a
few
files
that
really
matter
and
they're
not
that
long,
and
they
are
not
that
complex.
B
So
I
think
it
should
be
relatively
straightforward
to
to
review
but
yeah
I've.
A
B
That
was
all
I
had
to
say
about
that
pr.
Does
anyone
have
any
questions
about
that
or
other
concerns
that
that
I'm
not
thinking
about
here.
A
I
have
just
a
question:
why
do
we
do
it
like
a
hand,
roll
and
not
generating
the
code
from
the
portal
files.
B
If
we
generate
the
code
from
the
profiles,
so
we
probably
will
use
generated
code
for
the
proto
for
the
actual
proto
serialization,
but
this
package
only
does
the
transformation
required
to
be
the
input
to
the
generated
code?
A
B
Separate
it
so
that
we
can
only
deploy
this
code
to
browsers,
because
if
we
include
all
the
proto
code,
like
all
that
static
protocol
for
the
browsers,
it
was
a
huge
package,
I
think
even
minified
when
it
was
bundled
and
stuff
it
was
like
60
or
70k
and
with
the
just
the
transformations
here.
It's
like
single
digit
k.
A
B
Okay,
there
are
a
few
metrics
pr's
here
that
are,
you
know,
high
priority
for
the
new
metrics
sdk,
so
I
need
reviews
on
them
whenever
anybody
has
time
andy
instrumentation
examples,
dependency,
update,
question,
go
ahead
and
ask
your
question.
D
Yeah,
so
I
was
working
with
one
of
the
instrumentation
examples,
specifically
the
express
and
koa
ones,
and
they
are
depending
on
point
two.
Five
of
the
instrumentation
package.
D
You'll
have
to
forgive
me
because
I'm
kind
of
catching
up
with
status
of
releases
and
stuff,
but
there's
a
field
that
was
specifically
like
that's
currently
deprecated
but
wasn't
deprecated
in
the
version.
That
was
in
the
example,
and
so
I
was
just
partly
curious
about
like
how
we
update
these.
B
Yeah,
so
only
some
packages
have
been
released
as
1.0.
I
think
it's
1.0.3
now,
no
that's
the
api
1.0.1
for
that
for
the
sdk,
but
there's
only
some
packages
that
have
gone
to
1.0
the
rest
are
still
at.
I
think
0.27
and
you
can
tell
the
difference
when
you're
looking
at
the
js
repo
anything
in
the
packages
directory
is
1.0
and
anything
in
the
experimental
directory
is
0.27.
D
Gotcha
and
instrumentation
is
inside
experimental.
It
is
experimental,
yes,
okay,
cool.
B
I
think
until
the
instrumentation
sig
determines
you
know
what
the
stability
guarantees
are
for
a
1.0
instrumentation.
We
kind
of
can't
stabilize
that
because
we
we
don't
want
to
have
something
released
as
1.0
and
then
have
the
instrumentation.
Sig
say
these
are
the
guarantees
for
something
that's
1.0
and
something
that
we
didn't
initially
think
about
when
we,
when
we
were
releasing,
it
got
it.
I
think
that
is
most
likely
to
happen
this
summer,
but
I'm
not
that
plugged
into
the
instrumentation
seg.
So
I
don't.
I
don't
exactly.
D
Know
that
makes
sense,
so
in
theory,
it
would
be
updating
those
packages
to
0.27
instead
of
0.25,
as
opposed
to
like
the
instrumentation,
isn't
actually
released
at
1.0.
Okay,
that
makes
sense.
So
what
is
the
typical
process
for
doing?
That?
Is
that
something
we
automate.
D
B
Any
way
right
now,
the
examples
are
usually
pretty
out
of
date,
just
because
we
make
updates
and
packages
and
the
examples
are
not
a
high
priority
at
that
time,
and
then
it's
just
not
something
that
we
that
we
do
one.
There
have
been
various
proposals
to
solve
this
in
the
past.
B
I
don't
think
anyone's
even
attempted
to
actually
do
anything
about
it
yet,
but
one
thing
I
think
that
we've
talked
about
a
few
times
and
that
everybody
seems
to
generally
agree
would
work
is
to
move
all
the
examples
into
the
directories
of
the
packages
that
they're
showing
the
example
of
so
instead
of
being
this
top
level
examples
folder
it
would
be
in
the
koa
package-
would
have
an
example
folder
and
then
just
reference.
B
You
know
the
instead
of
installing
coa
from
npm.
It
would
just
reference
the
local
version
of
it,
which
would
make
it
very
easy
to
just
run.
You
know,
typescript,
compile
and
see.
If
you
broke
anything
yeah,
that's
really
easier
to
keep
them
up
to
date,
and
then
maybe
we
could
automate
that
as
a
part
of
the
ci
just
to
check
to
say,
hey
the
example
broke.
You
need
to
look
at
this.
D
D
B
Yeah,
I
would
definitely
appreciate
that,
and
then
I
think
it
probably
does
still
make
sense
to
have
a
top
level
example,
but
instead
of
showing
an
example
for
an
individual
package
or
something
like
that,
it
would
just
probably
show
here's
how
you
would
set
up
an
instrument.
Yeah
yeah.
F
D
B
Perfect,
I
appreciate
it,
that's
something
I
think
that's
been
tickling
the
back
of
our
brains
for
a
really
long
time.
Everybody
realizes
it's
problem,
but
nobody
seems
to
have
time
to
tackle
it.
B
All
right,
I
appreciate
your
time.
Then
anybody
else
have
something
they
want
to
bring
up
today.