►
From YouTube: 2021-04-22 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
A
All
right
well
laden
fixes
cereal,
please
everybody.
D
Yo,
can
you
guys
hear
me?
We
can't
hear
you
louder.
Oh
nice,
nice,
hey!
What's
up
guys
right
here,
all
right,
yeah,
so
alex
isn't
here
today
looks
like
there's
some
items
on
the
agenda,
but
I
don't
think
it
will
be
a
long
meeting
today.
As
diego
said,
can
you
guys
you
know
if
you
could
add
your
name
to
the
attendees
list?
D
It
also
looks
like
mzeremba
in
the
in
the
zoom
chat.
I
don't
know
if
you've
ever
been
joined
one
over
six
before,
but
I
don't.
I
don't
recall
seeing
your
name
before
unless
if
you
you
joined
last
week,
I
wasn't
here.
D
Also,
if
you're
talking
like,
I
don't
think
I
could
hear
you,
anybody
else
can
hear
him
nope
all
right.
He
just
he
just
left
all
right,
cool
scared,
him
away
nice
anyways
cool.
I
guess
we
could
just
get
started.
Then
let
me
show
you
my
screen.
D
D
Things
went
pretty
smoothly
this
time.
I
think,
as
the
maintainers
were
kind
of
getting
used
to
doing
this,
maintaining
two
of
these
versions
at
the
same
time
and
contribute
was
pretty
straightforward.
I
think
this
time
it
was
pretty
smooth
because
we
didn't
have
any
last
minute.
Pr's
that
went
in
and
you
know
no
new
folders
were
created
that
up
the
build
script
or
anything
so
yeah,
it's
pretty
cool.
D
Secondly,
I'm
going
to
be
starting
to
move
open,
telemetry,
instrumentation
folder
to
the
contrib
repo.
I
believe
we
did
talk
about
this
a
while
ago.
It's
just
that.
You
know
I
didn't
have
the
time
to
do
this
with
the
with
the
stable
release
and
everything,
but
I
think
now
that
since
we're
seeing
a
lot
more
traction
in
the
contrib
repo
as
well
as
you
know,
things
are
getting
more
stable
in
core.
You
know
it'd
be
good
to
do
this
as
well.
D
It
also
will
like
remove
one
more
point
of
like
confusion.
I
guess
within
the
core
repo
since
open
telemetry
instrumentation
is
in
the
beta
version,
but
everything
else
is
in
the
1.1,
so
I
think
that'd
be
good.
Does
anybody
have
any
objections
to
this
or
strong
arguments
for
me
doing
this.
D
I
don't
think
so,
though,
like
the
the,
I
think
the
terms
are,
but
there's
nothing
in
terms
of
like
implementation,
details
or
like
what
we
should
do.
Besides
for
the
semantic
conventions,
I
guess
yeah.
A
What
I
know
is
that
old
tape
or
tap
one
is
instrumentation.
So,
but
I'm
not
sure
if
that
means
the
instrumentation
should
live
in
the
main
regal.
D
C
D
Semantic
version-
that's
it
yeah
cool,
any
other
comments
of
this
before
moving
on.
D
Nice,
okay,
cool
last
thing
I
want
to
talk
about,
is
alex
and
I
have
been
doing
a
lot
of
issue
triaging
within
the
past
few
weeks.
I
saw
shakanth
doing
some
of
them
too.
So
you
know
thank
you
for
that.
D
We
kind
of
narrowed
down
a
bunch
of
our
issues,
especially
because,
like
we
have
this
bot
now
and
we
didn't
want
to
be
closing
off,
like
you
know,
prs
we
didn't
want
to,
but
we
also
do
want
to
close
a
lot
of
pr's
that
have
been
stale,
so
we
kind
of
like
looked
through
all
of
them
saved
like
the
first
half
except
the
first
half
of
the
first
page,
because
it's
most
recent,
so
yeah,
so
everything
is
like
up
to
date,
now
feel
free
to
like
pick
up
stuff.
D
If
you
find
them
relevant
to
your
need
and
yeah,
we
do
have
like
some
tech
debt.
You
know
a
lot
of
like
good
to
haves,
feature,
requests
and
stuff,
but
you
know
it's
up
to
your
discretion
cool
many
questions
on
that.
D
I
think
we're
doing
pretty
good.
It's
like
77
issues
now
and
contrib,
not
too
bad,
either
yeah
yeah,
so
we're
definitely
getting
a
lot
more
activity
and
could
trip
after
the
release.
So
pretty
good
nice
all
right.
Moving
on
ego
release,
2.0,
oh
boy,
all
right
go
ahead!.
A
Yes,
so
for
this
week's
dose
of
controversy,
how
about
we
release
2.0
and
break
everything
I'm
just
kidding,
so
what
I
mean
is
this:
I
opened
this
pr
1768
later
on.
If
you
can
share
that
in
your
screen,
please.
A
The
one
in
the
middle
all
right,
so
I
took
a
look
at
these
at
our
code
and
I
realized
that
we
have
a
bunch
of
stuff
that
is
public,
but
it
should
not
be
or
it
is.
A
It
is
or
their
symbols
are
not
pepe
compliant,
but
that's
a
relatively
minor
issue
and
some
stuff
like
that.
Also
yesterday,
I
noticed
that.
Can
you
go
to
main
please
and
yeah
if
you
go
to
exporter
folder
exporter,
yes,
otlp,
yep,
src,
stuff,
open
tournament,
exporter
or
tlp
yeah,
if
you
can
see
that
we
have
a
module
here,
that
does
not
have
any
anything.
I
mean
nothing
that
we
can
import
from
it
from
its
version.
A
So
this
pretty
much
is
just
like
that
code,
but
it's
part
of
the
public
api
right
now.
So
in
order
for
us
to
remove
this,
we
will
kind
of
need
to
break.
I
think.
D
D
I
don't,
I
don't
think
this
folder
was
dead
code.
This
was
explicitly
done
because
we
wanted
to
split
up
the
exporter
folders
into
different
packages.
It
just
so
happens
right
now
that
we
only
support
one
protocol,
which
is
grpc,
but
in
the
future
we
might
have
others.
So
users
who
want
all
of
the
protocols
would
just
install
this
one.
D
E
D
It's
like
you
know
like
I
don't
want
to
have.
You
know
thrift
related
libraries,
so
I
only
installed
this
one
and
vice
versa,
but
if
I
want
all
of
them,
I
installed
this
one:
okay,
yeah.
A
Yeah
I
just
realized
when
I
was
working
on
some
code
of
mine,
that
I
had
to
change
the
paths
in
some
application
code
that
I
have
because
the
trace
exporter
module
of
otop
was
now
placed
elsewhere,
but
I
don't
I
don't
know
if
that
was
done
before
or
after
the
one
over
or
release.
A
Well.
In
any
case,
what
I
have
seen
is
that
my
main
point
is
this:
we
have
some
public
stuff
that
should
not
be
public
in
order
for.
G
A
To
change
that
either
to
remove
that
or
to
make
them
private,
we
will
need
to
upgrade
our
major
version
to
be
very
strict.
I
don't
know
if
that's
convenient
for
practical,
probably
not
the
thing
that
I
have
added
in
these
pull
requests
is
a
script
that.
A
Looks
around
over
code
and
finds
the
public
stuff.
So
if
you
can
go
to
install
json
you'll
find
resources
in
there.
Please.
A
There
we
go
yeah,
that's
all
right,
yes,
sir.
Yes,
so
that
file
resolve
json
is
the
output
of
that
this
script.
That
shows
us
all.
The
public
symbols
that
we
have
in
every
module.
So
a
couple
of
things
we
could,
as
I
said,
like,
incorporate
all
these
changes
and
release
to.
A
2.0,
but
probably
that
will
be
controversial
and
confusing
and
stuff,
or
I
think
that
we
can
at
least
incorporate
this
into
our
ci,
maybe
so
that
every
time
there's
a
request,
the
script
is
run
and
the
user.
That's
trying
to
get
this
request
in
is
made
aware
of
all
the
public
stuff,
that's
being
added.
G
A
D
I
think
the
adding
to
the
ci
is
a
good
idea.
You
know
we
want
to
prevent
or
like
mitigate
this,
our
api
service
from
increasing
any
further
yeah.
I
don't
know
the
answer
to
releasing
a
new
major
version.
Yo,
though.
D
D
Not
doing
it,
but
I'm
interested
to
hear
what
other
people
think.
A
Yeah,
if
I
just
may
add,
I
think
that
the
this
stuff
that
we
have
in
our
public
api
that
should
not
be
there.
It's
not
that
big
of
a
problem
right
so
far.
So
far
right
I
mean
because
our
our
project
is
relatively
new
and
this
problem
has
not
grown
too
much,
but
I
think
that
if
we
don't
do
something
to
put
this
under
control-
and
we
will
have.
A
C
A
All
right,
so
I
don't
know
if
somebody
else
has
something
to
say
about
this,
but
what
I
can
do
with
this
cpr
is
transform
it
into
a
pr
that
just
includes
this
script
into
ci.
Some
in
some
way
I'll
have
to
investigate
how
to
do
that
right.
A
Then
I
guess
we
will
stay
in
one
one
point,
one,
our
time
being
forever
forever.
Hopefully,.
B
F
Yeah
I
was
going
to
punch
in
real
quick.
Has
anybody
ever
used
anything
like
these,
like
this
deprecation
package?
There's
probably
others,
but
it
basically
gives
you
like
decorators.
F
So
you
can
say
when
things
are
deprecated
and
you
can
easily
find
all
the
deprecated
things
so
like
come
2.0,
we
can
easily
delete
them
like,
so
we
can
make
backward,
compatible
changes
and
then
mark
things
and
not
have
it
go
out
of
hand.
Does
anybody
have
any
experience
or
think
we
should
use
that
kind
of
thing.
A
I'm
not
sure
if
that
allows
you
to
make
backwards,
compa
compatible
changes
because
marking
something
has
duplicated.
I
think
it's
just
like
a
heads
up
for
the
users
that
tells
them
this
thing
will
go
away
in
the
next
major
version,
but
it
will
still
be
a
breaking
change
when.
A
What
I
mean
is
that
I
think
these
deprecation
decorators,
the
only
thing
that
they
do,
is
that
they
give
the
user
a
heads
up
that
tells
them
okay
you're,
using
something
that
we
will
remove
in
the
next
major
version,
but
still
it
still
will
be
breaking
when
that
gets
removed.
I
believe
that's
how
it
works.
D
Yeah,
you
guys
are
talking
about
the
same
thing
with
some
yeah,
the
next
major
version
it
will
be
removed,
but
diego
is
just
saying
it's
still:
a
breaking
change
makes
sense.
Yeah
the
whole.
The
whole
deprecation
notice
is
just
a
friendly
way
to
customers
and
users
to
have
a
better
experience
in
terms
of
migration
to
the
new
version,
so
by
the
time
that
they
upgrade,
they
should
already
be
well
aware
that,
like
their
code
base
shouldn't
have
the
deprecated
stuff
anymore.
That's
the
whole
point.
D
I
believe
I
haven't
personally
used
any
like
libraries
or
decorators
that
do
this,
but
dot
net
is
doing
the
same
stance,
exact
same
thing:
that
when
you're,
what
you're
saying
aaron.
So
I
think
it
will
be
a
pretty
good
practice
if,
if
we
want
to
explore
doing
that
too,.
C
A
What
we
can
do
is
that
maybe
we
can
put
those
decorators
on
the
stuff
that.
F
Yeah,
that's
that's
what
I
was
trying
to
suggest
just
that
we
don't
lose,
because
I
think
we
also
did
something
for
somewhere
else
where
we
left
like
a
placeholder
so
that
it
wasn't
breaking.
But
we
don't
want
to
keep
that
forever.
So.
H
D
G
All
right
so
this
this
issue,
the
like
this
whole
discussion,
is
about
adding
adding
a
timeout
for
the
exporters.
G
One
of
the
one
of
the
discus
point
here
is
that
that
having
span
processor
to
do
the
retry
logic
and
also
pass
the
time
mode
to
the
exporter
seems
like,
but
the
specification
is
clearly
states
now
that
there
shouldn't
be
any
retry
logic
in
the
sdk.
G
It
should
be
completely
be
part
of
the
exporter,
so
we
will
have
to
only
do
any
retry
logic
card
timer
in
the
exporter.
Only
so
I
was
like
so
so.
Basically,
this
exporter,
some
exporters
now
can
block
indefinitely.
So
there's
no
time
out
so,
but
but
but
the
specifications
say
that
the
export
call
should
not
block
indefinitely.
There
should
be
some
up
reasonable
upper
limit,
but
it
does
not
say
what
and
then
there
shouldn't
be
any
retro
logic
in
the
exporter.
G
It
should
only
be
a
sorry
in
the
sdk,
but
it
shouldn't
be
in
the
sd
exporter.
So
I
I
wanted
to
talk
about
this,
which
what
what
is
the
reasonable
limit
that
we
want
to
agree
on
so
so
the
export
call
does
not.
You
know.
G
No,
no,
it
should
not
be
in
sdk.
So
the
one
of
the
points
chris
and
you
were
talking
was
that.
E
G
F
G
So
yeah
that's
one
of
the
point
I
wanted
to
talk.
Also
so
otlp
explicitly
says
that
any
network
failures
should
it
should
retry
like
with
the
you
know,
exponential
backup
mechanism,
but
there's
nothing
says
about
the
zipskin
and
again
exporters.
It's
only
for
the
otnc.
H
F
Okay,
I
was
gonna,
say
yeah,
I
don't
mean
return
retry,
I
just
mean
like
if
you
do
an
exponential
back
off
and
it
takes
600
seconds.
Is
that
supposed
to
block
the
next
batch
in
the
in
like
this
ban
in
the
batchman
processor?
Or
do
you
asynchronously
retry
and
then
return
success
or
failure.
G
So
so
the
call
is
blocked.
So
once
you
send
a
badge
to
the
exporter,
exporter
should
retry
when
there
are
some
network
values,
but
but
if
there
is
any
other
failure
it
should
it
should
return
the
export
result,
failure.
Otherwise
it
should
return
such
so.
That
call
is
blocked,
but
it
should
not
be
blocked
indefinitely.
D
That's
the
exponential
yeah,
the
change
in
timeouts
yeah.
F
G
D
G
G
E
F
Yeah,
it
makes
sense,
but
I
guess
even
if
we
make
it
like
20
seconds,
if
you're
generating
like
500
spans
in
10
seconds,
then
you're
you're
gonna
have
a
problem
getting
anything.
I
was
just
gonna
start
dropping
everything
right.
It's
like,
I
guess
I'm
just
confused
if
it
should
be
asynchronous
or
not.
D
F
F
D
E
F
Yeah,
it's
still
open,
it's
not
really
resolved
but
yeah
like
that's
that's
basically.
My
point
is
like,
if
you're
doing
it
concurrently,
that
means
that
the
batch
span
processor
is
sending
you
spans
before
you're
finished,
which
means
you
have
to
return
something
insanely
before
you're
done.
So,
like
you
return
success,
do
you
return
failure?
I
think
you
put
that
in
the
issue,
but
yeah.
D
D
D
E
G
This
is
still
an
issue:
yes
yeah
also
zipkin
and
eager
exporter,
so
dipkin
uses
request
module.
We
can
pass
pass
the
timeout
to
that.
I
I
think,
you're
also
using
something
similar.
We
can
do
that,
so
we
can
set
that
timer
there
so
that
it
does
not
block
indefinitely.
That's
that's
for
the
setting
timer
and
on
this
retry
mechanism.
G
D
G
G
Yeah,
if
you
find
that
we
can
have
abstract
color
or
something,
then
we
can
go
ahead,
yeah,
that's
that's
for
the
timeouts
part
and
then
and
then
I
want
to
also
want
to
talk
about
shutdown
part.
So
the
specification
says
that
if
the
shutdown
should
only
be
called
once
for
the
exporter
and
any
subsequent
calls
should
return
failure,
wait.
D
G
G
I'll
create
one
very
nice
right
and
next
thing
is
there's
another
issue
for
splash
alex
added.
If
you
can
open
that.
H
E
G
D
D
G
That's
that,
if
you
are
talking
that
in
the
process,
spam
processor
but
like
exporter
once
it
receives
the
batch,
there
is
nothing
else
we
are
doing
like
we
are
converting
it
serializing
and
then
sending
it
over
to
the
yeah.
G
Yeah,
whatever
you
said,
make
sense
for
the
bus.
But
what
what
does
this
mean
in?
In
the
context
of
exporter.
F
I
think
we
just,
I
think
sorry
I
was
gonna
use
that
I
think
two
things
one.
It
would
be
like
the
timeout
and
the
concurrency.
If
you
have
something
backing
off,
you
would
try
all
those
fans
again
and
then
another
thing,
I
think,
is
it's
just
supposed
to
be
a
blocking
api
so
that
the
spam
processor
can
call
force
flush
and
then
it
will
block
until
the
export
is
done.
F
If
it
has
anything
but
like
yeah
right
exporter,
shouldn't
shouldn't
do
any
batching
necessarily,
but
I
think
it's
just
supposed
to
be
like
a
way
to
block.
G
It
also
says
that
you
can
return
like
you,
can
make
a
call
call
back
so
that
they
can
get
result
asynchronously.
The
last
point,
in
the
first
place.
D
But
this
is,
this
is
a
span
processor
thing
right.
G
Yeah,
it
makes
sense
in
the
in
that
context,
but
like
in
exporters,
yeah.
E
G
E
G
G
This
there's
no
way
to
do
that
right
now.
So
what
do
you
people
think
about
adding
that
ability
to
other
exporters
as
well.
D
G
D
I
think
we
just
need
to
add
it.
I
don't,
I
don't
know
if
we
have
an
issue
for
it,
probably
not.
G
D
G
E
G
There
is
some
some
separate
file
for
this.
All
of
this
right.
D
B
E
E
G
D
Yep,
that's
it
all
right
nice.
Does
anybody
have
any
other
pr's
or
issues
that
they
want
to
talk
about.
D
All
right:
well,
if
that's
the
case,
then
I
guess
we
can
call
it
early
this
week.
I
will
see
you
guys
next
week,
all
right
all
right
later.