►
From YouTube: 2021-05-05 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).
D
C
C
Yeah
this,
the
top
paragraph
still
mentions
getter.
I
thought
that
most
folks
moved
to
slack
now.
E
E
Okay
about
five
minutes
after
the
hour,
so
I
think
we
can
get
started.
The
first
thing
I
wanted
to
talk
about
was
this:
suppress
instrumentation,
api
method
that
we
had.
The
tc
has
asked
us
to
move
this,
and
before
I
open
a
pr,
I
wanted
to
make
sure
we
were
all
in
agreement
about
where
it's
being
moved
to.
E
So
I
was
going
to
open
a
pr
to
create
a
api
extensions
package
in
the
core
repo
and
before
I
did
that
I
just
wanted
to
make
sure,
particularly
with
bart
and
valentine
that
that
sounds.
Okay.
F
Yeah
yeah,
I
I
was
arguing
on
the
on
the
issues
about
implementing
and
sharing
a
key
inside
core,
but
I
think
it's
a
it's
easier
to
have
an
extension
and
maybe
in
the
future
we
will
add
more
stuff
to
it,
but
actually,
when
I
think
about
it,
could
we
because
the
metrics
api
is
currently
another
package?
Could
we
somewhat
merge
them
at
some
points
like
since
it's
not
on
the
main
api.
E
F
Yeah,
I
think
it's
to
avoid
even
too
many
api
package.
We
already
have
a
lot
of
a
lot
of
package.
So
that's
what
I
was
the
thing
that
I
was
writing
on
the
issues.
That's
I
I
think
it's
quite
hard
for
for
new
users
and
even
new
contributors
to
to
find
what's
what
was
their,
what
they
want,
sorry
on
what
they
are
looking
for
across
two
or
three
reports
and
maybe
or
20
of
the
30
packages,
but
we
will
not
have
the
new
people
here.
E
F
Yeah
but
the
the
matrix,
the
matrix
api
is
on
the
core
repo
too.
So
I
was
I
was
suggesting
like
since
it's
pretty
much
the
same
since
it's
not
actually
specs
on
the
on
the
api
side.
Maybe
we
should
like
rename
the
api
matrix
that
we
have
like
to
to
be
an
extension
and
then
add
the
context
stuff
inside
it
like
api,
experimental
or
something
like
that,
yeah
yeah,
exactly.
E
Yeah
I
mean
that
works
for
me,
speaking
of
metrics.
I
don't
have
it
on
the
agenda
today,
but
I
know
the
metrics
specification
has
made
a
lot
of
progress
in
the
last
couple
of
weeks
and
months.
So
it's
probably
time
for
us
to
start
spending
some
some
real
time
on
that
again
soon.
E
E
E
Next
thing
I
wanted
to
talk
about
is
a
couple
of
bugs
that
we
still
have
open
this
first
one
isn't
assigned
to
anyone.
Yet
I
already
have
quite
a
few
things
assigned
to
myself,
so
I
was
hoping
for
a
volunteer
for
this.
It
should
be
relatively
easy,
though,.
G
E
Thank
you
for
these
next
three
or
for
the
next
two.
There
are
already
pr's
open,
so
they
just
need
to
be
reviewed,
so
I
won't
talk
specifically
about
them,
but
please
review
them
and
this
fourth
one
we
talked
about
this
last
week.
I
don't
actually
know
if
this
is
a
bug
or
not.
It
was
originally
opened
in
a
different.
E
A
I
was
looking
into
this,
but
it's
mentioned
that
they
use
the
aws
collect
exporter
and
I'm
not
really
sure
if
they
use
our
or
it
was
someone
mentioned
but
yeah.
I
didn't
look
very
like
getting
and
trying
just
reading
through
this
one
I
will
get
back
to
this
today,
but
there
was
some
mention
about
the
aws
exporter
which
is
between.
I
don't
know
either
it
was
in
the
in
the
yam
file
or
mentioned
here.
E
E
There
are
also
there
was
a
pretty
old
bug
that
was
assigned
to
valentine
that
there
are
two
pr's
open
for
for
configuring,
the
sdk
using
environment
variables
and
they
both
need
reviews
and
approvals.
It
looks
like
this
one
actually
is
pretty
close.
E
Oh
yeah
so
valentine
I
commented
on
this
earlier,
but
I
I
I
think
this
name
might
be
confusing,
since
it's
actually,
but
once
once
that's
fixed.
I
think
this
is
mergeable.
E
I
don't
know
if,
where
is
on
the
call
or
not,
it
looks
like
no,
but
I
talked
to
him
about
these
yesterday
and
he
said
that
he
should
have
time
today
to
work
on
them.
So
hopefully
he's
working
on
these.
E
The
next
two
here
are
done:
they're
just
pending
tests
and
reviews
and
conflict
resolution,
so
these
should
hopefully
be
merged
today.
If
we
can
these
next
two
require
changes
in
multiple
pr's
or
in
multiple
repos,
so
they're
being
worked
on,
but
changes
across
multiple
repositories
are
always
a
little
bit
slower.
E
So
timely
reviews
definitely
help
move
these
things
along.
It
looks
like
already
got
all
three
pr's
open
for
his,
so
he's
just
waiting
for
reviews
and
I'm
still
wait
still
working
on
my
second
pr
so,
like
I
said,
timely
reviews
are
always
helpful.
E
This
using
spam
context
for
link
this
is
actually
has
enough
approvals
already,
but
I
wanted
to
get
your
review
on
this
part
if
possible,
just
because
changes
to
the
api.
I'd
like
to
oh-
and
I
thought
valentine-
had
reviewed
this-
to
maintain
your
reviews
on
this.
Just
to
get
this
because
it's
the
api,
I
want
to
get
as
many
maintainer
reviews
as
possible.
E
Sorry
valentine,
I
thought
you
had
already
reviewed
it
and
this
last
one
I
assigned
to
myself.
I've
not
opened
the
pr
on
this
yet,
but
it
will
probably
require
changes
across
multiple
repositories.
E
E
Sounds
like
no
so
rauno,
I
don't
know
if
I'm
pronouncing
that
correctly
or
not.
C
C
Yeah
sure,
so
there
is
a
like
lengthy
description
of
the
issue
there
on
the
github
issue
as
well.
But
this
essential
point
is
that
many
of
our
instrumentations
basically
are
no
ops.
E
Yeah,
there
are
certainly
multiple
instrumentations.
I
I
know
express
is
one
of
them,
but
I
think
the
other,
like
http
framework
instrumentations,
are
kind
of
the
same
way
and
I
believe
the
mongodb
or,
like
the
database
ones,
do
the
same
thing.
E
We
did
this
in
order
to
prevent
having
a
bunch
of
orphaned
root
spans.
Essentially,
so,
if
you
don't
have
a
parent
span
and
you
make
a
bunch
of
mongodb
spans
that
can
be
confusing
in
a
different
way.
C
E
So
I
know
at
least
some
of
those,
if
not
all
of
them
have
a
configuration
for
this.
I
think
actually
florina
mentioned
it.
Oh,
no!
That's
the
ignore
incoming
paths.
E
I
believe
there
is
a
configuration
for
allowing
it
to
create
spans
with
no
root
as
far
as
how
the
you
know
whether
they
should
be
children
of
each
other
or
siblings
or
whatever.
I
think
that
that's
going
to
be
different
on
a
per
instrumentation
basis,
but
even
you
know
for
express,
for
instance,
if
you
just
create
three
parentless
spans
for
the
middleware.
E
That
would
be
super
confusing.
So
maybe
we
should
create
one
parent
span
to
wrap
these
three
spans
or
something
like
that.
Creating
them
as
children
like
this
one
is
a
little
bit
more
difficult
and
doesn't
necessarily
make
sense
because
the
middlewares
are
not
actually
children
of
each
other.
You
know
in
the
actual
the
culture
of
the
program
they
don't
they
don't
call
each
other.
So
this
parent-child
relationship
doesn't
make
as
much
sense
to
me.
E
A
C
I
mean
if
you
are
looking
to
measure
any
of
your
handlers
in
isolation,
for
example,
you
would
want
to
see
something
and-
and
I
kind
of
think
it's
it-
it
comes
with
like
two
issues
here.
One
is
the
usefulness
of
the
data
that
comes
out
in
the
situation
where
there
is
no
apparent
span
to
attach
the
handler
span
to,
but
another
one
is
that
kind
of
the
know.
C
What
way
out
of
that
situation
is
is
even
worse
in
my
mind,
so
it's
not
only
that
that,
like
only
having
a
expert
instrumentation
installed,
would
be
very
beneficial
per
se,
but
it's
also
that
if
I'm
installing
a
expert
instrumentation,
it
doesn't-
and
it
doesn't
have
happen
to
have
a
parent
span
over
direct
the
whole
request.
C
Then
it
basically
does
nothing
not
basically
it
does
nothing,
and-
and
there
is
no
configuration
option
for
this,
nor
any
log
entries
for
it
or
no
errors,
so
basically
nothing
so
so
an
operator
wouldn't
know
what
to
do
in
that
sense
or
why
it's
not
working,
and
that
that's
one
of
the
reasons
for
the
second
option
here,
that's
about
having
apparently
spent
is
that
at
least
an
operator
would
kind
of
get
that
hint
that
okay,
I
see
all
of
my
handlers
are
appearing
as
spends
here,
but
there
is
no
parent
spence
for
them,
so
maybe
I'm
lacking
http
instrumentation
or
I
don't
know
how
how
intuitive
it
might
be
for
for
someone
who's
setting
this
up.
A
E
Not
necessarily
true,
in
every
case
you
could
have
like
you
know,
a
set
timeout
or
said
interval
that
pulls
a
database
or
something
like
that,
and
then
the
database
span
would
be
the
first
span.
You
see.
A
Okay
but
shouldn't
you,
then
create
basically
a
span
and
run
those
everything
inside
the
context
of
the
span.
Like
I
don't
know,
call
it
interval
execution
of
database
check,
create
a
span
and
run
the
query
in
the
context
of
of
the
span,
and
then
you
have
like
perfect
way
of
doing
this.
A
C
And
I'm
also
kind
of
reluctant
to
add
the
span
automatically
that
that
spans
the
whole
request,
because
it's
kind
of
re-implementing
what
the
http
instrumentation
does.
So
I
would
be
afraid
of
a
situation
where
we
would
basically
re-implement
http
instrumentation
in
all
of
the
framework
instrumentations.
If
you
understand
what
I
mean,
I.
A
A
But
here
you,
your
action
would
be,
I
don't
know
some
interval,
so
I
think
you
should
basically
instrument
this
interval
and
then
create
everything.
What
is
happening
in
the
callback
for
decision
terval
into
a
new
span,
because
that
was
basically
the
executor
of
this
of
this
whole
flow
here,
because,
like
imagine,
you
have
the
callback,
as
you
said,
and
you
do
three
different
requests,
one
of
two
database
postgres
mysql
and
mongodb.
A
What
should
be
the
parent
of
them?
Who
should
create
the
parent
which
instrumentation
it's
just
impossible?
So
it's
the
responsibility
of
this
particular
interval
that
should
create
a
span
which
you
can
call.
I
know
getting
fetching
information
from
databases
and
run
everything
else
into
this
particular
context.
E
C
Yes,
so,
basically,
while
implementing
another
framework
like
web
framework
instrumentation
for
router
package,
I
noticed
that
that's
kind
of
I'm
still
struggling
to
understand.
What's
the
expected
behavior.
C
So
how
should
I
implement
the
new
instrumentation
when
the
reasonable
parents
spend
and
for
me
it
was
unintuitive
to
not
do
anything
if
if
there
is
no
parent
spend
and
as
florida
mentions
in
the
issue
as
well,
the
parent
spend
might
not
be.
You
know
the
request
spend
at
all
so,
and
that
creates
another
case
which
is
in
the
instrumentation.
We
don't
actually
know
whether
we
are
dealing
with
the
http
span
or
not,
and
most
of
the
frameworks
actually
expect
the
http
span
to
be
there
because
they
will
be
renaming.
D
C
And
there
is,
there
is
another
issue
about
that.
I
think
both
of
you
were
involved
with
that
as
well.
So
it's
it's
more
of
a
question
like
how
should
I
implement
other
like
framework
instrumentation.
E
So
I
think
it
sort
of
depends
on
you
know
a
case-by-case
basis,
essentially
so
with
express
as
an
example.
The
way
that
express
is
implemented,
the
you
have,
the
the
middleware
spans
are
all
siblings
of
each
other,
and
if
there
is
no
parent
span
to
contain
them
all,
then
you
just
end
up
with
a
bunch
of
parentless
spans
with
no
real
meaning
like
it
would
be
really
difficult
to
derive
any
value
from
that.
E
But
if
you're
implementing
a
different
web
framework
that
doesn't
work
that
way
that
doesn't
have
that
you
know
sibling
middleware
context.
Maybe
it
does
have
like
some
global
request
method
that
you
could
instrument
to
get
an
entire
span
from
start
to
end
and
it's
useful
without
the
http
instrumentation.
E
I
just
think
in
the
case
of
express
at
least
it
made
sense
to
do
it
that
way,
and
you
could
make
the
argument
both
ways,
probably
for
most
of
them,
but
it
was
really
just
at
the
time
that
whoever
it
was
that
wrote
these
instrumentations,
you
know
thought
that
this
was
the
way
that
made
sense
to
them
and
that's
the
way
they
did
it.
None
of
this
behavior
is,
you
know,
specified
by
the
specification
or
anything
like
that,
and
it's
all
you
know,
essentially
what
makes
sense
for
the
given
instrumentation.
E
I
know
the
behavior
is
configurable
for
some
of
them,
but
I
think
it's
not
configurable
for
others,
and
I
I
guess
it's
just
it's
really
up
to
you
as
the
instrumentation
author.
If
somebody
uses
your
instrumentation
and
does
not
have
the
http
information
instrumentation
installed,
will
they
get
any
value
out
of
your
instrumentation?
C
Okay,
thanks
very
much,
I
got
some
good
feedback
here.
I
might
come
back
with
a
question
for
you,
daniel
at
least
or
maybe
part
as
well,
just
like
with
the
case
of
actually
still
having
a
like
a
hand,
drill
like
parentless
handler
spends,
but
but
other
than
that,
thanks
for
the
for
the
collab
on
this
thanks.
G
Yeah
can
can.
Can
I
ask
a
question
on
that,
so
maybe
maybe
a
misunderstanding
something
entirely
on
open
telemetry,
since
I'm
not
that
deep
into
it
yet,
but
in
the
case
of
express
I
mean,
does
it
even
make
sense
to
not
have
the
http
instrumentation
loaded?
So
is
there
no
way
to
say
like
hey
if
I
load
the
express
instrumentation
also
load
the
http
instrumentation
like
a
hard
dependency?
E
I
mean
that
is
a
valid
question.
It's
not
none
of
our
dependents
or
none
of
our
instrumentations
currently
depend
on
any
other
instrumentation.
E
That
used
to
not
be
the
case
we
had
like
https
depended
on
http
for
a
while,
because
there
was
a
lot
of
shared
logic,
but
I
think
currently
we
don't
have
any
that
depend
on
another
one
in
the
case
of
like
express,
I
think
that
it
totally
would
make
sense,
but
in
the
case
of
something
like
mongodb,
which
one
would
you
have
as
the
parent
there's
no
yeah.
G
Sure,
but
if
the,
if
the
dependencies
is
a
given,
I
mean,
or
if
you
say,
hey
http,
I
always
also
want
to
load
the
net
library
or
dns,
or
something
like
that.
So
to
not
have
like
an
endless
list
of
things
to
load,
I
mean
at
some
point:
did
the
question
is
like:
do
we
really
need
all
of
them
or
some
of
them,
but
this
this
is
something
I
was.
I
was
wondering
as
well.
C
One
more
issue
with
that
might
be
that
that
the
http
instrumentation
is
is
a
catch-all,
so
the
http
instrumentation
does
not
know
which
one
of
those
spans
it
creates
actually
will
end
up
being
inside
the
express
framework
right.
So
it
happens
before,
and
if
the
user
doesn't
actually
configure
the
http
instrumentation
themselves,
they
might
get
a
lot
of
spans
from
http
instrumentation,
which
they
didn't
expect
to
be.
There
like,
for
example,
outgoing
requests
and
basically
anything.
A
A
E
Another
problem
that
you
have
is
a
version
conflict,
so
if
the
express
instrumentation
that
you
have
depends
on
some
version
of
the
http
instrumentation,
but
then
the
end
user
application
wants
to
use
some
older
version,
for
instance,
and
they
pin
a
version
and
the
versions
don't
match.
Then
npm
will
happily
install
both
of
them
in
the
node
modules
tree,
which
then
you
end
up
with
some
extremely
confusing,
because
these
instrumentations,
by
the
very
nature,
are
patching
the
load
process.
E
E
F
And
I
would
like
to
add
about
this.
That's
I
think
each
I
mean
we
mentioned
some
issues
with
instrumentation
having
instrumentation
as
dependencies
or
optional
extra,
and
I
I
think
that
should
be
the
job
of
of
what
we
call
meta
packages
which
actually
bundle
every
dependencies
that
we
that
you
want.
That
user
should
expect
like,
for
example,
express
an
am
and
http
that
are
banded
together.
F
So
I
mean
end
users
that
just
want
something
that
works
just
use
the
meta
packages
that
install
all
the
instrumentation,
so
you
just
don't
need
to
look
at
wait,
do
do
which
information
with
instrumentation
do
I
need
to
load
extra
extra,
so
I
think
it's
just
the
job
of
another
packages
to
to
actually
and
we
we
tend
to
to
to
go
into
this
direction
with
all
of
our
sdk.
F
For,
for
example,
in
the
car
we
had
the
discussion
last
week
with
with
the
tracing
sdk
that
need
to
be
configurable
via
the
environment,
about
which
exporter
do
we
need
to
use,
but
we
we
don't
really
want
to
have
like
or
or
low
level
sdk
to
have
all
the
dependencies
that
is
needed
to
to
be
able
to
configure
it
via
the
environment
like
each
exporter.
E
I
think
something
we
could
do.
That
is
easy,
and
probably
uncontroversial
is
if
in
each
instrumentation
like
in
the
express
instrumentation
if
a
span
is
going
to
be
created,
but
there
is
no
parent's
fan
and
we
don't
create
one.
We
log
just
log
the
first
time
that
happens
log.
This
was
skipped
because
there
is
no
parent
span.
F
I
think
it's
already
controversional,
because
I
really
the
api
by
default,
the
api
doesn't
log
anything,
it's
already
discussed
that
it
doesn't
need
to
to
log
and
it
shouldn't
log
by
default.
So
by
default,
if
someone
just
just
plug
in
something
and
doesn't
understand
it,
it
will
just
not
see
the
log
actually
so
and
for
people
that
that
know
what
they
are
doing.
They
will
get
the
lock
too.
So
I
don't
think
that's
that's
an
easy
solution.
G
It
would
be
helpful
to
have
it
then,
at
least
in
the
documentation
like.
If
they
do
nothing,
then
it
should
at
least
be
in
the
really
in
the
high
level
documentation.
So
in
the
readme
md,
or
something
like
that
to
say,
like
hey
this
package
is,
is
not
sending
you
any
spans
if
you,
if
you
not
have
something
like
a
parent
like
the
http
instrumentation,
so
people
are
not
searching
like
crazy.
Why
this
is
happening.
E
Yeah,
certainly,
I
think
that
that's
it
should
happen
right
if
it's
not,
I
think
it
actually
is
documented,
but
if
it's
not,
it
should
be.
F
I
mean
since
some,
so
I
I'm
I'm
not
sure
I
wrote
the
express
package
and
instrumentation,
but
I'm
not
sure
if,
if
I
added
an
option
to
to
ignore
the
to
just
to
be
able
to
control
if
the
spanner
is
created,
if
there
are
no
parent
spam,
I'm
pretty
sure
it
is
not,
but
even
so,
if
even
if
it's
in
the
config,
I
think
it
should
be
on
the
top
level
as
severine.
If
I'm
pronouncing
correctly
too
is
a
should
be,
it
should
be
on
the
top.
F
Read
me
that
by
default
it
doesn't
it
doesn't
do
anything
if
you
don't
have
a
gtx
press,
http,
sorry
instrumentation
enabled.
G
F
Okay,
I
mean,
if
you
have
a
suggestion
about
how
we
should
do
the
wording
to
make
it
clear,
because
I
mean
I'm
I'm
fine
with
the
current
state.
I
think
it's
it's
enough
documented,
but
if
you
have
suggestions
to
make
it
better,
I
mean
please
if
you
can
make
a
pr
or
maybe
comment
on
an
issue,
so
you
know
exactly
what
what
you
should
what
what
you
would
want.
That
would
help
us
a
lot.
I
think
sure.
So
I
can
do
this.
F
Okay,
so
if
you
don't
with
this
the
the
next
issues,
I
I'm
it's
pretty
much
linked
to
what
we
talk
about
right
now.
So
it's
about
the
fact
that
the
express
instrumentation
depends
on
the
sdk
to
update
the
name
of
the
http
spam.
We
discussed
already
a
little
bit
on
the
issues.
F
That's
we
shouldn't
do
this,
it's
quite
actually
just
so.
The
aim
for
for
anybody
that
isn't
aware,
is
to
for
the
hdb
spawn
to
have
a
correct
name
like
if
you
have
an
a
shipping
route
with
another
id
inside
it.
Currently,
the
name
of
the
hp
span
by
default
will
just
be
http
gets.
You
will
not
have
the
path
inside
the
name
of
the
of
the
span
and
so
what
we
did,
because
the
http
doesn't
doesn't
know
about
which
root
are
inside
the
instrumentation.
F
So
that's
done
by
by
a
specific
instrumentation
like
express,
for
example,
and
so
we
with
the
express
and
actually
a
lot
of
hp
framework
instrumentation,
do
the
same.
F
They
will
just
get
the
current
span
when
they
are
there
when
they
are
creating
theirs
and
if
it
starts
with
http,
they
will
rename
it
with
the
correct
the
correct
path.
I
don't
think
I'm
not
sure
if
it's
clear,
but
I
explained
it
in
the
issues,
and
so
we
discussed
a
little
bit
about
this
and
I
just
wanted
to
to
have
an
agreement
on
what
to
do
to
fix
this.
F
I
agree:
that's
it's
kinda
hacky
and
it's
not
really-
and
we
kind
of
suggested
to
to
have
a
specific
key
inside
the
context
like,
for
example,
the
the
surplus
instrumentation
key
that
we
can
use
to
to
to
set
that
the
actual
domain
actually
span.
That
is
currently
instrumented
instrumentated.
F
So
the
the
framework
can
set
the
correct
food
that
they
know
about
for
the
hp
span.
So
that's
pretty
much
the
proposed
solution-
and
I
I
just
wanted
the
the
your
inputs,
daniel
specific
danielle
and.
E
Yeah,
I
I
think
a
context.
Property
totally
makes
sense,
and
then
you
just
document
on
the
http
instrumentation
readme.
E
This
instrumentation
sets
this
property,
and
so,
if
you're
trying
to
affect
you
know
discover
if
your
parent
is
an
http
span.
This
is
what
you
should
look
for,
it's
not
in
the
api,
so
I
don't
think
the
specification
people
will
be
angry
at
us
for
doing
it.
E
E
So
if
somebody
if
the
spec
changed
and
said
http
spans
should
be
named
some
different
way,
and
I
made
that
pr-
I
never
would
have
even
realized
that
this
dependency
was
there,
so
it
this
is,
I
think,
in
its
current
state,
very
fragile,
and
I
think
that
the
context
is
a
perfectly
elegant
solution
for
that.
F
Okay
and
about
the
context
key,
so
we
have
the
the
the
concern
for
the
instrumentation.
So
should
we
add
it
into
the
the
experimental
packages
that
we
you
will
create
for
the
super
instrumentation
or
do
we
declare
on
the
http
one
and
just
import
it
as
dependency?
I
think
it
should
be
treated
as
the
same
as
the
as
the
suppressed
instrumentation
key,
but
not
sure.
B
A
Can
we
make
this
a
bit
safer,
like
we
did
with
the
shimmer
so
in
in
case,
because
this
would
be
something
that
people
will
use
to
so
create
a
helper
inside
the
instrumentation
package
that
will
depend
currently
on
this
experimental
new
package.
A
So
you
don't
need
to
export
this
everywhere
and
then
you
will
have
this
functionality
on
the
instrumentation.
The
biggest
advantage
would
be
once
we
have
to
remove
the
experimental,
because,
let's
say
the
api
will
change
and
we
finally
have
it.
We
will
just
do
this
small
change
in
the
instrumentation
package
and
that's
it.
A
A
E
Yeah
off
the
top
of
my
head,
I
can't
immediately
think
of
any
problems
with
that.
So
it's
probably
okay.
You
know
once
we
start
implementing
it,
we
might
run
into
something,
but
for
now
I
think
it
probably
makes
sense.
E
Something
that
the
specification,
or
at
least
ted's
instrumentation
group
may
want
to
know
about,
because
this
is
probably
something
that
other
cigs
are
running
into
is
my
guess,
because
there
are
probably
quite
a
few
of
them
that
when
they
create
the
http
span
initially,
they
can't
give
it
a
good
like
route.
F
Name,
okay!
So
so
so.
The
next
step
for
this
should
be
to
open
apr
on
the
core
to
to
have
this
new
new
key
new
new
context,
key
sorry
and
on
the
instrumentation
package
and
then
open
a
specification
issues
to
to
ask
if,
if
it
should
be
on
the
on
the
specific
specified
on
the
sdk
or
something
like
this.
F
E
That
was
the
last
thing
we
had
on
the
agenda
for
today.
Is
there
anything
that
anybody
wants
to
go
back
over
that
we
didn't
cover
fully
or
something
new
that
people
want
to
bring
up,
or
are
we
good
for
the
day.
D
I
have
a
question:
oh
yeah
go
ahead,
we
have
like
two
230
open
issues
and
some
some
look
like
they
could
be
closed,
but
they're
still
open
or
what's
this,
how
do
we
close
issues
is
there
is
like?
Sometimes
someone
makes
a
bug
and
then
a
year
nothing
happens.
Should
we
close
it
or
it's
just
there
polluting
the
issue
list.
E
You
know
not
infrequently,
so
I
think
there's
value
in
having
the
ones
that
make
sense,
there's
probably
a
lot
that
are
no
longer
issues
that
are
still
open,
though
we
don't
really
have
a
process
for
running
through
those
are.
Are
there
issues
in
particular
that
you
were
thinking
of,
or
you
just
saw
that
I.
D
E
E
We
do
our
best
to
close
them,
but
sometimes
we
miss
them
when
we,
when
we
fix
things.
E
E
Okay,
then,
I
hope
everybody
has
a
good
rest
your
day,
and
I
will
talk
to
you
next
week.