►
From YouTube: 2020-09-23 .NET Auto-Instrumentation 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
B
C
C
B
C
A
A
A
All
right,
I
think,
I
think,
it's
time
to
get
started.
Greg
has
been
doing
the
work
about
how
the
injection
of
the
diagnostic
source.
Yesterday
you
had
a
discussion
and
so
far
it
seems
that
the
best
approach
is
kind
of
for
us
to
have
a
source
version
of
diagnostic
source
to
inject.
A
If
it's
not
available
on
the
the
normal
load
path
assembling
and
the
idea
is
that
we're
gonna
work
in
parallel
on
that
I'm
gonna
start
just
doing
the
the
work
of
setting
up
the
diagnostic
source
source
version,
a
kind
of
rendering
style
inside
the
ripple
without
dependencies
and
greg
is
doing
the
the
further
tests.
With
that,
I
don't
know
if
you
want
to
add
more
details
to
that
greg.
B
I'll,
not
necessarily
we
went
over
the
high
level
thing
last
time
already.
If
you
have
questions,
I
can
definitely
answer
them
now.
Otherwise
we
have
a
internal
google
doc
about
this,
so
what
I'll
probably
do
is
I'll
just
copy
paste
it
in
I'll
slightly
change
it,
because
it
describes
the
version
that
I
was
prototyping
last
week,
and
this
week
we
had
a
design
review
with
the
team
and
then
a
long
conversation
with
powwow,
so
I'll
update
the
dock
and
copy
paste
it
into
the
issue,
and
that
essentially
summarizes
it.
A
A
Needed
and
earlier
today,
zach
and
I
started
a
conversation
about
reorganizing
the
folders,
with
kind
of
parallel
goals
in
kind
of
first
making.
Clearly,
what's
the
proposal
and
the
dependencies
or
things
between
the
the
ci
integration
tests
and
the
the
folders
that
we
have
there
and
also
kind
of
to
facilitate,
in
the
medium
term
kind
of
facilitate
us
to
be
able
to
pick
up
changes
between
the
the
the
different
ripples
that
people
may
fork
and
also
from
the
original
ripple
that
that
just
started.
A
A
B
So
for
the
for
the
for
the
for
the
things
that
for
the
folder
discussion
that
you
had
earlier
today,
so
I
mean,
I
think
the
goal
the
immediate
like
next
few
days
ago,
was
to
yeah:
do
the
folders
right
each
folder,
each
root
level,
four
that
will
be
either
merged
or
not
matched
between
the
repos
right,
so
that
essentially,
the
goal
is
that
top-level
folders
shouldn't
contain
files
that
some
of
them
are
kind
of
shared
between
the
reapers
and
some
of
them
are
not,
and
then
we
wanted
to
merge
whatever
we
have
added
from
in
data
doc
over
the
last
several
weeks
back
into
hotel.
B
When
do
you
guys?
What
is
the
reasonable
timeline
for
this
guys.
A
I
I
I
don't
know
the
the
exact
timing.
I
think
it's
a
bit
kind
of
hard
to
guess
right
now,
but
what
zac
and
I
discussed
it
was
to
kind
of
do
the
reorganizing
on
the
dd,
folder
and
td
repo,
and
I
you
pull.
Actually.
I
should
pull
even
before
that
pull
the
changes
that
happened
in
data
dog.
A
So
then
we
can
reorganize
the
folder
and
then
I'll
put
that
change
to
the
open,
telemetry
repo.
But
I
I
that
I
don't
have
a.
I
guess
about
the
timing
of
that.
You
know.
B
So
so
do
you
guys
prefer
to
first
do
the
reorganization
of
folders
and
then
do
the
merge
or
you
want
to
do
first
emerge
and
then
reorganization,
the
four
folders
and
then
another
merge?
Should
you
upload
it.
A
I
I
think
I
think
you'll
be
easier
to
do
one
merge
than
the
reorganization
of
the
folders
and
then
I
pulled
the
organization.
Okay
sounds
good,
I
I
hopefully
hopefully
I'm
gonna.
Do
you
know
that
devs
are
the
most
optimist?
People
in
the
world,
I'm
gonna
say
that,
hopefully,
by
next
weekend
or
next
week
next
week,
meaning
we
have
that.
But
you
know
we
are
very
optimistic.
A
I
hope
that
we
have
their
organization.
I
will
start
to
work
on
the
emerge
today
or
tomorrow,
to
pull
the
chains,
but.
A
B
A
Cool-
and
I
owe
I
owe
as
appropriate-
I
review
even
on
the
data
dog
repo,
because
it's
also
open
source
and
we
can
yeah
before
it
comes
to
yeah.
B
Makes
sense
makes
sense
cool,
so
we
hope
that
both
of
it
will
be
done
by
next
wednesday,
but
we
are
not
entirely
sure.
B
Is
actually
what
is
your
feeling
about
the
organization?
Is
it
like
rather
realistic,
rather
not
realistic,
even
if
it
can't
commit.
D
Yeah,
it's
pretty
realistic.
They
we
just
need
to
figure
out
if
the
ideas
that
we
paula
and
I
kind
of
came
up
with
if
they're
reasonable.
If
there's
any
issues
with
that
and
then
also
just
re-linking,
some
of
the
build
stuff
to
account
for
the
mood
folders.
But
it
sounds
like
a
realistic
timeline.
B
Okay,
perfect
cool.
I
also
have
nothing
else.
I
will
yeah
just
to
kind
of
go
a
little
bit
more
depth
in
what
paulie
mentioned
so
the
current
prototype
for
for
activities.
B
I
will
create
a
sub
branch
in
so
right
now,
it's
in
my
private
own
repo
and
not
in
the
company
repo
I'll,
create
a
branch
on
in
hotel
and
move
into
there
that
so
we
will
be
building
it
inside
of
hotel
instead
of
inside
of
datadog.
B
That
will
make
it
easier
for
power
to
contribute
directly
and
we
will
be
working
in
a
different
branch.
So
we
don't.
We
don't
need
like
at
this
very
early
stage.
I
don't
think
we
need
prs
in
that
branch.
Once
we
get
to
like
a
little
bit
more
stable,
end-to-end
prototype,
then
we
can
start
doing
prs,
make
sense.
A
Yeah,
I
I
I
think
the
the
ripple
is
configured
in
a
way
that
it's
gonna
require
us
to
approve.
That's
the,
but
but
we
can
even.
A
Yeah
I
I
would
check
that
oh
yeah,
we
can.
We
can
change
that
to
our
convenience.
You
know,
okay,
we
we
have
the
rights
there
and
we
can
change.
B
Sounds
good
cool
yeah,
so
right
now
I
have
assembly
loading
working
in
in
a
dynamic
way,
but
with
with
the
additions
that
powell
is
working
on,
we
will
make
it
more
robust
and
I
am
currently
working
on
on
the
emission
of
delegates
that
will
show
the
apis.
B
So
yeah
cool,
that's
pretty
much
it.
I
don't
think
I
don't
have
anything
else.
Anybody
else
has
any
additional
agenda.
C
I
can
talk
a
little
bit
about
what
I
was
thinking
about
doing
so
as
part
of
just
getting
up
to
speed
more
with
the
code.
That's
out
there.
I
was
planning
on
just
experimenting
with
seeing
if
I
could
take
the
open,
telemetry,
sdk
and
embed
it
within
the
the
tracer
and
see
what
the
interactions
there
could
look
like
nothing.
That
would
be
anything
ready
to
go,
but
just
if
I
could
line
things
up
with
a
particular
test
app
that
has
the
right
dependencies
in
place.
C
Can
I
actually
get
something
working
where
I
can
see
traces
being
emitted
via
the
hotel,
sdk.
B
Yeah
that
may
make
sense
for
but
there's
two
two
considerations
to
keep
in
mind.
As
as
you
do
this
generally,
it's
a
good
idea,
but
generally
like
just
ch,
choo
choo.
So,
first
of
all
the
actual
collector
inside
of
the
tracer,
we
need
to
consume
activities
via
the
shims
that
we
are
currently
building
with
power.
So
that's
one
consideration
and
then
the
other
is
I
appoint
you
to
a
branch
in
the
data
dog
repo
where
we
have
a
prototype
of
of
using
activities.
B
The
prototype
does
not
address
the
the
versioning
space.
That's
that
just
a
kind
of
it's
a
prototype,
but
just
reference
the
diagnostic
source
directly,
but
it
solves
a
bunch
of
challenges
that
we
have
in
the
tracer
now
around
performance
and
reliability
of
how
we
batch
things
together
before
they're
serializing.
So
it's
essentially
the
exporter
part
and.
B
B
I
have
some
prototypes
that
I
didn't
even
push
in
any
repos
to
kind
of
take
what
I,
what
I
will
send
you
further
is
a
sort
of
a
compromi,
a
compromise
between
sdk
and
what
you
will
see
in
that
branch,
and
once
we
can,
we
will
kind
of
move
further
on.
We
might
even
contribute
some
part
of
it
back
into
the
sdk
it
essentially
it
is.
It
addresses
two
areas
that
this
decay
currently
doesn't
address.
B
One
is
just
one
is
very
specific
to
data
dog,
but
now
we
have
the
scenario
and
the
other
is
generic.
The
generic
is
essentially
trade
off
configuration
possibilities
for
performance,
because
in
sdk
it's
an
application.
We
want
to
give
customers
a
lot
of
frequency,
a
lot
of
flexibility
to
make
it
behave
in
different
ways.
We
don't
need
in
the
tracer,
so
I
you
know
I'm
saving
allocations
and
checks,
and
whatever
I
choose
to
on
that
class,
and
also
I
am
using
sync
all.
B
I
o
is
synchronous
on
a
background
thread,
because
again
we
control
this.
We
don't
want
to
use
thread,
starvation,
this
kind
of
stuff
and
then
that's
the
generic
part
of
it.
And
then
the
specific
part
of
it
is
datadog
protocol
requires
the
entire
trace,
the
entire
local
trace
of
the
rate
without
the
re-entry.
So
the
part
that
you
know
you
were
entered
and
then
you
did
several
spans
and
then
now
you're
done.
B
This
needs
to
be
serialized
as
a
as
one
thing,
so
we
are
not
able
to
send
spans
that
belong
the
like
a
trace
in
like
in
in
several
packets.
So
we
need
a
mechanism
that
batches
these
together
and
then
cause
serialization.
A
We,
what
we
did
was
we
changed
it
at
the
api
level.
We're
doing
on
the
exact
properties
perhaps
is
more
familiar,
because
there
is
the
agent
api
level
we
change.
We
make
we
made
that
layer
pluggable,
so
we
we
plug
something
to
serialize
at
that
level
there.
So
we
can
serialize
to
zipking
and
basically
is
the
format
that
we've
been
using.
You
know.
B
So
so
the
current
the
current
prototype
that
I
have,
because
I
wanted
to
make
this
as
efficient
as
possible
and
minimize
any
lookups,
because
the
thing
is,
we
now
need
to
group
essentially
spence
by
trace
and
to
make
this
really
really
fast.
I
built
this
capability
into
the
very
high
level
of
the
collector
rather
than
into
the
serializer.
It's
an
option.
B
It's
not
required,
so
there
is
a
currently
a
configuration
flag
and
if,
as
soon
as
a
span
is
finished,
we
know
immediately
whether
whether
or
not
it's
a
root
span,
the
local
roots
pen
and
if
it
is
and
if
it's
not,
then
we
put
it
in
a
special
bucket
that
collects
the
entire
trace,
and
if
it
is
the
root
span,
then
we
take
the
bucket
and
send
it
to
the
serializer.
And
if
the
option
is
not
enabled,
then
we
send
every
span
to
the
serializer.
B
C
Okay
yeah,
so
so
it
sounds
like
you've
already
experimented
with
the
idea
that
that
I
was
thinking
about
playing
around
with
so
yeah
it'll,
be
it'll,
be
interesting
to
see,
see
what
you
got.
B
A
Sounds
very
good
chris.
If
you
want
to
kind
of
feel
free
to
bring
this
discussion
on
guitar
or
via
a
draft
pr.
Whatever
you
you
have,
I
think
I
think
people
you
like
to
have
the
discussion
with
the
issues
or
things
that
you
find
or
questions
that
you
may
have
sure.
Yeah.
B
Yeah
and
then
so,
my
high
level
plan
is
once
once
activities
has
a
like
prototype
that
that
works
kind
of
entrant
I'll.
You
know
if
you
made
some
a
lot
of
progress
in
that
space
by
then
then
we'll
combine.
If
not,
then
I
will
start
working
on
in
that
area
and
we
can
combine
with
the
time
whatever,
wherever
whatever
stage
you're
at
then
we'll
take
it
from
there.
A
Okay,
so
we
save
a
lot
of
time.
We
get
back
a
lot
of
time
if
nobody
has
anything
else.
E
Yeah,
I
do
have
one
quick
thing:
it's
it's
eric
here.
I
just
wanted
to
check
in
and
see
about.
You
know
in
terms
of
goals
and
timelines.
You
know
obviously
with
the.net
sig
we're
targeting
that
november
30th
ga
date
and
I'm
just
wondering
like
where
we
think
we're
going
to
get.
You
know
with
auto
instrumentation
kind
of
in
that
time
frame
and
what
we
think
is
reasonable.
A
I
I
would
love
to
to
have
this
by
ga
time,
but
I
think
we
are
still
grabbing
with
the
initial
stuff
and
we,
our
rough
planning,
is
still
very
high
level.
You
know
so
I
would
say
from
my
part,
I'm
I'm
I'm
targeting
this
to
attempt
to
be
ga.
A
But
realistically
I
think
we
are
going
to
be
a
bit
late
for
that,
but
I
I
would
love
to
kind
of,
as
we
kind
of
perhaps
go
over
the
first
stumbles
off
the
not
stumbled,
but
the
first
issues
of
that
we
have,
in
our
plate
kind
of
define
a
little
bit
better.
That
initial
rough
road
map
that
we
published
before.
B
I
honestly
have
very
high
doubts
that
we
well
actually.
First,
we
need
to
have
a
clear
list
of
what
we
need
to,
because
roadmap
is
kind
of
what
what
we
want
to
do,
but
that
is
more
flexible.
What
is
less
flexible?
What
are
the
things
that
need
to
be
done
in
whichever
order
before
we
are
okay
with
being
ga,
because
it's
it's
it's
a
non-clear
question,
because
the
this
trace
is
already
in
production
and
ga
for
several
vendors.
B
So,
theoretically,
we
could
just
call
the
caller
ga
right
now,
but
I
think
we
don't
want
to
because
we
would
like
to
generalize
a
certain
certain
things
and
make
them
more
pluggable.
So
I
think
the
first
step
would
be
to
make
a
ultimate
list
what
it
is
that
we
need
to
take
off
to
bga,
because
we
could
declare
it
today
right
and
then
we
can
talk
about
like
timelines.
A
Yeah,
I
I
think
eric
that
we
we
we
do
have
space
for
some
pmi
working
on
this
regard,
about
the
the
things
that
greg
mentioned
about
also
even
establishing
our
criteria
for
ga.
That
is
not
the
same
as
the
library
the
client
libraries
wants.
You
know
so.
B
Generally,
I
personally
believe,
but
that's
just
very
subjective-
is
that
there's
absolutely
no
reason
for
us
to
have
to
match
the
30th
of
november
date
if,
if
it
turns
out
to
be
natural
and
easy
and
things
align,
that
would
be
cool
to
kind
of
be
in
on
that
bandwagon.
But
if
not,
what
do
we
care
as
long
as
we
make
clear
progress.
E
Yeah
and
that's
okay
with
me
too,
that
was
more
just
just
for,
like
you
know,
transparency
on
where
we're
at
just
wanting
to
know.
You
know
if
that
was
a
reasonable
goal,
or.
B
Not
yeah,
I
would
suggest
maybe
somebody
can
like,
if
you
like,
if
you
like,
you
can
get
a
google
doc
going
with,
like
you
know,
inspired
by
paulo's
roadmap
that
would
list
all
the
things
that
we
would
like
to
have
done
to
call
things
ga
or
just
add
it
to
apollo's
dock,
whatever
you
prefer
and
then
we
can
review
it
together
and
then
once
everybody
is
happy,
then.
E
Yeah
I
can
take
an
initial
stab
at
it.
I'll
certainly
need
lots
of
help
from
you
guys,
but
but
yeah
I
can.
I
can
start
organizing
that
cool.