►
From YouTube: 2021-03-18 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
C
A
D
Yes,
I
also
have
to
leave
this
meeting
in
25
minutes
or
so.
Yeah
no
worries
we'll,
probably
have
a
short
meeting
today
so
yeah.
I
only
have
one
absolutely
massive
pr
to
discuss.
A
Yeah,
I
already
added
that
oh
is
it
the
same
one
yep
yep,
that
one
cool
yeah.
A
So
I
guess
the
only
thing
that
we
wanted
to
talk
about
was
that
so
we
decided
to
we're
making
some
great.
Oh
I'm
not
sharing
my
screen.
A
Okay,
so
we
made
some
great
progress
in
terms
of
closing
out
all
of
the
rc2
issues.
I
believe
we
only
have
two
left.
We
started
with
like
12
last
week,
so
good
job,
guys,
it's
pretty
awesome.
A
The
only
ones
left
are,
you
know,
as
diego
said,
the
getter
and
setter
one,
which
I
believe
he
put
out
a
pr
just
yesterday
and
this
last
otlp
exporter
separate
protocol
thing,
which
alex
has
been
working
on
otlp
and
jaeger
prs
have
already
been
merged.
I
think
it's
only
zipkin
that
is
left
and
I
believe
away
and
shrikanth
has
have
already
commented
on
that
and
approved
it.
So
just
waiting
on
alex
to
make
some
changes
and
fix
the
build
so
awesome.
A
I
think
we're
we're
pretty
much
set
to
be
the
third
language
that
goes
ga,
I
believe.
Hopefully
it
could
be
go
they're
in
like
a
similar
situation
as
us,
so
yep
we
were
gonna
yeah.
We
were
trying
to
probably
gonna
yeah
get
the
release
on
monday.
We
don't
really
want
to
release
tomorrow
and
it's
kind
of
like
cutting
it
close
either
also
give
diego
some
breathing
room
so
yeah.
I
think
that'll
be
good
any
questions
regarding
that.
A
Pretty
straightforward
note:
yeah,
oh
and
also
yeah,
so
kant
is
an
approver
now,
so
it's
pretty
awesome.
It's
been
yeah
contributing
a
lot
very
active
on
the
slack
channel
and
the
getter
previously
so
congrats,
sir
thanks
a
lot
for
your
contributes.
C
C
A
Cool
all
right.
Well,
there's
no
other
topics
regarding
that.
Oh
there
was
also
something
else
yeah
alex,
and
I
are
also
planning
to
delete
all
of
the
old
packages
that
we
renamed
previously.
I
believe
that
was
the
consensus
that
we
have
and
we're
going
to
be
deleting
them
as
soon
as
the
release
goes
out
to
you,
we're
also
planning
to
have
a
like
blog,
post
or
announcement.
A
I
believe
someone
from
you
know
lightstep
and
microsoft
are
trying
to
put
that
together.
So
look
out
for
that
too.
Shortly
after
the
release
is
out
so
yep
and
I
think
we
plan
on.
I
know
we
said
it's
rc2,
but
I
believe
we
don't
really
need
like
an
interim
step,
so
I
think
rc2
would
just
be
the
the
1.0.
A
So
there.
A
Anything
in
between
rc2
and
1.0
that
we
can
learn
pretty
much,
so
don't
be
surprised
if
that
happens,
unless
if
anyone
has
a
very
scathing
reasons
for
why
we
shouldn't
do
this,
the
releases
will
like
if
we
do
rc2
and
then
1.0
they'll
be
exactly
the
same.
So
yeah
cool-
that's
that's
pretty
much
it
for
that.
I
think
we
could
just
go
straight
on
the
pr's
cool,
so
diego.
This
is
your
remove
setters
and
getters
vr
yeah.
You
want
to
talk
about
this.
D
Sure,
okay,
if
you
click
on
the
files
change,
please
thank
you.
You'll
see
at
the
right
how
how
small
the
cursor
is.
D
Okay,
so
this
pr
is
extremely
big
and
the
matching
pr
for
the
country,
repo,
is
also
very
big.
Now
this
pr
should
get
us
rid
of
a
lot
of
code.
Most
of
the
changes
here
are
called
removal
because
the
the
propagation
it
is
done
with
carriers
and
carriers
are
dictionaries
or
something
that's
very
similar
to
dictionaries.
D
D
Exactly
what
happened
is
that,
while
I
was
refactoring
all
this
code,
I
also
cleaned
up
a
bunch
of
code
that
I
was
finding
in
the
files
that
I
was
cleaning
up,
so
it
is
there
already,
but
please
take
a
look
because
reviewers
may
want
the
code
cleanup
to
be
separate
into
other
pr.
If
that
is
the
case,
I
I'll
try
to
do
it.
D
Since
this
is
rc2,
I
prefer
to
open
it
up
now,
as
it
is
because
I
understand
this
is
urgent
and
if
the
the
hooking
up,
if,
if
folks
want
me
to
move
the
hotend
up
to
another,
just
let
me
know
that
take
some
more
time,
but
if
you
prefer,
I
can
do
it.
I
can
do
it
as
well.
D
Oh
by
the
way,
this
should
be
an
api
affecting
change
right
because
we're
removing
we're
changing
the
signature
of
the
inject
and
extract
methods,
among
many
other
things.
So
just
just
a
heads
up
to
everybody.
A
Yeah,
just
by
looking
at
this,
like,
I
really
prefer
you
splitting
out
the
changes
that
not
relate
to
this
issue,
as
well
as
the
removing
the
getters
and
setters.
A
A
Secondly,
there
is
no
conversation
at
all
in
this
issue
as
well.
If
you
just
take
a
look
at
remove
getters
and
setters
like
if
someone
had
no
context
of
what
you're
talking
about
oh
yeah,
you
wouldn't
know
how
this
yeah
like.
How
would
this
relate
to
this
right?
So
if
you
could
add
something
in
your
description
saying
like
hey,
we
are
going
to
be
removing
getters
and
setters,
and
this
is
the
reasons
why
and
also
how
that
solves
this
okay
that'd
be
good
yeah.
D
When
do
you
want
this
separation
to
be
done,
because,
right
now,
I
need
to
jump
into
another
issue
that
I
had
put
away
to
get
this
pr
done
so.
A
Yeah,
will
you
well
it'd
be
great
to
have
this
pr
in
a
state
in
which
it's
like
the
reviewers
can
review
it
easily
like
as
soon
as.
A
A
Yeah,
if,
if,
if
you
can't,
if
it
takes
too
long
to
do
that,
like
I
would
at
least
in
the
description
like
numerate,
exactly
which
files
to
look
at,
I
guess
or
like
what.
What
kind
of
you
know
like
cosmetic
or
optimization
changes
that
you've
made?
That
don't
relate
to
this.
D
No,
in
fact
it
should
what
happens
is
that
at
this
point
it's
become
a
bit
blurry
the
line
between
what
is
a
cleanup
and
what
is
necessary
for
this
pr,
because
this,
the
way
that
we
are
handling
the
the
getters
and
setters
and
and
everything
was
it
used
a
lot
of
this
pattern
that
which
was
pretty
much
extracting
the
first
element
from
a
list
that
contained
only
one
element
and
all
that
is
gone
now,
so
it
it
it
could.
How
do
I
say
this?
D
It
is
not
exactly
the
removal
of
the
sellers
and
getters,
but
it's
almost
completely
related
to
these
changes.
The
the
removal
of
all
these
methods
that
did
all
the
extraction
of
the
first
element,
all
the
kind
of
stuff.
So
I
am
sure
I
can.
I
can
provide
a
better
description
and
at
least
reviewers
know.
Okay,
some
of
these
changes
are
article
cleanup
or
may
look
like
like
it,
but
pretty
obvious
right,
so
just
that
people
know
that
they
they
may
find
some
stuff,
at
least
in
this
pr
in
the
indianapolis.
D
It's
not
completely
related
to
this.
I
can.
I
can
take
a
look
at
how
how
many
of
those
changes
can
be
moved
away
from
this
pr,
but
yeah
it'll
be
just
pretty
tight
to
get
that
done
to
release
on
monday.
D
No,
I
I
just
started
what
happens.
Is
that
this?
This
pr
included
a
lot
of
searching
and
replacing
and
making
that
uniform
made
that
searching
and
replace
much
easier
right?
So
it
was
a
way
of
speeding
things
up
the
development
of
this
pr.
All
these
changes
that
are
there
are
there
are
more
correct.
As
far
as
I
know,
for
example,
this
this
format
should
be
in
lowercase,
because
it's
not
a
it's,
not
a
constant
regarding
prepaid
and
everything
else,
right
and
stuff
that
should
be
private.
D
I
try
to
make
I
made
it
private
and
all
the
kind
of
things,
so
it
is
there
right,
but
yeah
just
to
give
you
a
heads
up
on
situation
that
I
am
in
regarding
this
guy
right
now,.
A
A
Yeah,
okay,
so
I
guess
you
could
yeah
like
try
your
best
to
do
that,
like
we're
trying
to
aim
for
monday,
but
like
it,
you
know
it's
not
like
a
strict
deadline
or
anything
I'd.
Rather
this
be
done
properly.
Then
you're
being
rushed
into
doing
it.
So
if
you
could
just
take
the
time
to
just
like
split
up
the
stuff
that
we
actually
need,
don't
worry
too
much
about
the
monday
deadline.
Then
you
know
right.
Yeah,.
A
More
it's
more
like
the
sooner
you
do
that,
like
the
sooner
we
can
review
it
right,
yeah
because,
like
if
you,
if
you
get
it
by
monday,
like
you
know,
we
still
need
to
get
two
reviewers
and
approvers
to
look
at
the
whole
thing
and
there
might
be
a
back
and
forth
between
us.
So
like
monday
would
be
like,
like
the
closest
we
can
ever
release
right,
so
it'd
probably
be
like
tuesday,
wednesday
or
thursday,
because
we
still
have
to
approve
it
and
merge
it
in
and
then
we
we
do
have
the
release
right.
A
It
yeah
and.
D
I'm
sorry
for
the
confusion.
It
just
made
it
way
easier
to
make
those
changes.
As
long
as
I
was
searching
or
replacing
or
removing
a
bunch
of
stuff
sure
sure
yeah
well,
I
was
developing
this
all
right.
Yeah
I'll
do
my
best,
then
just
a
question
here
later.
So
the
plan
is
to
move
straight
to
100
right,
yes,
and
that
should
be
that
that
should
mean
commitment
to
the
api.
And
yes,
yes,
all
right
well,
so.
A
Scary
man,
commitment
yeah,
that's
that's
that's
why
we
were
very,
very
strict
on
hey.
Is
this
affecting
rc1?
Is
this
affecting
rc2?
That's
why
we
got
carlos
to
come
in
and
like
kind
of
blanket
statement
hey.
This
is
good,
so
gave
us
more
confidence.
C
A
I
think
we
have
the
appropriate
people
for
this.
One.
A
Okay,
so
this
has
been
out
for
a
really
long
time
and
this
would
actually
be
nice
to
get
in
for
1.0,
and
it
seems
like
a
lot
of
people
have
made
comments
on
it,
but
haven't
like
affirmed
that
decision.
A
I
believe,
like
kind
of
ping
circumference
away
before,
but
do
you
guys
know
the
status
of
this
pr?
I
haven't
looked
at
it
at
all.
B
I
think
the
author
hasn't
been
very
active
lately.
A
couple
of
weeks
ago
I
did
review
it
and
I
found
the
implementation
to
be
a
bit
too
complex.
I
think,
and
I
think
there
are
ways
to
simplify
it
dramatically,
but
the
author
hasn't
replied
to
the
comments
yet.
B
I
don't
think
so:
no,
it
doesn't
break
anything
if
it
comes
in
later.
I
don't
think
it
breaks
anything
unless
I'm
missing
something.
It
only
improves
some
education.
A
Okay,
so
karth,
what
do
you
think.
C
Yes,
it
doesn't
break
anything.
It's
only
like
foxy.
C
A
B
C
B
So
so
I
think
the
behavior
change
would
be
that
in
in
some
cases,
calling
the
get
get
tracer
would
provide
a
different
type,
a
different
implementation
of
tracer,
but
the
interface
for
the
tracer
would
be
the
same.
So
code
shouldn't
break
okay,.
C
B
A
I
see
okay,
that
should
be
okay,
then
I
will.
C
B
But
yeah,
I
think
it
it.
It
is
expected
to
change
in
some
edge
cases
like
if
in
a
couple
of
cases
where.
B
So,
if
you
look
at
the
attached
issues,
so
one
issue
is
where
django
there's
a
bug
in
in
django.
If
you
set
up
the
pipeline
before
django
itself
starts
up
or
unicorn
starts
up,
I
don't
remember
exactly
which
one
now,
but
it
could
be
argued
that
it's
a
bug
fix,
because
the
current
behavior
is
that
pipeline
doesn't
work.
If
the
order
of
setup
setting
up
the
pipeline
is
in
a
certain
way,
then
tracing
just
doesn't
work
it.
Everything
is
a
no
for
the
lifetime.
I.
B
Right
yeah,
so
when
we
land
this,
like
that
use
case
should
actually
get
fixed,
so
we
could
like
this
is
probably
a
bug
fix
for
me.
I
guess.
D
Yeah,
I
just
wanted
to
bring
this
to
your
attention,
because,
right
now
we
have
this
open
discussion
regarding
what
is
and
what
is
not
a
breaking
change,
and
I
think
we
have
not
yet
reached
an
agreement
or
kind
of
decided
what
what
could
be-
and
I
think
that
should
be
critical
to
decide
before
we
go
to
one
or.
B
See
perhaps
we
should
yeah?
Maybe
we
should
list
this
this
pr,
and
then
there
was
another
issue
that
aaron
was
working
on,
which
sparked
the
whole
discussion.
Maybe
we
should
list
these
two
as
examples
and
see
if
like
what
we
think
about
these
two,
maybe
it'll
help
us
come
to
an
agreement,
maybe
not.
A
D
Yeah
I
mean
what
happens
is
that
we
are
planning
to
get
into
a
stable
release
and
what
separates
the
stable
release
from.
What
we
have
now
is
that
we
will
be
committed
to
keep.
It
keeps
things
backwards,
compatible
right,
and
if
we
don't
have
an
agreement
on
what
backwards
compatibility
means,
then
I
think
we
we
will
be
in
a
very
sketchy
position,
so
so
yeah.
A
A
Only
only
thing
that's
up
in
the
air,
which
is
the
whole,
is
behavior
a
backwards,
compatible
thing
that
we
need
to
ensure,
like
everyone
already
agrees
on
this
whole
major
version
thing,
you
know,
can't
break
the
public
api
right,
so
it
literally
should
just
be
like.
Should
behavior
breaking
behavior
be
part
of
the
api
stability?
That's
it
right.
Yep,
like
that's.
A
D
Know
this
right,
yeah
yeah
yeah,
I
think
so
far.
People
have
just
been
posting
their
their
points
or
trying
to
bring
more
information
into
discussion.
D
A
D
Yeah,
but
I
pretty
much
just
exposed
all
my
my
thoughts
there
in
that
comment,
so
everything
that
I
think
about
the
issue
is
there
yeah
by
the
way?
Those
are
my
points
there,
but
of
course,
if
people
decide
that
behavior
changes
should
be
this.
A
D
D
So
what
I'm
trying
to
say
is
that,
even
when,
when
I
find
that
to
be
an
issue
and
stuff,
if
most
folks
prefer
that
behavior
changes
being
be
included
into
possible
breaking
changes,
so
I'll
I'll
I'll
go
along
with
what
the
the
decides
right,
I'm
not
gonna.
A
Just
sit
down,
okay,
I
will
I
will.
I
will
take
action
on
this.
This
is
just
ridiculous,
so,
okay
cool,
so
I
think
that's
pretty
much
it
guys.
I
think
we
should
prioritize
this
discussion.
It
is
kind
of
I
do
agree.
It
is
kind
of
important
before
we
release
at
least
so.
B
B
To
the
document,
I
just
need
a
couple
of
minutes
to
just
bring
it
to
everyone.
We
don't
need
any
action
on
this
today
yeah,
so
there
are
a
couple
of
edge
cases
like
in
some
cases
when
a
client
http
library
is
instrumented,
but
that
library
internally
uses
some
other
http
library
or
lower
level
functions,
and
if
we
have
instrumentations
for
both,
then
in
that
case
we
generate
end
up
generating
two
client
spans,
which
is
very
weird,
and
it
can
actually
like
break
or
confuse
back
ends
and
the
systems.
B
A
B
Right
so
your
url
three
url
three
instrumentation
then
suppresses
http
client
instrumentation,
which
is
which
is
not
ideal,
because
htv
client
might
be
adding
some
useful
information
like
dns
time
or
whatever,
which
rise
it
took
or
or
anything,
because
it's
lower
level.
It's
there's
more
information
there
right
and
in
any
case,
even
if
it's
not
lower
level,
it's
yeah,
it's
still
important
to
to
have
instant
expense
from
all
the
instrumentations.
So
another
similar
issue
is
with
whiskey
and
django.
B
One
person
recently
reported
a
bug
on
slack
where
they
were
using
whiskey
in
ubiski,
instrumentation,
microwhisky
and
then
also
django
instrumentation.
So
what
was
happening
is
usb.
Instrumentation
was
generating
one
server
span
and
then
django
would
extract
the
parent
context
from
the
incoming
request.
B
So
so
it
looks
like
there's
some
like
there's
some
need
for
instrumentations
to
either
like
cooperate
with
one
another
or
spans.
To
maybe
like
have
some
delayed
like
spans
can
decide
whether
their
clients
are
servers
in
a
delayed
manner
like
they
can
check,
look
at
their
children
and
then
decide
or
something
I
don't
know
what
the
correct
answer
is
just
wanted
to
bring
it
up
for
now.
So
people
have
some
time
to
think
about
it.
A
C
A
A
It's
difficult
to
imagine
the
first
place.
Is
there
a
way
where
it's
like,
there's
no
way
we
can
build
instrumentations
off?
Well,
that's
already
what
we're
doing
right,
like
django's
using
some
wizzy
stuff
alaska's
using
some
whiskey
stuff.
A
C
B
Me
neither
yeah,
I
just
wanted
to
open
it
up
so
in
case
any
any
people
have
any
ideas
that
we
might
take
it
forward,
but
but
yeah
this
is.
This
can
wait.
We
can
discuss
this
after
one
thing:
yeah.
A
Thanks
for
articulating
this
yeah,
you
should
bring
it
up
again
next
week
when
we
have
more
people,
I'm
interested
in.
A
People
say:
okay,
cool
anything
else
from
anyone
else.
I
feel
like
that's
pretty
much
it
for
today,
okay,
cool,
so,
if
that's
it,
I
will
see
you
guys
next
week.