►
From YouTube: 2021-08-26 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).
C
Always
on
point
with
the
responding
to
people's
bugs
man,
I
know
he's
so
fast
so
fast
with
it.
It's
like
damn
yeah.
B
C
Just
give
people
a
couple
more
minutes
and
then
we'll
get
started.
B
B
By
accident
yeah
well,
but
don't
do
it
don't
don't
deal
with
me
yet
yeah,
let's
just
delete
these
people.
A
A
C
A
A
It's
like
the
opposite
of
burglar,
gloves,
yeah
yeah,
but
it
is
cold
here
in
germany
for
my
tropical
standards,
so
I
use
I
use
these
gloves
because
I
can
type
with
them
right
right.
It'll,
be
probably
I
mean
the
temperature
here
is
probably
nothing
that
many
people
will
consider
cold,
but
I
am
extremely
they
get
cold.
C
C
Yeah,
I'm
always
going
to
start
off
the
thursdays
with
the
wild
wild
meeting.
You
know
wild
8
a.m,
meeting
okay
cool!
We
can
get
started.
Let
me
share
my
screen
real
quick.
C
All
right,
okay,
so
I
was
out
last
week,
so
I
just
kind
of
pasted
a
bunch
of
topics
that
was
up
last
week,
just
to
kind
of
reiterate
what
was
decided
in
case
people
forgot.
We
did
have
a
release
yesterday
or
this
morning.
I
guess
thank
you
away
for
doing
that.
That
was
his
first
time
releasing.
We
had
a
couple
of
rants
a
couple
of
issues.
I
actually
can
let
away
speak
to
that.
Do
you
anyway,
you
want
to
talk
a
little
bit
about
the
process.
You
had.
E
Yeah,
the
press
was
quite
straightforward
and
all
the
automation
bits
worked
as
expected.
Everything
just
worked.
It
was
very
smooth.
There
were
some
gaps
in
in
the
documentation,
especially
around
how
to
to
deal
with
the
country
of
core
interdependency.
E
That
was
obvious
to
me,
because
I
know
that
one
of
both
the
referees
very
well,
but
probably
still
should
document
that
I'll
try
I'll
try
to
do
that
next
week
and
prepare
release
script.
That
updates
the
change
logs.
That
has
a
couple
of
bugs
so
we'll
try
to
fix
that
as
well.
So
then,
these
two
minor
issues
was
pretty
smooth.
A
A
A
B
A
A
C
Nice,
nice
all
right,
sounds
good,
so
the
next
topic
we
have
core
repo
passes
all
tests
on
windows.
Does
that
refer
to
the
pr
that
you
put
up
away
about
the
let's?
Do
this
or
something.
D
B
E
C
So
these
errored
out
when
you,
when
you
ran
the
talks,
build.
E
D
G
A
Sorted
and
that,
if
from
what
I
understand
from
recommend
that
happens
because
the
in
windows,
the
parents
have
seen
start
time
as
a
child,
so
that
doesn't
work.
That's
what
I
meant
with
separating
this
into
two
testing
paths
so
that
we
keep
the
exact
implementation
that
we
have
right
now
in
one
path
and
then
add
another
one
for
windows.
E
Or
or
maybe
I'm
not
yeah,
I
think
in
in
general,
it
makes
sense,
but
in
this
case
like
if
I
added,
if
you
added
something
specific
for
windows,
I
think
it
would
make
a
lot
of
sense.
But
in
this
case
I
think
we
generalized
it
even
more
instead
of
specializing
it
for
windows,
so
the
new,
what
I
replaced
it
with
is
even
more
like
even
less
platform
depending
so
okay,
the
new
implementation
works
for
all
platforms.
E
G
A
We
make
a
change
to
this
test
case
and,
for
example,
we
want
to.
I
don't
know,
test
the
order
of
the
spans.
A
Then,
if
that
happens,
we
will
probably
end
up
with
a
blog
that
is
hard
to
debug
because
it
fails
in
windows.
So
if,
if
we,
what
I'm
trying
to
say
is
that
you
have
valuable
knowledge
when
this
knowledge
about
the
the
the
start
time
being
the
same
in
department
charlie
in
windows.
That's
that's
very
valid
knowledge.
It's
a.
E
Yeah,
so
this
is
not
specific
to
this
test.
This
is
in
contributes
all
over
this
change.
You
can
see
in
country
vr,
so
I
I
agree
with
you
that
it's
platform
specific
knowledge,
but
I
think
what
we
should
do
here
is
probably
add
another
test
that,
like
serves
us
like
an
independent
test
that
just
specifically
tests
the
ordering
of
spans
like
time,
stamps
or
spam,
and
in
that.
D
E
D
E
Timing
is
not
precise,
so
maybe
I'll
create
an
issue
because
it
might
be
an
issue
actually
like
it
could
be
considered
a
bug
in
hotel
if
two
spans
there
are
a
few
nanoseconds
for
get
the
same
time
stamp
on
windows,
correct.
It's
probably
a
bug
anyway,
so
I'll
create
an
issue
for
that,
and
and
we
can
like
someone
can
take
it
up
or
I
can
take
it
up
and
we
can
investigate
and
try
to
fix
it
and
as
part
of
that,
we'd
also
like
add
a
test
case
for
this
situation.
G
All
right
that
should
take
a
little
bit
more
time
and
in.
A
Order
not
to
block
this
pr
I'll
be
more
than
happy.
If
there's
a
comment
just
in
this
pr
in
that
line,
yeah,
okay,.
F
C
E
F
Oh,
I
was
gonna
say,
first
of
all,
oh
wait.
There
was
like
an
issue
you
can
link
for
this
too,
which
I
think
was
actually
assigned
to
you.
Also.
I
was
I
was
looking
through
like
issues
a
while
ago,
and
I
was
I
was
like
oh
I'll,
never
get
to
that,
and
then
this
shows
up
so
nice
work.
Did
you
look
at
the
contrib
repo?
F
Yet
I
think
I
I
tried
to
do
this
for,
like
my
for
the
google
cloud
exporters,
and
then
I
ran
into
an
issue
with
grpc,
where
it
was
like
trying
to
build
grpc
from
scratch,
because
there
was
no
pre-compiled
version
for
like
windows
and
one
of
the
older
versions
we
support.
So
I
don't
know
if
you're,
if
you'll
still
hit
that,
but
I
think
control
will
probably
be
more
challenging
in
general.
E
Yeah,
I
don't
remember,
hitting
and
hitting
that
yeah.
I
don't
remember
running
into
that
issue.
There
are
some
other
issues,
though,
that
are
still
open
on
the
contract
I
fixed.
Most
of
them
need
to
look
into
a
couple
of
packages
that
are
failing
so
hopefully
next
week,
we'll
have
will
have
it
working
on
country
as
well,
but
yeah.
I
didn't
see
the
issue
with
grpc.
C
C
It's
one:
eight,
eight,
nine,
okay,.
C
So
I
don't
think
nathaniel
is
here
today,
but
I
think
we
talked
about
this
last
yeah
we
talked
about
this
last
week.
I
think
the
consensus
was
just
too.
C
C
Moving
right
along
okay,
I
remember
we
talked
about
metrics
last
week
too.
Just
to
reiterate,
diego
has
been
working
hard
on
the
sdk,
sdk
prototype
and
the
api
pr
I
just
wanted
to.
You
know,
link
it
here.
C
If
people
are
interested,
you
know
it's,
I
think
all
of
the
previous
comments
and
issues
have
been
addressed.
So
I
think
this
is
ready
for
review
so
feel
free
to
comment
on
this
thanks
yeah
yeah.
That
was
very
key.
A
Sure,
by
the
way,
I
made
a
mistake
in
this
pr
when
I
was
messing
up
with
git,
I
actually
accidentally
deleted
every
metrics
api
test,
so
I
need
to
adjust
at
the
back,
so
I
just
realized
that.
F
A
E
F
A
Oh
by
the
way,
now
that
you
mentioned
that
why.
D
D
C
C
F
C
C
Definitely
a
reason
there
was
definitely
like.
There
was
some.
There
was
some.
There
was
some
some
like
bugs
that
were
brought
up
that
wasn't
catched
by
our
unit
tests
when
incorrect
types
were
passed
in.
I
believe
something
like
that
and
my
pi
did
catch
them.
Yes,.
A
A
I
could
fix
it
thanks
in
my
point,
I
I'm
not
sure
if
that
is
worth
it
for
olivia
for
the
evening,
but
just
something
for
people
to
think
about.
C
Well,
if
you,
if
you
feel
strongly
about
it,
you
can
open
up
a
discussion,
but
I
don't
think
we're
enforcing
it
for
your
metrics
pr.
You
can
always
like
open
up
a
new
pr.
If
we
decide
that
we
need
it
so.
F
Yeah
I
mean
I
I'm
asking
because
I
mean
well.
First
of
all,
I
guess
I
personally
am
a
fan
like
we
have
a
pretty
big
code
base
at
this
point.
I
think
it's.
It
helps
a
lot
for
people
who
are
reading
the
code
so
even
without
running
the
type
checker.
F
It's
it's
pretty
helpful
because
sometimes
it
can
be
hard
to
like,
like,
for
instance,
if
you
take
attributes
and
and
you're
just
using
open
telemetry
for
the
first
time.
You're
gonna
have
no
idea
like
what
you
can
put
besides
a
dictionary
when
we
have
like
kind
of
specific
requirements
that
we'll
checked
about
like
if
it
can
be
a
list,
if
it's
nullable
et
cetera.
F
So
I
think
just
for
like
code
readability,
it's
pretty
good
and
then
also
we've
had
like
multiple
multiple
issues
open
where
people
are
like,
I'm
using
my
pi
and
I'm
using
open
telemetry,
but
the
like
stubs
aren't
published
like
people
want
them
in
general.
So
I
think
I
mean
personally
I
would
I
would
not
want
to
get
rid
of
them
and
I
think
they're
pretty
helpful
for
users
too,
but
just
like
from
like
a
reviewing
standpoint.
It's
nice
to
to
add
like
semantics
to
your
code,
at
least
I
think
so.
A
Those
are
good
value
points.
If
you
all
agree,
I
can
open
up
a
discussion
so
that
aaron
can
add
these
points
somewhere
and
me
as
well,
so
that
maybe
we
can
discuss
something
there.
A
Do
you
do
you
all
feel
like?
We
should
open
up
a
discussion
about
this.
C
C
F
C
F
The
other
thing
I
was
going
to
ask
is
like
we
have
some
of
these
sort
of
like
mix-in,
trait
kind
of
classes
that
are
just
markers
like
I
know
that
was
something
we
originally
had,
and
it
was
like
a
big
part
of
earlier
metrics
api
specifications
that
we
had
where
they
were
like
this
one's
grouping
and
this
one's
synchronous
asynchronous
and
it
was
sort
of
like
a
categorization
and
like
I
think
we,
I
think
it's
probably
less,
unless
it's
like
really
useful
for
the
sdk
implementation.
F
A
I
think
it
is
useful
for
yes,
okay,
but
I'm
not
totally
sure
so.
Just
please
leave
a
comment
there
so
that
I
remember
to
take
a
look.
Yeah.
A
That
it
is
necessary,
also
disclaimer,
grouping
and
adding
are
not
part
of
the
api
document.
B
A
An
official
concept,
but
it's
something
that
josh
mcdonald,
which
who
is
one
of
the
architects
of
all
these
metrics
things
added,
and
I
found
it
really
useful
because
it
kind
of
helps,
describes
the
nature
of
the
metrics.
In
fact,
I
don't
know
why
it
is
not
in
the
spec.
I
think
it
will
be
great
to
have
it
there
when
doing
the
implementation.
I
realized
that
it
was
very
useful
but
yeah
just
to
give
you
the
sorry,
the
the
complete
picture
about
grouping
and.
C
Yeah
aaron,
if
you
could
just
comment
on
the
pr
yeah
I'll,
definitely.
C
Stuff
yeah
cool
thanks
just
want
to
just
look
at
like
open
census,
implements
it
in
a
similar
way
as
well,
and
I
do
agree-
it's
like
very,
very
it's
not
as
intuitive
when
you
look
at
it,
but
in
terms
of
like,
as
diego
mentioned,
explaining
what
the
behavior
for
each
of
these,
because
there's
like
there's
many
permutations
in
which,
like
the
the
metrics,
can
take
and
like
these
properties
are
kind
of
just
like
like
decorated
onto
like
the
base
class
and
it
it.
C
It
makes
sense
in
that
way.
So
right,
right.
F
I
guess
my
thing
is
like
if
we
can
keep
it
out
of
the
public
api
for
now,
I
think
it'd
be
good
and
then
we
can
evaluate
because
like
if,
for
instance,
we
wanted
to
rename
them
or
we
found
out
that
one
of
them
wasn't
quite
right,
like
people
could
be
relying
on
his
instance,
checks
and
stuff
like
that
down
the
line
and
like
we
could
leave
them
yeah,
we
could
leave
them,
make
them
like
private
or
something
like
that.
I'm
I'm
fine
with
that.
F
I
think,
like
one
big
feedback,
I
saw
with
the
metrics
the
the
older
metrics
spec
was
that,
like
there
were
six
instruments
and
it
was
too,
they
were
kind
of
confusing
and
it
was
sort
of
approached
very
mathematically
as
opposed
to
like
how
other
instrumentations
do
it,
where
you
just
have
like
counter
and
histogram
for
the
most
counter,
histogram
and
game.
So
yeah,
just
just
my
two.
I
don't
know
how
useful
it
is
for
users
and
just
maybe
we
could
keep
it
out
to
start.
But
I'll
comment
on
the
pr.
So.
C
Okay,
cool
sounds
good,
nice,
any
other
topics
that
people
want
to
talk
about
before
we
go
into
the
prs.
C
All
right
cool
all
right
starting
off.
I
think
this
is
diego's
pr,
yep
cool,
so
we've
added
registers
to
check
keys
and
values.
I
think
we
have
a
bunch
of
comments
on
here.
C
Okay,
I
guess
they
just
need
to
be
addressed.
Yeah.
A
C
Yeah,
if
you
could
just
address
those,
I
think
we
have
a
lot
of
reviews
for
this
already.
So
I
don't
think
any
more
feedback
is
needed,
but
cool.
E
C
I
think
we
already
got
the
approvals
for
this,
but
if
anyone
wants
to
take
a
look
at
khan's
pr
for
just
adding
a
few
docs
at
what
the
logging
exporter
would
look
like
feel
free
to
take
a
look
at
this,
I
did
have
a
question
related
to
the
trace
context
stuff.
C
So
basically,
my
question
is
like:
will
the
collector
output
be
showing
trace
related
information?
Circon,
oh,
is
that
something
separate.
C
Okay,
that's
okay!
I
will
just
continue
the
discussion
in
the
pr
then,
if
that's
cool,
no
worries.
C
Instrument
entry
points,
so
I
think
I
believe
the
discussion
ended
was
that
we
are
going
ahead
with
this
change.
I
think
please
take
a
look
at
this.
I
think
yeah,
like
diego
changes,
so
that
it's
like
super
straightforward
now
and
super
bare
bones
after
many
many
iterations
so
yeah.
I
think
it's
simple
enough
to
know
what
we're
talking
about.
C
I
think
I
think
we
have
time
diego
to
talk
about
like
what's
next
what
you
were
talking
about
before,
just
like
quickly,
iterate,
what
your
plan
is,
after
this
is
merged.
Yeah.
Can
you
please.
B
Open
the
discussions
sure.
A
All
right
there
should
be
a
discussion
in
separate,
no
define
the
problem
set
all
right,
so
that's
the
the
problem
set
next
thing
that
we
need
to
do
is,
I
think,
work
on
item
one.
A
These
changes
that
add
the
pre
and
post
instrument
entry
points
well,
as
you
just
saw
only
at
those
center
points,
but
the
distro
base
class.
This
is
still
living
in
the
instrumentation
package,
so
I
think
the
first
thing
we,
the
next
thing
that
we
should
be
doing
now-
is
moving
that
distro
class
into
their
own
separate
package.
Now,
once
that
we
or
I
mean
if
we
do-
that,
we
also
will
also
need
to
make
a
decision
on
the
name
of
the
package.
A
A
So
I
in
my
previous
pr,
I
suggested
to
only
keep
the
configurator
thing,
because
it
has
a
more
representative
name
that
distros
in
my
opinion,
but
but
yeah.
So
I
think
actually,
that's
that's
the
the
next
topic.
Should
we
keep
both
this
throw
and
configurator,
or
should
we
only
have
one
and
if
so,
how
should
it
be
named.
C
Right
right,
so
I
I
know
that
at
least
within
azure
and
like
I,
I
think
there
is
something
in
the
specs
too,
like
distros
is
a
it's
a
common
term
that
people
are
used
to
already
right.
C
Was
kind
of
just
something
that
we
kind
of
just
made
up
at
the
time
when
we
were
implementing
auto
instrumentation?
C
So
if
you
feel
strongly
that
both
of
them
kind
of
do
the
same
thing
like
my
preference
is
like
we
keep
the
distro
name.
Okay,
we
don't
need
both
of
them.
Yeah.
A
C
A
Okay,
so
what
we
can
do
is
that
I
mean
assuming
that
this
entry
point
pr
gets
merged
is
that
after
that
happens,
I
can
create
another
pr
that
moves
the
distro
class
into
its
own
package
separating
both
and
removes
the
configurator
thing.
B
A
I
mean
one
of
the
problems
that
we
have
is
that
the
this
draw
is
coupled
with
instrumentation,
as
you
can
see
here
so,
and
that
happens
because,
oh
you
mean
here
right,
yeah
yeah,
exactly
so
the
solution,
and
that
is
a
problem
and
the
solution
for
that
is
to
have
have
destroyed
the
the
distro
base
class
into
its
own
package.
A
You
mean
that
currently
there
is
a
oh
sorry,
oh
yeah,
okay,
yes,
we
we
should
sorry.
Yes,
we
should
move
the
the
bases
for
class
from
the
instrumentation
package
to
the
distribution.
C
Was
there
any
problems
with
this?
There
might
have
been
a
reason
why
we
weren't
able
to
do
that,
and
maybe
we
do
need
a
new
package.
Does
everyone
anyone
remember.
C
Right
so
so,
open
telemetry
dash
distro
should
only
be
like
the
open,
telemetry
implementation
of
a
distro
right.
A
Right,
yeah
away
raises
a
valid
point.
I
mean
this
plan
that
I
have
assumes
that
we
will
find
a
solution
for
the
selection
of
the
this
for
the
multiple
disorder
right
right.
C
To
have
less
packages,
if
we
could.
C
Like
to
have
less
packages,
it's
just
it's
just
simpler
for
users.
C
A
Yeah,
why
is
that?
Because
that
way,
you
don't
get
these
dependency
problems
for
stuff.
C
Oh
yeah,
as
a
as
a
implementer
as
a
developer.
That
makes
sense,
but
let's
say
we
do
come
up
with
a
new
package
called
open,
telemetry
based
distro,
or
something
like
that
right
for
just
just
to
like
hold
the
the
stuff
we're
trying
to
move
out
from
open,
telemetry
instrumentation
right.
C
A
Oh
no,
no!
No,
I
was
I
was
thinking
sorry.
I
think
I
was
arguing
against
not
moving
based
this
way
out
of
opportunity,
transformation.
E
By
the
way
you
you
mentioned,
the
spec
respect
mentions
this
journal.
Has
anyone
looked
at
what
the
spec
expects
of
register.
E
C
That's
what
I
was
thinking
before
yeah
if
it
becomes
like
a
like
a
necessity.
A
C
C
If
that's
the
case,
then
we
have
to
move
out
like
auto
instrumentation
logic
as
well
right.
All
of
those
are
not
specked
out
so.
C
It's
not
that
like
it's,
what
we've
moved
them
out,
because
they're
not
specked
out,
that's
one
of
the
reasons,
but
it's
mostly
because,
like
they
are
like
isolated
enough
that
we
can
develop
them
as
features.
A
Yes,
the
only
thing
that
I'm
concerned
with
is
that
it
seems
like
there
at
least
there
is
an
intention
to
specify
the
distros
and
we
are
already
working
on
on
the
implementation
of
the
distro.
So,
what's
going
to
happen,
if
the
spec
ends
up
specifying
something
that
goes
against
our
implementation
and
we
have
already
released
a
public
api
right
so.
E
E
C
Cool
all
right,
great
convo,
guys
so
we'll
get
this
merged
in
real
quick
and
then
I
think
that
is
a
good
direction
that
we're
heading
to
address.
Point
number
one
thanks,
diego.
A
Oh
that
beer-
I
I
was
trying
to
help,
but
I
think
I'm
making
things
worse.
A
Yeah
alex
opened
this
pr
that
changed
the
this
port
to
8,
and
then
I
think
shri
kant
or
no
sorry
away
informed
us
that
it
should
be
four
three
one
one,
seven
right
so
alex
is
out
on
vacation.
So
I
tried
to
add
a
commit
on
this
pr
that
changed
that
to
this
other
number,
and
now
the
docker
tests
are
failing.
A
C
C
E
A
A
A
C
Yeah,
if
yeah.
E
C
Investigation
but
yeah
like
if
it's
several
degrees
better
than
your
job
away,
that
has
been
causing
some
annoyance
that
we
had
to
keep
re-running
the
builds
so
yeah.
C
F
Like
another
test
issue
too,
with
the,
I
think
it
was
elastic
search,
it
was,
it
wasn't
flaky,
but
I
think
we
disabled.
C
F
And
there
was
an.
F
Yeah,
I
don't
know
if
there's
anything
to
discuss
it
looks
like
it
looks
like
we
just
need
to
update
the
mock.
Maybe.
F
Commented
them
out
in
the
talks.
F
Yeah,
I
wonder
I
wonder
if
the
I
saw
a
lot
of
bugs
around
this
and
I
kind
of
wonder
if
they're
gonna
make
another
release
that
might
fix
it.
So
it's
all
bugs.
C
Filed
against
elasticsearch
version,
seven
yeah
yeah.
F
C
C
Cool
any
other
prs
or
issues
that
people
want
to
get
addressed
before
we
move
on
15
minutes
left
we're
pretty
doing
pretty
well
on
time
today,.
F
Looked
at
it
briefly,
I
think
basically,
the
issue
is
that
there's
no
like
use
context,
context
manager.
So
if
you
set
baggage,
you
have
to
call
attach
and
then
detach
the
token
instead
of
just
using
like
a
with
like
you
would,
with
the
use
span,
context
manager.
I
think
we
discussed
this
or
maybe
I
like
pinged
in
slack
about
it
or
something.
I
think
it's
just
sort
of
something
we
missed
kind
of
like
a
convenience
thing,
almost.
A
Yeah,
on
the
other,
by
the
way
when
we
were
implementing
this
context
thing
with,
attach
and
detach
it
also
caught
my
attention.
The
fact
that
this
was
a
python
standard
library
feature
and
they
had
not
implemented
it
with
a
context
manager.
So
I
mean
I'm
not
sure
if
this
is
something
that
we
should
should
be
asked
directly
to
to
the.
F
A
I
mean
we
can
do
we
can
do
it,
but
in
the
in
the
same
spirit
as
the
remember
these
assert
not
racist,
mixing
that
I
implemented.
It
is
something
that
is
completely
outside
of
the
scope
of
open
telemetry.
A
I
I
understand
that
it
will
be
convenient
to
have
it
so
I'm
I'm
complete,
I'm
not
against
having
it.
I
mean
if
there
was
a
pr
and
I'll
probably
update
it,
but
just
wanted
to
point
this
out,
because
if,
if
we
do
it
then
we'll
be
adding
something
to
our
public
api
that
is
not
related
to
open
telemetry,
I
mean
we
don't
have
to
be
that
strict
about
it,
but
something
to
consider.
C
Okay,
so
I
remember
we
added
some
something
related
to.
There
was
another
like
api
method.
We
added
to
the
sdk,
that's
related
to
context.
It
was
on
the
span
or
something
like
that
and
that
wasn't
actually
explicitly
called
out
in
the
specs
either,
but
we
added
it
as
a
convenience
thing,
but
does
anybody
ever
know
kind
of
like
what
I'm
talking
about.
C
C
No,
no,
not
that
one,
not
that
one
but
anyways
yeah,
sorry
that
that
was
a
while
ago
also
aaron.
I
think
yeah.
E
C
Know
if
I
might
be
guessing,
but
was
the
reason-
maybe
we
didn't
add
this
last
time.
I
remember
talking
about
something
like
this,
but
it's
because
like
like
the
the
tokens
adding
and
removing
them,
sometimes
they
can't
be
like
encapsulated
or
something
within
like
a
certain
and
then
one
context,
something
like
that.
C
A
You're
talking,
that
could
be
a
reason
why
it
is
not
implemented
in
the
python
in
the
standard
library
itself,
because
it's
the
most
common
cases
that
they
need
to
be
handled
in
separate
scopes.
Right.
A
F
C
Yeah
but
like
in
terms
of
the
instrumentation
or
that
use
case
like
we
don't
actually
call
use
spam,
I
mean
we
don't
pretty
sure
we
set
the
token
explicitly
for
some
instrumentations
or
something
but
anyways
yeah.
F
C
I
think
the
main
thing
was
what
diego
pointed
out
like
if
we
do
add
it
to
our
api.
It's
like,
I
think,
with
the
guarantee,
but
if
this
is
a
compelling
enough
feature
and
like
I
don't
foresee
it
causing
us
a
lot
of
issues,
but
you
know,
then
maybe
we
can
just
add
it
as
a
convenience
thing.
If
it's
cool
you
know.
C
E
E
E
C
A
D
F
So
so
then
I
mean
we
could.
We
could
add
one
for
baggage.
That's
like
use
use
baggage
too,
because
I
think
in
baggage.
It
definitely
makes
more
sense
to
to
have
it
kind
of
like
this.
Like
you'd
set,
you'd
set
a
baggage
value,
make
some
requests
and
then
like
you'd,
want
all
your
metrics
to
have
that
baggage,
and
then
you
would
detach
after.
F
A
B
C
Okay,
we
can
just
continue
the
discussion
in
the
discussion.
F
Damn
it
the
other
discussion
thing
I
added
was
somebody
asking
for
like
a
release
schedule
and
then
hopefully
they
said
we
were
doing
this.
I
think
I
think
this
has
come
up
a
few
times.
I
don't
know
if
anybody
else
has
any
other
topic
we
can
discuss.
That
might
be
more
important.
We
can
just
skip
it
since
I
think
we
already
have
that
one
before
yeah
the
release
schedule.
C
C
I
think
this
is
this
is
fine
in
terms
of
having
a
release
schedule,
it's
just
a
matter
of
like
when
we
decide
to
implement
it.
So.
F
Yeah
yeah,
I
guess
I
guess
the
controversial
topic
here
would
be.
We
could
like
use
conventional
commits
and
then
do
automated
releases,
so
it
would
figure
out
the
like
if
it's
a
batch
or
minor
version
or
whatever
I
don't
know.
If
anybody
wants
wants
to
automate
more,
I'm
I'm
not
the
one
with
the
burden
of
the
maintenance,
though
so.
C
I
think,
like
just
without
even
considering
autoing
more
into
question
like
it's
fine
for
us
to
do
this.
If
it's
a
monthly
cadence,
that's
like
our
normal
velocity,
regardless.
C
Oh
wait:
do
you
go?
What
do
you
guys
think
like
should.
E
A
A
I
mean
sorry
away
just
released
right.