►
From YouTube: 2022-03-02 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
A
Yeah,
okay,
then,
give
me
just
a
second
here.
B
A
B
I
can
give
a
quick
update
on
the
release,
so
we
we
should
be
able
to
do
another
rc.
This
week
we
had
like
some
bug
fixes.
Last
weekend.
We
also
have
some
pending
prs,
which
not
yet
much,
but
hopefully
we
can
merge
it
in
the
next
day
and
do
a
release.
It
would
be
like
rc3
and
1.2
is
still
like
waiting
for
the
spec.
B
So
that's
the
only
update
which
I
want
to
share
about
one
point.
It
looks
like
the
spec
chin
that
didn't,
but
I
saw
a
note
that
there
will
be
a
dedicated
spec
meeting
every
friday
just
to
accelerate
the
sdk
stabilization.
So
hopefully
that
would
mean
things
would
get
speedier
progress
and
we
would
be
unblocked.
B
Yeah,
I
think
we
mean,
in
the
absence
of
any
other
agenda
items
we
can
go
over
the
request
or
any
any
other
questions.
A
Yeah
sure
do
you
want
to
start
with
the
pull
request
from
one
two
or
just
you
want
to
start
at
the
top?
I.
B
Think
my
either
way
is
fine.
I
think
we
can
go
from
the
top.
Is
there
any
other
questions
which
we
want
to
take
now?
Otherwise
yeah
we
can
go
to
the
beer,
it
looks
like
the
they
still
empty.
B
Yeah,
so
this
one
I
made
like
after
I
tried
to
use
a
different
tool
like
perfume
dotnet
tries
to
get
the
logs,
but
those
tools
have
a
requirement
that
you
have
to
explicitly
list
the
name
of
each
and
every
event.
Source
doesn't
really
have
the
option
like
wildcard,
so
which
means
we
have
to
make
sure
like
we
publish
all
the
names,
so
I
treat
the
doc
slightly
so
that
like.
B
If
someone
is
using
these
tools,
they
can
know
the
name
of
the
event
source,
but
the
self
diagnostic
feature
does
not
need
that
because
we
are
like
a
wildcard
subscription
internally.
So
just
minor
tweaks.
So
if
you
have
any
feedback,
please
let
me
know
also.
I
made
it
like
even
more
obvious
that
you
can
update
it
or
you
can
enable
logging
without
restarting
the
process.
B
It
was
kind
of
there,
but
I
made
it
like
even
more
clear,
because
some
folks
complained
that
it
was
not
very
clear,
so
yeah,
some
really
minor
tweaks
but
useful
one.
In
my
opinion,.
A
A
B
Covered
not
super
clear,
but
I
don't
think
we
want
to
do
that,
because
perfume
has
a
like
its
own
tutorial,
dotnet
tracers,
it's
on
tutorial
log
man
has
another
total,
so
we
don't
want
to
be
like,
like
spending
too
much
effort
documenting
how
to
use
those
tools.
If
someone
is
using
them,
I
think
they
would
figure
out
how
to
provide
the
parameters.
B
C
B
B
B
Thanks,
please
create
like
couple
of
follow-up
issues
based
on
the
comments
like
we
might
want
to
like
follow
up
on
that,
but
just
create
an
issue.
Don't
no
need
to
address
anything
right
now,
but
having
an
issue
open
will
allow
us
to
come
back
to
these
issues
later.
If
you
choose
to.
C
C
D
Okay,
okay,
so
we
we
had
a
tech
talk
regarding
from
eps,
and
basically
people
are
following
this
dog
for
a
small
exercise
and
then
these
are
the
steps
or
the
step.
I
guess
that
could
be
clearer
because,
like
multiple
people
got
stuck
here
when
using
grafana,
so
this
is
basically
a
minor
change
based
on
the
feedback.
I
got
from
the
talk
section.
B
Okay,
so
that
was
like
an
internal
microsoft.
Tech
talk,
so
we'll
probably
be
doing
something
for
the
community,
because
I
think
the
last
time
we
had
one
was
two
years
back
when
paulo
and
sergey
from
like
splunk
and
now
google.
They
talked
about
like
some
instrumentation
engine
stuff
and
after
that
we
never
had
any,
but
hopefully
like
once
we
do
1.2.
We
can
do
like
some
tech
talks.
Maybe
like
go
deeper
into
how
we
I
mean
mostly,
we
don't
want
to
be
like
offer
tutorials.
B
We
probably
want
to
do
something
which
explains
how
the
sdk
is
designed.
It
takes
a
very
different
approach
for
logging
and
tracing
and
for
metrics,
so
maybe
we
could
cover
some
of
them
once
one
point
two
is
out.
B
I
don't
know
it's
done
inside
microsoft,
so
unless
I
mean
someone
has
to
verify,
there
is
no
microsoft
secret
there
I
hope
not.
But
if
it's,
if
the
intention
is
to
share
with
the
community,
I
would
just
say
record
one
fresh
put
it
to
like
youtube
and
share.
B
B
Yeah,
but
someone
has
to
like
review
and
make
sure
like
there
is
no
incorrect
aspects
in
it,
because
it's
it's
as
good
as
doc.
So,
just
like
read
code
review
dogs,
we
need
to
review
the
videos
yeah.
B
Okay,
yeah
we'll
review
this
pr.
Nothing
needs
to
be
discussed
further.
B
A
I
think
it's
pretty
straightforward,
but
I
am
curious
about
I
guess
yeah
you
had
to
comment
see
joe
about
waiting
on
the
spec.
I
guess
it
was
a
comment
actually
in
the
code
and
I
guess
I
was
a
little.
I
was
a
little
curious.
What
was
this
referring
to?
I
assume
it's
a
pretty
old
comment.
I
looked
at
it.
B
I
put
that
comment
because
at
that
time
the
wording
was
not
part
of
the
spec.
It
was
still
a
no-tip,
but
since
then
it
was
merged
into
the
actual
spec.
If
you
read
the
current
spec,
it
talks
about
the
detectors
and
what
should
it
take
and
where
should
it
return?
Okay,
yeah
so
yeah.
B
On
this
I
said
yeah
yeah.
This
was
like
way
earlier,
probably
at
that
time
and
everything
was
experimental.
So
put
that
comment
saying
we
don't
want
to
expose
it
until
it's
clear,
but
now
it
looks
like
it's
stable.
It
was
part
of
the
stable
really,
so
the
spec
wouldn't
have
any
breaking
changes,
so
we
should
be
comfortable
exposing
this
as
public.
B
B
Processor
and
now
resource
builder,
but
by
the
way
like
in
that
topic,
we
need
like
some
updates,
which
I
wanted
to
do
like
a
few
weeks
back.
I
will
still
be
doing
that.
It's
basically
that
all
that
doc
is
like
too
much
tied
into
the
tracing.
Like
writing
an
instrumentation
library
extending
all
those
things
are
like
very
much
tied
to
tracing.
B
Even
even
this
pr
is
tying
the
resource
to
tracer,
but
like
resource
is
like
floating
thing
across
all
three
signals,
so
we
should
like
move
it
elsewhere,
but
let's
get
this
merge
and
then
we
can
do
a
little
bit
of
rearrangement
of
the
dock,
so
that
things
which
are
common
should
be
like
moved
to
like
some
common
place
and
referred
by
all
the
trace
log
and
matrix
okay.
But
it's
like
not
a
blocker.
For
now
we
can
address
that.
Even
the
stick
was
like
that.
B
Initially
there
were
a
lot
of
duplication
for
traces
and
metrics,
but
eventually
someone
refactored,
move
things
into
common
and
then
started
offering
from
other
places.
So
it's
a
nice
editorial
change.
We
can
do
later.
B
C
Okay,
my
machine
is
not
allowing
me
to
do
anything
which
one
is
this
improve
get
uri.
E
E
E
E
E
Basically,
in
a
nutshell-
and
I
think
having
it
consistent
across
the
repo
is
nice
so
that
when
we're
reviewing
prs,
if
you
see
that
static
pattern,
you
know
it's
good,
that's
always
going
to
work.
If
it's
not
in
that
pattern,
you
have
to
understand
the
quirks
of
the
compiler
to
know
if
it's
going
to
work
and
even
if
it
does
it's
slower,
you
kind
of
get.
What
I'm
saying
like
to
me.
It's
a
win-win.
Just
always
do
the
static
field
and
move
on.
B
E
Of
the
top,
one
is
sort
of
the
good
pattern,
so
it's
always
it
just
loads
the
static
field
and
then
jumps
into
whatever
call
is
happening.
The
second
one
is
that's
if
it
doesn't
work
at
all,
it's
just
going
to
allocate
a
delegate
every
time.
So
that's.
E
E
Whereas
the
first
one,
the
very
top
of
that
example,
is
with
the
static,
so
basically
all
we're
doing
is
we're
pre-initializing
the
field
as
static,
so
that
will
become
the
delegate
and
then
every
invocation
of
whatever
you're
calling
in
this
case
it's
string.create,
but
it
could
be.
You
know
anything
if
you're
parsing
log
scopes.
It
has
the
same
pattern.
It's
kind
of
used
all
over.net.
E
B
Yeah,
so
we
can
just
click,
ask
everyone
to
review
and
like
see
if
there
is
any
strong
opinion
about
this,
otherwise
we
should
be
good
to
merge
it
or
if
the
person
is
not
available,
we
can
merge
it
and
then
do
the
follow-up
to
the
new,
like
idea,
which
michael
suggested
to
make
it
consistent
with
the
rest
of
the
repo
and
gain
the
like
buff
benefit.
While
doing
that
yeah.
B
I
don't
think
I
mean
this
person
is
like
a
first
time
contributor,
so
I
don't
know
whether
they
are
usually
available
so
we'll
see,
and
if
it
doesn't
happen
like
we
can
do
for
all
of
our
sellers.
B
Okay
cool,
but
it's
only
in
the
instrumentation
library
right.
It's
not
touching
anything
else
so
like
we,
okay
qra
should
be
part
of
some
instrumentation
like
that.
Here.
A
B
Vr:
okay,
okay
yeah!
We
can
review
it
if
it
happens
like
in
next
couple
of
days.
We
will
make
it
part
of
the
next
release,
otherwise
to
the
next
one
yeah.
B
I
think
we
can
skip
these
two,
like
the
like
minor
additional
things.
I
don't
think
like
it
was
intended
to
be,
must
like.
Did
you
intend
it
to
merge
or
get
it
merged
or
were
using
it?
I
do
I'll
read.
The
histogram
appears.
B
Part
yeah
yeah
that
one
actually
riley
did
approve
it,
but
he
left
a
comment
and
then
I
was
wondering
that
oh.
C
B
So
maybe,
like
I
think
you
mentioned
in
command
like
we
can
put
a
comment
with
some
actual
code
but
comment
it
out
so
yeah.
So.
B
Let's
just
do
that,
because
I
mean
we
have
to
modify
it
to
that
way
and
yeah
yeah
histogram
benchmarks.
I
think
it
should
be
fine,
it's
very
straightforward.
You
should
be
able
to
merge
it
through
any
discussion.
Maybe
the
next
two
one
requires
some
next
three
one.
So
let's
go
to
the
more
interesting
ones.
C
Yeah,
so
is
this
the
thing
which
we
discussed.
F
Last
week
yeah
we
talked
about
this
last
week.
As
far
as
I'm
aware,
this
pr
is
ready
to
merge.
A
Just
for
fun,
I
took
a
brief
look
at
the
java
implementation
granted.
It
doesn't
necessarily
mean
any
thing
in
terms
of
what
we
should
or
shouldn't
do,
but
I
did
note
that
java
is
actually
making
on
each
collect
cycle.
That's
taking
a
complete
snapshot
and
allocating
like
a
immutable,
measured
point.
I
know
that
that's
a
pattern
you
were
discussing
previously
but
or
a
potential
solution
that
was
being
discussed
previously.
B
You
know
we
discuss
that
like
for
a
different
reason,
also
like
when
we
want
to
do
the
cleanup
we
have
a
currently.
We
have
a
single
like
buffer
thing.
It's
it's
not
a
buffer,
like,
I
think
it's
an
array
of
metric
points
and
when
we
see
a
new
metric
point,
we
like
increment
the
pointer
by
one
and
start
using
the
next
one,
but
we
currently
don't
have
any
mechanism
to
reclaim.
B
So
at
that
time
like,
let
me
think
you
were
working
on
that
pr
to
try
to
reclaim
it,
but
what
we
ended
up
with
whatever
we
do.
We
need
to
put
it
like,
surrounded
by
like
some
locking
mechanism,
explicit,
lock
or
like
some
slim
log,
for
that
time,
like
what
I
was
proposing
was
if
you
have
two
buffers
like
that
one
array
of
metric
points
and
another
one
and
one
being
the
active
one,
another
being
the
inactive
one.
B
So
whenever
an
export
or
collect
occurs,
we
swap
and
all
the
fresh
updates
would
happen
to
the
new
one.
The
old
one
is
spread
up.
So
there
is
only
the
character
thread
is
touching
the
inactive
one,
so
it
can
safely
remove
clean
up
everything,
but
then
at
some
point
we
had
to
like
reconcile
them
and
merge
them
together.
B
So
we
decided
like
it's
a
little
bit
complex,
we'll
come
back
to
it
later.
So
maybe
it's
not
directly
related
to
what
we
just
mentioned,
but
it's
very,
very
close.
C
B
Mostly,
our
puffy
is
like
very,
very
good,
like
I've
been
like,
comparing
with
other
solutions
as
well
like
we
have
inside
microsoft,
there
are
like
other
metric
libraries,
so
we
were
comparing
the
performance
and
it
seems
like
very
good
already
so,
unless
we
have
a
very
strong
need
to
improve
the
puff
further,
we
can
probably
leave
with
this
thing
for
now,
the
other
we
might
still
need
to
do
it
for
the
memory
efficiency
part
like
we
want
to
like
reclaim
metric
points
which
are
not
used.
B
So
at
that
time
we
need
to
like
do
like
some
free
architecting
or,
like
some
deeper
analysis
before
we
can
do
that,
but
because
it's
mostly
fine
for
now
once
we
finish
all
the
features
like
we
have
like
bunch
of
other
features.
So
maybe
once
we
finish
all
of
them,
then
that
would
be
the
right
time
to
come
back
and
see
if
there
is
any
different
design
or
different
are
internally
designated
thing.
B
I
mean
I
tried
the
examples,
and
that
was
also
like
a
concerning
in
terms
of
performance,
so
I
basically
said
okay.
This
is
something
we
should
really
need
some
time
to
think
through.
So
we'll
come
back
to
that
when
we
actually
start
doing
that,
because
that
would
mean
like
we
have
like
feature
complete
and
then
that
would
be
the
right
time
to
do
like
any
major
performance
sessions.
B
E
Was
so
asp.net
core?
Has
this
kind
of
weird
behavior,
where
it
pushes
a
log
message
with
a
state,
that's
sort
of
deferred
over
http
context,
so
until
you
enumerate
the
values
it
doesn't
execute
it
so
in
our
buffered
exporting
it
can
execute
after
the
http
context
has
disposed,
in
which
case
you
get
exceptions.
E
E
We
capture
the
results,
so
it's
sort
of
safe
to
then
export
later
on,
so
that
change
was
pretty
small
and
then
cj
threw
out
the.
Maybe
we
should
clear
the
states
when
we're
done
like
scopes
that
made
it
a
little
bit
more
complicated,
so
it
ended
up
being
more
code
and
I
had
to
update
all
the
tests,
but
I
think
it
was
a
good
good
change
to
have.
B
So
what
what
do
we
do
in
the
log
statement?
Now
we
get
the
state
and
we
I
trade
like
do
we
call
the
enumerator
and
I
trade
through
it
and
copy
it
into
a
different
one?
Is
that
what
we
are
doing?
It's
kind
of.
E
E
E
E
You
can
just
get
the
raw
object
or
you
can
turn
on
the
state
parsing,
in
which
case
we
try
to
resolve
a
read-only
list.
There's
three
possible
cases
it.
It
is
a
read-only
list,
in
which
case
we
just
take
the
the
casted
version
or
the
concrete
interface
version.
If
it's
an
I
innumerable
on
line
85,
we
make
a
copy
of
it
here
and
then,
if
it's
just
an
unknown
type
of
object,
we
add
it
in
an
empty
key
value
pair.
That's
on
line
93.,
so
those
bottom
two
cases
were
already
making
copies.
E
E
E
B
E
B
E
B
E
Think
I
can
pick
up
that
code
real
quick
to
see
it
depends
on
the
concrete
type
if
it's
a
list
or
a
dictionary,
those
implement
eye
collection,
so
they'll
get
the
better
perf.
B
Maybe
let
me
ask
you
slightly
differently,
which
scenario
are
we
optimizing
for?
Is
it
for
the
scenario
where
the
state
is
an
I
collection
or
is
it
when
like
state
is
something
else.
B
And
I
believe
that's
what
happens
when
user
uses
the
log
information
here,
because
line
31
is
not
using
the
raw
logging
api.
It
is
using
the
extension
method
on
I
logger,
which
creates
this
collection
of
read
sorry,
collection
of
key
value
pairs,
and
it
contains
that
special
thing
called
original
format,
which
contains
the
raw
string
like
hello
from
curly,
brace,
name,
curly,
brace
price,
then
like
another
entry,
with
the
name
and
value
as
tomato
and
price
and
2.99.
B
B
B
I
see
okay,
then
we
need
to
see
if
we
can
improve
that,
because
I
think
most
likely
people
will
be
using
this
by
default,
because
in
their
eye,
logo
documentation
is
recommending
using
the
formatted
log
value
approach.
E
B
Like
have
you
seen
like
folks
using
anything
other
than
the
formatted
logs,
because
I
have
seen
like
pretty
much
everyone
who
use
ogre,
they
simply
follow
the
spinner
core
and
I
logger
talk
and
they
are
like
100
percent
of
them
is
recommending
the
extension
methods,
which
would
mean
we
are
going
to
get
the.
I
really
list,
not
ira
collection.
So
maybe
we
should
see
if
we
can
optimize
it
for
the
popular
case,
if
possible,.
A
B
Yeah,
it's
not
the
copyright
like.
So
when
we
get
the
state
what
we
are
basically
doing.
Is
we
go
through
the
item,
one
by
one
like
we?
I
try
through
it.
While
we
are
in
the
log
statement
itself,
then
like
save
it
somewhere.
So
that
seems
unavoidable
to
me
I
mean
if
you
are
processing
it
asynchronously,
then
you
have
to.
E
B
E
B
Yeah
I
mean
that
might
be
an
option
as
well,
because
I
mean
because
it's
not
recom,
there
is
no
recommended
parties
or
anything
about
state
and
it
was
kind
of
surprising
for
me.
It's
kind.
E
B
B
There
is
nobody
yeah,
I
I
suck
for
it.
There
is
no
guardian
such
that.
It's
just
that
the
x
building
extension
methods,
like
log
information,
log
warning
they
are
implementing
at
least
so
most
providers
do
that
special
casing.
If
it
is
an
identity
list,
do
something.
Otherwise
I
think
they'll
just
do
like
two
string
or
something.
B
I
don't
know
whether
this
is
like
very
specific
to
the
asp.net
core,
like
backing
the
state,
with
a
with
something
tied
to
the
scope
of
the
request,
or
this
is
like
very
common
elsewhere.
B
It
may
be
like
this
is
something
which
I
can
ask
and
see.
If
there
is
any,
I
mean,
do
we
get
like
any
guidance
from
the
I
logger
owners.
E
B
So
maybe,
like
a
related
thing
like
what,
if
we
enable
the
parse
state
values
option,
even
in
that
case
we
have
the
same
issue
right
like
when
we
ask
enable
our
state
values.
Can
we
copy
everything
into
or
okay,
that's
basically
same
as
we.
E
Could
do
it
there,
but
then
people
using
like
the
simple
mode
they
would
be
paying
for
those
cycles
when
they
don't
necessarily
need
to
because
they
could,
just
if
they're
executing
in
line
per
call
they're
going
to
loop
it
in
that
chain.
They
will
never
run
into
this.
You'd
only
see
this
if
you're
trying
to
access
it
later
on
another
thread
or
defer
it
somehow
yeah.
B
Okay,
it
was
kind
of
surprising
for
me
as
well
because,
like
a
lot
of
people
inside
microsoft
at
least
are
using
this
already,
but
senior
relays,
like
majority
of
them,
are
using
the
simple
one.
There
is
no
batching,
that's
why
no
one
has
reported
it
so
far.
So
now
people
are
using
the
otl
p1
which,
by
default
patches
and
now
we
started
seeing
this
issue.
B
People
inside
microsoft
were
using
it
for
quite
some
time
now
it's
very,
very
interesting,
yeah
anyway.
Let's
continue
this
in
the
pier
I'll.
Take
another
look
see
if
we
can
do
like
something
to
make
the
common
path
faster,
but
if
there
is,
if
it's
increasable,
then
yeah,
that's
the
reality
like
we
have
to
live
with
that,
so
we
can
just
accept
it
and
then
move
on.
C
A
A
Basically,
there
was
some
additional
language
added
to
the
spec
about
the
detection
of
duplicate
instruments,
so
insta
declaring
an
instrument
multiple
times,
there's
a
term
here,
identical
meaning
that
it
has
the
same
name,
description,
unit,
kind
like
counter
or
gauge,
and
then
in
our
case
also
like
data
types
so
like.
If
you
had
like
a
a
counter
like
a
long
counter
versus
a
double
counter,
those
be
not
be
identical.
A
They
would
be
distinct,
but
if
they,
if
there
is
an
instrument
with
the
same
name,
then
the
change
is
that
we
should
not
reject
that
any
longer.
So
I
have
implemented
that
in
this
pr.
B
So
when
you
say
we
should
not
reject
what
we
are
going
to
do
is
if
the,
if
you
are
getting
an
instrument,
let's
say
some
name,
a
we
are
getting
another
instrument
with
the
same
name.
We
should
just
like
return
the
original
state
so
that
any
updates
from
the
original
instrument
and
the
new
one
they
got.
They
update
the
exact
same
metric.
A
Is
that
the
overall
idea?
That
is
the
idea
if
they
are
so
there's
that
distinction
between
they're
identical
so
all
of
their
all
of
their
name
kind?
You
know
description
is
identical,
then.
Yes,
this
pr
returns
the
same
the
same
instance
or
handle
the
same
underlying
metric
and
things
will
be
aggregated
together
from
those
two
instruments.
But
if
anything
is
different,
if
they're
distinct,
then
that
will
lead
to
multiple
metric
streams
with
possible
duplicate
names,
yeah
with
duplicate
names,.
A
Right,
correct,
yeah,
we'll
just
pass
it
to
the
exporters.
The
specifications
still
says
that
it
should
be
logged.
Okay,
there,
a
warning
should
be
logged
that
a
duplicate
instrument
wasn't
countered
and
it
was
somehow
distinct.
A
There's
some
suggestions,
some
guidance
in
the
specification
that
suggests
that
the
warning
message
should
really
help
guide
the
user.
Like
hey,
you
know,
if
you've
got
a
description,
that's
different,
then
here's
the
view
configuration
that
you
could
apply
to
to
reconcile
these
things.
A
A
A
long
line
that
just
simply
says
either
change
the
name
or
or
use
ad
view
to
resolve
the
conflict,
but
it
doesn't
go
into
details
about
how
to
resolve
the
specific
conflict
that
just
occurred.
So
that's
something
that
we
could
do.
I
think
it
may
be,
as
apologies.
B
If
we,
we
cannot
print
the
exact
statement
like
we
cannot,
I
mean,
is
it
even
feasible
to
print
the
exact
add
view
statement
like
with
the
original
name
replacement
name
can?
Is
it.
A
Feasible,
something
is
feasible,
I
think
so,
if
say,
if
two
two
instruments
were
declared,
everything
was
the
same,
except
for
maybe
the
units
then
well.
Units
is
a
bad
example,
because
you
can't
change
units
with
with
a
view.
Description
is
a.
A
B
Okay
and-
and
I
think
like
when
you
originally
opened
the
vr-
you
mentioned,
it's
only
handling
the
you
know
view
path.
Is
that
still
the
case
or
are
you
handling
both
view
and
handling
both
now.
B
The
two
okay
yeah,
we
probably
need
a
big
change
log.
Explaining
this
I
mean
I
don't
expect
many
people
to
be
intentionally
creating
duplicates,
but
now
they
are
going
to
see
a
different
behavior.
So
if
they
were
accidentally
creating
too
many
metrics,
we
would
have
dropped
it,
but
now
we'll
let
them
all
flow
so
like
it
should
be
good
to
be
highlighted
in
the
changelog.
B
It's
unlikely
unless,
like
someone
is
intentionally
trying
to
test
the
system,
okay,
yeah,
so
I
think
we
should
wait
for
this
pr
to
be
marked
for
the
next
release
candidate,
because
that
way
it
has
like
enough
payload
like
it.
We
have
some
of
improvements.
We
have
the
resource,
detectors,
some
bug,
fixes
and
small
spec
complaints
related
things,
so
that
would
make
a
good
release
candidate
83,
so
maybe
yeah.
I
mean
I've
tried
to
do
it
before
end
of
this
week.
B
So
we'll
try
to
review
this
pr
today
and
tomorrow
and
see
if
we
can
merge
it
by
like
friday
morning
at
late
at
the
latest.
So
we
can
do
the
release
on
friday,
because
also
has
at
least
one
follow-up
pr
for
the
histogram
improvements.
There
will
be
like
a
minor
follow-up
to
that,
so
so
that
way
we
should
be
able
to
do
a
rc3
release
by
end
of
this
friday
sounds
good
yeah,
oh
okay,
so
I
think
that
was,
I
think
everything
else
was
like
slightly
older.
B
We
already
at
least
discussed
it
a
few
days
back
yeah
an
exam
yeah.
So
I
think
I
I
still
need
to
try
the
releasing
part.
So
maybe
I
quickly
go
through
the
client.
So
can
you
take
the
build,
slash,
releasing
process?
You
just
want
to
like
ask
something
quickly.
So
when
I
did
the
release
last
time,
I
did
a
shortcut.
I
skipped
like
one
step,
which
was
to
do
the
github
release.
B
Releasing.Md
yeah,
but
it
looks
like
people
were
counting
on
that
being
there.
So
I'll
follow
everything
here.
But
what
I'm
going
to
do
is
I'll
modify
the
say,
michael
there's,
another
michael
maxwell
who
wrote
the
automation
file
check
with
him
and
do
one
thing
which
is
to
modify
the
workflow
to
publish
directly
to
nougat
because
it's
currently
stopping
at
my
gate.
B
So
the
most
complex
manual
steps
here
is
like
from
seven
onwards,
because
you,
the
automation,
like
ends
at
my
get
so
then
you
go
to
my
get
download
everything
to
local,
then
download
nougat
then
set
the
key,
execute
bunch
of
commands
locally
and
then
verify
that
everything
is
still
there.
So,
but
the
contributor
point
directly
pushes
to
nougat,
so
I
think
I'll
work
with
him
to
modify
the
steps
to
modify
the
workflow
to
directly
push
to
nuget
and
reduce
the
number
of
manual
steps
here.
B
We
would
still
need
that
manual
step
to
do
the
github
release,
so
that
part
is
already
covered
by
the
automation
pr,
so
we
should
be
able
to
like
combine
like
different
things
like
comparing
like
some
steps
into
one
and
change
the
actual
process
where
we
bypass
the
my
get
and
directly
go
remove
it.
So,
in
combination
of
all
these
things,
I
think
we
should
reach
a
point
where
we
can
do
a
release
like
in
less
than
10
minutes.
15
minutes,
yeah
I'll
share
the
update
on
friday.
B
When
I
actually
do
it,
I
mean
I
mean
I
was
hoping
that
I'll
be
done
with
that.
Like
last
time,
so
we
can
all
take
rotation
and
try
it
already,
but
it
hasn't
happened
so
this
time
I'll
try
to
make
it
happen
and
we
can
do
a
rotation
next
time
onward.
So
it
should
be
like
very
straightforward.
For
anyone
to
I
mean
any
maintainer
who
has
access
to
do
the
actual
release.
B
Maybe
I
have
one
more
ask
for
like
all
of
us
here,
so
can
you
open
the
country
repo?
I
have
like
some
activities
going
on
there,
which
hyphen
code
rib
at
the
end.
B
So
we
have
two
pr's
to
be
discussed,
the
second
one
from
the
top
and
the
177,
the
even
counter
listener,
so
slightly
below
even
counter
listener
yeah.
So
these
I
mean
mostly
ready
but
still
has
like
some
frame
final
adjustment.
It's
like
definitely
worthy
of
doing
a
initial
release.
B
So
if
anyone
has
cycles,
please
go
and
look
at
it.
I'm
I
mean
we
do
have
like
two
and
I'll
explain
like
why
the
first
one,
the
other
one,
the
1777
one,
is
about
even
counter.
So
this
is
basically
like
converting
even
counter
to
emit.
I
mean
subscribe
to
even
counter
using
the
old
way
like
the
even
counter
way
and
in
turn
produce
a
observable
gauge
or
observable
counter
and
pipe
it
through
the
new
metric
pipe
like
the
open,
elementary
sdk.
B
It
has
like
some
challenges
because
even
counter
does
not
have
a
way
to
read
the
aggregated
metrics.
It
only
has
a
thing
called
like
refresh
internal,
so
you,
when
you
register,
you
specifically
tell
them
at
the
registration
type
hey.
This
is
a
refreshing
role,
so
it
gives
a
call
back
like
every
that
interval
on
second
order
and
second,
but
there
is
no
ad
hoc
way.
B
So
the
challenge
is
with
professors,
because
with
prometheus,
like
the
scrape
records
can
come
anytime.
So
at
that
time
you
cannot
just
go
and
ask
even
going
to
hey.
Give
me
your
current
one,
because
there
is
no
such
api
encounter.
So
what
we
are
trying
to
do
is
we
are
in
some
interval,
like
maybe
like
10
seconds
or
something
we
get
the
values
from
encounter
and
store
it
in
another
state,
some
dictionary
or
something
like.
B
I
forgot
like
what
data
structure
they
are
using
like
some
data
structure
and
then
when
promises
comes
fit,
give
the
cached
one
to
the
prometheus.
So
there
is
always
like
a
mismatch,
because
even
if
this
only
comes
like
once
in
15
minutes,
we'll
be
spent
spending
all
this
time.
Getting
this
thing
so,
but
there
is
no
better
solution,
and
I
don't
think
like
you
encounter,
will
be
like
improved
to
support
this,
because
the
future
direction
is
to
use
the
new
metrics
api.
So
that's
this
deal.
B
It
will
have
some
limitation,
but
it
will
still
work.
It's
a
little
bit
inefficient,
but
it
still
work.
That's
this
pr,
however,
the
reason
why
we
have
the
other
pr
is
because,
based
on
some
anecdotal
evidence,
majority
of
the
people
who
use
the
ui
counter,
they
are
using
it
just
to
get
the
some
system,
runtime
statistics
which
were
previously
available
as
a
performance
founder
in
the
3d.net
core
world.
B
So
since
the
net
core
does
not
have
a
performance
counter,
dotnet
team
decided
to
use
the
encounter,
so
people
are
interested
in
new
encounter,
mostly
not
always
but
good
amount
of
cases,
primarily
just
to
get
this
information.
The
like
dc
stats
memory,
stats,
third
pool
stats,
so
there
is
a
workaround
which
is
these
metrics
are
available
as
a
static
method
from
like
gc
dot,
get
heap
size
or
processor
process
dot
get
usage.
So
there
are
like
different
methods
which
already
expose
this
without
going
through
the
encounter.
B
In
fact,
they
encounter
internally
uses
this
method,
so
this
pr
is
like
very
targeted
instrumentation
to
get
some
metrics
from
the
dotnet
runtime
without
any
even
counter
thing.
So
this
will
be
like
a
proper
instrumentation.
B
There
is
a
very
limited
subset,
like
I
think
I
would
say,
like
maybe
like
506,
compared
to
the
30
plus,
which
we
would
get
from
even
counter
but
noah
from
dotnet
team,
and
he
commanded
him.
He
will
create
work
items
in
the
runtime
report
to
expose
more,
but
it
won't
happen.
It
won't
get
backpacked
up
to
the
old
version,
so
whatever
happens
and
dotnet
time
will
only
be
in
the
seven
eight
nine
in
the
future
one.
B
So
we
need
to
do
like
some
hacks
here,
like
some
reflection
or
something
here
to
work
around
that
so
yeah.
So
that's
the
background
of
these
two
peers
of
folks.
How
time
please
go
ahead
and
look
at
it.
It's
quite
likely
we'll,
like
start
merging
things
just
to
make
progress,
because
it's
been
like
waiting
for
quite
some
time,
so
I'll
probably
approve
it,
and
with
the
comment
saying
that
there
are
issues
but
we'll
just
do
an
initial
release
and
fine-tune
things
as
we
learn
more.
B
So
just
a
request
for
folks
to
contribute
this
pr,
and
there
are
like
so
many
potential
breaking
changes
in
the
future
because
we
might
be
using
like
some
names
for
the
metrics
and
dimensions,
but
once
the
semantic
conventions
evolves,
there
will
be
like
if
it
may
be
recommending
a
different
can
different
name.
So
because
of
that,
we
cannot
release
this
as
stable.
We'll
have
to
do
it
as
a
alpha
or
beta.
B
B
I
think
this
is
like
very
important
lot
of
people
who
are
going
to
ask
this
like
as
soon
as
they
see
the
metrics
being
stable,
like
they
last
very.
B
How
do
I
get
the
some
built-in
metrics
from
dot-net
runtime,
because
most
other
systems
already
have
this,
including
prometheus?
So
we
need
to
like
spend
some
time
here
and
reach
out
to
team
whenever
we
need
help
from
to
unblock
each
and
every
individual
metric.
B
And
we'll
see
if
we
can
list
someone
from
dotnet
team
as
the
owner
to
this
one
or
maybe
like
this-
is
a
writer
topic,
like
we
discussed
about
two
months
back
about
moving
instrumentation
libraries
from
the
main
repo
to
the
contract
repo.
B
I
didn't
get
much
time
to
think
through
it,
but
it
looks
to
me
like
there
is
still
some
value
in
keeping
some
instrumentations
in
the
main
ripple
because,
like
with
control
repo,
there
is
no
guarantee
like
who
wants
it
for
routing
what
would
be
the
support.
B
B
If
that
happens
like
there
is
no
guarantee
that
package
will
be
updated
or
if
it
has
a
bug
fixed,
no
one
would
respond
the
other
hand
in
the
main
repo.
At
least
there
are
like
some
people
who
are
actively
working
on
it,
and
there
is
some
sort
of
guarantee
that
this
is
not
like
a
real
support
guarantee,
but
at
least
it
has
a
better
like
better
than
something
random.
B
In
the
control
group,
so
I
don't
know
whether
any
repo
has
solved
this
problem,
so
we
will
need
to
like
discuss
this
like
once.
We
I
mean,
I
would
say,
let's
discuss
it
once
1.2
is
there,
but
if
at
all
possible,
I
would
want
to
keep
this
as
part
of
the
main
ripple,
because
this
is
like
something
very
important
for
every
dot
net
user
and
we
want
to
give
the
impression
that
this
is
something
which
is
really
supported
like
not
right
now,
but
once
it
is
in
that
shade,
I
mean
I'll
know
my
like.
B
If
you
have
any
any
thoughts
on
that
or
maybe,
if
not
it's
fine
like
we'll,
come
back
to
this
program
later.
A
I
don't
necessarily
have
a
problem
with
that.
Moving
this
to
the
main
repo,
so
I'd
also
be
open
to
talking
about
what
it
would
look
like
to
give
the
contrib
repo,
maybe
a
little
bit
more
attention
like
if
there
were.
If
there
were,
if
we
moved
the
existing
instrumentation
libraries,
would
it
be
possible
to
maintain
us
as
the
main
maintainers.
B
Yeah,
the
main
reason
why
I
brought
it
up
is
because,
like
the
moment,
we
put
anything
into
your
contract,
then
it
immediately
people
generally
get
the
feeling.
Okay,
this
is
like
it.
This
could
be
like
really
unstable.
Even
if
it's
the
package
itself
is
stable,
there
is
no
guarantee
that
it
would
remain.
It
would
continue
to
work
with
the
newer
and
newer
version
of
the
sdk,
because
no
one
is
actively
going
to
keep
them
up
to
date
with
the
changing
semantics
and
because
many
conventions
could
change
in
the
future.
B
So
if
this
is
not
updated,
then
it
will
remain
like
uncomplained,
so
there
is
no
guarantee
that
it
would
be
updated.
So
maybe
one
idea
is
like
we
can
create
a
curated
set
of
instrumentations,
keep
it
in
the
main
repo,
and
we
expect
who
is
the
maintainer
and
approval
of
the
main
report.
They
are
expected
to
maintain
them
as
well
to
keep
up
with
all
the
semantic
and
maintenance
changes,
but
I
don't
know
how
we
would
pick
that.
B
Maybe
we
need
to
like
do
some
more
discussion
to
figure
out
like
what
qualifies
us
a
package
which
can
be
hosted
in
the
main
repo
versus
something
else.
One
one
like
very
dave
explain
criteria
would
be
if
it
is
shipped
by
the
as
part
of
the
official.net
release,
then
we
can
keep
it
slowly,
qualify,
http,
client
and
sp
net
core
everything
else
would
move
out.
B
Maybe
maybe
this
one
also
like
the
pr
which
we
are
staring
at
right
now
that
since
it's
directly
part
of
the
dot
net,
we
could
like
specially
guess
these
three
make
it
part
of
the
core
group
and
everything
else.
I
don't
know
about
single
client.
Is
it
still
ship
from
dotnet
foundations,
repo?
I
think
so
it
is
still
part
of
the
foundation.
B
So
I
mean
dotnet
foundation
is
a
broader
team,
but
mostly
I
am
saying
whenever
the
new
version
of
download
comes,
there
is
a
bunch
of
packages
which
are
released
along
with
that
like
entity
framework,
spinner
call
http,
client
all
those
things.
B
So
so
we
might
need
to
write
some
guidelines,
so
that
obviously
means
like
things
like
thing:
reduce
does
not
fit
in
there
and
grpc
might
have
to
because
of
the
weight
is
like
piggybacking
on
the
http
client,
so
it
may
have
to
be
like
specially
cased
and
kept
there
but
yeah
having
like
fully
thought
through
this.
But
this
is
something
which
we
want
to.
B
B
Okay,
any
other
I
mean
I
didn't.
I
don't
have
my
mouse
helping.
So
there
is
a
chat
in
the
zoom.
Is
that
something
which
you
want
to
look
at.