►
From YouTube: 2022-01-19 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
Hello,
everybody!
Sorry
if
anybody
had
any
issues
with
the
meeting
link
that
the
invite
somehow
got
deleted.
So
I
had
morgan
recreate
it.
C
D
New
meeting
invite
does
not
have
a
link
to
this
doc.
Okay,
I
will
let
morgan
know.
B
I
guess
let's
get
started
here.
The
first
item
that
I
have
on
the
list
is
the
otlp
trace
exporters
and
the
release.
As
far
as
I
know,
there's
only
one
pr,
that's
blocking
the
release
for
that.
I
commented
on
the
pr
earlier
to
see
if
the
author
can
update
it.
I
think
yeah,
because
amir
had
a
couple
of
comments
about
the
example,
but
other
than
that.
B
Okay,
so
once
we
can
get
that
that
pr
merged
we
can
release.
So
please
review
that
if
you
haven't
reviewed
it
yet
and
hopefully
the
author
can
update
it
soon.
B
B
Rauno,
you
have
a
issue
here
that
you
created.
Would
you
like
to
talk
about
this.
D
E
Last
last
week,
we
discussed
briefly
discussed
this,
whether
we
should
drop
support
for
eight
node,
eight
and
ten,
and
someone
kindly
suggested
us
to
start
the
discussion
publicly
about
this,
for
especially
for
people
who
do
not
come
to
those
meetings.
Synchronously
and
that's
what
I
did.
B
Yeah,
so
I
saw
that
you
created
this
issue
and
I
tried
to
reach
out
to
some
of
my
colleagues
about
it
and,
unfortunately
they're
all
in
europe,
and
mostly
I've
gone
home
for
the
day
by
now.
So
I
don't
have
like
an
official.
I
guess,
stance
from
dynatrace
as
personally
as
a
maintainer,
though
I
agree
with
this
like
I,
maintaining
the
old
versions
has
been
kind
of
annoying.
B
B
Then
we
don't
have
to
come
continuously
have
this
discussion
in
the
future.
So
I
I
guess
I
in
principle
I
agree
with
you,
I'm
waiting
on
to
hear
from
my
co-workers
to
find
out
if
there's
any
issues
that
I'm
not
aware
of.
F
I'm
just
curious
like
what
yeah,
obviously
supporting
old
versions
of
of
runtimes
can
become
painful.
I'm
just
wondering
there's
any
like
big
wins
by
dropping
like
note
8
or
10
like
is
there.
B
Is
there
so
there's
a
couple?
The
the
most
pressing
one,
I
think,
is
our
browser
like
karma
and
stuff
like
that
that
that
can't
be
updated
like
we
have.
We
have
a
handful
of
packages
related
to
those
types
of
things,
and
I
don't
remember
exactly
what
the
issue
was,
but
we
would,
it
would
definitely
speed
up
the
ci
because
we
would
drop.
You
know
those
branches.
B
So
that's
in
a
you
know,
an
immediate
win,
and
there
are
a
few
packages
like
I
know
in
contrib
there's
some
instrumentations
that
are
instrumenting
packages
that
don't
support,
note,
8
and
node
10.
So
they
need
to
be
skipped
and
it
complicates
the
ci.
I
don't
know
if
ronno,
if
you
have
anything
to
add
to
that.
E
No
not
at
this
point,
but
I
think
it's
it's
just.
You
know
like
a
general
way
to
keep
up
the
like
hygiene
of
the
project
and
not
consider
there
are
some
small
like
changes
to
the
language
that
node
8
doesn't
support
stuff
around
try,
catch
and
promise
support,
for
example.
E
It's
usually
like
easy
enough
fix,
but
I
think,
like
it
shouldn't
be
that
we
have
a
huge
win
dropping
to
support,
but
like
is
there
a
huge
benefit
on
keeping
them
around,
because
once
the
like,
the
next
version
like
at
node
18,
will
be
released
like
we
have
another
one
and
another
one
and
another
one
like
it's.
Probably
I'm
just
recommending
us
to
have
some
kind
of
policy
and
a
rule
around
the
support.
B
B
I
don't
know
if
there's
any
you
know
publicly
available
types
of
usage
stats
for
for
node.js
in
terms
of
just
what
versions
are
currently
in
use,
I'm
sure
there
probably
are
somewhere,
but
I
I
agree
with
the
principle
of
just
not
maintaining
them
forever,
with
no
real,
tangible
benefit.
B
I
guess
let's
leave
this
discussion
open.
You
know
for
for
at
least
a
little
bit.
We
don't
want
to
open
up
open
this
issue
and
then
two
hours
later
make
a
decision.
I
don't
think
so.
Let's
leave
leave
this
open
for
a
little
bit
for
for
some
discussion
and
talk
about
it
again
next
week.
B
Back
to
the
api
1.1
release,
one
of
the
pr's
we
were
waiting
on
was
merged
already
and
there's
one
more
here,
which
has
three
approvals.
I
noticed
this
morning.
Oh
it
looks
like
it
got,
merged
perfect,
okay,
never
mind,
so
these
were
the
three
that
we
were
waiting
on.
B
B
B
Yep,
so
if
we're
happy
with
this,
do
we
want
to
release
this
now
or
is
there
any
reason
to
hold
it
for
any
period
of
time
that
anybody
can
think
of.
B
If
everyone's
okay,
I
think
I'll
just
release
it
and
assuming
things
go
well,
should
be
available
today,.
B
A
A
B
B
B
I
don't
think
it
actually
is
a
problem
if
an
implementation
does
not
use
all
of
the
arguments,
but
I
suppose
before
releasing
it
this
afternoon,
I
can
try
to.
I
can
try
to
install
this
api
version
with
the
existing
sdk
and
make
sure
there's
no
problems
with
it.
H
B
We'll
have
to
update
the
sdk
repo
also
and
the
contributor.
C
A
B
So
one
thing
we
can
do
that
we
used
to
do
in
the
core
repo
is
we
could
release
it
with
the
npn
tag
next,
instead
of
the
latest
and
then
update
the
sdk
and
then
publish
all
the
tags
at
the
same
time,
do
we
think
we
should
do
that
here.
B
B
To
to
bump
the
version
and
just
hold
it
as
a
draft
until
we
release
this.
G
B
B
I'll
create
a
pr
in
the
sdk
repository
as
a
draft
to
update
the
api
version,
and
once
we
get
the
the
exporter
port
pr
merged,
we
can.
B
I
Yeah
I
just
wanted
to
share
some
feedback
on
this
issue.
I
opened
a
draft
pr
and
I
was
able
to
get
some
feedback
from
valentin
and
I
just
wanted
to
share
my
next
steps
and
see
if
anyone
had
any
feedback
on
it
as
well.
I
But
basically,
my
current
implementation
of
the
retries
for
the
http
exporter
won't
work
because
of
a
breaking
change,
because
I
was
trying
to
move
the
batch
spam
processor
timeout
from
the
bat
spam
processor
to
the
exporter,
because
I
was
trying
to
find
a
way
to
end
the
the
retries
within
the
batch
spam
processor
timeouts,
but
then
found
out
that
the
exporter
itself
should
have
a
time-out
variable
according
to
the
spec,
which
is
great
because
I
believe
an
issue
was
open
for
a
2706
to
add
one
of
those
timeouts.
I
I
guess
no
roadblocks
yeah
just
a
status
update
and
if
there's
anything,
that's
kind
of
standing
out
to
you
that
on
this
next
steps
that
I'm
gonna
take,
if
you
think
it
will
work
or
won't
work.
But
basically
the
issue
I
was
having
is
that
my
retry
logic
kept
trying
to
retry.
I
Even
though
the
bat
spam
processor
timeout
went,
went
off
or
fired,
so
I
needed
a
way
to
stop
the
retries
within
a
certain
time.
B
One
thing
we
could
do
is
I
don't
know,
I
guess
it
would
be
a
breaking
change.
I
was
going
to
say
we
could
have
some
sort
of
event,
emitter,
that
that
would
notify
the
exporter
that
it
should
cancel
its
ongoing
operation.
I
Yeah,
I
was
thinking
if
we,
if
the
timeout
variable
that
belongs
to
the
exporter,
so
that
that
default
is
10
seconds.
As
long
as
the
retries
are
within
that
timeout,
then
the
batch
spam
processor
should
be
okay,
because
that's
30
seconds.
B
Right,
but
if
they're
both
configurable,
so
somebody
can
easily
make
it
shorter
on
the
batch
span,
processor
or
longer
on
the
exporter
right
right,
yeah
I
mean
I.
I
think
this
is
a
somewhat
well-known
issue
in
js
and
that
affects
a
lot
of
different
things.
I
guess
there's
there's
two
options
here:
we
we
either
come
up
with
some
way
for
the
span
processor
to
notify
the
exporter
that
it
should
cancel
its
current
operation
or
we
document
it
as
a
known
issue
that
if
the
timeout
expires,
any
ongoing
operations
could
continue.
B
Both
of
them
are
imperfect
solutions.
I
guess,
if
somebody
has
a
better
idea,
I'm
open
to.
J
J
Another
colleague
that's
does
some
work
on
the
java
sdk
and
I've
implemented
this
support
in.net
our
other
colleague
in
java,
and
it's
subject
to
the
same
thing.
At
least
it's
current
implementation
that,
if
the
if
the
export,
if
the
exporter's
timeout
is,
is
set
to
something
greater
than
the
batch
span,
processors
to
time
out,
that's
the
exporter
is
going
to
keep
on
going
on
its
merry
way
with
retries.
If.
J
J
How
would
you
do
do
you
all
have
any
preferences
for
how
this
functionality
is
enabled
in
that?
The
reason
why
I
ask
is
that
there's
no
specification
currently
there's
been
some
discussions
at
the
level
of
specification
about
like
reasonable
defaults
for
rewrite
policies
and
so
on,
but
nothing's
been
settled
on
yet
so
you
know
like
I
said
we
have
some
colleagues
working
on.net
and
java.
We've
come
up
with
what
we
believe
to
be
reasonable
defaults,
but
enabling
this
functionality
is
kind
of
like
a
hidden
config
switch.
J
Currently
the
specification
yeah
you're
looking
at
here,
I
think
it's
down
at
the
bottom
does
say
it
should
retry
the
retry
retry
must
be
supported.
I
think
it's
all
the
way,
maybe
at
the
bottom
of
this.
D
J
B
Are
doing
or
if
they've
handled
this
at
all,
you
seem
a
little
bit
more
aware
of
net
and
java
than
I
am
maybe
matt
can
speak
to
ruby.
B
Yeah,
it
would
be
nice
to
know
what
the
other
sigs
are
doing
here,
but
even
more
than
that,
it
would
be
better
if
it
was
specified
which
it
clearly
just
isn't
right.
Now,.
B
Is
there
currently
any
retry
I
know
svetlana
is,
is
implementing
retries,
but
there's
no
current
implementation
right.
The
you're
you're
coming
up
with
a
full
new
implementation,
correct,
yeah,
okay,
I
guess
let's
look
at
what's
what
the
other
cigs
are
doing.
Ideally,
this
would
be
specified,
but
maybe
there's
a
reason.
J
B
It's
not
specified.
J
I
can
share
I'll
do
it
after
the
meeting,
but
I
can
share
that
some
of
the
conversations
there
there's
issues
out
there.
I
would
take
me
a
little
bit
to
find
them,
but
there's
some
issues
about
discussions
at
the
spec
level
on
this
that
are
yet
to
be
resolved
and
also
I
can
share
the
java
and
the
net
implementations
yeah.
Maybe
on
svetlana's
issues,
just
for
you
for
your
guys's
awareness.
B
So
it
does
say
it
must
be
exponential
and
there's
a
timeout.
So
I
guess
if
we
just
say
one
second,
two.
Second,
four.
Second,
eight.
Second,
if
we
just
double
it
every
time
until
you
hit
the
timeout
or
something
like
that,
that
would
be
a
reasonable
solution.
I'd
like
to
see
what
the
other
with
the
other
implementations,
are
doing,
that.
B
Yeah,
I
don't
really
have
anything
else
to
add
to
this
right
now.
Does
anybody
else.
B
Yeah,
I
believe
that
this
retry
implementation
specification
is
specifically
for
the
the
open
telemetry
protocol
exporters.
So
I
don't.
I
don't
think
this
affects
like
the
zipkin
or
the
jaeger
exporter.
B
Okay,
so
I
guess
alan,
you
said:
you'll
link
some
of
the
specification
discussion
and
if
it's
easy,
can
you
also
look
into
what
what
net
and
java
are
currently
doing?
Yep
yep
I'll
share
that
I'll
share
it
on
the
issue,
maybe
yeah
on
the
issue.
It
would
be
great
or
you
can
add
it
to
the
doc
or
both
whatever.
Whatever
is
easier
for
you,
I
guess
the
issue
is
a
little
bit
easier
to
more
searchable.
B
I
I
did
want
to
bring
up.
The
second
issue
is
with
the
grpc
exporter.
B
I
D
B
B
So
it's
not
a
client
error
and
if
you
use
the
grpc
scheme,
you
don't
run
into
issues
correct
correct.
B
B
So
maybe
it
would
be
okay
for
us
to
just
completely
ignore
the
scheme.
I
can't
say
whether
or
not
without
looking
into
the
code
a
little
bit.
Is
there
an
issue
for
this?
Have
you
created
an
issue,
or
can
you
create
one.
B
Yeah,
I
I
would
appreciate
it
if
you
could
create
an
issue.
I
I
just
can't
remember
enough
about
the
implementation
right
now
to
to
have
anything
really
intelligent
to
say
about
it.
I
A
A
B
Yeah
so
yeah,
I
appreciate
it
if
you
would
create
an
issue
and
we
can
look
into
it.
A
little
bit
more,
I
think,
ignoring
the
scheme
in
the
future
is
probably
going
to
be
an
acceptable
solution,
though
just
because
I
think
grpc
only
works
over
http
2,
so
it's
not
like
you
can
put
a
different
scheme
in
there
and
expect
it
to
work
and
we're
not
using
the
scheme
for
anything.
B
K
B
I
did
add
a
few,
so
there's
a
new
pr
here
from
legendicus,
which
is
adding
web
worker
support
by
removing
the
use
of
some
apis
that
are
not
available
within
web
workers,
and
this
is
something
we've
talked
about
in
the
past.
I
suspect
that
at
least
nev
is
interested
in
this,
but
probably
others
as
well.
B
There
are
two
new
bugs
that
have
been
created
here.
I
haven't
really
looked
too
much
into
either
of
them,
but
the
first
one
here
is
call
stack
size
exceeded
in
the
otlp
http
exporter.
L
Yeah,
I
think
this
actually
should
be
marked
as
an
enhancement
rather
than
a
bug,
so
they're
exclusively
talking
about
handling
circle
dependencies
so
and
they
want
to
be
able
to
say
okay,
I've
got
an
object
which
has
a
link
back
to
some
other
parent
object.
L
It
referenced,
I
don't
know,
but
you
can
see
that
what
did
you
do?
Sometimes
nested
libraries
or
us
may
generate
objects
with
circular
object
references,
so
it
would
be
awesome
if
and
yes
it
would,
but
we
get
a
whole
bunch
of
do
we
just
drop
it.
Do
we
put
in
a
tag
saying,
dropped
but
yeah?
I
don't
necessarily
think
it's
a
bug,
but
it's
probably
something
we
should
consider.
B
B
Yeah,
I
think
the
q
collector
any
value
does
use
just
a
basic.
I
don't
think
it's
jason
stringify.
I
think
it's
just
the
string
constructor.
I
guess
I'll
ask
for
a
little
bit
more
info
here,
but
I
agree
if
that's.
B
B
Jager
exporter
filters
out
links
having
a
different
link
span.
Id
I've
also
not
looked
into
this
since
I
haven't
really
been
here
at
the
beginning
part
of
this
week.
Does
anyone
have
any
thoughts
on
this
or
looks
like
it's
quite
a
long
this
year.
A
I
looked
at
it
and
it's.
It
seems
that
we're
not
a
transforming,
transforming
links
correctly
in
a
jager
exporter.
I
B
C
B
It's
always
hard
to
dig
back
through.
I
I
can
try
to.
I
won't
do
this
while
we're
on
the
call.
I
can
try
to
dig
back
and
see
why
that
was
added
in
the
first
place,
or
at
least
who
added
it.
So
I
can
ask
them
if
there's
a
reason
for
it,
but
is
there
anybody
that
that
wants
to
take
on
this
issue
that
I
can
assign
this
or
should
I
leave
it
unassigned
for
now.
B
B
These
are
the
pr's
and
issues
that
were
marked
stale
by
the
bot
in
the
last
week,
so
I
want
to
go
through
them
and
see
if
we
should
leave
them
as
stale
or
if
we
should
mark
them
as
not
stale,
so
we'll
just
go
through
them.
One
by
one
here
allow
instrumentations
to
be
extendable,
looks
like
this
was
created
a
pretty
long
time
ago
and
has
not
had
any.
E
K
Okay,
yeah,
I
was
at
the
time
I
I
remember
this.
B
And
yeah,
I
I
can't
think
of
a
reason
not
to
so
I
guess
I'll,
remove
the
scale
label
here.
B
Should
we
mark
this
as
never
stale,
I
mean
it's
a
it's,
an
enhancement
that
won't
you
know.
Time
doesn't
make
this
one
go
away.
I
don't.
B
B
Don't
we
use
like
the
beacon
api
to
to
send
these
shouldn't
they
be
sent?
It
looks
like
martin
asked
for
more
information
the
day
that
this
issue
was
created
and
none
was
none
was
given.
L
Yeah,
I
think
I
stumbled
over
this
at
the
end
of
last
year,
there's
during
the
unload
process.
L
B
B
Sense
so
you're
saying
that
the
batch
span
processor,
once
we
receive
an
unload
event,
should
go
into
essentially
simple
processing
mode,
correct
yeah.
It
should
just
start
throwing
them
out
the
door
yep
yeah.
That
seems
obvious
enough.
I
also
think
that
that
probably
falls
under
the
umbrella
of
feature
request,
though,
and
not
a
bug.
I
agree.
Yeah.
L
L
We're
not
capturing
necessarily
all
the
unload
events.
We
probably
need
to
be
looking
at
the
visibility
change
for
hidden
because
there
are
some
states
in
chrome
where
you'll
actually
never
get
to
before
unload
on
a
mobile
device.
L
B
Okay,
is
there
anybody
that
I
can
assign
this
to,
or
should
I
add,
the
up
for
grabs
label
here.
B
Okay,
eager
exporter,
cash
is
sender.
I
remember
this
one
too,
this
is
the
the
yeager
exporter
is
cashing
the
resource
so
that,
if
spans
that
come
along
later,
have
a
different
service
name
they're
exported
with
the
previous
service
name.
So
I
think
at
the
time
we
had
just
decided
not
to
cash
the
resource,
there's
no
real
benefit
of
doing
that
in
the
exporter,
but
I
think
this
was
just
never
handled.
B
I
think
that
probably
we
do
not
want
this
to
be
closed,
because
I
think
we
do
want
to
handle
this.
B
I
can't
I
I
don't
remember
this
well
enough
to
make
that
decision
right
now,
but
for
now
I
guess
I
will
just
look
into
this
after
that
after
the
meeting
here.
B
B
B
B
It
looks
like
the
the
person
that
created
this
issue
did
not
create
a
pr
I
will
assign
this
to
myself
for
now,
but
I
will
reach
out
to
valentine
and
see
if
he
has
time
to
do
that.
B
Okay,
then,
I
guess
everybody
have
a
good
week
and
I
will
talk
to
you
next
wednesday.