►
From YouTube: 2021-08-03 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
B
B
Oh
by
the
way
I
didn't
I
didn't
put
this
on
the
agenda,
but
the
the
sampler
from
a
couple
weeks
ago,
the
one
that
we
migrated.
I
could
use
a
review
on
that
one
in
the
contribution
sometime,
okay,
yeah.
C
I
can
link
here
there
are
like
couple
of
new
pr's
in
the
content
repo,
which
requires
review.
I
mean
there
are
five
open
requests.
I
mean
this.
B
C
Okay,
let's
give
it
another
minute
to
see
if
anyone
else
wants
to
join
and
meanwhile
you
can
put
your
name
in
the
attendees
list.
C
A
C
Should
we
wait
or
yeah,
let's
give
like
one
more
minute:
okay,
no
one
shows
up.
Then
we
can
just
like
get
a
brief
summary
of
what
you
want
to
discuss
and
then
end
early,
hey,
ellen.
C
Okay,
yeah.
I
think
it
should
be
fine
for
us
to
start
not
three
minutes
past
four,
so
really
I'll.
Let
you
go
for
the
first
one
in
the
agenda.
A
Yeah,
this
is
basically
my
was
trying
to
change
something
in
this
repo,
which
is
an
esd
on
that,
and
I
started
to
have
questions.
I
talked
with
seizure
and
say
it
seems
in
the
open
climate,
instrumentation
library
we
have
some
dependency
here
and
anything
under
asp.net
in
general
would
take
much
longer
time
and
by
quickly
looking
through
the
code.
A
I
I
I
can
see
it
has
nothing
specific
to
microsoft,
so
it
might
be
good
idea
if
we
can
move
that
to
the
open,
telemetry
community
and
try
to
remove
any
microsoft
specific
thing
to
make
it
when
diagnostic
so
welcome
other
contributions
and
also
make
it
more
widely
adopted
by
the
other
components.
So
I
talked
with
cereal.
He
told
me
as
it
seems
to
be
a
good
idea,
so
I
talked
with
michael
and
he
likes
the
idea,
and
then
I
I
talked
with
the
asp.net
team
and
got
there.
A
Okay,
so
from
legal
part
were
clean
and
and
both
this
repo
and
our
open
commentary
projects
are
another
patch
to
license.
So
we
don't
have
any
license
issue
and
I
also
give
heads
up
to
the
maintainers
me
in
this
monday
and
got
good
to
go
signal,
so
I
want
to
move
to
the
next
step,
but
here
I
want
to
quickly
go
through.
A
So
the
first
question.
Sorry,
if
there's
any
question
before
I
I
go
to
the
list
of
questions,
I
have.
D
A
C
Which
publishes
the
diagnostic
source
events,
so
the
instrumentation
in
open,
elementary.net
repo
just
enables
this
module
and
then
reads
the
diagnostic
source
events
and
then
like
populates
activity
and
exports.
So
this
is
like
a
dependency
of
the
instrumentation,
currently
yeah,
okay,
okay,
I
remember
this
contest.
A
Michael
jordan,
so
michael
jordan
yeah,
I
was
just
going
through
the
context.
I
I
think
michael
knows
the
context.
So
if
there's
no
more
question,
I
I
can
just
go
to
explain
the
questions
and
we
can
discuss
what's
the
best
thing
we
can
have.
So
the
first
question
is
we're
going
to
make
the
contribution
should
that
be
in
the
open,
timesheet.net
report,
or
should
that
be
in
the
country
report
and
my
proposal
would
be.
A
C
An
alternate
option
would
be
to
move
both
to
the
contrary
group,
like
move
asp.net
itself,
yeah
instrumentation
labor
itself
to
the
control
crypto.
This
was
something
we
discussed
like
some
time
in
the
past,
but
we
never
actually
did
anything,
but
it's
still
possible
for
us
to
lift
and
shift
all
the
instrumentations
from
the
main
report.
To
the
contrary.
People.
C
Okay,
so
if
we
are
like,
since
it
has
a,
I
mean
since
the
sp
net
instrumentation
has
a
dependency
on
this
package
and
s
p
net
is
currently
in
the
main
repo.
We
should
make
this
part
of
the
main
repo.
C
Could
we
make
it
like
what
what
would
we
call
it
version
like?
Would
it
be
like
1.0,
or
would
it
be
just
following
the
other
instrumentations
in
this,
because
there
is
no
reason
there
is
no
connection.
A
Later,
we'll
cover
that
later,
I
have
the
next
question.
Okay,
so
the
second
question
is:
should
this
be
a
separate
library-
or
it
should
be
just
part
of
the
the
instrumentation
library
and
my
proposal
would
be-
will
keep
it
as
a
separate
library,
because
I
I
know
there
are
other
components
which
take
dependency
on
this
and
I
can
see
there
are
other
components
they
might
not
be
ready
to
move
to
open
telemetry
yet
and
over
time.
I
think
the
moment
we
start
to
have
better
confidence.
A
The
telemetry
correlation
package
can
move
over
and
once
they
move
over,
depending
on
whether
like
people
like
the
feedback,
people
are
willing
to
merge
that
into
a
single
component.
We
can
decide
next
step,
but
I
wouldn't
start
by
merging
the
logic
into
one
single
instrumentation
library.
For
now,.
A
And
then
we
can
talk
about
the
the
steps,
so
my
proposal
would
be
I
want.
I
want
us
to
be
able
to
keep
some
history.
I
like
any
history
that
happened
already
in
that
report.
I
I
think
it
doesn't
make
too
much
sense
to
keep
that,
especially
some
of
the
like
the
people
who
committed
like
who
contribute
to
that
report.
They
might
not
be
willing
to
have
their
name
showing
up
in
open
time
trend.
This
is
the
donations.
I
think
it
might
make
sense
to
ignore
that
history,
but
anything
happened
after
that.
A
But
given
this
on
a
separate
branch
it
doesn't
matter,
then
we
have
small
prs
each
one
trying
to
solve
a
particular
issue
so
probably
like
clean
up
the
and
make
sure
the
copyright
information
that
the
header
everything
is
correct.
Then
we
can
like
have
some
clean
up
and
make
sure
everything
compiles.
We
update
the
solution
and
build,
and
then
we
do
some
integration
and
we
have
to
figure
out
the
version.
I
I
think
the
version
should
align
with
the
the
open
telemetry
like
semantic
combination
and
not
cementing
the
semantic
version
and
the
general
scheme.
A
So
the
first
release,
probably
shouldn't
be
a
stable
version.
It
should
be
a
preview
version
and
we
can
probably
bake
it
and
ship
it
together
for
the
matrix
release,
which
is
enough
this
year,
so
which
means
the
existing
microsoft
experiment
report
will
still
be
there,
and
I
have
to
work
with
microsoft,
folks
to
build
a
plan
that
eventually
we
can
dedicate
this
and
point
people
to
open
telemetry.
A
But
after
we
clean
up
old
code,
everything
works
in
that
branch
and
cicdo
works.
We
can
merge
the
branch
back
to
man
instead
of
squash,
all
the
commits
we
can.
We
can
keep
all
the
commits.
So
we
have
the
full
history
of
what
we
changed
since
information.
A
C
Okay,
I
don't
see
any
issues.
I
have
one
comment
about
like
if
you
are
anywhere
investing
like
some
time
on
this,
we
could
consider
upgrading
the
actual
telemetry
module
to
use
the
new
activity
source
api
as
opposed
to
doing
the
existing
one.
C
It
may
not
be
the
first
step
but
like
if
you
are
like
spending
some
time
getting
it
part
of
open
telemetry.
We
should
do
it
the
right
recommended
way,
rather
than
the
legacy
way,
but
it
can
be
like
a
after
after
the
first
release
thing,
definitely
something
we
should
be
doing.
A
Yeah
and
it
can
happen
at
stage
g-
you
see
like
from
abcdef.
It's
all
like
minor
changes.
Yes,
yes
at
stage
g,
we
need
to
make
some
decision
here
like
which
approach
we're
taking,
and
I
expect
we
probably
want
to
do
some
major
changes,
because
that
code
was
very
old.
It
probably
not
targeting
the
latest
api
that
we
want
people
to
use.
E
Hey
guys,
I
joined
a
little
late,
it's
kind
of
similar
to
what
cjo
is
saying.
I
forget
exactly
what
that
code
does,
but
it's
there's
some
things
it
does
so
in
our
asp.net
instrumentation.
We
have
to
like
check.
You
know
if
we're
using
custom
propagators
and
we
create
a
new
activity,
we
have
to
add
in
support
for
baggage.
E
So
I
was
kind
of
thinking
about
the
idea
of
keeping
it
separate,
there's
pros
and
cons
to
that.
If
it
was
included,
then
we
could
streamline
all
that.
You
know
to
participate
in
the
sdk
and
the
apis.
You
know
baggage
propagation
and
the
default
propagator,
which
might
be
kind
of
nice
for
customers
that
are
using
open
telemetry
for
people
that
just
want
to
use.
You
know
this
specific
thing
as
it
is.
That
would
be
a
con
for
them.
A
A
A
C
E
Yeah
I'm
happy
to
help
out
too
riley.
If
you
need
it.
A
A
C
C
Okay
sounds
good:
let's
move
to
the
next
one,
so
I
created
an
issue
a
few
hours,
few
minutes
back
just
trying
to
get
some
feedback
from
the
community.
It's
about
the
matrix
api,
which
is
part
of
the
dot
net
and
is
about
to
be
released
in
couple
of
maybe
three
months.
C
So
please
go
through
the
issue,
but
I'll
just
summarize,
so
all
the
instruments
I'm
using
counter
as
an
example
here,
has
multiple
overloads
to
supply
attributes
and
it's
called
attributes
are
called
tags
in
the
dot
net.
So
there
are
like
three
overloads
which
allow
up
to
one
dimension,
two
dimension
and
three
dimension.
C
These
apis
do
not
require
like
anything
to
be
allocated
on
the
heap
you
can
just
see
like
it
takes
one
two
three
parameters.
So
if
you
need
to
pass
more
than
three,
then
you
have
like
two
options.
One
is
to
do
the
params
option,
which
would
mean
like
an
alias
like
arrays
and
allocated
here,
and
then
there
is
another
option
which
is
to
like
allocate
it
somewhere
and
for
providing
it
will
expand
to
it.
C
So
obviously,
like
these
t,
these
overloads
are
the
fastest
in
terms
of
no
allocation.
So,
if
you
are
like
within
that
three
dimension,
you
are
good.
So
if
you
have
more
than
that,
you
either
pay
for
the
allocation,
or
you
have
to
do
some
extra
work
to
avoid
that
allocation.
So
trying
to
see
like,
what's
up
that
three
was
a
number
which
was
just
like
out
of
random
picked.
C
Considering
it
takes
time
to,
or
my
team
cannot
just
add
like,
like
50
or
100,
so
they
just
picked
like
the
minimal,
which
is
three,
is
what
they
picked.
So
if
there
is
a
feedback
from
the
community
and
like
other
apm
vendors,
that
three
is
not
going
to
be
like
sufficient
or
let's
say
that
we
come
up
with
the
number,
like
eight
is
the
most
common
one.
We
want
to
let
the
dotnet
team
know
about
that
and
timing
wise.
C
If
we
let
them
know
by
end
of
this
week,
if
there
is
a
good
enough
reason
that
there
are
maybe
like
seven
or
eighties
required,
even
for
open
telemetry
scenarios
and
for
other
apm
vendors,
then
there
is
a
very
good
chance
that
it
can
be
made
part
of
the
dot
net
six.
But
it's
not
really
required
to
be
part
of
dot
net
six.
It
will
just
make
like
life
easier
for
folks
who
are
using
dot
net
six.
They
don't
have
to
do
any
extra
work
around.
C
So
if
there
is
not
enough
need,
as
of
today,
it's
totally
fine.
We
will
revisit
this
and
it
it's
an
additive
change
to
the
dotnet
api,
so
it
can
be
added
anytime
in
the
future
electronic
seven,
eight
nine
ten
whenever
so,
basically
the
ask
is,
if
you
are
like
an
apm
ender
or
you
if
you
are
running
like
metrics
in
production
right
now.
Let
us
know
like
what
is
a
typical
number
of
dimensions
you
use.
Is
it
under
three
then
good?
No
need
of
anything.
C
If
it's
more
than
three,
then
please
comment:
what
is
the
expected
number?
Not
the
max
number
of
dimensions
which
you
see
like,
but
what
is
the
like,
90th
or
99,
most
common
scenario.
I
did
try
to
poke
the
semantic
conventions
from
open,
telemetry
itself,
which
talks
about
the
attributes.
C
It's
still
like
very
early
stages
in
its
mark
experimental,
it
hasn't
been
updated
to
the
new
apis
yet,
but
and
it
does
not
explicitly
say
the
number
of
attributes,
it
says
that
these
are
the
attributes.
Only
like
one
is
marked
as
required
or
recommended
like
pretty
much.
Everything
else
is
like
optional
and
the
list
which
I
shared
is
for
http
and
rpc
calls.
C
It
looks
to
me
right.
It
would
be
around
five
to
eight
based
on
the
semantic
conversion.
It's
still
experimental,
but
based
on
the
based
on
whatever
information
is
available
in
the
semantic
convention.
So
for
me
it
looks
like
open
telemetries
typical
use
case
would
require
anywhere
between
five
to
eight
dimensions.
C
So
if
you
are
like
an
apm
vendor
or
you
have
a
metric
use
case
in
your
company,
please
comment
here
to
let
us
know
and
please
make
sure
to
do
that
by
end
of
this
week.
So
we
can
try
to
see
if
this
can
be
done
in
dot
96
time
frame.
C
Otherwise
we
will
come
back
and
do
it
and
target
the
next
train
from
dot
net,
which
will
be
electronic
seven
or
eight.
A
B
A
I'm
confused,
okay,
and
also
I
I
think
the
semantic
convention
is
a
very
good
point:
freedom
hall,
as
many
combinations
mentioned
many
things
can
be
optional,
but
I
I
think
for
typical,
like
instrumentation
library,
like
asp.net
core,
you
don't
know
what
the
customer
would
want,
so
I
would
assume
you're
going
to
report
everything
that
is
mentioned
in
the
semantic
combination,
although
it's
not
required
so
in
this
way,
I
would
just
for
sake
of
safety.
A
C
In
the
matrix
thing
as
well
like
we
have
like
thursday,
there
is
a
meeting
in
matrix,
so
I'll
put
it
there
and
I'll
like
share
the
link
to
this
issue
in
the
slack
channel
right
away.
So
people
have
like
some
time
to
read
through
it,
but
I
just
don't
know
like
whether
every
language
has
like
this
regularly
span
concept
or
or
like
a
location
so
I'll
just
share
like.
C
Hopefully,
people
would
be
able
to
share
some
feedback
yeah
and
like
for
people
like
michael
who
use
like
matrix
in
production
and
for
lm,
like
if
you
know
from
your
company.
What
is
a
typical
thing?
Please
comment
here
as
well,
so
for
that
there
is
a
timeline
like
that:
there's
a
deadline.
C
We
want
it
really
soon
like
java
apply,
then
they
may
not
have
the
same
deadline
as
servers
because
they
are
not
tied
to
the
language
itself,
so
yeah,
but
I'll
still
ask
the
engineers
group
and
metrics
to
see.
If
anyone
has
comments
there.
A
Yeah
and
just
to
make
it
clear
like
like,
if
you
don't
have
ships
with,
for
example,
by
default
up
to
four
dimensions,
you
all
have
allocation
free
from
the
api
and
later
based
on
the
feedback
in
download
the
number
from
four
to
eight.
Then
all
the
existing
customers
who
have
already
instrumented
using
the
api
they
all
they
need
is
just
to
recompile
the
code.
They
don't
have
to
change
any
code.
A
But
if
they're
trying
to
do
the
assembly
binding
like
they
take
the
latest
version
of
the
the
dotnet
assembly,
I
think
they
would
still
use
the
params
version.
Yeah
I
mean
I
haven't
waited
for
it,
but
it's
quite
likely
be
the
case
yeah.
So
if
your
application
compiled
with
the
current
united
states
preview-
and
you
use
five
dimensions,
if
you
take
the
new
version
which
downloads
free,
I
believe
you
have
to
recompile
your
code.
A
If
you
take
the
binary,
you
will
still
bind
to
the
premise,
and
that
makes
me
a
little
bit
worried
because
I
think
the
instrumentation
library
is
shaped
as
a
binary
form.
So
in
this
way,
like
there
are
application
developers,
there
are
instrumentation
library.
There
are
ours
like
open,
telemetry
authors
and
the
separation
of
the
responsibility
and
makes
me
worried
that
taking
those
dependencies
and
make
sure
everyone,
recompiles
and
ship
a
new
package
is
going
to
take
much
longer
time.
A
C
All
right,
there
are
no
questions
on
this
one
I'll,
just
move
to
the
last
trophy,
so
just
sharing
update
on
the
1.2
alpha
2,
which
I
will
be
pushing
it
to
next
week.
I
did
some
testing
last
week
and
like
there
is
a
significant
amount
of
buffer
today,
so
I'm
trying
to
refactor
the
code
which
would
allow
us
to
reduce
all
the
logs
in
the
hot
part,
because
we
currently
have
at
least
two
locks
in
the
hotpath
one
for
finding
out
which
aggregator
to
pick
and
second
is
once
you
have
the
right
aggregator.
C
Then
you
take
another
log
to
do
the
actual
mathematical
operation
of
some
or
histogram
calculation,
and
there
is
also
a
location
in
the
hot
path
which
is.
There
are
two
allocations.
One
is
the.
Whenever
there
is
a
metric
being
recorded,
we
get
the
number
and
a
regularly
span
of
key
value
pairs.
So
the
first
thing
which
we
I
mean
based
on
the
current
implementation,
is
we
use
a
thread:
local
storage
and
the
thread.
Local
storage
has
a
pre-allocated
key
value
pair
array
of
up
to
three
matching
the
dot
net.
Three
magic
number.
C
We
try
to
point
the
array
to
the
right
only
span
and
we
do
an
in
memory
or
in
in
place
sorting.
Then
we
use
it
as
a
key
to
do
the
lookup
in
the
dictionary.
So
up
to
this
point,
there
is
no
like
pressure
location.
There
is
only
a
thread
local
thing,
but
there
is
sorting,
but
after
that,
if
the
key
is
not
found,
we
have
to
like
copy
the
keys
from
the
literally
span
to
somewhere,
so
that
it
can
be
used
to
say
key
to
the
dictionary.
C
So
that's
one
allocation
and
second
is:
if
the
aggregator
does
not
exist,
we
allocate
a
new
brand
new
aggregator,
which
is
the
second
allocation.
C
So
I
don't
know
like
how
much
I
would
be
able
to
optimize
by
end
of
next
week,
but
I'm
going
to
target
the
aggregator
part,
which
seems
to
me
like,
can
be
easily
pre-allocated.
So
if
you
expect
to
support
like
a
thousand
time
series
per
instrument,
you
can
allocate
thousands
of
them
in
the
very
beginning.
C
We
can
I'm
also
modifying
the
aggregators
to
be
just
structs,
not
classes,
it's
a
bit
harder
because
it's
currently
like
implementing
an
interface.
So,
even
if
I
just
make
it
struct,
it
won't
really
help
because
of
the
interface
it's
implementing.
It's
sometimes
boxed,
so
I'm
just
trying
to
find
what
is
the
best
way
to
balance.
C
So
two
aspects
to
solve
one
is
try
to
avoid
the
dictionary
and
explicit
log
and
second,
is
avoid
the
allocations
in
the
aggregator
itself
and
avoid
the
lock
so
I'll
be
focusing
mostly
on
the
second
part,
but
it
looks
like
it
would
require
a
good
amount
of
refactoring.
So
it
would
be
unlikely
that
we
will
we
should.
C
We
should
not
be
spending
like
too
much
time
writing
the
prometheus
exporter,
which
was
one
of
the
things
which
we
planned
in
alphabetical,
because
it
would
be
like
a
lot
of
way
rights
after
the
exporter
structure
changes
so
I'll
share
like
some
pr's
later
and
hopefully
target
next
week
to
do
the
alpha
2
release
that
I
said
there
is
no
other
player,
victor
merged
the
pr
for
histogram.
C
C
So
when
we
trace
on
vacation
this
week,
so
when
he's
back
early
next
week,
we'll
try
to
see
whether
we
can
do
the
mini
version
of
views
along
with
other
refactorings,
because
we,
as
of
now
the
views,
will
be
touching
the
exact
same
place
where
we
are
trying
to
optimize
spoke.
So
it
will
be
a
lot
of
collation.
So
we'll
try
to
see
if
we
can
minimize
that
and
do
the
minimal
view
thing
which
we
discussed
last
week
as
part
of
the
alpha
2
and
do
a
full
blown
view
much
later.
C
Okay,
any
I
already
did
like
couple
of
refactoring
which
reduced
some
allocation,
but
I
don't
think
that's
good
enough.
So
we'll
keep
iterating
on
that
until
we
reach
a
state
where
we
we
shouldn't
be
taking
any
logs
in
the
hot
path
and
we
shouldn't
be
doing
any
unnecessary
locations,
we
might
not
be
able
to
do
the
zero
log
thing
for
two
reasons.
One
is
the
like.
C
We
need
support
from
top-notch
api
change
for
anything
more
than
three
and
most
likely
we
will
still
need
to
allocate
some
key
values
in
the
heap,
because
the
incoming
incoming
api
is
only
giving
us
the
release
band,
which
we
cannot
use
for,
like
any
storage.
So
we
have
to
do
that
allocation,
but
that
should
be
it
nothing
more.
C
D
C
D
C
C
I
think
I'm
just
looking
at
the
spec.
I
think
it
asks
about
two
cement:
two
metrics,
okay,
one:
okay,
it's
actually
active
records
and
duration;
okay,
so
it
stills
to
one
I
think
in
the
new
world
it
would
be
a
histogram,
not
a
value
recorder
and
active
requests.
C
There
is
no
up
down
counter
in
document
apa.
I
think
I
should
be
writing
that
as
a
issue
because,
like
even
though
the
open
elementary
aps,
spec
has
seven
instruments
the
up
down
counter
and
the
async
version
of
that
is
now
part
of
the
dominant
api,
and
there
is
a
reason:
why
did
not
include
that
at
least
in
the
initial
version?
C
It's
because
the
typical
use
case
of
this
instrument,
the
up
down
counter,
is
to
measure
things
like
queue,
size
or
active
requests,
and
in
dotnet
there
are
tools
like
dotnet
counters
and
visual
studio,
which
can
like
enable
metrics
on
the
fly
to
a
running
process.
It
can
just
like
turn
on
some
visual
studio
tool
or
a
counter.
It
can
start
seeing
the
numbers
from
that.
C
So
for
for
the
active
records,
if
you
do
not
like
start
from
the
very
beginning,
we
wouldn't
have
any
idea
about
what
is
the
current
number
of
active
records,
because
we
lost
the
initial
updates.
We
are
starting
like
somewhere
in
the
middle.
C
The
only
thing
which
the
api
gets
is
how
much
the
number
is
increasing
or
decreasing,
since
we
don't
know
like
what
is
the
base
on
which
it
is
operating,
so
the
the
open
limiter
api
is
moving
ahead
with
that,
but
decided
we'll
wait
for
some
feedback
before
we
introduce
such
an
instrument,
because
the
tools
will
not
know
what
to
display
for
what
is
the
default.
Aggregation.Net
tools
will
be
doing
for
such
instruments,
so
we'll
not
be
able
to
do
that.
C
But
I
want
to
see
like
whether
we
have
some
alternates
than
this
one,
because
the
counter
ap
cannot
be
used
because
there
is
no
way
it
can
go
down.
It
can
only
go
up
so
I'll
have
to
like
do
some
research
and
see
what
is
the
best
way
to
get
back.
Maybe
we
can.
What
would
a
gauge
not
work?
Yeah
grades
like
there
is
a
thing
called
asynchronous
grades,
so
that
should
allow
us
to
use
that
yeah
yeah.
C
But
if
that's
the
case
like,
we
need
to
wait
for
us
the
sdk
to
actually
support
the
gauge
instrument.
So
we
can
like,
as
you
said
in
the
beginning,
we
can
get
rid
of
the
counter
and
just
do
the
duration
now
that
we
support
histogram.
So
that
should
be
the
right
thing
to
do
right
now
and
when
we
decide
or
when
we
add
the
wage,
we
can
bring
back
the
counting
thing
to
count.
The
number
of
records.
C
C
Let's
you
said
I
have
to
check
whether,
like
the
sdk
actually
enables
this
program,
we
enable
the
aggregator
I'll
check
whether
the
actual
pipeline
is
connecting
histogram
instrument
to
the
right
aggregator,
so
that
I
I'll
check-
and
let
you
know
if
it's
not.
It
should
be
like
very
small
pr
to
make
it
happen,
and
I
don't
expect
any
changes
in
the
instrumentation
based
on
the
effect
they'll
be
purely
against
the
dominant
api,
which
for
which
there
is
no
change.
C
Absolutely
change
is
going
to
be
in
the
aggregator
store,
slash
the
actual
aggregator.
So
there
would
be
some
changes
in
the
interface
which
exporters
are
seeing,
but
yeah
it
should
not
affect
any
instrumentation.
D
Oh
yeah,
and
I
think
I
said
that
I
would
add
the
http
client
instrumentation
tool,
but
yeah
that
should
also
be
unblocked
actually
in
the
next
day
or
two
okay.
C
Which
can
happen
in
parallel
without
any
conflict?
The
instrumentations
can
like
happen
like
really
parallel
without
any
interruption
with
the
actual
sticky
work.
C
Yeah,
the
exporter
would
require
some
change,
because,
right
now
we
are
giving
like
a
list.
I
just
put
it
inside
the
batch.
I
just
borrowed
it
from
the
tracing
and
logging.
The
batch
thing,
michael,
like
riley,
wrote
that
thing,
but
it's
not
using
the
batch
in
the
right
baby,
still
like
crazy.
Actually,
so
I
need
to
like
create
a
new
batch
which
knows
how
to
like,
walk
through
the
list
of
active
time.
Series
then
give
that
as
the
input
to
the
exporter,
so
there
would
be
like
some
changes.
C
I
did
that
like
already,
but
then
I
realized
it's.
It's
like
really
big
refractor,
like
huge,
like
went
beyond
my
like
reasonable
limit,
so
I
I'm
like
taking
it
step
by
step,
so
I
made
one
mars
last
friday
there
will
be
a
couple
more
this
week,
hopefully,
by
end
of
next
week,
we
should
be
able
to
bring
the
performance
to
a
much
better
number
and
after
that,
we'll
address
the
rest
of
the
instruments
and
the
things.
C
C
I
really
want
to
ask
for
one
question
about
this:
instrumentation
left
a
comment
and
probably
like
in
the
multiple
comments
which
overwrote
it
it
got
lost
so
okay
right
here,
so
for
all
the
instrumentations
which
we
currently
have,
which
is
which
are
instrumenting
a
library
which
produces
the
legacy,
the
diagnostic
source
way
of
activity.
C
So
quartz
is
an
example
of
such
thing.
So
the
part
which
I
was
having
confusion
is
about
the
the
property
feature
thing.
So
let
me
show
exactly
what
I
need
so
like
in
all
of
the
instrumentations.
We
don't
like
cache
the
cached,
the
payload
into
exception.
We
use
the
fetcher
to
effectively
read
the
exception
from
the
payload.
C
However,
this
is
seeming
to
be
doing
just
a
caster.
I
don't
know
whether
it
works,
so
I'm
just
happy
to
hear
like
if
like
if
this
is
a
right
approach
or
not.
I
haven't
spent
enough
time
understanding
this,
so
if
michael
or
ellen,
if
you
know
whether
this
approach
would
work
as
opposed
to
using
the
property
feature,
that
would
be
helpful.
E
C
Okay,
but
even
if
it
is
doing
like
stop
or
like
a
separate
event,
would
casting
from
the
payload
work
generally
like
because,
like
this
is
the
payload
which
we
get
it
probably
an
anonymous
object
or
something
and
oh,
we
are
trying
to
extract
the
exception
from
that.
Just
by
casting
it.
D
C
C
A
convention,
the
name
ends
with
like
dot
exception,
at
the
variance
we
treat
it
as
a
convention.
Okay.
So
the
only
way
to
know
whether
this
is
the
right
way
is
to
look
at
the
actual
place
where
the
right
event
is
happening
and
see
if
they
are
indeed
passing
an
exception
asses
if
they
are
passing
it
as
like
something
else,
then
like
we
need
to
use
a
fetcher
approach,
okay,
yeah,
that
makes
sense
yeah.
I
mean
pretty
much.
This
pr
looks
good
for
me,
but
I
didn't
knew
about.
C
In
fact,
even
the
stop
activity
and
start
activity
was
initially
doing
a
cast,
but
then
I
asked
I
left
a
comment
like
whether
it
works,
but
then
in
the
subsequent
committed
code
change,
so
either
it
didn't
work
or
the
author
just
changed
it,
because
I
uncommented
so
I
don't
know
which
one
is
the
case
yeah
but
like.
Overall,
it
looks
good
and
it
has
test
sign
like
treat
me.
I
can
pretty
much
everything
we
need.
C
So
if
we
have
like
cycles,
please
help
review
this
vr
and
there
is
another
ask
which
we
discussed
like
two
weeks
back
about
migrating,
all
the
at
least
to
begin
with
the
extensions
package.
C
I
haven't
got
time
to
do
that,
so
if
anyone
has
cycles,
if
you
can
do
like
the
lift
and
shift
from
the
main
dripper
to
this
repo
and
also
like
other
few
other
things
are
like
just
renaming
the
packages
to
be
like
removable,
so
I'll,
create
an
issue
here
and
see
if
there
is
anyone
who
can
help
with
that,
so
maybe
there
are
folks
who
are
trying
to
help.
This
might
be
like
a
very
small
thing
for
them
to
do
so
I'll
create
a
couple
of
issues
to
see.
C
If
anyone
wants
to
work
on
that
all
right,
I
don't
have
any
other
topics
so
we'll
see
again
next
week,
so
there
are
no
releases
this
week.
I
will
be
updating
the
milestone
to
reflect
that
the
release
will
be
on
next
friday.