►
From YouTube: 2022-03-08 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).
B
B
C
C
B
It's
like
very
much
like
all
buildings.
Everything
are
open,
it's
just
that,
like
people
are
still
figuring
out
their
commute
and
all
the
logistics
on
coming
back.
C
Yeah
I
I
had
some
colleagues
from
from
the
time
from
microsoft
that
I
worked
at
microsoft.
Invite
me
for
lunch,
and
I
said,
let's
wait.
At
least
the
weather
gets
good.
A
B
Your
name
to
the
attendees
list
and
we
do
not
have
anything
in
the
agenda
I'll
just
quickly
update
that
we
just
delete
released
rc3.
Last
friday
we
might
be
forced
to
do
a
a
shorter
time
period,
release
of
rc4
because
we
had
some
potentially
breaking
change.
I
mean
it's
still
not
stable,
but
might
be
like
a
surprise
for
many
users,
so
yeah
and
already
has
appeared
so
we'll
go
over
it
in
a
moment
so,
based
on.
B
So
it's
a
good
thing
that
we
know
people
are
using
it,
so
that
should
give
us
more
confidence
next
time
when
we
release
yeah.
So
that's
the
only
update,
so
I
don't
know
when
we
would
do
it,
maybe
like
as
early
as
next
monday,
so
we'll
just
merge
the
fix
and
maybe
anything
relatively
small
pr.
We
should
be
able
to
merge
and
do
a
release
in
like
early
next
week.
B
Yeah
and
spec
is
still
not
stable,
so
don't
know
when
it
will
be,
and
there
are
still
like
active
discussions
going
on
to
make
that
happen,
and
there
is
even
a
dedicated
friday
meeting
to
stabilize
some
metrics
back
so
yeah.
That's
the
latest
update
from
me
and
if
there
are
any
topics
to
discuss,
we'll
go
for
it.
Otherwise,
we'll
just
look
at
like
few
open
pr's.
C
Well,
more
related
thing,
and
this
is
kind
of
obvious,
but
I
just
want
to
confirm
to
to
be
sure
about.
What's
going
to
happen
is
I
do
expect
that
we
have
a
release
before
may
so
as
soon
as
the
specs
stable
a
little
bit
but
may
is
because
microsoft
drops
the
support
for
net
five.
So
I
do
expect
that
then
at
the
moment
the
sdk
kind
of
doesn't
view
new
versions.
B
Yep
so
like
one
extreme
cases,
let's
assume
this
tech
do
not
reach
stable
in
the
next
three
months.
So
in
that
case,
we
may
want
to
like
rethink.
How
do
we
want
to
do
one
point
we
may
want
to
do
a
one
point:
one
dot
sum
release
just
relaxing
the
dependency
version
so
that
we
can
unblock
users.
We
just
want
to
run
on
like
0.961
type,
because
currently,
the
only
way
someone
can
use
dotnet
6
is
by
using
the
1.2,
rc
or
1.2
star
packages.
C
I'm
coming
with
this
question
because
we
are
going
to
try
to
do
one
kind
of
data
release
for
the
instrumentation.
We
are
not
sure
about
timelines
and
I'm
trying
to
consider
if
we
should
support
net
five
or
not,
and
this
is
going
to
be
tied
to
whatever
the
sdk.
Does
you.
B
I
think
we
should
be
like
based
on
what
we
see
happening
in
the
spec
ripple.
There
is
strong
motivation
for
people
to
release
the
metrics
back
as
stable
as
soon
as.
B
That's
probably
what
like
allen
also
felt
like
you're,
also
in
the
spec
meeting
right
like
do
you,
I
mean
nobody
can
predict
it,
but
based
on
what
we
see,
it
should
happen
like
really
soon
now,.
C
Yeah
yeah,
so
I
I
do
expect
that
we
have
a
version
for
net
five
and
then
we
probably
likely
everything
going
as
expected.
We
also
release
our
beta
with
support2.net
file,
but
yeah,
okay,
okay,
hey
it's
just
to
confirm,
but
just
you
to
be
sure
that
these
are
also
the
plans
for
you
guys,
one
one
related
thing,
but
perhaps
we
take
at
our
other
moment.
It
makes
sense
for
the
the
things
that
are
going
to
be
released
in
the
in
the
future.
C
So
your
release
just
for
what
microsoft
current
support
runtimes
I
mean
but
fixes
for
things.
I
I
remember
reading
some
time
ago
about
the
version
policy
and
things
like
this,
but
I
don't
recall
if
we
have
anything
like
we
are
not
going
to
publish
fixes
for
versions
that
are
out
of
life,
support
from
microsoft
or
anything
if
that
is
expressed.
B
Maybe
we
can
look
at
what
we
have
turned
down
for
questioning.
I
don't
think
we
mentioned
anything
about
what
do
we
do
for
hot
fixes
or
like
releases,
so
maybe
yeah
packaging
nonstably?
I
don't
think
so.
I
think
like
the
way
I
understand
your
question
is:
let's
say
we
release
like
1.2.
B
C
Exactly
it's
kind
of,
I
think,
if
I
think,
a
lot
of
the
users
that
I
have
they
typically
they
they
want
to
project
bility.
We
can
even
say
that,
okay,
we
don't
fix
after
the
end
of
life
by
microsoft,
but
ideally
I
would
like
to
have
we
don't
fix.
We
fix
for
a
quarter
or
six
months.
C
You
know
kind
of
just
to
have
some
predictable
time
window
for
that
and,
of
course,
we
don't
need
to
kind
of
do
and
decide
that
now
it's
just
something
that
typically,
they
ask
me
to
have
some
information
about.
You
know.
B
Got
it
yeah?
Maybe
it's
good
to
clarify
like
whether
what
what
is
our
like
hot
fix
policy
like
we
could
simply
state
that
the
hot
fixes
are
only
a
play
or
released
on
the
most
recently
released
stable,
no
matter
what
the
timing,
so,
if
he
just
didn't
release
anything
for
like
next
two
years,
so
our
policy
would
be
like
whatever
hotfix
is
there.
It
will
be
applied
to
the
most
recent
table,
even
if
it's
two
years
or
two
months
old,
we'll
never
go
to
any
previous
version
to
patch
it.
B
That
would
be
like
the
easiest
to
like
even
execute
from
a
like
logistic
perspective
yourself,
because
it's
still
like
manual,
so
you
have
to
I
mean
anything
other
than
this
would
require
like
significant
manual.
C
B
Okay,
so
the
microsoft
part
is
only
applicable
to
the
runtime
right,
so
we
just
need
to
follow
whether
a
particular
runtime
is
supported
or
not.
Okay,
I
think
we
have
a
very
general
statement
about
that.
Like
we
simply
say,
we
support
all
the
officially
supported
dotnet,
core
and
dotnet
framework,
except
for
six
one
and
any
exceptions
are
not
indirect,
so
this
is
only
general
statement.
We
have,
I
think
it's
good
to
clarify
the
hotfix
policy.
I
can
send
a
small
clarification
and
specifically
for
the
dotnet
six
part.
B
B
C
I
will
reveal
this
today
if
there
is
anything
that
I
think
needs
to
be
updating
readings
or
something
I
think
the
va
is
like
that.
B
Yeah,
actually,
this
is
like
something
in
the
actual
spec.
It
says
there
is
no
plan
to
backboard
bug
and
security
fixed
to
prior
minor
versions
of
the
sdk
may
be
only
applied
to
the
latest
okay.
So,
even
if
you
do
it,
it's
still
in
compliance
with
what
the
official
spec
says.
D
As
it
applies
to
I
mean,
I
guess
this
is
kind
of
a
hypothetical,
because
I
don't
know
how
likely
this
would
actually
happen.
But
if
I
recall
the
reason
why
we
we
upped
the
version
of
support4.net
framework
to
461
because
was
because
of
the
system.diagnostics.metrics
stuff
was
not
going
to
be
backported
to
anything
earlier.
B
B
Why
they
choose
to
do
that
is
dotnet.
461
will
be
out
of
support
like
sometime
next
month
and
they
usually
like
they
don't
have
a
release
planned
at
the
middle
of
the
year,
so
it's
usually
like
yearly,
so
they
just
decided
to
take
like
four
five
months
ahead
of
time.
They
drop
support
for
net
for
six
months,
so
yeah
yeah.
D
I
let
you
continue,
so
you
were
saying
so
I
was
thinking
you
know
forward.
Like
you
know,
something
like
that
were
to
occur
again
would
open
telemetry
that
with
open
telemetry
sdk
need
to
do
like
a
major
version
bump,
because
it'd
be
dropping
earlier
version
like
earlier
runtime
version.
B
B
If
that
version,
if
the
reason
why
we
are
doing
it
is
because
that
underlying
version
itself
is
no
longer
supported,
I
think
we
can
do
it
without
bumping
major
version.
We
had
this
like
discussion
and
at
that
time
we
asked
everyone
maintainer
and
approver,
and
we
decided
okay.
We
are
not
going
to
bump
the
major
version,
because
the
reason
why
we
are
doing
is
because
of
the
underlying
framework
itself
being
auto
support,
but
if
it
just
tomorrow,
we
decide
okay,
let's
not
support
anything
other
than
dotnet
six.
B
Yeah
and
for
the
instrumentation
libraries
are
anyway
not
stable
and
they
have
a
more
harder
dependency
on
the
dot,
not
run
time
like
0.5
or
6
or
3.1.
So,
but
we'll
like
discuss
that
when
the
time
comes
because
there
is
no,
I
don't
see
like
any
hope
that
the
semantic
conventions
will
be
stable
in
the
next
three
or
four
months.
So
we
have
like
plenty
of
time
to
find
that
out.
What
do
we
do
with
the
instrumentation
like?
B
In
fact,
there
are
like
some
pr's
in
aspect
trying
to
define
the
telemetry
stability,
and
I
also
think
dotnet
very
recently,
added
the
support
for
schema
url
so
to
be
ga
like
when
dot
net
sound
comes,
but
we
should
be
able
to
support
that,
and
I'm
hoping
that
I
I
don't
really
think
that
any
of
the
instrumentation
libraries
would
be
stable
before
that
and
by
the
time
it's
ready
for
stable.
We
would
have
released.net
7,
which
supports
the
schema
url,
and
we
should
be
able
to
follow
whatever
the
spec
says.
D
D
But
then,
as
it
applies
to
that
statement
that
you
just
brought
up
in
the
spec
like
what,
if
there
were
what
if.net
framework
48
was
still
supported
by
microsoft,
but
there
was
some
massive
security
problem
in
like
the
open,
telemetry
library,
we
might
have
a
policy,
maybe
where
we'd
want
to
go
back
and
hotfix
a
prior
version
of
the
sdk
again
complete
hypothetical.
B
Yeah,
I
think
one
thing
which
I
forgot
to
mention
is
like:
we
have
seen
like
more
activities
in
the
contrary
before
so
let
I
just
open
it
so.
Last
week
we
added
another
maintainer
just
to
like
keep
things
moving
here,
because
there
are
like
quite
large
number
of
pr's
which
did
not
receive
any
attention
so
we're
trying
to
see.
If
we
can,
I
mean
it
won't
be
like
tomorrow
onwards,
we
like
spend
more
time.
B
It's
just
that
now
we
have
one
more
helping
hand,
so
we'll
need
to
like
do
some
groundwork,
just
to
make
it
a
little
bit
more
organized
like
write
down
some
rules
like
some
expectations
from
someone
who
is
contributing
and
what
is
the
policy
to
like
kick
something
out
if
they
are
not
being
nice
with
other
things,
because
right
now
the
ca
is
going
to
run
for
everything.
B
So
if
you
have
a
misbehaving
component,
it's
going
to
break
the
entire
ci,
so
we'll
have
to
like
write
down
some
rules
before
we
can
like
start
getting
like,
I
mean
start
accepting
more
contributions
yeah,
so
we
will
probably
like
steal
something
from
other
repos.
I
think
collector
has
a
very
like
very
active
ecosystem
in
contributor.
We
might
be
able
to
revise
something
from
there.
B
There
was
another
attempt
like
a
couple
of
months
back
just
to
liberate
something
which
the
javascript
sig
used.
We
haven't
like
really
made
it
happen.
So
as
of
now,
we
have
code
owners
file
like
that.
Codeos
file
is
practically
useless
because
unless
the
person
who
is
listed
as
a
code
code
owner
has
right
access
to
the
report,
they
won't
be
notified
and
their
reviews
won't
count.
So
it's
kind
of
know
the
there
is
no
use.
B
So
there
is
a
special
key
type
action
created
by
the
javascript
folks
in
open
elementary
and
trying
to
use
the
yeah.
I
think
this
is
the
one
trying
to
do
it
so,
but
we
need
like
more
folks
to
actively
work
on
this
yeah.
This
is
the
one.
B
So,
with
one
extra
hand,
we
are
hoping
that
we
should
be
able
to
like
make
some
progress
here
and
also
there
was
other
issue
which
we
discussed
sometime
back
about
renaming
to
remove
the
word
contrib
from
this
thing,
so
that
it
look
a
consistent
name
and
the
nuget
package
will
point
to
the
right.
Repo
and
people
can
always
figure
out
which
one
it's
coming
from.
B
So
just
updating
something
about
concrete
and
there
are
like
active
peers,
especially
about
adding
more
metrics.
So
if
folks
have
time,
please
offer
to
help
these
vrs
yeah
and
this
one
is
going
to
be
merged.
Today,
like
this
is
a
oldest
pr
but
still
alive.
B
If
it's
green,
then
I'm
going
to
hit
the
mouse
button
yeah.
Finally,
it's
green,
so
I'll
just
merge
it
we'll
be
like
doing
mass
renaming,
not
mass
renaming,
we'll
do
like
one
by
one
and
start
release.
So
utkash
has
admin
credentials
now,
so
you
should.
B
There
are
some
exceptions,
especially
the
aws
one,
because
they
are
already
stable,
so
we
may
not
be
able
to
rename
the
nokia
package
so
I'll,
just
let
them
know
and
they
can
decide
whether
they
want
to
still
rename
and
somehow
like
offer
a
migration
path
for
the
users
anyway.
Those
are
just
quick
updates
on
the
controller
program
status,
so
we
have
a
couple
of
pr's.
Maybe
it's
interesting
to
look
up.
B
I
think
these
are
like
simple
examples,
very
straightforward
one.
I
don't
think
we
need
to
review
today,
but
I
think
it
makes
sense
for
us
to
review
these
two.
So
let
me
start
with
this
one
and
I'll
explain
why
this
is
important,
so
this
is
improving
the
existing
instrumentation
library
for
asp.net
to
image
metrics
as
well-
and
this
is
mostly
borrowing
from
the
sp.net
core
and
I
believe
it's
also
the
same
for
http
client.
B
So
I
put
a
comment
here
like
because
this
is
relying
on
sorry.
Let
me
see
if
I
can
modify
yeah,
so
this
one
is
currently
like
relying
on
an
activity
being
present,
because
we
are
going
to
use
the
activity
to
calculate
the
duration,
but
one
of
the
like
foundational
id
is
like.
Even
if
tracing
is
completely
disabled,
like
zero
percent
sampling
or
like
completely
disable
the
whole
thing,
then
there
won't
be
an
activity
at
all,
so
we
want
matrix
to
still
work,
even
in
that
case.
B
So
I
don't
see
like
how
easy
these
two,
like
do
that.
So
I
put
a
comment
here,
but
it's
okay
for
us
to
at
least
release
some
initial
versions,
because
we
do
have
the
same
thing
for
usb
network
today
it
works.
It's
just
right
it
at
some
point.
If
sp
code
move
to
the
activity
source
way
of
creating
activities,
there
is
a
possibility
that
the
activity
may
not
be
created
at
all.
It's
it's
going
to
affect
the
matrix.
At
that
point.
B
It's
not
like
strictly
correct
today,
because
it's
usually
the
root
one,
as
you
always
create
the
root
one.
Even
if
sampler
is
unfavorable,
but
like
the
general
ideas,
it
should
be
like
really
independent
of
tracing.
So,
but
what
I
really
want
to
bring
here
is
for
now
we
don't
want
to
like
really
wait
for
it
to
be
like
really
ironed
out,
because
this
is
still
usable
for
you,
sir.
So
we'll
go
ahead,
I
mean
once
it
is
moved
out
of
draft.
B
We
should
be
able
to
release
this
so
we'll
have
like
all
the
instrumentation
libraries
which
currently
produce
traces.
They
can
also
produce
metrics,
even
though
it
has
issues
we
just
like
put
it
in,
like
some
readme
saying
that
there
are
known
issues
and
then
like
once
the
things
proceed
towards
the
stable
state
at
that
time,
we'll
need
to
like
make
sure
disabling
tracing
would
have
no
impact
on
metrics
and
vice
versa.
It's
mostly
the
one-way
thing
like
if
tracing
is
disabled.
B
Metrics
are
likely
to
be
broken,
so
just
fi
like
and,
of
course,
it's
still
trapped,
so
nothing
right
now
actionable,
but
just
an
faa
that
we
need
to
do
similar
things
for
all
the
existing
instrumentations
as
well.
B
D
D
We're
also
refactored
to
use
those
options.
The
mistake
here
was
that
all
the
exporters
then
basically
got
like
you
know
the
quote-unquote
manual
configuration,
meaning
that
you
need
an
explicit
push
or
or
you
either
need
to
explicitly
flush.
The
matrix
now
or
the
workaround
that
you
articulated
here
is
that
well,
you
can
configure
your
metric
reader.
C
D
Explicitly
periodic
and
you
can
even
configure
the
the
export
interval,
so
that
was
previously
not
required
for
the
otlp
exporter,
and
so
that
was
the
unintentional
part
of
that
change
and
the
fixes.
D
Fix
here
is
now
you
know
this
is
kind
of
like
a
the
fix
is
now
that
all
the
push
exporters
are
using
the
periodic
metric
reader
behind
the
scenes
that
that
fixes
the
otop
exporter.
It
also
defaults
to
60
000
milliseconds,
as
you
see
on
that
line
there,
so
that
that's
as
it
was
before
it's
it's
kind
of
like
technical
nuance,
that
the
console
and
the
in
memory
also
use
the
the
periodic
exporting
metric
reader
because
they
still
behave
the
same.
D
D
It's
just
kind
of
underneath
the
covers
there
using
the
periodic
exporting
metric
reader,
and
I
did
that
in
part
to
basically
move
us
towards
getting
rid
of
this
whole
manual
metric
reader
type
thing,
which
is
not
really
anything
that
was
ever
declared
in
the
specification
we
had
it
earlier
on,
because
we
thought,
maybe
that
would
be
the
more
reasonable
thing
to
have
for
the
the
console
and
the
in-memory
exporters
is
like
a
manual
flush
cycle.
D
But
I
think
that
there's
some
consensus
now
at
the
specification
level
that
no
no
like
having
some
sort
of
a
period
for
at
least
the
console.
I
don't
know
about
the
in
memory.
I'm
gonna
put
out
a
spec
pr
today
to
propose
the
interval
for
console
and
in
memory.
B
So
at
the
end
state
like
the
ideal
state
would
be.
This
would
clearly
clarify
that
x4
type
like
whether
it's
periodic
or
manual
or
use
the
wrong
word,
but
whether
it
is
exporting
on
a
regular
interval
or
liking
field,
so
that
would
come
from
the
spec
itself,
so
we
don't
need
to
make
any
decisions
here.
Like
I
mean
it's
just
happened.
That
allen
is
also
writing
that
spec,
but
once
it
is
part
of
the
spec
we
will
be
just
like,
following
whatever
the
specs
say.
B
So,
if
it
says
console
is
by
default,
push
and
periodic
with
the
time
interval
10
seconds,
we'll
just
adapt
it,
as
is
okay
yeah.
I
think
we
should
be
good
with
this
pr
and
like
ireland
like
will
you
be
working
on
the
follow
up
to
remove?
I
saw
you
commenting
somewhere,
but
now
I
cannot
find
it
yeah
somewhere.
You
mentioned
that,
like
you
will
do
a
separate
pr
just
to
remove
the
manual.
D
Yeah
I'll
do
that
today,
that'll
be
a
really
quick
pr.
I
just
didn't
want
to
like
model
it
together
with
with
this,
this
bug
fix
effectively.
B
Okay,
yeah
so
I'll
do
the
review
for
this
one
and
then
wait
for
your
pr.
I
don't
know
like
what
else
we
need
to
wait.
It
would
be
like
good
to
wait
for
at
least
till
early
next
week,
so
we
we
still
have
like
some
open
prs
which
are
related
to
metrics.
I
think
we
should
be
able
to
get
them
in
maybe
like
they
got
yeah.
This
is
good
option
to
include,
and
maybe
this
one
this
one
and
prometheus
is
fine.
B
Let
me
okay,
this
one
is
probably
covered
here
and
if
you
do
like
the
sum
matrix
instrumentation
for
spinach
and
sql
or
something
else
I
mean
like
which
open
this
one,
he
might
be
opening
api
for
cpr
as
well.
I
mean
it
could
be
like
very
early
stage,
but
at
least,
if
you
have
like
enough
payload,
it's
a
good
justification
to
do
a
release.
So
I
mean,
as
of
now
I'll,
just
wait
for
like
next
month,
I'll
put
a
date
as
next
monday
for
doing
the
next
rc
yeah
that
should
cover.
B
I
mean.
I
don't
think
that
yeah,
the
other
thing
which
I
wanted
was
keys.
There
were-
or
there
are
quite
a
large
number
of
issues
opened
in
the
prometheus
metric
expert,
so
I
yesterday
tagged
all
of
them
with
prometheus,
and
now
we
can
see
it
here.
B
So
we
don't
really
have
like
any
bandwidth
to
look
at
it
today
or
like
this
week.
So
most
likely
we
need
to
like
delay
it
anyway.
The
specs
are
not
going
to
be
ready
for
prometheus
right
now,
so
it's
going
to
come
later,
but
there
are
like
quite
large
number
of
issues
we
need
to
discuss.
I
think,
while
he
like
left
some
comments
and
like
michael
left,
some
comments
and
then
there
is
new
person,
let
me
forget
travis.
B
He
also
left
some
comments,
so
we
need
to
make
some
decisions
about.
How
do
you
want
to
structure
prometheus
export
or
whether
it
should
be
hiding
the
underlying
implementation
that
whether
it
is
a
split
core
middleware
or
whether
it
is
doing
http
lists?
So
those
things
we
have
to
like
make
some
decision,
but
given
I
personally
wouldn't
have
time
to
work
on
prometheus
this
week,
so
we
just
see
like
try
to
like
release
the
other
components
as
soon
as
possible
and,
like
previously
prometheus
slightly
later,
the
main
motivation.
B
The
spec
for
prometheus
exporter
would
definitely
come
after
the
sdk
itself
being
stable.
So
we'll
have
like
slightly
more
window
to
find
out
the
prometheus
thing.
B
B
It's
just
that
it's
just
in
the
queue
right
after
the
sdk,
maybe
I'll,
see
like
if
michael
or
riley
has
some
time,
because
michael
and
riley
was
mostly
working
on
prometheus
from
the
very
beginning,
so
we'll
see
if
any
of
them
have
more
cycles
to
address
some
of
the
issues
and
most
likely
those
issues
will
clear
like
some
discussion
so
and
let
them
propose
something,
and
we
probably
need
to
cover
it
in
the
next
meetings,
because
it
has
to
be
like
a
common
decisions.
B
So
might
not
be
resolving
prs.
That's
it
yeah,
any
other
thing
which
we
want
to
discuss
or
anything
most
of
them
are
like
very
minor
things.
We
already
discussed
this
and
this
one
we
already
discussed
lately.
We
still
want
to
see
if
there
is
any
way
to
improve
the
performance
for
the
common
path.
So
we'll
ask
the
team
for
some
guidance
before
we
merge
it.
So
we
put
the
I
mean
it's
already
broken
and
we
just
fix
the
immediate
bleeding
by
try
catching
the
exception.
D
Question
about
those
open
vrs.
I
know
that
we
went
over.
I
see
one,
that's
mark
stale
that
we
talked
about
last
week.
The
get
uri.
D
D
But
I
think
you
brought
up
a
good
point
that
this
individual
is
a
first
time
contributor
to.
I
can
take
a
look
at
this
today
and.
A
D
B
Good
up
we'll
go
to
the
sp
one,
so
it's
we
still
have
like
in
case.
We
regret
later
that
something
is
not
right.
We
can
already
go
back,
so
we
have
that
luxury
for
anything
in
instrumentation,
so
that
should
make
it
relatively
easy
to
approve
prc.
Instrumentation
yeah,
like
thanks
for
help
here,
like
I've,
been
like
trying
to
like
encourage
people
to
like
really
offer
small
pr's,
and
these
are
like
really
small
pr's.
B
So
we
should
like
try
to
watch
them
quickly,
yeah
anything
else,
nothing
new
here
I
will
see
if
there
is
any
issues
which
needs
discussion.
I
think
I
think
I
responded
to
like
at
least
a
few
of
them,
and
we
have
seen
like
a
quite
number
of
issues
opening
about
the
routing
related
thing
in
asp.net
core
instrumentation
like
this
is
very
similar
to
that,
and
I
I
didn't
tag
it
with
the
right
label.
So
it's
not
very
easy
to
find
so
I'll.
B
Try,
try
some
of
them
in
the
sense
I'll,
apply
the
right
label
and
hope
that,
like
more
folks
have
time
to
help
one
like
this
is
another
example.
There
are
at
least
like
four
or
five
like
bugs
or
like
potentially,
nice
features
to
have
or
could
be
bugs.
I
don't
know
which
needs
to
be
addressed,
but
they
are
all
in
the
instrumentation
library.
So
it's
like
slightly
less
private
than
others.
B
Okay,
yeah,
no
other
topic
so
we'll
see
again
next
week,
so
I'll
sing
with
allen
to
coordinate
the
rc
for
it.
We'll
only
do
it
like
next
week,
but
we
want
to
make
sure,
like
all
the
pr's
are
ready
by
the
end
of
this
week,
so
that
we
can
do
a
release
early
next
week.