►
From YouTube: 2020-05-13 .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
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
B
C
C
C
Just
start
reading
they
start
with
this
stuff
and
I'm
positive
that
we
we
are
gonna,
get
changes
that
we
need
when
they
donate
to
support
that
you
know,
but
I'm
sorry,
I
lost
you.
Can
you
repeat,
I,
start
reading
the
issue
for
status
and
I
I'm
positive
that
we
we
don't
need
to
support
as
it
is.
You
know
that
I
think
that
is.
There
is
a
confusion
if
two
things
kind
of
the
status
of
the
expanding
error,
reporting
in
terms
of
stagnant
thing,
I
think
we
should
separate
these
two
discussions,
but
I
I.
C
B
Yeah
yeah
and
a
long
position
is
known
last
night
and
what
one
thing
we're
thinking
like
a
given
spend
might
have
multiple
exceptions
and
also
for
Donna
exceptions
might
change.
It
might
got
a
great
exception,
so
might
be
able
to
leverage
things
like
events
or
something
for
the
actual
exception
or
the
error
message,
but
the
span
is
the
status
is
more
like
from
the
consumer
perspective
like,
even
if
you
got
some
exception
telling
you
like
Stack
Overflow,
but
from
the
application
perspective.
Probably
everything
is
fine.
I
just
want
to
report
status.
A
B
The
the
thinking
I,
probably
we
should
move
the
community
meeting
back
to
like
the
Mauryan
time
for
last
year.
So
you
can.
You
can
always
turn
that,
instead
of
doing
the
switch,
because
once
you
miss
a
meeting,
it's
very
hard
to
catch
up
and
and
your
women
tend
also,
we
want
to
make
sure
that
you're
there
and
still
they
seems
to
be
flexible,
so
he's
okay.
We,
we
move
the
meeting
back
yeah.
A
D
Yeah,
so
how
do
you
want
to
structured
like?
Should
we
just
repeat
what
we
said
or
should
be?
They
go
through
the
issues
which
might
have
like
one
by
one.
How
do
you
want
to
structure
this
one,
because
we
basically
did
what
we
basically
did
yesterday
was
violently
of
an
order
of
the
North
Star
goal
and
how
we
are
going
the
direction
like
encode
and
like
some
of
the
issues
which
we
see
are
temporary
like
point
in
time,
issues
which
will
be
resolved
as
we
get
closer.
D
A
So,
from
from
my
perspective,
I
think
a
lot
of
the
things
that
I
was
highlighting
is
the
difference
between
the
open,
telemetry
spec
and
what
is
present.
Is
it
not
in
that
view,
and
what
the
the
PR
currently
is
and
I'm
over
the
PR
that
you've
got
at
the
moment
and
what
the
there's
a
diagnostic
sauce
PR
for
the
nor
did
is,
is
not
complete.
We
know
that
that's
just
an
initial
iteration
and
the
subsequent
changes
can
be
made
in
an
iterative
in
an
iterative
process.
A
I
think
the
main
thing
that
I
wanted
to
raise
and
I
think
Powell
or
raised
it
in
yesterday's
sake,
which
I
got
up
to
us.
It's
that
the
open,
telemetry
API
is
two
parts.
The
first
part
is
in
the
API,
it's
a
consistency
across
all
languages
and
therefore
that
you
can
move
between
the
languages
consistently
and
understand
that
a
lot
of
the
objects
consistent
in
context
and
that
that
translates
between
different
areas
and
then
the
second
part
is
the
SDK,
which
is
an
implementation
of
that
API.
A
So
I
think
we
definitely
lose
that
if
we
were
to
adopt
I'll
lose
some
of
that.
If
we
were
to
adopt
the
activity,
an
activity
sauce,
that's
not
to
say
that
I,
don't
think
that
that's
the
wrong
thing
to
do
it's
thing,
but
a
significant
thing
that
will
be
different
in
the
dotnet
implementation
compared
to
everywhere
else,
because
we'll
have
to
do
that
at
the
API
level.
It
won't
be
done
at
the
SDK
level,
because
we're
talking
to
people
it
will
be
basically
presenting
open
telemetry
for
dotnet,
you
use
activity
and
activity.
A
So
if
you
don't
use
sponge
and
traces
and
so
on,
so
that's
one.
One
thing.
The
second
thing
is,
if
it
was
also
discussed
briefly,
is
that
the
first
thing
we
will
be
looking
at
is
the
tracing
element
or
walking
telemetry
work
and
then
possibly
want
a
metrics,
and
then
the
logging
orphan
telemetry
API
covers
all
three
components
of
that.
So
I
will
have
a
disjointed
API
because
of
that
so
we'll
have
one
for
in
Microsoft's,
Diagnostics
source,
API
of
activity
and
activity
sauce
and
then
another
for
in
open.
A
Telemetry
is
a
public
API
that
is
metrics
and
logs
logs,
not
air-eye
and
completable
metrics
that
are
close
to
being
complete.
So
it
feels
they
work,
we're
sort
of
struggling
both
sides
and
I
think
that's
really
dangerous.
If
we're
wanting
to
move
towards
beter
auto-off,
we've
got
a
target
towards
the
end
of
the
year,
because
we're
going
to
need
some
sort
of
consistency
with
I,
don't
want
to
be
moving
big
chunks
of
the
API
around
like
that
and
not
without
good
cause,
of
course.
So
yeah,
that's
that's
I!
A
Don't
like
the
me
into
parts
of
it.
I
think
activity
sauce
activity,
an
activity
sauce
using
those
directly
from
the
Microsoft
library
isn't,
is
a
great
thing.
I
think
having
somebody
being
able
to
instrument
with
those
things
and
being
able
to
open
telemetry
API
to
to
collect
that
information
would
be
ideal
and.
A
C
I
have
the
the
same
kind
of
concern
about,
but
there
are
Chileans
for
that,
but,
like
the
API,
that's
visible
for
application,
people
write
applications,
and
my
first
instinct
at
the
moment
is
that
we
should
provide
API
for
that.
Even
if
it's
a
wrapper
around
activity
from
the
meeting
yesterday,
I,
don't
know
if
you
go
to
that
part
mark
I.
C
C
What
I'd
be
moved
so
far?
I
don't
think
there
is
nothing
that
prevents
it
from
to
be
adapted
to
activity.
I,
don't
see
that
as
a
problem,
but
I
find
that
it's
very
risky
that
we
are
gonna
have
a
lot
of
a
lot
of
no
we're
gonna
have
fragmentation.
What's
gonna
happen.
Is
that
somebody
that
snow,
open
telemetry
is
gonna,
arrive
at
dotnet
trying
to
write
something
and
they
are
gonna,
see
hey,
they
don't
have
the
API.
C
Oh,
they
use
activity,
but
oh
I'm
gonna
write
the
API
on
top
and
then
there
will
be
a
open,
telemetry
API,
that's
not
from
the
origin,
no
yeah,
and
even
if
we
just
have
a
ship
around
activity,
I
think
my
first
impression
is
that
we
should
pursue
to
have
that
shame.
But
I'm
I
can
be
convinced
that,
with
the
examples
and
trying
ABI
that
perhaps
I'm
worrying
too
much,
but
that's
my
start
position.
C
The
other
is
that
I
think
whatever
you
do
for
activity
and
mapping
through
open
telemetry
in
the
end,
there
is
always
a
back-end
format
right.
So
a
lot
of
what
you're
gonna
do
is
actually
define
the
conventions
kind
of
oh.
If
you
do
this
activity,
this
is
the
equivalent
of
something
in
open,
telemetry
and
in
a
sense
with
that
definition.
C
A
E
We
have
to
still
learn
the
network
plus
learn
so
I
ought
to
be
honest,
like
I
jumped
in
and
I
saw,
it
was
happening,
I
didn't,
say
anything
but
I.
Second,
everything
Mike
said
in
this
call
and
I
also
want
to
comment
on
a
PR.
That
I
also
have
my
reservations.
Hearing
it's
completely
abandoning
the
package
that
has
the
API
and
just
going
all
the
way
through
only
with
activity,
I
think
it's
not
the
way
to
grow
personally.
E
So
if
at
least
we
can
have
this
shim
and,
like
you
know,
would
it
be
possible
to
ship
the
API
like
that
course
through
and
starts
activities
like?
That
would
be
that
would
be
I
believe
the
VCL
as
well
like
all
the
promises
that
the
activity
give
it.
It's
great
I,
don't
get
me
wrong
right,
but
it
is
it's
a
problem.
A
At
the
same
time,
yeah
from
like
from
the
experience
I've
got
off
sorry
little
exposure.
I've
got
the
weather
the
new
activity
map,
it's
diet,
activity,
sauce
works,
I,
don't
really
view
it
as
an
overly
different
way
of
how
we
can
instrument
something.
As
we
are
now
age.
It
should
just
be
aware
for
us
to
instrument
instrumentation
we
built
into
a
library,
and
we
can
just
collect
that
in
the
open,
telemetry,
API
representation
and
then
once
what
so
as
a
an
activity
completes,
it
becomes
as
so.
A
We
talk
to
it
as
a
spun,
and
then
it
goes
through
the
normal,
open,
telemetry
pipeline
export
as
and
we've
already
got
it
in
that
format
that
we
want
to
deal
with
it
and
then,
whenever
it
goes
to
backpack
and
exporters,
then
it
totally
unaware
that
it
really
came
from
an
activity.
It's
an
open,
telemetry
representation
of
that.
B
It's
all
I
want
to
expand
my
my
thinking
this
so
I
think
for
for
tracing
metrics
and
logs.
The
general
interest
here
is:
we
want
to
push
more
things
into
tonight.
So,
having
done
it
easier,
providing
more
support
for
telemetry
is
a
nice
acting
for
everyone,
but
the
intention,
I
think
is
not.
We
won't
donate
to
entirely
replace
the
API
surface.
I
would
imagine
some
of
the
API
surface
level,
even
SDK
accessories
like
his
or
her
or
some
instrumentation
related
API
surface
like
the
way
to
deal
with,
like,
like
other
propagation
format,
correlation
format.
B
Those
things
have
always
been
like,
like
there's
a
need
to
have
those
things
in
API.
The
goal
is,
if
done
that,
can
do
more
than
in
the
open
time
for
API
layer.
We
can't
have
a
very
thin
layer,
we
can,
we
can
do
less,
and
this
will
be
a
benefit
for
performance
and
also
like
as
more
people
eating
donuts.
They
see
the
benefit
from
leverage
in
open
country.
B
That
means
less
diverge
story,
so
this
is
a
general
direction
and
I
I
agree
that
the
current
situation
were
still
trying
to
explore
so
words,
we
start
with
trace
and
I
think
for
matrix
API,
probably
by
another
year,
we'll
still
have
that
inside
open
telemetry,
and
you
eventually
want
to
see.
If
we
can,
we
can
support
some
of
them
in
open
in
donut
framework.
The
the
general
idea
is.
We
want
donut
to
do
more
to
make
open,
telemetry
right
her,
but
not
to
compete,
whistle
open
telemetry.
Regarding
the
concept.
This
is
something
I'm
on
offense.
B
So,
while
I
was
the
maintainer
for
Python,
we
were
working
on
the
login
API
integration
and,
at
the
time
I
believe
we
had
a
long
conversation
and
still
is
hardening
the
login
say
you
join
the
login
side
or
the
schema
agency.
You
can.
You
can
see
the
similar
like
conversation
or
debate,
so
people
are
thinking.
Should
we
make
sure
every
single
language
runtime
have
the
same
API?
B
If
not,
we
can
provide
that
from
the
open,
kilometer
API
layer
try
to
make
sure
everything
looks
the
same
across
all
the
languages
or
sometimes
we
can
step
back
and
try
to
be
that
language
automatic
examples
I
can
give
is
forego
language.
I
know
the
NGO
has
its
own
compacts,
which
she
compassed
execrated
and,
and
they
took
that
approach.
So
the
contacts
API
is
based
on
the
goal
made
head
contacts
and
for
Python
logging.
B
We
kind
of
decided
that,
instead
of
inventing
a
brand
new
open
climate,
login
API
the
Python
login,
each
I
will
just
be
the
Python
runtime
logging
API,
and
if
open
telemetry
put
extra
requirement
whoa
Explorer,
we
can
use
the
primitives
provided
by
Python
runtime
and
provide
that
feature
in
open
country
or
even
like
more
ideal
case.
We
can
work
with
the
Python
runtime
to
put
that
as
part
of
Python
and
and
for
context.
That's
already
happening.
B
So
you
know
what
historically
Python
has
a
like
this
thread-local
storage
based
context,
management
and
later
they're,
like
asynchronous
concept,
but
how
to
probably
get
the
contacts.
Probably
in
the
asynchronous
context.
That's
something
we
solved
with
context
Mars,
and
it
was
not
their
only
work
on
open
senses.
B
When
we
see
the
need
will
have
this
open
synthesis
requirement,
we
start
to
have
the
discussion
with
a
runtime
and
eventually
the
runtime
give
us
a
very
good
performance
implementation
of
convex
war
and
that
that
kind,
how
has
to
like
either
this
I
use,
TLS
or
contacts
more
depending
on
the
runtime.
This
is
a
good
addition
for
donut
I.
Think
we
want
to
do
the
same
so
for
them,
I've
done
it
have
a
lager
at
the
API
I
want
to
see.
Instead
of
open
climb
should
build
building
its
own
logging
idea.
B
You
want
to
walk
with
a
logger
to
improve
that,
so
a
logger
will
be
a
hundred
percent
compliant
with
open,
climb
tree,
the
more
open
climb
which
we
can
involve
as
a
standard
to
have
all
the
language
runtime
and
the
third-party
libraries
willing
to
embrace
that.
Instead
of
we
doing
the
work
to
close
the
gap,
I
think
this
is
actually
the
only
function,
but
from
process
perspective,
there's
always
like
different
languages
to
move
at
different
pace,
and
sometimes
the
language
have
historical
reason.
The
name
doesn't
look
like
the
same.
Like
forego.
You
know
the
context.
B
Is
it's
not
exactly
the
same
name
as
a
as
a
like
open
time,
and
also
like
for
even
for
I,
feel
like
like
in
general,
we
call
that
Spain
has
a
set
of
key
value
pairs.
We
call
it
a
tribute,
but
for
some
languages
actually
build
has
a
special
meaning
and
they
don't
want
to
use
actually
don't
use
property
or
like
different
things.
So
those
are
the
things
we
try
to
find
that
balance,
and
this
is
the
place
where
I
see
people
around
the
fence.
E
Like
I
understand
what
you're
saying
I
agree
with
it
like
at
century:
two
years
ago
we
started
unifying
the
API,
so
all
the
SDKs
know
languages
have
that,
so
we
have
go
and
rust
in
etc,
and
we
had
a
lot
of
these
where
we
had
to
decide
between
being
idea,
Matic
or
being
or
being
unified,
and
you
know-
and
just
there
was
no
way
to
be
on
a
file
like
you-
can
call.
We
have
a
function
called
init
in
Objective
C.
E
C
I
understand
the
desire
to
not
have
two
competing
api's,
but
I
don't
see
them
as
really
competing.
I
I
would
see
that
there
is
a
that
is
a
library
framework
that
doesn't
want
to
take
a
dependence
or
won't
pay
telemetry.
They
they
should
be
free
to
use
their
runtime
with
the
excellent
stuff
that
comes
from
the
runtime,
but
I
would
like
to
people
that
are
writing.
The
application
should
be
able
to
kind
of
transport,
especially
let's
say,
environments
that
have
multiple
languages.
C
B
Agree,
and
also
for
for
that
thing,
another
thing
being
thinking
is:
we
want
to
enable
the
scenario
if
the
customer
has
a
like
hyper
performance.
Open,
telemetry,
compatible
c++
is
DK
and
they
have
explorers
in
for
that.
They
won't
use
that
to
replace
the
donor
at
highest
DK.
We
should
enable
that
yourself
telling
like
that
is
so
different,
so
you
can
use
a
sip
Hospice
SDK
to
use
the
Python
open,
Irish,
API,
plus
the
open
country
sip
has
precisely
that
works,
but
for
donor,
unfortunately,
we're
different.
It's
not
in
to
work.
B
A
Yeah
yeah
I,
agree
and
so
part
of
what
we've
done
with
the
c-sharp
implementation.
The
Dhamma
implementation
is.
We
have
try
to
separate
a
lot
of
the
concept
that
the
top-level
things
into
the
API
for
which
is
possible.
It
is
possible
company,
past
rounds,
other
things,
but
I
think
we
are.
We've
definitely
got
some
dependencies
between
the
SDM.
You
had
the
moments
about
eight
guys,
not
a
purely
an
API.
It's
there
is
got
this
got
some
implementation
concept
in
there,
so
I
think
we
I
agree.
I,
think
we
need
to
separate
that
I
will
love.
A
C
And
I
have
a
suggestion
here
for
for
us
to
have
kind
of
get
a
feeling
for
the
things
I
are
already
mentioning
yesterday
that
assume
the
PR
is
Murshid.
Are
you
kind
of
extend
exporters,
OTO,
paj,
zip
King
to
export
from
activity?
So
we
can
see
that
on
practice
how
things
go
and
where
we
perhaps
need
some
feature
changes
in
activity
activity,
source
YUM,
a
related
finger
will
be
to
be
writing
the
wrapper.
So
we
can
get
a
feeling
out
so
how
it
looks
how
it's
gonna
behave,
I!
B
So
I
think,
like
I,
want
to
quickly
unblock
this
progress,
so
we
can
move
forward
and
try
to
explore,
because
this
is
a
critical
time.
The
earlier
we
can
explore
things,
the
more
like
leanness
will
have
to
push
down
at
him,
make
the
change
and
finally,
I
think
I
like
this.
This
PR
is
just
the
first
time
and
then
we
look
at
the
preview
for
release
from
donut
he's
far
from
ideal,
like
the
tired,
only
support
stream
and
support
all
the
time.
B
So
we
have
been
having
this
discussion
this
morning,
see
Joe
and
I
are
working
with
Terok
Nor
and
they
kind
of
figured
out
a
good
solution
and
so
far
I
think
I'm
happy
with
the
solution
that
it
proposed
I
want
to
see
that
him
in
preview
of
five
as
early
as
possible
and
and
they
don't
get
enough
feedback
for
them.
They're
kind
of
like
having
that
gap
disconnected
they're
going
to
shape
something
that
seems
to
be
working
for
open
times
and
in
end
we'll
figure
out.
B
Something
is
not
working
so
either
we
decided
okay
to
abandon
is
effort
entirely
that
that's
a
bad
thing
for
all
of
us
or
decide.
Okay,
we're
going
to
leave
this
as
70%
completed,
which
is
also
bad,
so
I
won't
try
my
best
to
push
this
to
see
if
we
can
arrive
at
95%
of
the
coverage.
So
it
looks
very
similar
to
open
time
check
with
the
5%.
We
know
we
probably
don't
have
enough
energy
to
cause
the
gap,
but
we
have
a
reasonable
mitigation
in
the
open
telemetry
layer
to
smooth
that
out.
A
Yeah
and
I
think
that
that's
really
valuable.
We
do
want
to
move
quickly
because
we
want.
We
put
this
three
copies.
Three
parties
involved,
a
you've
got
the
people
developing
open,
telemetry
this
SIG
and
then
also
the
dotnet
team
that
are
providing
this
new
interface
and
the
classic
collection
of
classes
and
I
do
also
agree
that
there's
a
risk
that,
if
we
don't
move
fast
enough
with
the
will,
will
will
potentially
just
have
to
stop
what
we're
doing
and
go
back
to
what
we
were
doing
or
something
like
that.
A
B
Be
supportive
if
the
current
ice
DK
is
in
the
beta
or
even
like
country
a
status
I,
can
the
a
branch
would
make
sense,
given
the
current
status
is
still
like
off
a
very
early
stage,
I
think
to
move
faster,
probably
like
I
would
want
to
see
like
we
can
consider
it
on
a
single
branch,
because
separating
a
branch
will
introduce
a
lot
of
like
because
merge
poor
scenes
from
one
branch
to
another
and
also
all
the
testing
infrastructure
and
work
out
doubled.
So
given
is
alpha
like
they
were,
pointing
to
I.
B
Think
I
would
prefer
to
move
faster,
I,
tolerant
in
some
additional
like
additional
burden.
We
might
take
freedom
belief.
We
see
a
Tim
person,
have
the
chance,
we're
going
to
reverse
and
hard
work
and
stop
investing
meanness.
I
would
rather
to
stay
like
it's
ten
percent
I'd,
rather
to
pay
for
that
later,
because
I
think
ninety
personnel,
the
chance
will
be
successful
here
so
I
want
to
focus
more
energy
here
yourself,
I'm
a
low
percentage
like
thing
one.
D
D
Then
we
can
do
the
actual
like
removing
of
span
and
at
the
at
that
time
we
can
revisit
the
decision
of
should
be
like,
while
we
are
deleting
the
span,
instead
of
deleting
it
make
it
a
thin
wrapper
around
activity.
If
we
choose
at
that
time,
because
right
now,
the
way
I
intend
to
work
is
I'm
not
going
to
do
it.
D
For
example,
the
next
thing
which
chuckling
sampler
this
sampler
is
all
about
working
on
span
but
I'm,
going
to
replace
sorry,
not
replace
I'll,
be
adding
something
old
activity,
sampler
which
will
operate
on
activity,
context
and
activity
kind,
and
things
like
that.
So
it's,
like
addition,
so
at
least
in
the
next
few
weeks,
while
we
are
right
trading,
will
have
both
options
available.
We
won't
be
like
very
specifically:
I
won't
be
deleting
sampler
I
will
be
just
adding
activity
sampler
and
all
the
existing
examples
board
using
the
old
one.
D
It
should
just
work
it
just
prefix
activity
to
it.
So
we'll
have
it's
bit
of
burden,
because
I
have
to
like
pretty
much
duplicate
the
effort,
but
I'm
absolutely
fine
with
that,
because
that
way
we
can
all
see.
How
did
you
approach
compares
with
the
new
one
we
can?
Also?
There
is
some
other
person
who
is
trying
to
do
benchmarking,
so
we
can
really
see
whether
we
gain
performance
or
like,
or
we
are
like
losing
performance.
So
you
can
so
this
way
like
we
are
progressing
at
the
same
time.
D
We
are
not
like
I
want
the
activity
to
be
the
API,
but
we
are
not
essentially
deleting
or
removing
spam.
It
will
be
like
coming
at
a
later
stage
when
we
have
seen
activity
in
action
and
the
moment
we
are
going
to
delete
span
at
that
time.
We
can't
really
sit
and
decide
whether
we
want
to
ship
the
shim
layer
or,
like
some
sugar
coat
on
top
of
activity,
so
that
people
from
Java
or
NGO
would
feel
much
more
comfortable
with
the
names
which
they
are
familiar
with.
D
But,
like
I
was
saying
yesterday,
it's
it's
something
which
we
can
add
later
like.
We
don't
want
to
add
it
like
right
away.
We
can
just
move
to
say:
without
this
sugar
coating
or
wrapper,
the
primary
goal
is
to
try
the
new
API
as
soon
as
possible
asset
potential
replacement
for
span
and
then
play
with
it
and
see
if
we
need
something
from
dotnet
team
and
because
that's
a
train
which
we
definitely
want
to
care
so
like
I,
tried
as
soon
as
possible.
I'm
like
I'm.
D
Writing
that
sometimes
I
feel
like
I
should
be
writing
dirty
code.
Just
to
like
proceed.
That's
one
of
the
reason
why
I
initially
decided
to
do
like
the
it
it
has
like
so
many
things,
but
right
now,
I
just
read
like
one
thing
so
that
I
can
like
that
right.
So
we
still
have
the
old
way.
I'm,
not
deleting
so
towards
the
next
few
weeks
will
be
like
closing
the
gaps
and
I
expect
that
we
will
be
like
90
to
95
percent
complaint,
because
dr.
D
team
is
parallely
working
on
addressing
things
like
they're
already
working
on
tax
being
spring
spring
and
I
think
we
will
uncover
more
things
because
I'm
just
looking
at
something-
and
there
may
be
things
which
are
missing
so
only
we
would
only
know
if
you
try
it.
So
that's
one
of
my
motivation
is
going
that
really
first,
probably
leaving
Spain
as
it
is
I
initially
thought
like
I'll
just
delete
spanning
or
like
replay
Spain,
but
based
on
the
feedback.
I
think
it's
best
to
leave
Spain
untouched
and
have
a
parallel
working
stream
for
activity.
D
Of
course,
I'm
still
working
on
same
branch,
I,
don't
really
like
the
idea
of
multiple
branches,
given
that
we
are
in
early
alpha
stage.
So
what
about
this
approach,
just
to
repeat
and
continuing
for
shielding
with
activity
no
applied
to
remove
span
in
at
least
I?
Please
still
everyone
get
a
chance
to
get
a
feel
of
our
2t
works,
and
once
we
reach
that
stage
where
activity
and
span
are
like
accepting
names
and
terminologies
conceptually
both
are
aligned
like
that's.
D
A
C
I
was
gonna
say
that
I
I
think
that
sounds
reasonable.
I
I
think
on
the
low-level
things
I
think
a
bunch
of
things.
Perhaps
we
can
get
by
making
the
in
generic
because
they
are
just
trans
transporting
the
data
and
kind
of
we
can
have
the
same
code,
but
now
is
generic.
It
could
be
transporting
they
spend.
E
C
They
activity
what
needs
to
be
specific,
is
kind
of
the
exporters
and
we
need
to
separate
somewhere
in
namespace
or
something
they
the
sheen.
You
know,
I
I
think
that
that
will
be
reasonable.
If
you
do
this
way
and
we
can
keep
working
on
the
master
branch,
you
know
because
one
way
or
another,
my
understand
is
activity,
source
and
activity
are
here
to
stay.
We
are
just
design
about
the
features
that
we
need
to
ask
from
the
dotnet
team
and
about
the
sheen
regarding
expand
and
trace.
No.
A
Yeah
I
think
I,
agree.
I,
think
it
was
just
as
a
suggestion
to
see
if
that
would
be
a
better
solution
by
agree.
I
think
we
want
as
much
visibility
on
this
and
we
want
as
much
people
participating
to
get
that
that
comparison
between
what
we've
got
now
as
far
as
interest
is
and
metrics,
and
then
we'll
be
what
it
will
look
like
in
the
activity
map
to
Vsauce
world
as
long
as
there's
none,
it's
not
a
replacement
which
I
agree.
That
is
would
be
detracting,
and
then
we
can.
A
We
can
assess
that
as
we
go
forward
to
see
if
there
are
any
problems,
what
the
gaps
are
look
like
and
then,
if
we
want
to
take
that
next
step,
then
we
can
remove
what
we
currently
have
with
the
shim
or
something
like
that
and
make
sure
that
that's
the
wall
compatible
and
we're
still
look
as
much
like
the
open
telemetry
as
we
can
but
then
depend
directly
on
what
the
activity
of
active
resource
will
look
like
in
the
future
thing.
That's
that's
fine.
A
D
I,
don't
really
know
if
any
one
actively
trained
labelled
a
few
customers
like
just
trying
it
out,
but
no
one
has
it
running
anywhere
like
in
production
or
anything.
So
we
even
if
it
wants
really
desire
to
like
break
spine
into
activity.
It
will
be
breaking
change,
but
it's
it's
not
like
really
a
big
problem,
because
people
are
still
like
early
adopters
are
experimenting.
How
how
it
looks
like
not
really.
A
Deploying
to
production
or
anything,
yeah
and
I
think
Robbie's
point
as
well
as
the
we
are
so
in
alpha
we're
not
you
know,
we're
allowed
to
be
breaking
at
this
form
between
different
versions
and
things
like
that.
So
if
we
did
want
to
take
it,
those
touch
changes
it's
much
better
to
do
that.
Work
now
before
we
announce
be
there
yes
and.
B
Some
comments
regarding
the
CEOs
PR
I
think,
like
the
the
logic
behind
they
said,
I
was
trying
to
push
down,
as
so
hard
I
have
been
telling
them.
You
need
to
release
this
as
early
as
possible
to
consolidate
feedback
from
the
community,
because
they're
going
to
be
a
lot
of
feedbacks
and
they
were
happy.
They
want
to
paly
said
like
from
70%
to
80%
and
told
them
like
no
way
you
want
to
release
70%
and
get
blamed.
B
So
we
come
together,
figure
out
what's
the
gap
and
try
to
code
that,
so
that's
the
current
situation
because
they
were
under
that
pressure.
I
cannot
like
push
them
to
release
this.
So
we
know
there
are
a
lot
of
gaps
for
some
of
the
things
like
this.
We
don't
have
status
and
we
don't
have
a
like,
like,
inter
type
or
any
primitive
data
type
or
array
of
primitives
as
specified
in
open,
telemetry
I
said
I
should
build
an
attribute.
B
We
need
to
make
a
decision,
and
this
is
something
we
need
to
explore
and
see.
We
can
call
the
car
this
way.
We
split
the
work,
so
simple
select
status
is
just
iconic
him
rich
how
to
open
climate
rate
and
and
see
we
can
have
a
better
solution.
So
we
can
the
spec
and
then
come
back,
not
a
block
for
us.
The
the
worst
case
is
but
another.
A
D
Were
generally
discussing
okay,
so
we
were
like
gently
discussing
it's.
It's
always
easy
to
add
things.
It's
the
reverse
is
notis.
If,
once
we
add
like
status,
then
we
will
be
forced
to
keep
it
forever,
so
we
can
operate
with
absolute
minimum
and
then
add
things
as
we
like
I
still
collect
more
feedback
and
make
sure
that
status
is
going
to
stay
in
opera
limit
respect
as
well.
C
Say
that
we
do
have
time
to
get
things
to
true
this
back.
There
is
still
time
to
change
stuff
and
I
think
they
start
us.
Actually,
it's
a
good
example
status
as
it
is
the
easiest
kind
of
not
generic
in
a
lot
of
sense.
So
we
also
perhaps
drive
some
of
that
work
as
we
find
stuff
in
trying
to
to
do
the
adaptation
tool
to
chew
activity,
activity,
source.
C
D
A
What
you've
already
is
is
a
good
starting
point.
If
we're
happy
on
a
master
we
we
can
do
far.
We
can
create
more
chaos,
just
about
tweak
things
and
the
feedback
I
think
from
what
I
saw
of
your
PR
I
think
that
that's
in
the
Orcas
they
to
be
accepted,
so
it
doesn't
so
I,
don't
watch
you
and
that
you
progressed
to
the
next
stage.
Okay,
yeah
and
this.
B
B
So
probably
we
need
to
tag
that
either
is
something
we
think
we
need
to
figure
out
like
how
how
close
the
gap,
if
done
IBM
cannot
do
that
for
them
or
like
Paul
mentioned,
we
probably
need
to
have
a
very,
very
thin
layer
of
Shem
that
just
cause
spam
and
the
lying
is
coming
activity
or
having
an
NPI
that
does
no
check
and
decide
whether
we
should
remove
the
Tavella
parent.
If
the
value
is
now
all
other
things,
we
need
to
figure
out.
B
We
don't
need
to
bother
down
at
him
and
in
there
every
category
of
issues
where
tonight
he
needs
to
follow
up
and
for
things
done,
if
he
needs
to
follow
up,
I
think
they're.
There
two
categories:
when
is
minor
thing
that
they
need
to
add,
but
we
gave
them
time
to
think
about
a
better
designer.
They
need
to
talk
with
the
open
primary
community
things
like
status
code,
and
there
are
some
minor
thing
that
they
should
just
figure
out.
B
How
to
unblock
us
remember
the
like
primitive
data,
types
for
add
tag
and
probably
consider
change
their
name
to
add
like
attribute
or
having
both
api's
exist.
Those
are
things
like
minor
thing,
but
they
need
to
do
and
they're
bigger
thing.
They
need
to
come
to
the
community
negotiate
and
come
up
with
a
plan.
So
in
this
way,
I
think
we
know
like
which
party
is
responsible
for
what
and
we
can
make
progress
in
parallel.
B
E
A
B
Sorry
I
agree.
This
he'll,
like
github
actions,
is
a
very
stable
thing
like
we
suffered
from
that
a
year
ago,
but
now
we
start
love
that
a
lot
and
we
start
to
move
all
the
Microsoft
internal
projects
to
use
github
as
much
as
possible.
But
for
for
the
package
thing
I
think
probably
is
something
like
we
want
to
bake
it
for
for
a
while
and
try
to
observe
don't
jump
into
that.
Yeah.
A
E
D
D
So
it's
low
like
ice
again
was
saying
it's
really
slow
because
we
got
only
like
one
core
because
of
that
it's
slow,
but
it
still
acts
6
minutes
for
doing
one
see
a
bill,
so
we
can
live
with
that,
so
I'm
not
going
to
pursue
that.
Yet,
once
we
get
you
do
like
a
stage
where
we
had
a
bordo
should
beta,
then
we'll
have
free
cycles
to
investigate
like
making
our
CI
bit
yeah.
B
A
Yeah
yeah
I
think
it
should
definitely
be
part
of
like
a
ga
release
milestone
rather
than
what
we're
currently
working
on.
So
it's
something
that
we
need
to
have
in
place
before
we
get
to
that
stage
and
a
better
integration
testing
and
like
component
testing
and
that
sort
of
stuff
it's
all
great
to
have,
but
maybe
a
little
time
in
the
future,
once
we've
got
our
API
and
SDK
is
more
stable,
yep.
D
Okay,
so
be
good
to
go
so
Paolo
just
to
give
you
an
update
like
tomorrow
and
day
after
tomorrow,
it's
vacation
for
our
team
in
Microsoft,
it's
a
special
vacation.
So
if
this
PR
is
much
before,
then
you
will
in
if
you
have
cycles,
you
can
look
at
one
of
the
exporter
taking
activity.
If
that's
something
which
you
mentioned,
you
will
have
some
time
to
work
on
that
right.
Oh.
C
It's
murdered,
I,
look
at
it,
starting
to
I,
probably
do
separate
PRS
for
each
one
but
I
as
far
as
its
merge
it'll
start
to
looking
first
with
the
OTO
P.
That
was
the
one
that
I'm
more
familiar,
but
then
I
will
jump
to
the
others
and
right
after
that,
I
think
I
separate
in
some
namespace,
but
start
to
write
a
sheen
on
top
of
SDK.
Okay,
yeah.
D
Yeah,
so
one
only
one
thing
which
would
change
here
is
like
I
would
I
would
like
differ
from
doing
replacing
span
like
everything
else
would
be
premisis
in
like
putting
this
logic.
Adding
more
support,
something
like
this
is
where
probably
follow
can
help
like
this
part
is
deferred,
will
not
be
replacing
and
be
just
adding
activity.
So
this
is
like
several
days
before
Near
East
Alaska,
so
we
can
worry
about
it
as
we
reach
that
stage.
Yes,.
A
D
Which
are
not
directly
related
to
replacing
activity
and
span
I
will
create
new,
because,
like
the
issue
about
active
symbol
span
processor,
it
already
exists,
so
I
don't
want
to
solve
it
as
part
of
this
PR.
So
for
any
of
those
issues,
I'll
create
an
issue
because
we
need
to
address
it
anyway,
separately
from
this
yeah,
so
that,
like
I,
can
be.