►
From YouTube: 2021-05-04 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
A
Okay,
can
anyone
confirm
if
you
are
seeing
my
meeting
notes
page.
B
A
A
Okay,
I
think
we
can
start
now
if
you're
in
the
call-
please
add
your
name
to
the
attendee
list.
We
have
again
very
small
agenda
or,
let
me
add
one
more
thing
just
so
that
I
don't
forget
it
towards
the
end.
So
first
thing
is
like
we're
just
following
up
from
last
week,
trying
to
do
releases
from
the
control
repo,
so
I
shared
like
followed
the
guide
which
pragash
has
written
and
it
looks
like
we
have
some
pieces
missing
from
it.
A
So
let
me
open
that
pr
here.
So
this
is
the
like
exact
steps.
Oops,
sorry,
I
opened
the
wrong
one
release
process
yeah,
so
I
followed
this
and
I
felt
this
is
still
incomplete.
We
need
to
do
like
some
more
steps,
so
I
asked
because
to
like
work
on
prasant
to
work
on
it.
I
hopefully
that
he
can
like
finalize
the
exact
steps
and
we
can
try
to
automate
it
it's
still
manual,
but
it
should
be
like
very
straightforward
to
automate.
A
So
basically,
as
of
today,
I
am
done
with
mass
transit
and
I
also
did
the
elastic
search.
We
still
have
entity
framework
and
I
think,
stackdriver,
to
be
published,
so
we'll
wait
for
the
like
second
iteration
of
the
actual
release
process
and
use
the
entity
framework
as
a
validation
for
the
new
steps.
A
So
another
comment
which
I
mean.
Another
question
which
I
want
to
raise
is
right:
now
the
automation
goes
till
the
myget
publish
there
is
nothing
like
really
fancy
about
you
get
published,
but
it
is
manual.
So
do
you
any?
Does
anyone
has
concerns
if
you
make
nougat
push
as
part
of
the
workflow
right
now?
If
you
look
at
the
actions
for
any
of
the
packages.
A
Is
there
any
concern
if
we
make
you
get
published
as
like
automated
and
as
part
of
the
I
mean
the
pr,
the
push
for
a
particular
tag
will
trigger
the
release.
So
if
someone
with
admin
writes
like
maintainers,
if
you
push
a
tag
which
matches
the
let's
say,
for
example,
if
it
is
mass
transit,
you
push
a
tag
with
mass
transit,
hyphen
version,
whatever
that
will
trigger
the
entire
release
process,
including
then
you
get
part.
A
So
if
there
are
no
issues,
anything
I'll
just
go
ahead
and
make
that
automation
so
that,
like
we,
don't
need
to
do
like
manual
steps
there
will.
There
is
still
one
more
minor
step,
which
is
to
do
the
github
release.
I
think
it
should
also
be
like
automatable
when
I
say
github
release.
I
really
mean
creating
a
like
github
release
here.
That
should
also
be
like
easily
automatable.
A
C
Yeah
and
these
are
only
accessible
to
the
ci
job,
that
is
upon
the
the
merge
to
the
membrane
right.
If
someone
is
near
pr,
are
they
able
to
get
this
secret
or
not.
A
Yeah,
that's
a
good,
I
think
we
explored
this
earlier
and
there
is
no
way
for
people.
I
mean
there
is
a
like
feature
which
prevents
this
from
being
printed
out
like
there
is
no
way
like
you
can
like
print
it
out
or
like.
Basically,
you
are
trying
to
ask
like
is
if
there
is
a
like
random
guy,
who
submits
a
pr
which
yeah.
C
Yeah,
there
are
two
things
I
want
to
clarify:
one
is
if
some
random
guy
is
sending
a
pr
there
shouldn't
be
a
way
for
them
to
get
this
without
anyone
like
knowing
like,
if
I'm
an
evil
guy,
I
sent
a
pr
there
shouldn't
be
a
way
I
can
steal
the
secret
here.
The
second
part
is
about
people
who
have
the
maintainer
or
like
higher
priority,
like,
for
example,
they
have
privilege
to
access
the
deployment
or
like
published
pipeline.
A
I
I
need
to
like
actually
verify
because
it
looked
to
me
like
last
week
like
if
someone
is
submitting
a
pr
it
has,
you
can
actually
modify
an
existing
yaml
file
to
trigger
or
modify
the
actual
action.
But
I
just
don't
know
whether
like
can
someone
like
modify
to
access
secrets
or
print
it
out.
So
that
is
something
which
I
haven't
tried
out
yeah,
but
it
would
be
like
surprise
like
if
it
like
super
easy
for
anyone
to
just
grab
the
secret
by.
C
Ordering
apr
so
yeah,
so
the
the
first
thing
is
more
likely
generics
and
it's
not
specific
to
the
country.
It
applies
to
every
open
climate
report,
every
github
report.
The
second
part,
is
more
related
to
the
country
report
itself.
So
people
who
have
access
to
portal
tag
or
trigger
the
release
process.
A
Yeah,
so
that's
for
the
maintenance
place
like
people
who
have
access
to
push
the
tax,
because
the
tax
is
the
only
way.
Currently,
these
like
back
and
publish
actions
are
triggered,
so
the
only
people
who
can
trigger
it
are
the
maintainers.
But
I
see
your
point
like
what
is
like
someone
modifies
the
actual
yaml
file
to
be
triggered
for
something
else
and
like
steal,
the
secret
okay
yeah.
I
can
try
it
out
and
report
back
whether
this
is
indeed
an
issue.
A
C
So
this
is
something
discussed
early
this
morning
in
the
spike
meeting.
It's
related
to
the
site
status
and
people
who
have
been
on
open
timesheet
for
longer
time
might
know
like
status.
Initially
was
a
grpc
code
and
we
decided
to
make
much
simpler,
so
we
have
status
on-site
and
arrow,
and
also
okay
and
the
spec
was
basically
saying
today
that
okay
is
only
reserved
for
application
owners.
That
means
the
instrumentation
library
shouldn't
set
something
to
okay.
C
So
the
question
is:
if
someone
already
said
that
to
okay,
should
we
add
a
semantic
here
saying,
set
status,
will
respect
the
okay
as
a
final
state
and
not
supposed
to
change
that
later
on
and
that
your
description,
I
have
a
link
to
the
proposal
from
nikita
and
he
was
trying
to
push
the
spike
to
make
the
change
and
based
on
the
discussion
this
morning.
I
think
folks
are
thinking
it's
reasonable.
A
Would
you
expect
this
to
happen
in
the
dotnet
framework?
Also
right
because,
like
starting.6,
the
set
status
is
natively
supported
by
activity,
so
we
would
need
to
make
a
similar
proposal
to
the
document
itself.
Yes,
there.
C
C
Want
to
take
a
step
on
this,
and
this
one
is
just
appeals
that
I
don't
intend
to
merge
that
just
want
to
know
from
people
whether
you
agree
with
this
or
not,
and
depending
on
how
come
the
spike.
The
spike
can
decide,
whichever
way
like
whether
the
spec
will
allow
this
or
the
spec
is
saying
nothing.
But
I
I
just
want
to
prove
like
whether
the
spec
is
saying
yes
or
no
will
have
a
reasonable
solution
here,
and
people
think
is:
okay.
A
Yeah
this
looks
okay
because,
like
one
of
the
guidelines
is,
instrumentations
are
not
expected
to
ever
set
okay,
so
they're
only
trying
to
set
like
either
error
or
unknown
sorry
unset
yeah.
So
if
a
user
explicitly
sets
status,
then
instrumentation
will
just
I
mean
if
instrumentation
tries
to
set
it
to
error,
it
will
be
like
dropped,
because
user
has
explicitly
made
the
decision
to
mark
it
off.
Yeah
yeah.
C
A
C
A
Yeah
another
thing
is
ordering
because,
like
if
instrumentation
is
trying
to
set
like
exception,
I
mean
error
and
user
code
is
like
executed
like
afterwards
yeah,
but
these
it
would
just
overwrite
the
error
to
okay.
If
user
is
setting
okay
yeah
and
there
is
no
way
instrumentation
is
going
to
set
okay
before
so
yeah.
This
looks
fine.
A
So
what
is
expectation
from
like,
like
the
poc,
like
we
just
confirmed
that
this
works
or
like
do
you
expect
us.
C
To
already
the
expectation
is
whatever
the
spec
decides,
I
I
want
us
to
be
able
to
react
to
that.
If
the
spec
decided
to
do
nothing,
then
I'll
just
close
this
pr
and
assume
nothing
happened
if
the
if
the
spec
decided
yes,
we
want
to
take
this
approach.
I
I
just
want
people
to
see
if
this
is
reasonable
for
tonight
or
with,
we
think
we'll
hit
other
issues,
because
this
is
the
way
I'm
trying
to
get
feedback
from
this
community.
D
A
Yeah,
oh
dotnet
already
has
done
it
in
the
dot
net
six
preview.
We
are
still
depending
on
the
five
version,
so
once
six
is
like
g8
like
we
will
be
updating
to
that.
We
don't
need
to
yeah.
It's
already
mentioned
here
that
we
don't
need
to
iterate
through
the
text.
C
A
I
don't
know
the
right
answer
to
that
like
it,
it
could
be
like
debatable
because,
like
I
I
want
to,
I
mean
it's
already
like
okay,
but
I
I
did.
I
didn't
have
the
right
description
and
I
want
to
set
it
later
now.
You
prevent
me
from
doing
that.
Yeah
I
don't
have
like.
I
don't
know
whether
it's
the
right
way
or
not,
but
so
we
haven't
heard
anyone
complaining
about
this
issue,
at
least
in
dot
net
sync
before
but
yeah,
it's
a
good
issue
to
get
answers.
A
Like
an
official
answer
from
the
spec,
we
should
be
okay
to
support
either.
A
C
C
A
Yeah,
it's
okay
yeah!
If
it's
okay
once
then,
nothing
can
be
changed
afterwards.
Completely
yeah
yeah,
no
issues
here
and
we
like
one
suspect,
gets
like
green
lighted
and
merged
and
we'll
get
an
issue
in
the
dot-net
report
to
have
it
behave
the
same
yeah.
Hopefully.
A
Yeah,
it's
fine
until
like
june
july,
we
should
be
fine,
we
can
change
the
syntax.
I
mean
I'm
just
wondering
whether
dotnet
has
any
issues
like
enforcing
this
check.
A
I
mean
they
most
likely
just
follow
what
open
elementary
says,
but
I
don't
know
whether
like
dotnet,
would
have
any
concerns
about
restricting
changing
the
status
after
after
one
city,
okay,
yeah,
yeah,.
A
C
A
A
You
see
yeah,
okay,
let's
move
to
the
next
issue.
C
The
actual
yeah,
so
the
question
here
is:
if
I
look
at
the
milestone,
it
seems
by
end
of
may
we're
going
to
have
the
oh.
B
C
Have
re-released
so
so
after
beta
3
release?
What
are
we
going
to
do?
I
know
for
the
initial
stable
release,
like
the
sig,
has
spent
a
lot
of
time
like
everyone
here
trying
to
help
to
reveal
the
public
apis
to
make
sure
things
are
stable
and
we
we
decided
not
to
go
through
the
the
process
at
the
time.
It
was
a
new
process
introduced
by
bogdan
that
goes
through
the
tc.
A
This
falls
into
the
category
of
like
make
it
easy
to
configure
sdk
as
a
whole,
so
these
two
are
like.
We
need
to
finalize
it
before
we
release
1.1
stable,
because
these
are
public
api
changes.
So
that's
a
like,
in
fact,
that's
the
only
reason
why
we
do
not
have
a
solid
date
for
1.1,
because
these
are
being
like
actively
worked
on,
so
I
mean-
and
it
involves
public
ap
change.
A
So
if
we
ever
need
to
release
1.1
like
immediately,
we
need
to
like
revert
or
make
it
internal
these
two
changes
and
release
one
dot
one
and
make
these
two
as
part
of
the
even
next
release.
1.2.
A
C
A
Bug
fixes
slash
non
drawer,
shell
or,
let's
call
it
like
finalized
features.
There
are
features
which
allowed
native
activity
support,
which
I
don't
think
there
is
any
it's
a
new
feature.
It's
ready
to
be
shipped,
but
these
are
like.
Let
me
categorize
it,
so
these
are.
A
So
the
logo
code
changes
and
the
config
changes.
It's
there.
It's
already
part
of
the
public
api,
but
I'm
not
convinced
that
this
is
ready.
So
so
this
one
is
part
of
the
sdk.
Now
we
are
discussing
like
whether
it
needs
to
be
moved
to
api,
so
that,
like
instrumentations,
can
use
this
nice
improvement.
A
So
that's
a
key
thing
and
but
moving
into
sdk.
It
is
more
trickier
because
it
requires
a
service
collection.
So
there
are
like
open
questions.
So
that's
why
I'm
not
ready
to
say
this
is
ready
for,
like
1.1,
stable
and
same
with
logarithm.
We
added
scopes,
it's
a
public
api,
so
we
haven't
finalised
it.
There
are
active
peers.
So
until
these
two
like
buckets
like
logo
record
and
the
config
part
is
done,
we
cannot
release
1.1.
A
If
there
is
a
like
urgency
to
release
1.1,
then
we
need
to
like
mark
these
two
as
internal
for
now
and
release
1.1,
which
would
include
the
bug
fix
and
the
features
which
are
finalized.
A
If
there
are
like
no
immediate
pressure
to
release
1.1,
I
would
just
like
don't
do
anything
like
just
continue
to
work
on
log
record
change
and
the
config
part.
Whenever
we
think
we
are
ready,
we
will
just
release
one
dot
one,
and
I
don't
have
a
exact
timeline
to
commit.
A
So
most
of
the
people
who
were
asking
about
releases,
they
were
concerned
primarily
about
why
they
don't
have
instrumentation
studies,
and
that
is
something
which
is
beyond
our
control,
so
like
they're,
all
asking
like.
When
do
we
get
like
instrumentation
study?
So
that's
something
which
is
like
this.
A
Like
did
you
see
like
anyone
asking
like
for
one
dot
fun
to
get
a
1.1
to
get
a
bug
fix
or
anything
or
you're?
Just
like
curious,
like
whenever
I.
A
We
can
like
push
this
as
internal
and
release
1.1
and
continue
to
work,
because
I
don't
think
like
we
if
you
want
to
like
put
let's
say
like
next
end
of
this
month
for
beta
3
and
stable
in
the
week
after
that,
then
I
don't
think
like
we'll
have
time
to
solve
like
both,
but
this
is
indeed
like
little
bit.
Complex
michael
already
take
a
lot
of
work
to
make
it
work,
but
we
still
have
open
questions
to
be
discussed.
A
So
we
may
not
have
time
to
tackle
everything
if
we
intend
to
release
one
dot
one
like
fairly
soon.
That's
it
yeah.
So,
however,
like
if
longer
code
changes
the
scope
ones
are
finalized,
then
I
think
if,
if
we
can
ship
it
as
part
of
the
beta
3
release,
which
is
coming
end
of
this
month,
and
if
we
don't
see
like
any
major
concerns,
we
can
like
do
a
1.1
stable
with
whatever
I
have
highlighted.
A
D
Yeah,
I'm
just
trying
to
get
through
the
log
stuff
because
I
already
had
some
of
it
open.
We
don't
need
to
do
the
the
big
name
thing:
the
activity,
attaching
enrichment
thing
whatever
that
one
was.
I
can
just
stay
in
pr.
So
if
we
can
get
the
log
record
one
done
this
week,
then
I
can
switch
over
to
the
other
one.
A
Right.
Okay,
so
let's
assume
that
I.
A
Mean
I
mean
other
than
saying
I
deferred
provider
will
be
like
looked
after
after
the
load
record.
Do
we
want
to
put
like
any
actual
timelines
to
commit
that,
like
this
will
be
ready
like
in
the
next
beta,
or
should
we
just
not
mention
the
time
there
at
all.
A
Yeah
I
mean
it.
We
can
simply
state
that
it
won't
be
part
of
1.1
that
that
way
we
can
set
the
right
expected.
It
won't
be
part
of
1.1,
which
naturally
means
it
will
be
part
of
the
like
the
next
one,
which
is
one
point
and
we
are
not
committing
it.
When
would
1.2
come
so
at
least,
let's
try
to
see
if
this
makes
sense,
so
1.1
beta3
can
be
released.
End
of
may
with
long
record
changes.
A
It
seems
like
reasonable
and
like
approximately
one
to
two
weeks
or
1.1,
stable,
so
1.1.
C
And
then
I
have
my
answer.
I
I
guess
because
here
we're
adding
the
login
scope,
which
is
specific
to
donut
I
logger
and
and
the
other
changes
like
native
activity
support
those
are
not
in
the
spec
so
yeah,
I
I
don't
see
much
need
to
go
through,
because
the
tc
member
will
have
to
learn
all
that
specifics.
A
Yeah,
even
this
itef
deferred
tracer
builder,
would
be
like
very
closely
tied
to
dotnet
it's
it's
like
there
is
no
spec
about.
How
do
you
configure
things
except
and
that
config
is
part
of
the
tracer,
so
I
think
like
with
all
these
changes,
it
doesn't
look
like
we
have
we
are
implementing.
We
are
not
implementing
anything
new
from
the
spec,
so
yeah.
It
probably
makes
sense
to
not
go
through
this
process.
A
That,
okay
yeah,
so
if
everyone
is
okay,
I'll
update
the
milestone
with
this
one
and
I'll
we'll
see
like
based
on
like
whether
michael
and
I
will
have
time
to
finish-
I
defer
tracer
builder
in
1.1
I'll,
just
put
based
on
my
current
information.
It's
not
likely
to
land
in
1.1
because
we
will
be
starting
matrix
work
as
well.
So
a
good
amount
of
time
will
be
spread
into
like
looking
at
matrix,
prs
and
actual
coding.
A
So
if
you
reach
the
stage
where
we
are
about
to
release
1.1-
and
we
still
don't
have
a
confidence
that
this
is
ready,
we'll
like
remove
this
from
the
public
api
and
ship
1.1,
any
concerns
with
that.
A
A
A
Okay,
so
we
covered
pretty
much
all
the
topic
and
the
last
thing
is
just
an
update
about
matrix
work,
so
I
basically
started
nooking
the
existing
matrix
code
from
both
api
and
there
is
no
matrix
here.
It's
gone,
including
the
sdk
change
and
the
prometheus
exporter.
The
reason
is
we
pretty
much.
Have
it
almost
like
a
brand
new
spec,
so
none
of
the
existing
instruments
or
anything
makes
sense
anymore.
A
So
it
is
much
faster
to
like
write
something
from
scratch
rather
than
trying
to
modify
the
existing
code
so
step,
one
is
to
move
the
existing
one,
which
is
done
so
the
next
step
is
to
add
things
to
it.
So
let
me
write
that
zero.
A
This
part
is
done,
and
the
next
step
is
to
we
already
have
the
team,
along
with
victor,
doing
a
bunch
of
prototypes
to
get
the
metric
api
and
sdk.
A
However,
the
sdk
there
is
no
spec
yet
so
it
is
still
like,
like
mostly
prototypal,
but
api
is
very
good
to
be
it's
smart
experimental,
but
still
like
very
close
to
the
final
shape.
So,
to
begin
with,
what
we'll
do
is
we'll
just
have
the
matrix
api
in
the
hotel.
A
Itself,
but
this
will
be
removed
like
whenever
dotnet
gives
the
first
metric
apa
bit.
A
So
this
is
something
which
I'll
be
like
starting
right
away
and
then
do
like
the
minimal
sdk
change.
A
So
this
is
where
I
will
heavily
bore
off
from
all
the
prototypes,
which
victor
has
been
doing
so
I'll
spend
like
approximately
one
week
just
to
get
the
overall
like
framework
in
place.
Just
like
someone
calls
like
counter
dot
ad.
We
just
print
in
the
console
that
hey
someone
called
counter
with
this
value
with
these
labels.
I'll
just
do
that
framework,
and
then
I
think
parallely
metric
sdk
work
is
going
to
happen.
A
So
we'll
incrementally
add
things
to
the
auto
repo
like
borrowing
from
or
stealing
from
whatever
victor
has
already
prototyped
and
in
complaints
with
the
specs
as
they
are
written.
A
But
I
use
the
initial
one
one
and
a
half
weeks
just
to
iron
out
the
overall
structure
and
try
to
break
down
the
problem
and
do
like
sub
tasks
so
that
we
can
try
to
see
like
if
others
can
like
help
with
like
actual
implementation
like
if
one
person
is
like
interested
in
metrics
for
prometheus,
like
prometheus
exporter,
and
we
can
create
like
subtasks
and
have
it
as
end
or
like
someone
exploiting
like
otlp.
A
You
can
work
on
that
and
then
someone
else
can
work
on
writing
instrumentations
to
collect
actual
metrics
like
ellen,
worked
on
initial
pr
for
espana
core,
so
I'll
create,
like
I
mean
after
like
a
week,
just
to
get
the
framework
I'll
create
like
individual
sub
issues
and
then
come
back
to
this
thing
and
see
whether
people
can
take
up
individual
items
and
based
on
that
we'll
be
able
to
publish
a
like
more
refined
timeline
rather
than
I
mean
the
current
one
says
we'll
have
produced
by
mid-june.
A
That's
the
only
thing
which
we
have
did
we
say
yeah
there
will
be
preview
so
once
I
get
like
some
time
to
split
out
the
tasks
and
do
like
individual,
smaller
chunk
of
items,
and
we
have
like
people
committing
to
individual
items,
we'll
start
publishing
a
slightly
better
like
more
firm
timeline,
at
least
for
the
next
two
to
three
months.
We'll
still
expect
the
final
thing
would
be
like
november,
but
yeah,
that's
that's
the
update.
If
there
are
any
concerns
or
other
feedback,
we
can
discuss
it
now.
E
See
joe,
I
posted
in
the
chat
a
link
to
the
pr
for
the.net
metrics.
F
E
A
So
please
take
a
look
and
share
your
feedback.
I
think
it.
This
is
going
into
review
like
end
of
this
week,
so
we
you
still
have
opportunity
to
influence
it.
I
then
we
still
have
opportunity,
even
after
the
review,
but
we
have
like
very
short
time
window
to
meet
the
dot
net.
Six
timeline
so
pl.
If
anyone
is
invo
interested
in
involving
in
the
dot
net
api
design.
Please
take
a
look
at
this
pr.
It
should.
I
think
the
actual
meeting
is
also
public
fair.
A
I
don't
know
whether
the
actual
meeting
link
will
be
shared
here,
but
definitely
the
actual
video
recording
will
be
posted
here
from
the
actual,
like
ruby,
with
a
dotnet
api
design
thing
or
api
approval
team,
so
whatever
like
I
will
be
putting
in
matrix
api
will
be
like
thrown
away
as
soon
as
these
things
becomes
like
an
actual
negate
package,
part
of
system.technology
yeah
thanks
victor
anything
else,
you
want
to
add.
C
A
So
the
only
I
mean
it's
not
just
that,
like
we
still
need,
like
other
features
from
the
diagnostic
source
version.
Six,
I
think
status
is
one
of
them.
I
think
there
are.
There
was
like
a
couple
of
other
things
like
generating
custom
trace,
ids,
which
aws
was
interested
in.
I
think
there
was
one
more
I
don't
record
so
the.
A
C
A
Yeah
yeah,
so
we
have
to
defer
it
as
much
as
possible.
How
did
we
do
the
preview
yeah
for
previous
one?
We
were
anywhere
freely,
so
this
was
not
an
issue.
So
now
we
are
already
in
a
stable.
We
cannot
just
upgrade
to
dotnet
six
without
like
delaying
our
release
as
well.
A
At
some
point,
we
have
to
start
it.
I
just
don't
know
like
what's
up
writes
for,
like
maybe
like
october,
would
be
too
late,
but
right
now
would
be
too
early
as
well.
So
we
need
to
find
like
something
in
between,
so
that
we'll
have
enough
opportunity
to
let
my
team
know
that
whatever
they
implemented
is
working
and
if
not,
they
have
time
to
fix
button,
or
we
can
maintain
it
in
a
separate
branch
as
well.
Oh
yeah.
A
A
I
see,
I
think,
if
you
do
that,
then
we
don't
need
to
create
another
branch
and
maintain
it
because
it's
not
like
trivial
to
add
a
new
branch,
because
we
need
to
modify
cas
to
depend
on
it
to
do
like
constant
rebasing.
So
I
think
re
branding
the
matrix
to
the
I
mean
to
say
that
upcoming
or
some
other
name
would
mean
we
can
play
with
matrix
in
that
same
branch
and
we
can
also
do
any
dot
net
six
changes
in
that
branch
as
well.
A
Yeah,
I
don't
see
any
issues
with
that,
yet
at
least
there
is
no
pressure
to
do
that.
Like
initially
I
mean
at
least
right
now,
it's
like
still
maybe
should
be
deferring
it,
at
least
until
like
june
mid
or
something
because
it's
not
like
a
big
change
status
and
yes,.
A
Yeah
so
for
diagnostic
source
package,
apart
from
the
status
I
mean
and
the
traceary
generator,
I
don't
reflect
like
anything
being
addressed
in
the
dot-net
side.
However,
for
other
instrumentations
we
might
have
like
a
bigger
chain.
For
instance,
we
expect
asp.net
core
to
have
a
significantly
different
behavior
internet
six
onwards,
so,
but
that
would
only
affect
our
instrumentation
for
sp
network,
not
the
actual
sdk.
A
But
again,
I
don't
think
we
have
a
hard
dependency
on
the
actual
version
we
do
like.
We
do
use
like
reflection
to
figure
out
which
version
of
dot
net,
which
version
of
hp
net
code
we
are
running
in
and
based
on,
that
we
do
like
conditional.
So
I
think
it
should
be
something
which
we
can
handle
independent
of
the
dot
net
sixth
thing
trying
trying
to
figure
out
like
where
do
we
have
that
logic?
There.
A
Yeah
I'll
figure
it
out
yeah.
This
is
like
this
is
basically
we
are
trying
to
see
like
if
the
hosting
is
doctor
3
or
higher
than
we
know
that
it
supports
w3c.
And
similarly,
we
need
another
branch
which
basically
says
are
we
in
dotnet
6
of
sp
net
core?
If
that's
the
case,
it
supports
activity
source.
So
we
don't.
We
need
to
like
do
a
different
logic
here,
so,
but
that's
not
tied
to
the
sdk,
so
yeah,
it's
very
much
tied
to
instrumentation.
Only
so
we
should
be
fine.
There.
C
A
C
A
Plan
yeah,
so
we
don't
like
did
need
I
mean,
based
on
my
understanding.
We
would
still
support
net
standard
duo,
which
means
anyone
using
asp.net
core
2.1
can
still
use
it.
Even
though,
like
2.1
itself
is
duplicated,
I
mean
we
all.
We
can
remove
our
test
cases
for
2.1,
but
I
don't
think
we
need
to
like
remove
anything
from
the
diagnostic
source
or
like
api
or
sdk
package
itself.
A
That
would
be
the
same
for
diagnostic
source.
Also,
they
will
still
be
having
a
dot
net
standard
2.0
target,
which
means
like
you,
can
technically
use
it
in
dot
net
code
2.1,
even
though
the
package,
the
platform
itself,
is
not
supported.
D
F
I
guess
sorry
I'll,
just
I'm
a
little
fly
on
the
wall.
Just
just
don't
mind
me,
so
it
kind
of
comes
back
to
that
multi-targeting
question
a
couple
weeks
ago,
even
though
we
support-
or
you
guys
have
written
support
for
standard,
but
the
I
mean
standard
is
only
as
good
as
it's
it's
a
library
right,
it
doesn't
dictate
runtime
and
the
runtime
is
dictating
what's
available
really
in
terms
of
like
what
what's
running
in
what
you
can
capture
metric
or
a
diagnostic
source,
I
guess
so
it
just.
F
It
seemed
to
me
that
standard
was
it's
great
for
shipping,
but
it
as
far
as
like
capability
wise
it
doesn't.
It
doesn't
tell
you
a
story
like
what
really
is
available
and
we
were
kind
of
talking
about
that
a
while
ago,
and
I
I'm
quite-
I
was
kind
of
curious
if
anyone
reached
the
conclusion
on
the
the
best
approach
for
knowledge
we
haven't
reached.
A
We
haven't
reached
the
conclusion:
it's
still
utkarsh
and
I
was
trying
to
follow
up
with
the
docnet
team
to
get
the
official
guidelines.
We
haven't,
got
it
yet
so,
based
on
what
the
team
recommends,
we
try
to
tweak
out
them
because
it,
it
is
indeed
a
big
issue.
I
think
like
there
are
at
least
two
or
three
places
where
we
have
different
public
api,
but
even
if
we
make
the
public
api
saying,
the
actual
behavior
is
different.
So
we
want
to
get
some
guidelines
from
the
team.
A
I
think
michael
suggested
we
should.
Instead
of
targeting
for
instrumentations,
we
should
actually
target
like
dot
net
core
app
2.1.9
3.1
instead
of
right.
That's
if
the
dotnet
team
also
says
that
that
is
the
right
way
of
solving
that
problem,
then
yes,
we
will
do
it
but
yeah.
Having
got
I
mean
utkash
like
do
you
have
any
updates
on
that
or
we
are
still
waiting
to
hear
from
top
net
team.
A
No
yeah,
they
haven't
responded
back.
I
did
reach
out
to
them,
but
no,
no,
they
haven't
responded
back
yet.
A
Okay
yeah,
so
it's
still
an
accident.
I
think
we
said
like
we'll
come
back
and
same
update
as
this
week.
We
don't
have
any
update
this
week,
but
yeah
hopefully
we'll
have
something
by
next
week.
F
Yeah
the
sentiment
I
got
was
like
it
this.
The
conversation
was
similar
in
in
like
what
what?
What
are
we
taking
our
dependency
on
right?
Are
we
taking
dependency
on
net
core
or
standard
and
standard
doesn't
dictate
what's
running
in
the
application?
So
it's
just
similar.
A
Yep,
okay,
any
other
comments
on
that.
Otherwise
we
can
go
to
the
last
topic
in
the
agenda.
A
Okay,
so
this
is,
I
mean
we
briefly
mentioned.
This
is
one
of
the
thing
which
we
need
for
1.1,
so
michael
has
shared
this
vr
like.
If
anyone
wants
to
take
a
look,
it's
pretty
intense.
I
think
it's
it's
a
good.
I
mean
I
did
look
at
the
this
branch
before
it
became
a
pr,
so
I
have
like
a
basic
idea
of
how
it
works.
So,
nicole,
are
you
looking
for
anything
in
particular
yeah.
D
D
So
I'm
introducing
this
thing
called
a
log
record
scope
which
has
the
object.
That's
the
scope,
that's
actually
there
and
then
I'm
adding
this
integer
for
the
depth
that
depth
tracking
is
very
tricky
to
do
in
a
way
where
we're
not
allocating.
So
right.
Now,
I'm
doing
this
like
struct
pointer
thing,
it
looks
like
that's
not
going
to
work,
noah's,
saying
it's
dangerous.
D
I
might
be
able
to
work,
but
what
I
want
to
get
feedback
on.
Is
that
a
compelling
enough
feature,
because
if
we
eliminate
that
it's
much
simpler
to
build,
let's
scroll
up
a
little
bit,
I
have
an
example
here
where
I'm
using
that
depth.
It
does
allow
you
to
do
some
cool
things
like
that
depth
equals
zero
check,
that's
basically
sending
a
header
if
and
only
if
we
actually
get
scopes,
which
could
be
useful
if
you're
like
exporting.
Maybe
you
have
to
build
like
an
envelope
or
some
header.
D
You
have
no
way
to
know
in
the
net
api.
Like
do.
I
actually
have
valid
scopes.
You
can
only
call
into
the
4-h
and
then
it
gives
you
them
one
at
a
time
it
doesn't
pass
you
any
kind
of
counter
or
index.
That's
what
I
was
kind
kind
of
trying
to
address
with
the
depth,
I'm
also
using
it
there.
When
I
write
to
the
console,
so
I'm
just
kind
of
adding
for
this
particular
scope.
Let's
say:
scope,
zero.
It
has
two
items
and
then
you
go
on
to
scope.
D
The
second
scope
it'll
be
depth
of
one.
It
might
have
one
item,
so
it
kind
of
just
allows
you
to
track
stuff,
maybe
do
logic
if
you
need
to
detect
it,
it's
not
in
the
dot
net
api.
It's
something
I'm
trying
to
enrich
here
in
our
api,
but
it's
just
very
difficult
because
it's
an
integer
and
the
dot
net
api.
You
have
to
pass
it
some
kind
of
state
which
it's
going
to
box.
If
you
give
it
a
struct,
it's
going
to
make
a
copy.
D
So
if
you
increment
that
number,
it's
not
a
reference
to
it.
So
it's
it's
just
very
tricky.
So
that's
sort
of
the
first
feedback
I
need
like
do
we
want
this
depth?
Is
it
important
enough
where
we
find
a
solution,
or
do
we
just
take
it
out
and
do
something
more
simpler
to
implement?
Does
that
kind
of
make
sense.
C
C
C
I
I
think
we
can
do
that.
But
my
take
is,
is,
although
a
very
nice
to
have
feature
without
it,
people
can
do
the
for
each
with
a
single
flag
somewhere,
for
example,
they
can
put
a
local
variable
in
the
process.
Scope
item
say:
have
I
seen
any
scope
so
far
and
they
can
track
the
number
of
scopes,
so
that
doesn't
seem
to
be
the
unknown
word
for
those
users
like
it's,
not
a
a
game-changing
thing.
C
D
C
A
Yeah,
but
it
still
addresses
the
other
issue
with
batching
and
scope,
so
I
mean
I
have
one
question
like
we:
do.
We
really
expect
people
to
use
this
api
directly
or
because
we
are
doing
it
automatically
for
the
user
if
we
are
using
the
batching.
So
what
would
be
the
use
case
for
people
like
end
user
to
call
like
buffer
log
scopes
on
the
logo
record?
Is
it
when
they
are
writing
their
own
batching
processor,
but
not
the
built-in
one?
Is
that
the
only
time
they
would
use
this.
A
Okay,
yeah,
I
mean
I
was
trying
to
see
like
if
it's
not
like
a
common
scenario
that
we
could
just
not
make
it
public
right
now,
because
it's
easy
to
add
it
back.
If
we
see
a
need,
because,
most
of
the
time,
if
people
are
writing
like
filtering
or
some
sort
of
processor,
they
like
try
to
wrap
the
batching
one
or
they
they'll
still
use
the
one
of
the
built-in
one
like
simple
voice
as
patching.
A
That's
what
even
all
the
exporters
are
also
using
it.
They
just
like
rub
themselves
inside
the
built-in
ones.
So,
but
it's
not
a
big
deal,
if
you
can
reduce
it's
not
like
very
obvious,
I
mean
unless
you
read
the
whole
thing
like
what
am
I
supposed
to
do
with
this
method
for
log
scopes,.
D
A
A
I
think
it
would
be
okay
to
start
with
that,
because
every
time
we
make
something
public,
then
we
will
have
to
like
make
sure
it
is
like
really
refined.
A
If
you
don't
see
the
need
like
urgently,
we
can
start
with
it
internal
and
yet
it
still
solves
the
problem
of
like
batching
when
they
are
using
the
built-in
ones
and
then
expose
it
later
if
there
is
a
need
for
it
sounds
good
yeah
that
I
said
like
I
mean
I
haven't
looked
at
this
pr,
but
from
the
existing
code,
which
I
looked
at,
it
looked
very
nice.
So,
okay,
yeah
any
other
comments
which
you
want
to
discuss
right
now
or
I'll.
Just
leave
comments
in
the
pr.
A
So
one
additional
thing
is,
I
think
we
probably
want
to
modify
the
like
dogs
like
yeah,
okay,
it's
already
modified
right
here,
okay,
it
says
what
do
you
do
with
that?
But,
okay.
A
Okay,
yeah
I'll
look
at
the
pr
and
raise
any
concerns,
but
overall,
like
once,
we
get
rid
of
the
unsafe
and
depth
part
scope
it
down.
Then
it
should
be
good,
like
you're,
just
waiting
for
the
scopes
to
be
done
before
you
want
to
do
the
like
conversion
from
where
was
that
pr?
A
Process
yeah
so
michael
like
could
you
confirm,
like
we
want
to
like
first
solve
the
actual
like
scoping
issue
before
we
touch
this
one
right.
D
Yeah
those
api
changes
like
some
of
what
is
implemented
on
that
other
pr
is
also
on
this
one.
So
once
it
goes
in
on
the
main
api,
this
one
will
get
a
little
more
simple.
B
D
A
Okay,
yeah
so
I'll,
let's
try
to
solve,
because
this
is
indeed
like,
not
just
an
improvement.
This
is
like
fixing
a
bug
in
the
current
beta
version
as
well.
So
I
think,
let's
prioritize
this,
try
to
get
it
in,
and
I
mean
we.
If
there
is
a
need
we
can.
You
can
like
if
you
think
that
this
is
ready
like
this
week,
we
don't
need
to
wait
for
like
end
of
may
to
do
the
actual
release.
We
can
do
it
even
earlier
to
start
letting
people
use
it.
A
Okay
and
the
interestingly,
this
issue
has
like
lots
of
upwards,
so
I'm
pretty
sure
like
people
really
need
this
feature
like
attaching
locks
as
activity
events.
A
So,
like
couple
of
other
comments
trying
to
figure
out
where
that
is
where
people
are
asking,
this
feature
is
like
really
important,
but
yeah
I
don't
know.
Maybe
it
was
in
the
pr
like.
A
Okay,
anyway,
I'll
check
that
later,
so,
let's
try
to
close
the
scope
one
and
release
a
beta
version
with
that
and
then
try
to
like
incorporate
that
into
the
activity.
Attaching
log
processor
activity
event
attaching
low
processor.
B
B
B
C
If
no
other
questions,
I
have
a
simple
link,
I
want
people
to
take
a
look
so
there's
a
I
just
put
that
in
the
chat
window.
So
this
is
the
spike
pr
people
trying
to
introduce
a
complex
key
for
surprise
tracing
and
which
I
I
don't
think
in
donna
we're
going
to
do
that,
because
we
already
have
a
surprise,
instrumentation
key,
that
that
applies
to
all
the
signals,
but
I
want
to
get
people's
initial
idea
here.
So
please
take
a
look
and
think
about
if
this
pr
got
merged
in
the
spec.
C
C
E
C
Screen
this
pr
on
the
spike
is
trying
to
add
a
key
that
can
tell
all
the
instrumentations
to
suppress
tracing,
and
I
put
some
quest
question
here.
I
think
regarding
do.
We
want
to
have
a
one
single
flag
for
all
the
signals
or
we
have
individual
like
flags,
and
it
seems
the
direction
is
to
have
separate
flags
for
different
signals.
C
C
C
Okay,
I'll
stop,
sharing
anything
else,
see
you
I
I
just
saw
you.
You
came
back
he's
back.