►
From YouTube: 2021-03-12 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
No,
I
was
here
for
the
swift.
Let
me
double
check
the
meeting.
B
D
B
Hello
seems
like
maybe
there's
a
conflict
or
a
clash.
I
mean
clash
because.
B
Yeah
but
since
you
are
here,
I
would
like
to
ask
this
with
you
guys
how
proficient
you
are
in
python
and
if
you're
lucky
take
some
issues.
A
Nacho,
it
looks
like
the
zoom
calls
between
the
pythons
sink
and
the
swift
sig
are.
This
are
the
same
ones,
so
I
think
we
might
have
got
the
wrong
one
in
there.
E
Do
we
have
two
meetings
with
the
the
same
same
zoom,
apparently,
okay?
Well,.
E
D
E
Yeah
I
see
I
see
what's
going
on
here.
Let
me
find
a
new
meeting
url
for
this
real,
quick
and
I'll.
Add
this
to
the
the
swift
one
and
then
the
swift
people
can
pop
over
into
that
meeting.
E
E
E
Oh
and
then
is
there
password
for
this
now.
One
second
heard
my.
E
A
So,
oh
yeah,
it
actually
looks
like
the
python.
The
python
sync
is
on
the
wrong
one,
because
you're
you're
set
up
banana
on
the
calendar
but
you're
using
the
using
the
tomato
zoom
link.
E
I
see
python
is
no,
I
think,
they're
using
the
one.
That
starts
with
eight
two
eight.
E
E
To
me,
using
eight
to
eight,
so
I
wanna
switch,
which
I
wanna
switch.
Oh
yeah,
swift
over
to
banana
here
and
the
passcode
is
going
to
be
five
sevens.
Just
fyi,
I'm
not
sure
how
to
actually
bake
that
into
the
the
zoom
url.
E
G
C
E
E
B
F
F
F
All
right,
I
think
we
could
start
it's
already
907..
Oh
it
always
joined,
so
we're
ready
to
go
yeah.
It's
man
of
the
hour,
okay
cool,
so
we'll
just
go
over
the
agenda.
Like
usual,
looks
like
you
guys,
added
a
bunch
of
topics
already,
so
that's
pretty
awesome
we
can
go
through
strength.
Is
here
today
right
yep,
we
go
over
some
of
the
issues
that
you
wanted
to
go
through.
D
D
Relevant
started
a
discussion
about
removing
this
was
from
span
and
then
using
the
resource
from
the
current
tracer
provider,
but
wise
had
brought
up
a
nice
use
case
where
users
would
want
to
have
multiple
tracer
providers
within
a
single
process
with
different
resource
configuration,
whichever
they
would
like
to
have
and
and
took
out
that
use
case.
We
decided
to
keep
that
is
so
so
that
there
is
this
issue
which,
which
is
about
removing
the
service
name
from
the
exporter
constructors.
F
So,
first
of
all,
does
everyone
have
any
questions
about
the
initial
issue,
but
removing
the
resource
from
this
ban?
We
decided
not
to
go
through
with
it
because
of
always
use
case
that
he
pointed
out
as
sherkanth
has
mentioned,
and
that
has
led
into
more
discussions
about
related
to
the
service
name.
F
I
I
Right
so
when
you
make
a
response,
you
attach
it
to
the
tracer
provider
right
now
right.
So
yes,
and
then
it
gets
attached
to
the
spins
as
well
for
like
the
exporter,
yes,
but
conceptually
it's
at
the
tracer
provider
level
right.
So
I
I
didn't
actually
follow
that
other
issue
that
closely
right.
F
Yeah,
so
that
was
my
original
thought,
like
once
you
get
to
the
exporter
level
like
you,
can
just
read
from
like
whatever
tracer
provider
you're
using
right,
like
from
the
global
tracer
provider,
to
populate,
like
whatever
resource
information
you
need.
But,
however,
it's
outlined
that
it's
like
you
know.
C
F
Yeah
yeah,
the
proposal
is
to
actually
I
actually
looked
at
other
language
implementations
of
how
they
handle
this
java.
What
they're
doing
is
they're
pretty
much
just
reading
from
the
spans
resource
right
instead
of
taking
it
from
the
global
tracer
provider,
so
the
current
spans
resource
is
like
what
they
use
to
populate,
like
service
name
and
like
other
stuff.
That
is
relevant
net
is
doing
something
weird
as
usual.
F
F
It's
kind
of
strange,
because
I
feel,
like
things,
should
not
know
about
each
other
and
should
be
modularized,
but
it
is
nice
in
such
a
way
that
like
if
they
ever
reconfigured
the
tracer
provider,
like,
for
example,
if
samplers
were
allowed
to
be
changed
or
like
if
id
generators
are
allowed
to
be
changed,
their
components
would
automatically
pick
that
up.
But
you
know,
as
of
today,
like
we
can't
change
that
so
like
we're
still
okay
for
that,
but
I
don't
think
we
want
to
go
that
route
in
terms
of
implementation,
detail.
J
You've
gone
on
the
line,
if
downline
we
do
allow
changing
things
and
press
providers.
I
think
that's
even
more
even
more
reason
to
read
it
from
the
span
because
of
batching.
We
might
use
output,
supervisors
data
so
right.
Reading
from
the
span,
probably
the
safest
or
the
most
today.
F
They
never
use
it
like
when
users
can
possibly
explicitly
like
configure
the
tracer
provider
and
start
spams
themselves.
So.
I
Yeah,
that
makes
sense
I
was
just
gonna
ask:
is
it
does
the
specs
anything
about
the
spam
processor
or
exporter
being
used
in
multiple
trace
providers
like
is
that
allowed.
D
F
At
least
for,
like
my
pass-through,
like
I've,
never
seen
much
about
multiple
tracer
providers
except
one
small
excerpt
in
the
specs,
but
it
doesn't
say
anything
about
implementation
details.
All
it
said
is
like
users
can
possibly
configure
multiple
tracer
providers.
I
think
oa
did
link
that
somewhere.
I
just
yeah.
I
I
J
F
H
What
part
like
about
the
tracer
providers,
the
multiple
tracer
providers?
What
about
resource
being
on
spam,
yeah.
H
I
don't
think
so.
Honestly,
I
don't
think
that's
the
case.
H
So
I
think
that
if
I
understood
correctly,
you
are
asking
whether
it's
possible
that
multiple
tracer
providers
can
be
referenced
from
spam.
Is
that
the
case?
Do
you
think
that
you
are
talking
about?
He
could
have
in
the
same
process
different
tracer
providers
with
you
know
we
did
with
with
the
spans
that
could
reference
them.
F
H
F
F
There
are
some
like
issues.
I
guess
I
haven't
looked
at
these
yet
but
scrunt
did
you
want
to
kind
of
talk
about
this?
I
think
we
addressed
the
other
stuff
right.
D
Yes,
so
so,
like
believe
said
like
he
had
a
link
to
some
comment,
how
he
wanted
to
populate
this.
So
the
question
here
is
look
so
the
his
approach
is
basically
like
taking
the
like
the
first
spam
resource
as
the
resource
information
for
the
whole
batch,
so
is.
Is
it
possible
that
a
badge
to
have
a
spans
from
two
different
tracer
providers?
D
D
I
D
Yes,
yes,
so
that's
what
that's
what
I
also
trying
to
suggest
here,
like
you,
know,
group
them
by
their
resource
and
then
for
each
group
make
a
better
export
request
instead
of
taking
it
from
the
first
span.
F
Wait
aaron:
what
is
the
actual
like?
What
does
it
look
like
in
the
code
for
a
batch
spam
processor
to
have
different
to
peruse
to
have
spans
that
are
from
different
service
names?
To
have
different,
have
resources
with
different
service
names.
I
I
mean
so,
if
you
had,
if
you
made
like,
I
don't
know,
it
seems
like
a
weird
use
case
because,
like
resource
conceptually
would
be
like
your
your
app
that's
running
like
your
your
program,
so
it
makes
it
kind
of
weird
to
say
that
you
would
have
even
you
had
multiple
choice
providers
to
say
that
you
would
have
different
resources
for
each
of
them
yeah.
But
just
assuming
you
did
do
that,
you
set
you
put
the
batch
spam
processor
and
you.
I
F
G
Yeah,
I'm
not
sure
one
word,
the
other
yeah.
What's
the.
F
What
was
what
was
the
proposed
solution?
Shikon
like
what
was
the
if
we
can't
take
the
the
first
span.
D
Also
so
if
a
fspn
processor
can
have
like
from
various
resources,
so
each
batch,
we,
we
group
them
by
the
resource
like
unique
resource
and
then
for
each
of
the
for
each
group.
We
we
make
a
export
request
in
the
exporter.
I
I
see
by
the
way
I
do
think
I
have
like
a
use
case
for
something
like
this,
because
technically
we
put
pid
like
process
id
is
in
the
resource
and
specifically
for
like
python,
where
multi-processing
is
pretty
common,
you
would
have
one
trace
provider
per
process
or
something
like
that
and
they'd
have
different
resources.
But
I
mean
I
don't.
J
F
F
Okay:
okay,
good
good,
all
right,
nice
cool
sounds
good
to
me.
I
Should
we
raise
that
spec
as
well
like
what
do
you
guys
think?
Maybe
what
does
carlos
think.
I
H
J
Cool
should
we
should
we
should
we
specifically
point
out
batsman,
processor
or
just
generally
say
any
processor
should
only
be
used
with
one
provider.
H
F
Yes,
cool
also
alex,
I
think
part
of
this
issue
like
we
can
just
include
the
documentation.
So
I
don't
know
if
we
need
a
new
issue
for
this
specifically
yeah,
okay,
cool
awesome.
So
anything
else
on
this
topic.
F
F
Yeah
nice
awesome
aaron
onto
your
topic.
I
What
we
got
here
yeah,
so
I
I
pinged
in
the
slack
about
this
yesterday,
but
essentially
I've
seen
a
few
different
bugs
in
it
like
in
open
census
and
in
open
telemetry,
where
basically,
the
casing
of
like
a
header
for
a
propagation
can
screw
things
up
and
most
like
carriers
like
http,
headers
and
grpc.
Metadata
are
supposed
to
be
case
insensitive,
but
some
of
them
will
like
preserve
case,
and
I
see
there
were
some
bugs.
I
Admittedly,
most
of
these
ones
were
related
to
my
propagator,
which
has
this
capital
capitalization,
but
it's
kind
of
like
it
could.
It
could
be
out
of
my
control
too,
so,
like
I'll
change,
the
code
for
my
propagator
to
use
the
lowercase
version
of
this,
but
like
this
can
come
from
like
google
load,
balancer
and
stuff
like
that
right
so
also
with
grpc
metadata.
I
It
will
actually
raise
an
exception
if
you
give
it
anything,
but
all
lowercase,
which
is
what
the
other
bug
linked
was
the
the
thing
is
with
like
the
way
the
spec
is
written
with,
like
getter
carrier
and
everything
there's
no
way
for
us.
I
can,
as
far
as
I
can
see
in
our
code
like
in
the
opencelebrity
api
or
sdk,
to
force
lowercase.
I
It
would
have
to
be
done
in
like
the
instrumentations
that
are
calling
xtract
right.
I
don't
know
if
this
is
something
other
languages
have
seen
or
if
there's
like
a
a
clean
solution,
but
I'd
rather
not
have
to
like
duplicate
it
to
all
the
instrumentations,
and
then
I'm
also
wondering
if
there's
any
carriers
like
besides
hp,
headers,
grp
metadata.
That
might
actually
want
case
sensitivity.
H
H
I
Right,
I
I'm
wondering,
if
like
we
could,
so
we
have
getter
in
a
class.
I
don't
think
that's
required
by
the
spec,
but
like
our
getter
class
could
have
a
second
method
that
will
like
the
extract
function
will
actually
call,
and
then
it
will
do
like
the
lowercasing,
for
instance,
but
but
people
don't
have
to
use
that
getter
like
they
can
implement
their
own
getter
completely
from
scratch,
or
we
could
put
it
in
like
the
base
class.
That's
probably
the
only
way
I
can
think
of
doing
this,
but
yeah
it's
like.
I
H
I
H
Yeah,
I
I
do
remember
seeing
somewhere
it
was
not
in
java,
I
think,
but
I
remember
maybe
it
was
javascript
or
I
don't
remember
where
I
saw
that
somebody
was
proposing
exactly
this
having
a
base
method
that
could
do
something
yeah,
I
don't
think
it
was
applied,
but
yeah
if
you
can
refactor
the
code
and
have
prototype
for
this,
that
could
be
nice.
Like
you
know,
helper
methods.
F
Should
we
should
we
allow
users
to
have
the
option
to
do
that
so
like,
instead
of
doing
it
in
the
base
class?
We
only
like
for
the
propagators
that
are
defined
by
open
telemetry.
Have
that
lower
case
and
then
like?
If
users
want
to
use
propagators
that
rely
on
case
sensitive
headers
like
they
can
make
their
own
propagator
right.
I
F
I
I
I
Yeah
this
one
yeah,
so
it
does
some
conversion
and
this
this
works
for
all
the
ascii
ones,
but
then
I
looked
and
whiskey
doesn't
seem
to
to
do
this
right
now.
I
could
be
wrong
because
I
just
took
a
brief
look
but
yeah.
J
Isn't
this
something
what
a
language
to
agree
on,
because
we
might
do
it
in
python
and
have
fixes,
but
then
some
other
geology
or
pc
might
still
like,
maybe
understand
something.
Would
you
have
consistency
across
it.
I
Yeah
so
like,
if
right
now,
right
now,
I
think
with
the
whiskey
ones,
if
you
and
I
haven't
tested
this
but
like,
I
think,
for
instance,
with
flask.
It
would
do
this
like
if
you
called
it
with
trace
like
trace
parent
and
you
use
like
mixed
casing
or
all
caps,
or
something
like
that.
I
don't
think
it
would
get
the
propagation.
Let's
see,
let's
see.
F
Okay,
so
implementation
aside,
do
you
think
that
we
need
this
by
rc2.
H
Well,
I
could
say
that
you
are
going
to
break.
Do
you
think
this
would
end
up
breaking
the
api
or
changing
it?
Then?
Yes,
because
if
this
is
something
that
you
can
add
without
breaking
the
api,
I
think
you
can
wait.
G
G
I
I
B
No,
no
because
the
I
mean
what
matters
is
that
you
don't
get
any
attribute
errors,
for
example,
when
you
call
a
method
that
it
should
be
there
right,
you
should
be
expected
to
be
there.
You
return
something
else
or
it's
different.
Well,.
J
I
Maybe
I
can
prototype
doing
it
in
the
getter,
which
would
be
an
api
change,
and
then,
if
that
doesn't
work
or
if
it's
like
something
we
don't
want
to
do.
I.
F
So,
okay,
so
aaron
did
you
want
to
take
point
on
that.
I
Yeah,
I
can
file
an
issue
for
python
and
then,
if
we
think
it's
something
that
that
would
be
useful
for
other
ones,
we
can
like
open
a
spec
issue.
I
guess
okay,
yeah
cool.
B
Hey
aaron,
controversial
question
for
you
yeah.
Can
you
do
all
this
without
sellers
and
getters?
I
G
B
G
B
H
B
Yeah,
I
I
judy
thinks
there
are
languages
that
don't
need
them
and
I
think
python
is
one
of
them
and
I'm
trying
to
prove
that
without
vr.
So
I
I
still
I'm
still
implemented
so
I
gotta
see
if
it
works
right,
because
I
think
it
may
work
better.
I
don't
know
maybe
I'll
find
her
yeah.
H
I
don't
I
don't
know,
what's
your
exact
take,
but
bogdan
was
against
that
because
he
was
thinking
that
this
main
end
up
in
avoiding
getters
and
sellers
by
allocating
projects
by
creating
wrappers
so
yeah.
I
would
be
curious
about
that,
but
anyway
yeah
it's
it's
possible
to
not
define
together
and
sellers.
You
don't
have
to.
F
Hey
diego,
is
that
part
of
your
that
that
null
issue
that
you
were
assigned
to.
B
F
F
Okay,
any
more
questions
about
that
topic.
F
Awesome,
cool,
all
right,
moving
on
just
like
something
I
kind
of
just
wanted
to
brush
over.
I
guess
specifically
for
aaron.
I
was
wondering
like
what
I
I've
seen
some
of
your
you
know
cloud
platform
packages.
What
exactly
like
did
they
do
and
like
what
are
you
recommending
to
your
google
customers?
I
guess
especially
because.
E
I
I
It's,
it's
all,
basically,
the
same
state
as
open
symmetry
like
where
and
that's
why
we're
invested
in
like
maintaining
open
census
right
now,
because
we're
not
really
recommending
customers
like
take
on
open
telemetry,
because
they're
going
to
have
to
basically
fix
stuff
every
release,
and-
and
so
you
know
like
for
tracing
we're
hoping
after
this
1.0,
that
it
should
be
good
for
customers.
So.
F
B
Yeah,
exactly
just
just
for
the
record,
I
was
just
taking
a
look
at
this
semantic
version
definition
and
it
says
that
for
every
backwards,
incompatible
change,
you
gotta
increment
the
major
version,
but
it
doesn't
define
what
backwards
and
compatible
means.
B
H
H
And
stuff,
I
think
the
spec
needs
to
be
more
specific.
I
mean
there's
some
stuff
that
is
more
or
less
defined
in
very
general
terms,
but
you
think
that
it's
not
please
feel
an
issue
yeah.
I
think
that
what
we
have
now,
it's
only
basic
recommendations,
very
general
recommendations
of
what
we
expect
as
backwards
compatibility.
I
Cool
for
python,
specifically,
though,
like
I
think,
pip
has
rather
like
python
packaging
there's
some
pep,
for
it
is
like
there's
tilde
equals,
which
is
basically
saying
that
if
you
have
like
reversion
match,
it
will
pull
in
whatever,
like
newest
version
of
that
package
that
meets
the
major
version
such
that,
like
all
of
your
dependencies,
are
satisfied.
So
we
have
to
sort
of
assume
like
if
we
have
like
a
one
dot
x
release.
I
The
api
should
be
compatible
such
that
like,
if
somebody
ran
the
code,
it
wouldn't
break
like
like,
we
could
put
star
arg
star,
star
keyword,
keyword,
args
everywhere
and
like
satisfy
that
if
we
have
to,
but
I
think
that's
like
one
place
that
we
have
like,
we
don't
have
to
deal
with
binary
compatibility
for
python,
at
least
but
like.
I
think
we
have
to
at
least
deal
with
that.
That's
like
a
definition
right.
H
J
Yeah,
I
would
say
if
I
would
consider
this
a
breaking
change,
because
it
it
would
break
my
abs,
even
though
it
doesn't
raise
an
exception.
Personally,
I
would
see
it
as
a
worse
breaking
change
than
an
exception,
because
it
silently
fails
instead
of
telling
me
what
went
wrong.
F
That
is
one
use
case
of
that.
I
think
we're
specifically
trying
to
define
what
breaking
changes
or
backwards
incompatibility
is.
F
F
So,
okay,
how
did
we
start
talking
about
that?
Was
that
an
issue
that
was
diego
right.
F
Okay,
is
there
an
action
item
behind
that
like
do
we
need
to
do
something
about
that
right
now,.
F
H
Out
but
I
I
could
suggest
going
first
and
try
to
figure
out
how
this
would
apply
to
python
and
then
probably
we
can
from
any
specification.
You
know,
learn
something
from
that
yeah.
This
may
apply
to
other
dynamic
languages.
I
think
that
for
a
static
type
language,
it's
more
or
less
clear,
but
yeah-
you
guys
were
saying,
there's
different.
The
cyborg
here
is
different.
B
H
B
Yeah,
what
I'm
more
concerned
about
is
the
fact
that
an
api
change
can
be
clearly
defined
right,
because
you
can
see
that
a
method
is
not
there
or
a
class
has
been
removed
or
the
signature
now
requires
an
additional
permission
like
that.
But
behavior
is
much
harder
to
define
right
and
in
some
situations
it
may
cause
a
breakage
in
some
situations
it
may
not
so
kind
of.
I
Great,
I
think,
that's
sort
of
like
the
goal
of
the
spec
right
like
if
you
fail
to
implement
the
spec
correctly
and
it's
like
some
minor
bug.
You
can
do
like
a
patch
number
increase
right
like
if
you
thought
you
were
doing
something
and
that's
what
you
documented
and
you
weren't,
and
then
you
fix
it.
It
can
probably
just
be
a
patch
right,
no
and
not
in
all
cases,
but
then,
like
minor,
would
be
like
changing
behavior,
but
keeping
the
api
the
same
and
then
major
would
be
like
changing
api
right.
F
Okay,
do
you
want
to
start
the
discussion.
F
Cool
all
right,
moving
on
to
the
issues,
I
think
this
is
one
that
was
opened
by
diego.
B
I
do
want
to
talk
about
that
right.
Yes,
as,
as
I
previously
mentioned,
I
am
thinking
about
removing
all
these
sellers
and
getters.
So
carlos
reported
this
issue,
and
I
took
a
look
at
the
specification
specifically.
Let
me
just
paste
in
the
chat
look.
What
am
I
doing
here
there
is
this
discussion
here
there
so
later.
Can
you
please
open
up?
B
Thank
you
and
if
you
scroll
down
a
little
bit,
there
is
judy
saying
yeah
write
that
right
there,
okay
scroll
a
little
bit
up,
please
okay,
there
saying
that
there
is
pretty
much
two
ways
of
dealing
with
setters
and
getters,
and
this
is
how
I
understood
this
that
settlers
and
getters
are
specified
in
the
specification
as
optional,
but
that
does
not
mean
that
the
argument
in
the
injector
extract
function
is
optional.
B
I
believe
that
so
far,
all
of
our
propagation
is
done
with
carriers
that
are
dictionary-like
objects,
so
that
we
can
get
rid
of
the
setters
together,
because
there
is
a
common
interface
for
all
dictionary-like
objects
to
set
and
to
get
a
value,
and
that's
what
I'm
trying
to
prove
with
the
pr
that
maybe
I'll
open
if
I'm
successful,
that
gets
rid
of
all
these
setters
and
getters
and
if
everything
goes
well
open
up
dpr.
But
so
I
have
this
hypothesis
that
we
can
get
rid
of
that.
B
But
I
have
not
proved
it
yet
by
having
a
functioning
pr.
And
yes,
I
I
wanted
to
give
you
a
a
heads
up
to
aaron,
because
if
he's
depending
on
sellers
and
getters,
I
may
break
your
reports.
I
I
think
I
think
actually,
your
change
would
work
with
mine
because
we
can
just
have
like
if
we
have
a
dictionary
like
object,
we
can
do
the
case
conversion
in
there.
The
problem
is
with
the
getter
that
has
to
come
from
the
instrumentation
library
which
we
don't
have
control
over.
So
I'm
in
favor
of
what
you're
saying.
H
H
So
if
you
think
that
most
of
the
carriers
in
the
actual
implementations
are
going
to
follow
these
without
the
requirement
of
together,
that's
fine,
as
I
was
saying,
the
worry
that
volcan
had
is
that
you
end
up
creating
a
wrapper
around
many
objects
by
not
not
having
together,
because
with
together,
you
have
like
a
single
object
that
you
can
just
use
for
for
a
given
carrier.
You
know
type,
so
you
don't
have
to
be
recreating
the
grapplers.
H
He
was
afraid
that,
for
example,
let's,
let's
think
that
there's
probably
some
popular
hypothetically,
like
jungle
or
flask,
and
the
carrier
is
not
implementing
the
map
interface.
So
that
means
that
they
have
to
to
write
a
grappler
that
grabs
the
request
object
to
implement
this,
and
by
that
you're
creating
more
objects
than
needed.
B
F
F
F
I
H
H
Yeah
I
mean
I
mean
I
don't
know.
I
am
very
curious
now,
if
you
ever
legal
story,
that
most
carriers
like
flask
and
you
know
a
lot
of
similar
stuff,
the
jungle
request,
they
their
request
objects,
implement
the
map
interface.
I
think
that
would
be
an
interesting
optimization.
You
know,
because
you
don't
need
that
most
of
the
time
yeah
at
least
for
the
common
cases,
you
would
be
not
safe.
No,
you
are
saving.
H
B
Right,
yes,
that's
a
good
point.
The
other
great
thing
about
this
change
in
in
terms
of
controversy
is
that
we
are
also
going
to
decide
if
this
is
going
to
be
a
breaking
change
or
not,
because
we're
going
to
change
the
api.
F
H
F
C
C
H
Yes-
and
this
is
a
very
common
case
by
the
way
I
saw
that
in
a
lot
of
projects
not
only
vital
you
have
this
specific
suffix
and
yeah,
it's
like
preview,
so
it
doesn't
apply
to
you
know
you
don't
apply
the
same
rules
quite
yet
so
we're
safe.
H
H
F
B
All
right
great
to
know
they're
good.
Okay.
Yes,
that's
what
I
have
to
say.
Thank
you
for
your
awesome
cool.
F
So
for
the
action
for
that
yeah,
diego
just
just
feel
free
to
keep
exploring
that
option.
I
think
we're
all
on
the
board
with
the
idea
so
cool.
We
have
five
minutes
left.
So
let's
try
to
kind
of
speed
through
this
stuff.
I
I
Can
you
oh
yeah,
so
I
think
oa
like
had
an
objection,
that
this
is
kind
of
opaque,
like
we're
just
listing
all
of
them,
and
if
you
click
on
them,
they
take
you
to
the
documentation
too.
For
instance,
you
click
on
yeah,
like
the
compression
one
actually
has
a
docs
string.
You'll
see.
I.
I
F
Say
I
see
okay,
so
I
guess
so.
I
was
the
one
who
added
the
this
pr,
and
the
question
is
like
so
for
this
issue.
I
think
the
the
oh
not
this
issue
this
issue.
I
think
the
point
of
this
was
that,
like
first,
we
needed
one
place
to
where
all
the
environment
variables
are
listed
and,
secondly,
like
we
needed
to
expose
like
what
they
meant
and
like
what
they're
used
for
to
customers
in
like
a
very
simple,
easy
way.
I
think
that
was
the
whole
purpose.
F
It's
great
that
you,
like
did
the
whole
like
read
the
docs
thing,
but,
like
I
think,
without
the
like,
the
actual,
what
each
of
the
environment
variables
do
and
what
they're
for.
I
think
it
actually
doesn't
solve
the
issue
that
we're
trying
to
tackle
here.
I
Makes
sense,
okay,
I
mean
is:
is
it
all
right?
If
I
just
remove
the
fixes
and
then
we
can
add
those
in
separate
pr's,
because
I
think
I
don't
have,
I
don't
know
if
we
even
have
like
doc
documentation
for
all
of
them
that
I
can
just
paste
in
right.
F
I
Okay,
so
how
about
I
remove
the
fixes
from
here
so
that
it
doesn't
close
that
issue
and
then
yeah.
F
Yeah
so
like,
if
you
want
to
add
the
sphinx
part
and
if
it
if
that
adds
value
to
that,
like
once
you've
addressed
a
waze
comment,
I
think
that's
fine.
I
haven't
really
looked
through
this
because
it
isn't
draft
but
yeah.
I
just
wanted
to
outline
that,
like
it
actually
doesn't
fix
what
we're
trying
to
do
for
1147.
So.
F
Yeah
any
other
comments
on
that
got
three
minutes
left.
Let's
just
speed
through
this.
F
G
Wait
so
what
should
we
do
like?
Should
we
just?
I
think
I
I
know.
Oh
you
put
comments
on
yesterday.
Thanks
for
taking
a
look
at
it,
I
think
the
original
concern
that
aaron
had
around
whether
the
behavior
and
getting
a
different
tracer
or
a
new
tracer
which
going
from
memory,
was
the
last
thing
that
I
remember
about
this
pr.
G
I
think
we,
I
think,
I'm
okay
with
it.
I
think
the
question
that
oau
asked
around
whether
we
should
be
using
like
a
simpler
version
of
what
this
is
doing.
I
I
think
that's
probably
the
way
to
go
forward.
That
being
said,
I
also
don't
want
this
pr
to
end
up
like
lagging
for
another
month
or
two,
so
I
guess
if,
if
anton
comes
back
with
an
answer,
it
will
be
good
to
make
sure
that
we're
on
this,
like
this
week
or
as
soon
as
he
responds
basically
he's
been
pretty
responsive.
So.
F
Yeah
wait
thanks
for
thanks
for
taking
a
look
at
this
well
we'll
try
to.
I
know
we've
been
lacking
on
this
pr,
but
I
think
we
owe
it
to
him
to
try
to
close
this
out
or
at
least
address
his
issues,
asap,
so
cool
yeah
also
like
aaron.
If
you
could
then
take
a
look
see
if
he
answered
all
your
questions
and
if
we're
okay
with
the
behavior
change,
I
think
we're
good
to
go
for
that.
So
yep,
okay,
one
minute
left
here
in
last
pr
yeah.
I
F
Cool
all
right,
also
guys,
if,
if
you,
if
you
addressed
everyone's
comments,
please
just
do
the
like
request
review
kind
of
option.
I
think
it
pings
everyone
on.
I,
I
literally
just
use
the
notification
bell
to
see
what
I
have
to
do,
so
I
think
it
would
be
good.
F
This
refresh
button,
because
I
don't
really
know
if
you've
updated
stuff
or
not
until
that
happens,
yeah.
Actually,
no,
that's
a
lie.
I
get
updated
every
time.
Someone
changes
something,
but
it
doesn't
mean
I'm
gonna,
look
at
it,
so
yeah,
okay,
cool.
I
think
that's
that's
everything.
I
will
see
you
guys
next
week.
J
F
F
Yeah
good
question,
so
taking
a
look
at
our
issues:
real,
quick,
we're,
making
really
good
headway
thanks
guys
for
jumping
on
board
for
trying
to
close
out
all
these
rct
issues.
We
have
all
of
them
assigned
already
some
of
them
with
pr's
out
already.
We
are.
F
I
think
it
would
be
good
to
set
a
deadline
for
what
we
want
to
do.
1.0
alex.
What
do
you
think,
given
that
we
have
11
issues
open,
that
we
need
to
close.
G
F
We'll
say
tentatively
19th
if
we
could
close
up
some
of
these
issues
so
make
sense
to
everyone
guys.