►
From YouTube: 2020-08-11 .NET SIG
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
A
All
right
waiting
for
people
to
join,
please
put
your
name
here.
A
A
A
B
A
B
Was
just
quick
update
so
last
week
we
asked
everyone
to
look
at
the
a
run,
tech.net
runtime
change,
which
was
arising
out
of
open
telemetry
requirement
and,
along
with
that,
there
was
a
bunch
of
renamings
to
some
of
the
activity
listener
stuff
again
based
on
the
feedback
from
this
community.
So
the
good
news
is,
it's
all
approach
and
the
code
is
already
merged
and
it
should
be
available
in
rc.
B
I
think
it's
rc
one,
but
we
will
be
able
to
get
a
hold
of
the
build
if
from
the
daily,
build
or
daily
build
you
get.
So
if
anyone
wants
to
play
with
that,
we
please
go
ahead
and
do
it.
I
don't
expect
us
to
be
updating
to
that
immediately,
because
we
have
a
release
promised
on
end
of
this
month.
B
We
should
depend
on
preview
8,
so
we
won't
be
updating
to
rc1
before
that,
but
we
will
still
be
trying
it
out
just
to
see
how
things
work
and
if
you
find
any
issues
but
fix
bugs,
please
do
raise
them.
This
is
probably
the
last
opportunity
to
fix
any
anything
critical
because
after
that,
it's
directly
ga.
So
it's
almost
like
code
freeze
at
that
time.
B
So
that's
just
an
update.
Second,
is,
I
think,
really
would
cover
it
a
little
bit
when
we
talk
about
processors,
so
there
was
a
fairly
big
refactoring
on
how
tracer
provider
is
constructed.
So
previously
we
had
this
notion
of.
You
can
have
multiple
tracer
providers,
even
if
in
within
one
tracer
provider,
you
can
have
parallel
processing
pipelines
each
consisting
of
its
own
telemetry
or
span
processors,
slash
span
exporters,
and
we
have
greatly
simplified
that
so
now
you
still
have
the
ability
to
have
multiple
tracer
providers,
because
the
open
elementary
spec
allows
it.
B
And
but
what
really
changed
is
within
a
tracer
provider.
You
have
a
single.
No,
you
have
a
notion
of
a
single
pipeline,
so
the
tracer
provider
itself
is
a
pipeline.
You
can
have
any
number
of
processors
and
the
provider
has
no
knowledge
of
exporter.
It
only
knows
about
processors,
and
it
is
up
to
the
processors
to
invoke
or
not
invoke
the
exporter
based
on
its
logic.
This
matches,
how
other
reports
are
doing
and
how
the
specification
talks
about
it,
but
compared
to
our
released
beta.
This
is
a
fairly
breaking
change.
B
If
people
have
written
code
based
on
this,
they
will
be
break
like
broken.
So,
if
the
I
mean,
I
think
we'll
still
have
room
for
improvement,
so
we'll
be
still
type
rating
on
it.
But
if
you
have
feedback,
please
share
them.
The
pr
is
closed,
but
we
can
still
do
follow-ups
afterwards.
B
So
that's
pretty
much
my
update,
it's.
I
think
it
will
be
covered
when
riley
talks
about
exporter
yeah,
that's
it
from
my
side
and
everything
else
is
progressing.
We
have
some
peers
which
are
being
merged
and
still
working
on,
but
it
looks
like
we
are
still
on
track
to
release
the
next
beta
at
the
end
of
this
month.
B
I
think
I
can
talk.
One
more
thing
asks
general
feedback
on
detail
project
as
well
likes,
so
we
got
notified
from
the
spec
repo
that
every
report
is
required
to
start
a
github
project
to
track
the
overall
geo
release,
and
most
reports
are
already
doing
it.
So
I
try
to
get
a
start
on
that
by
creating
a
github
project
for
ga
and
eric
has
offered
to
help
with
arranging
things
there.
So
my
question
is:
how
do
we
give
permissions
to
eric
to
do
that?
B
B
B
C
Clarify
a
couple
of
things,
I
did
find
some
some
more
details
on
this
in
terms
of
creating
the
boards
you
know,
and
if
we
wanted
to
create
new
projects
for
the
milestones
or
not,
that
would
have
to
be
done
by
a
maintainer,
maintainer
or
admin
level.
Permissions
triage
doesn't
work
for
that
to
actually
create
the
board.
C
However,
there
is
some
other,
and
this
is
that
second
link
I
sent
to
you
see
joe.
There
is
some
other
additional
permissions
that
get
set
for
being
able
to
administer
stuff
on
the
board,
and
I
I
I
don't
know
if
you
need
to
be
a
maintainer
or
admin
to
be
able
to
change
those
permissions
or
not,
but
I
sent
that
documentation
link
to
you.
B
Okay,
so
let
me
try
that
out
and
see
if
it
helps,
but
the
next
question
is:
do
we
want
to
have
these
projects
to
track
the
beta
releases,
or
do
we
only
need
it
for
ga,
so
riley
says
I
know
so
so
right
can
you
like?
Do
you
know
what
is
overall
guidance
from
opendemo,
because
there
is
a
board
which
is
tracking
ga
release
overall
across
all
the
six?
B
A
As
we
currently
use
yeah,
even
for
the
open,
telemetry
spec,
I
think
only
the
ga
release
is
tracked
using
the
board
and
for
the
review
like
alpha.
Beta
release
is
not,
and-
and
given
it's
a
new
thing,
I
think
we're
running
fine
with
the
current
beta
release.
I
don't
see
any
immediate
benefit.
Besides
we're
changing
the
process
again,
so
I
I
would
be
against
like
using
the
board
for
beta,
but
if
people
have
energy
and
they
want
to
make
the
move,
I'm
not
against
that.
B
Sense
yeah,
I
mean
I
agree
as
long
as
the
milestones
and
labels
are
correctly
tagged,
then
it
should
be
fairly
easy
to
get
the
equivalent
of
project
view
by
writing.
That
I
mean
by
doing
the
right,
github
query.
We
should
be
able
to
still
see
what
are
the.
What
are
the
items
which
we
tagged
for
the
next
release
so
yeah.
I
think
I'm
fine
with
that.
So
we'll
use
eric's
help
to
get
the
tracker
ready
for
ga.
A
Yeah
and
I
believe
in
the
spec
people
also
mentioned
that
they've
seen
you've
seen
some
gap
between
the
milestone
tracking
and
the
board
and
both
dimension.
There
there's
some
automation
tool
that
for
people
like
who
wants
to
manage
the
milestone
things
directly,
they
change
the
status
of
the
issue.
It
got
reflected
in
the
board
directly,
so
you
don't
have
to
maintain
two
places.
B
Okay,
I
think
there
is
an
automation
for
projects
like
when
you
create
projects.
You
can
write
that
automation,
I
mean
you,
don't
have
to
write
any
code.
You
just
mention
it
and
like
based
on
the
issues
milestones
and
the
prs
associated
and
the
status
of
the
pr
the
board
gets
moved
automatically.
You
don't
have
to
like
first
work
on
the
issue,
close
it
and
then
come
back
to
the
board
and
update
it.
B
It's
supposed
to
be
automatic,
but
like
I'll
see,
if
eric
can
make
that
happen
for
ga,
so
we
don't
have
to
do
like
dual
work
of
updating
two
places
and
yeah
for
beta
we'll
continue
with
whatever
we
are
doing.
B
Okay,
really,
it's
your
topics
and
allen
has
added
something
else.
The
end
I
don't
know
which
order
you
want
to
go
across.
A
Yeah
we
can
follow
the
order
here.
So
I,
like,
I
think,
the
current
trace
provider
and
builder
refactor
is
almost
done
or
at
least
from
the
end,
the
user
perspective.
I
think
the
majority
part
is
done.
There's
some
performance
improvement
where
we
want
to
focus
on
the
memory
allocation
things,
but
that
shouldn't
affect
the
the
consumption
experience.
A
There
are
two
parts
I
I
think
we
need
to
make
big
changes
before
ga
and
one
is
the
exporter.
So
this
currently
spoiler
has
a
lot
of
issues
like
the
the
simple
exporter
will
will
just
like
randomly
create
tasks
and
shoot
that
to
the
runtime,
and
there
is
no
way
to
manage
where
these
tasks
are
like
finished
or
haven't
started,
and
how
to
handle
the
back
pressure,
and
eventually
I
heard
some
back
background
noise,
probably
from
seizure.
A
Yes,
in
this
way,
it's
a
it's
very
dangerous,
like
you
could
run
the
isdk
and
put
some
stress,
and
you
will
end
up
with
like
a
bonding
number
of
tasks
that
eventually
kill
the
process
and
I
believe
we
have
similar
issues
in
the
asynchronous
like
the
the
batching
exporter.
So
there
are
few
things
I
want
to
explore
and
I
figure
it
might
be
another
big
change,
similar
like
what
we
have
done
in
nutrition
provider
and
builder
I'll.
Do
this
step
by
step?
Give
some
like
initial
idea
similar
like
what
we
have
done.
A
A
So
the
number
one
pr
is
having
some
initial
idea.
So
here
I
basically
say
I
have
some
idea
how
we
can
simplify
this,
and
I
also
give
example
in
the
like
simple
tutorial
like
this-
is
what
you
end
up
with
with
this
program
you
can
instead
of
in
this
way,
you
can
change
that
to
a
simpler
way
and
gives
you
additional
benefit,
and
then
we
got
feedback
from
from
folks
to
say,
like
hey.
A
We
first
have
a
small
pr
to
describe
what
we
want
to
have
and
we
consulted
the
feedback
from
the
community
and
once
we
agreed
this
is
the
direction
let's
go,
and
then
we
send
the
big
pr
that
basically
change
everything
of
the
repo
touch,
all
the
colors
and
then
once
we're
okay
with
the
the
framing,
because
then
subsequent
pr
to
eventually
improve
that
towards
our
final
goal.
Figure
exporter
will
be
the
similar
thing
and
I
start
to
work
on
that.
I
hope
I
can
give
a
few
pr's
today
and
tomorrow.
A
The
next
thing
I
think
it's
not
listed
here,
but
I
want
to
quickly
mention
the
the
remaining
thing
I
think
we
need
to
make
big
changes
are
the
context
management
so
in
open,
telemetry,
spec
people
have
mentioned
there's
correlation
context,
but
from
the
w3c
standard
perspective
that
thing
got
renamed
to
baggage
and
currently
there's
a
lot
of
things
in
the
air.
But
I
figured
we
cannot
ship
open,
telemetry,
ga
if
the
contact
cpi
is
messy
like
used
to
be
like
correlation
contacts
baggage
and
some
of
the
like
runtime
contacting
and
also
there's
a.
A
I
forgot,
what
it's
called
they're
like
four
or
five
different,
like
names,
they're
all
related
to
context,
and
and
currently
it
is
not
ready-
and
we
have
some
issue
like
customer-
ask
that
correlation
context
is
not
a
dictionary.
It
seems
to
be
ordered,
and
I
have
no
answer
for
them,
because
I
know
the
correlation
context
shouldn't
exist
will
be
ga,
so
I
wonder
like
how
we
can
how
we
can
park
this
work.
A
A
A
Yeah
and
we
have
runtime
so
now
we're
making
things
even
more
complex,
so
this
part
has
to
be
solved
before
ga
and
we're
taking
a
dependency
on
the
spec.
But
this
part
I
figure,
will
change
a
lot
of
things
like
that
will
be
a
big
breaking
change
for
the
current
api
and
sdk.
It's
probably
like
for
beta3
I
mean
yeah
is.
A
B
A
Not
ready
yeah,
but
I
I
hope
if,
if
I
got
time
to
work
on
this
I'll
make
sure
this
one
is
ready
and
the
spec
is
ready,
but
probably
don't
have
energy
right
now.
So
I
want
to
focus
on
the
exporter
because
shooting
random
task
to
the
user's
application
eventually
might
crash
or
like
run
like
through
an
auto
memory.
This
seems
to
be
a
no-go
direction
at
all.
So
this
part
has
to
be
addressed
and
I
treat
this
as
a
high
priority.
D
From
folks
ready
for
the
context
api
this
the
last
week,
I
was
talking
with
michael
about
it
and
we
did
some
work
about
the
baggage
feature
and
he
will
probably
create
a
new
vr
addressing
it.
I
don't
know
if
it
addresses
everything
from
correlation
context
and
that
distributed
context,
but
has
almost
everything
from
the
context
header
to
the
baggage
header,
something
like
that.
B
B
Maybe
yeah
I
mean
I'm
just
saying
there
are
more
things
to
it
than
the
things
which
we
see
in
open,
telemetry
repo,
because
dotnet
already
has
some
sort
of
baggage
and
propagation
which
is
way
ahead
of
this
package.
It
was
called
baggage
like
at
least
two
years
before
the
spec
called
it
package
and
it
used
the
same
header
much
before
w3c
spec
came
into
being
so
it's
ahead
of
the
overall
thing,
but
it
may
also
be
drifting
from
the
final
actual
spec.
A
Okay,
so
sorry
for
hijacking
this
topic,
alan
silter.
E
Oh
yeah,
no
problem,
yeah.
No,
my
thing
is
just
quick.
I
I
just
had
a
interesting
interaction
with
somebody
over
the
weekend
who
was
trying
to
instrument
a
new
library,
and
it
got
me
to
thinking
about
the
open
issue
that
or
all
the
the
things
you've
stubbed
out
rightly
for
documenting
so
specifically
instrumentation
and
how
we
do
it,
and
it
was
a
good
exercise
for
me
to
just
kind
of
go
through
and
and
freshen
up.
My
my
knowledge
about
all
the
ways
that
instrumentation
can
be
done
and
general
question.
E
I
mean
I
understand
that
the
activity
source
apis
are
the
way
that
we
want
to
begin
to
guide
people
to
instrument.net
libraries,
but
as
far
as
documentation
does
it
make
sense
to
continue
to
kind
of
show
all
the
I
mean
like
the
legacy
way
as
well,
and-
and
if
so
you
know,
I
have
a
start,
I
guess
to
some
some
examples
to
land.
B
I
don't
think
we
want
to
like
advertise
it
anymore.
Then
it's
already
there
in
dot
net
repo,
the
new
guidance
even
from
dotnet
team,
would
be
to
use
activity
source
based
instrumentation,
because
it's
faster
it's
much
easier
to
write
and
it's
like
super
easy
to
consume
as
well.
B
So
I
don't
like
there
was
some
initial
plan
that
we
will
start
documenting
it
right
here
in
our
repo
in
open
elementary.net
repo
about
what,
if
I'm
a
library
or
the
right,
I
want
to
instrument
my
application
or
library
using
the
dotnet
activity
source
api,
but
eventually
it
will
move
into
dotnet,
runtime
propos,
the
official
document
owned
by
dotnet,
but
for
the
time
being
it's
something
which
we
should
have
so
specifically
like.
Is
there
any
like
more
examples
which
you
wanted
to
bring
about
from
the
microservices
one?
You
added.
B
We
should
demonstrate
like
how
to
instrument
the
ap,
because
I
think
the
one
which
we
currently
have
demonstrates
like
three
aspects:
how
to
instrument
how
to
instrument
a
specific
producer,
consumer
scenario
and
how
to
manually
propagate
the
context
and
extract
it
on
the
other
side.
So
these
three
are
like
the
important
things
which
someone
should
know
if
they
want
to
instrument
everything
else
like
consuming
it
sending
to
exporter.
It's
is
covered
elsewhere
in
other
dogs
in
our
people.
E
Yeah
well,
yes,
I
mean,
I
think,
that
you've
kind
of
answered
my
question
and
that
the
main
thing
that
we
want
to
focus
on
is
activity
source
based
instrumentation
and
that's
what
I
thought
the
answer
would
be,
but
the
reason
why
I
asked
the
question
is
that
it
this
the
question
from
this
community
member
in
in
gitter.
It
was
evident
to
me
that
you
know
they're
looking
at
examples
that
have
been
made
over
the
over
the
months
or
whatever
he.
He
specifically
cited
jimmy
bogart's
example
for
instrumentation.
E
Bus
and
so
there's
definitely
some.
It
seems
to
me
that
there's
some
stronger
guidance
that
maybe
we
can
put
out
there
to
say,
like
hey,
listen
activity
source
really
is
the
thing
that
everybody's
eyes
should
be
focused
on
now.
B
So
one
comment
here:
I
think
the
question
was
more
about
what
do
we
do
with
libraries,
which
are
already
instrumented
with
diagnostic
source?
How
do
we
convert
them
to
the
new
way?
So
two
answers
to
that.
One
is
change
the
instrumentation
itself
from
diagnostic
source
to
activity
source.
It
may
be
considered
a
breaking
change
for
the
library,
so
they
may
or
may
not
be
willing
to
just
accept
it.
B
Second,
is
we
how
to
write
instrumentation
for
that
similar
to
what
we
did
for
http
client
sp
net
core
grpc,
so
these
libraries
were
already
instrumented
using
diagnostic
source,
which
now
we
consider
as
legacy
instrumentation,
so
they
and
for
these
libraries,
which
are
like
already
ga
there
is
no
way
for
them
to
just
drop
it
and
convert
to
activity
source.
So
the
way
out
of
that
situation
is
we
ship
instrumentation
libraries
to
cover
that?
So
essentially,
we
are
listening
using
the
old
way
by
using
diagnostic
source
listener
and
we
translate
them
into
activity
source.
B
So
if
we
want
to
write
a
document
on
this,
I
think
it
should
not.
It
need
not
contain
any
actual
code
because
we
can
easily
refer
them
to
the
existing
instrumentation.
We
have.
We
have
at
least
six
of
them
already,
so
we
can
just
use
these
just
like
working
examples
and
briefly
mention
that
the
reason
why
we
are
doing
this
is
because
they're
already
instrumental
using
the
legacy
way
and
the
activity
does
not
follow
the
entire
activity
source
pipeline.
So
we
have
to
do
some
like
adapting
yeah.
B
E
B
Biggest
like
number
one
thing
which
I
would
highlight:
there
is
the
activity
when
created
using
the
old
way.
It
does
not
go
through
the
same
pipeline
as
the
activity
source
pipeline,
which
is
why
we
have
to
do
this
special
activity,
source,
adapter
thing
and
then
go
into
specifics.
Yeah.
It
would
be
great
to
document
that,
because
I
know
there
are
several
libraries
which
are
already
surrounded
using
diagnostics
source.
B
One
thing
like
there
was:
I
mean
apart
from
this
question.
There
was
a
question
about
elastic's,
first
dot-net
client
as
well,
which
is
also
emitting
diagnostic
source
as
well
yeah.
So
the
ideal
case
is
to
convert
them
to
use
activity
source,
but
if
not
use
the
to
be
written
guideline
to
write
an
instrumentation
library
to
translate
sorry,
someone
was
talking.
F
Hey
sorry,
I
I
was
looking
for
a
break.
I
didn't
mean
to
keep
interrupting
you,
so
we're
just
starting
our
library-based
integration,
just
a
quick
question
on
since
we're
going
to
be
doing
this
new
way
of
using
the
activity
source.
What's
the
what's
the
reference
implementation
that
we
should
be
looking
at
in
the
repo
and
what
are
what?
What
are
your
documents
going
to
be
based
off
of?
I
guess.
B
B
There
is
no
perfect
exact
like
real
life
example,
because
every
most
popular
libraries
like
http,
client
and
sp.net
core,
they
are
already
using
diagnostic
source
based
instrumentation.
B
So
there
is
no
like
reference
implementation
yet
for
activity
source
trying
to
see
whether
some
of
the
microsoft
azure
libraries
would
be
moving
to
activity
source,
then
we
can
use
them
as
a
reference
standard,
but
until
that
happened,
the
best
example
is
the
one
which
allen
has
put.
B
No,
I
don't
think
it's
that
I
mean
the
one
from
microsoft.
We
already
covered
it
with
our
instrumentation,
which
is
basically
four
things
like
asp.net,
sp.net,
core
http,
client,
http,
sorry,
street
training
and
sql
client
and
grpc,
which
is
not
strictly
microsoft,
but
yeah
somewhat.
So
this
is.
These
are
the
things
which
I'm
really
aware
of,
but
apart
from
this,
most
of
the
azure
sdks
are
also
using
diagnostic
source
based
instrumentation.
B
A
A
I
think
for
asp
asp.net.
It
is
probably
not
going
to
change
for
the
client
libraries.
I
think.
Eventually,
people
might
make
the
change,
but
it's
only
like
the
forward
change
they're
not
going
to
pour
that
backwards
and
for
either
sdks.
I
I
think
they're
similar
to
the
sdks
that
the
clients
we
have
so
they
will
start
to
instrument
using
a
new
way,
but
the
timeline
is
not
yet
very.
A
Clear:
okay,
any
questions
on
this
topic.
A
Okay,
so
I
don't
think
they're
outstanding
pr
that
we
should
talk
about
in
case
like
people
see
anything
we
want
to
cover.
So
this
simple
activity,
processor,
improvement
and
this
exposure
example
are
the
prs
that
michael
and
I
we
talked
about
so
there's
some
idea
how
we
should
improve
or
fix
the
current
exporter
and
we'll
try
to
address
that,
and
this
one
allen
is
working
on
the
surprise,
instrumentation.
A
I
I
think,
there's
a
question
from
me
about
the
potential
performance
penalty
and
I
think
we're
doing
the
the
balance
between
like
trying
to
strive
for
for
good
performance
versus
trying
to
be
protective
instead
of
relying
on
the
instrumentation
library
and
the
exposure
to
do
the
correct
thing,
and
I
believe
I
think
that
the
surprising
instrumentation
check
in
every
single
call
shouldn't
give
a
a
big
performance
penalty,
but
still
would
like
to
see
the
result
for
the
remaining
thing.
A
A
This
one
is
just
some
engineering
improvement
and
this
enrichment
scope.
I
think
personally,
I
like
the
idea
but
like
if
my
call
feels
it's
something
we
want
to
move
forward,
then
remove
the
draft
tag.
B
B
I
haven't
I
mean
I
promised
michael.
I
will
come
back
to
it
sometime
this
week
so
and
since
michael
is
not
here
to
discuss
it,
I
think
we
should
discuss
it
in
the
next
stand
up
because
it's
fairly
big
public
api,
it's
a
public
ep,
so
we
want
to
really
make
sure
everyone
agrees
that
this
is
the
right
way
to
go
so
yeah.
I
think
we'll
shift
it
push
it
to
the
next
meeting
so
that
we
can
all
be
a
little
bit
more
prepared
as
well.
Yeah
michael,
do
join
us
right.
A
B
But
the
reason
why
I
didn't
merge
it
yet
is:
we
are
still
like
heavily
changing
the
public
api,
so
it
will
be
like
a
pain
to
keep
updating
it
every
time.
So
let's
wait
for
at
least
one
more
beta
and
then
merge
it
in
because
afterwards,
then
we
can
be
like
much
more
conscious
about
changing
public
api,
so
I
mean
it
said,
must
have
by
the
time
we
have.
We
go
ga,
but
right
now
it
will
be
like
just
noise
for
us
to
keep
updating
the
public
api
talk.
A
A
B
I
think
we
will
be
keeping
I
don't.
I
mark
it
as
priority
two,
because
we
agreed
whatever
we
finish
in
beta,
we'll
merge
it.
We
won't
wait
block
beta,
because
this
is
not
done.
A
lot
of
things
are
part
of
metrics
like
lot
of
to
do's
are
in
the
matrix
area,
which
we
are
not
tracking
for
the
next
beta.
So
it's
it's
progressing,
but
I
mean
it
won't,
be
complete
for
this
beta.
B
With
priority,
two
is
because
we
can,
we
don't
have
to
block
beta
to
release
whether
this
is
done
or
not,
but,
as
you
said,
like
yeah,
we
can
even
move
to
next
beta.
It's
fine.
One
of
the
reason
why
I
want
to
put
it
here
is
just
to
give
it
like
more
importance,
because
it's
a
fairly
big
item.
It's
really
nice!
That's
why
I
put
it
less
like
some
water
in
the
immediate
milestone,
so
people
has
an
opportunity
to
start
fixing.
It.
B
Whether
we
addressed
everything
there's
an
open
pr
which
is
addressing
some
part
of
it
but
yeah,
it
should
be
very
close
to
be
done
so
I'll
verify
everything
is
done
and
that
much.
A
B
Something
similar
to
what
the
filtering
capabilities
like
if
one
of
them
is
related
to
the
exporter,
not
ex
exporting
its
own
spans,
the
one
which
alan
is
working
on,
but
there
is
a
related
issue
on
that
topic,
which
is
we
need
a
way
to
filter
out
things
like
much
early
in
the
pipeline.
So
two
things
and
one
is
being
addressed
by
allen
spear,
the
other
one
not
really
being
addressed.
E
I
don't
think
the
entire
thing
will
be
addressed.
Cj's
right,
I'm
mainly
focused
on
the
this.
From
the
standpoint
of
the
exporter,
though
riley
I
have,
I
think
I've
spoken
with
you
a
little
bit
about
toying
with
this.
I
once
once
we
get
past
like
the
conversations
around
the
exporter,
seeing
how
well
this
works
from
the
standpoint
of
some
instrumentation
grpc
as
an
example.
F
E
B
It's
a
generic
requirement
to
like
suppress
the
subsequent
instrumentation,
so
if
grpc
can
validate
it,
then
we
can
say
that
okay,
it's
done
it's
working
and
then
we
can
address
the
second
part,
which
is
very
closely
related
to
the
enrichment
scope,
pr
enrichment
and
filtering
based
on
strong
object
as
early
in
the
pipeline
as
possible.
B
E
Yeah,
I
think
I
think
it
would
be
fair
to
to
close
this
out
and
we've
discussed
enough
as
we
decide
to
expand
this.
If
we
decide
to
expand
this,
then
you
know
those
can
be
separate
issues.
The
one
thought
on
my
mind
is
there's
no
examples
right
now
for
grpc,
and
maybe
that
would
be
a
good
platform
for
doing
that
or
doing
them
as
separate
applications,
I'm
hoping
to
either
way,
but
I
think
a
separate
issue.
I
can
open
up
a
separate
issue
for
that.
B
E
B
So
maybe
like
we'll
club
it
when
we
address
the
context
part,
which
also
means
this
has
to
be
moved
to
the
next
milestone.
B
Next,
so
there
is
a
pr
which
eddie
and
michael
is
working
on
for
the
context,
so
maybe
like,
depending
on
how
much
progress
we
make
it's
possible
that
we
let
us
hit
earlier.
A
E
A
A
Yeah,
so
we
can
go
back
and
I
I
think
we
got
new
folks
like
some
of
the
previous
meetings,
so
I
probably
cannot
recall
like
who
haven't
done
the
introduction
yet
so
I
rely
on
everyone
here
to
see
like
who
should
do
the
self
introduction
and
we
can
probably
use
the
alphabet
like
order.
B
H
Why
are
the
exporters
part
of
the
open
telemetry
as
opposed
to
being
additional
dependencies,
for
instance,
if
if
an
exporter
requires-
let's,
let's
say,
for
instance,
the
jaeger
exporter
requires
extra
dependencies
and
I
don't
want
to
add
those
dependencies
because
they
cause
conflicts
or
whatever
other
reasons?
Why
are
they
part
of
open
telemetry.
A
It
is
not
part
of
the
open,
telemetry
core
api
nor
the
sdk.
The
open,
telemetry.net
product
has
multiple
components
and
the
jager
exporter
or
zip
king
or
any
other
exporter
they're.
Just
one
separate
binary,
separate
nuget
package,
yeah
dependency
on
the
other
core
packages,
but
you
don't
have
to
take
dependency
on
that
unless
you
use
that
okay
and
the
reason
we
keep
them
in
the
same
repo
is
just
for
management
issues.
So
the
general
principle
is
we
have
the
exporter
which
sends
it
her
to
a
open
source
platform.
A
Things
like
prometheus,
like
jaeger
zipkin,
so
the
backend
is
open
source.
We
try
to
keep
them
so
keep
this
report
self,
condensing
for
customers
who
want
to
use
open
source.
They
can
get
the
basic
stuff
running
instead
of
just
a
very
like
simple
console
exporter,
but
for
any
vendor
specific
thing
that,
for
example,
like
microsoft,
aws
or
like
gcp
backend,
the
exporter
will
not
be
in
this
repo,
okay
and
given,
like
the
source
code,
are
in
this
report,
they're
still
well
componentized,
so
people
can
feel
flexible
to
pick
whatever
component.
They
want.
G
Yeah
yeah
so
see
you
about
the
recommendation
of
using
like
activity
so
rather
than
diagnostic.
Is
it
the
same
like
recommendation
for
auto
instrumentation
agents,
other
instrumentation
for
dotnet,
as.
B
Well,
I
don't
really
know
whether
we
need
to
give
any
recommendation
for
auto
instrumentation,
but
since
auto
instrumentation
is
supposedly
going
to
inject
some
code,
then
I
would
expect
them
to
inject
the
recommended
approach,
which
would
be
activity
source
based,
but
follow
is
here.
Can
you
share
any
additional
insights
on
this
one.
A
Hi
paul
so
to
answer
a
question
quickly.
There's
a
separate
sig
meeting
about
auto
instrumentation.
I
think
that's
the
right
forum
instead
of
this
one,
but
in
general
I
agree
with
cj
mentioned.
I
think
if
the
activity
source
is
the
recommended
path
forward,
I
think
for
bad
code
instrumentation,
probably
they
need
to
align
as
well.
But
again,
this
is
not
the
right
forum.
I
Yes,
even
greg
started
to
work
on
some
prototype
using
activity
source
and
that
that's
the
idea
for
for
us
to
also
use
active
source
to
do
that
kind
of
experimentation
and
by
the
way
tomorrow,
we
have
the
media
at
1
pm.
If
you
want
to
join-
and
anyone
here,
of
course
is
welcome.