►
From YouTube: 2022-02-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).
A
Hello,
everyone
just
give
me
one.
Second,
while
I
start
sharing.
B
A
A
Start
with
the
first
update,
we
still
don't
think
the
metric
is
taking
spec
would
be
stable
this
week
for
sure,
like
hoping
that
it
would
be
like
sometime
next
week,
but
it's
still
unclear.
So
this
is
the
update
from
sdka
specification.
A
Sorry,
the
specification
submitting
this
morning.
So
so
we
won't
have
the
spec
release,
which
contains
the
sdks
table
this
time,
so
they're
going
to
do
a
spec
release
today
or
maybe
like
tomorrow,
but
it
won't
contain
the
metrics
being
marked
as
stable,
primarily
because
there
are
like
some
clarification,
pr's
which
seem
to
be
touching
not
just
sdk
spec
seem
to
be
touching
api
spec
and
a
little
bit
on
that
ammo.
A
So
you
can
see
it's
like
fairly
complex
because
it
supersedes
many
other
and
it's
fixing
at
least
four
issues
and
the
third
attempt
to
do
that.
So
I
don't
expect
this
would
be
to
solve
like
a
couple
of
days
and
most
likely
this
would
be
a
broken
factor
before
the
sdk
stable,
and
this
do
have
some
implications
on
dot
native.
A
Oh,
I
think
my
graphs
are
descending
yeah.
So,
as
you
can
see,
there
are
changes
in
aka
that
I'm
going
to
run
sdk.
We
are
going
to
like
actively
look
at
it
and
see
what
our
changes
are
needed
in
the
tournament
said.
It's
mostly
about
the
what
thing
allen
also
brought
last
week
about
what
constitutes
matrix
uniqueness.
A
The
vendett
went
from
the
name
along
being
the
uniqueness
thing
to
adding
the
meter,
but
now
we'll
have
to
do
more
things
and
like
including
the
kind
unit
and
description.
There
is
also
a
little
bit
more
complex
topic
about
like
callbacks.
A
So
if
you
have
like
10
instruments
with
the
same
name
and
all
other
things,
and
then
you
have
10
callbacks
like
how
do
you
deal
with
that?
So
this
does
have
some
implication
of
sdk,
so
on,
like
keeping
track
of
that
mostly
so,
I
don't
think
like
we'll
release
it
this
week
or
next
week.
A
If
we
were
to
make
some
change,
we
need
to
like
do
like
some
time
to
like
harden
it
before.
We
call
it
as
a
stable
thing
because
it's
like
little
bit
complex
from
a
usability
perspective,
even
though
the
change
might
be
like
very
straightforward
to
implement
so
I'll,
go
ahead
and
update
the
milestones
to
indicate
that
it
won't
be
happening
this
week
or
next
week
and
we
get
when
we
get
a
better
time,
we'll
update
it.
A
There
is
like
still
like
some
effort
in
respect
to
make
it
happen
sooner
because
they're
trying
to
target
this
pr
to
be
closed
in
a
week
so
yeah.
You
can
just
hope
that
this
would
happen.
Otherwise,
we'll
just
wait.
A
So
that's
the
update
on
the
release
side.
By
the
way
I
didn't
forget,
I
did
the
rc2
release.
I
could
not
use
the
scripts
rcs,
which
michael
has
added
so
I'll,
be
like
discussing
with
michael.
How
do
we
deal
with
that?
A
A
So
maybe
I'll
work
with
another
like
either
mike
or
to
try
the
new
script
next
time
and
see
if
we
can
make
it
slightly
easier
on
a
related
not
like,
we
might
want
to
start
moving
the
some
of
the
non-core
components
from
the
sdk,
because
we
have
like
too
many
projects
now
and
it's
going
to
get
more
and
more
so
I'll
see
if
I
have
like
some
time
to
clean
up
the
country
repo
to
make
it
ready
for
like
more
changes
like
we
already
have
like
some
issues
open
there,
because
contribution
guideline
is
not
updated.
A
A
So
that
should
ease
the
release
process,
because
once
one
of
the
complications
with
the
release
script
is
you
know
how
to
deal
with
a
two
set
of
things
like
one
is
a
core
component
which
has
a
version,
and
another
thing
is
another
non-core
component:
they
have
a
different
version,
so
the
script
needs
to
account
for
that
as
well,
and
sometimes
we
are
releasing
do
both
sometimes
not
so.
I
have
some
feedback.
I
will
share
with
michael
to
make
the
script
more
useful
for
the
next
release,
yeah,
so
the
let's
second
one.
A
I
think
I
did
it
so
I
was
investigating
like
a
bug
when
the
log
exporter,
which
actually
exposed
like
some
issues
where
we
are
throwing
and
handling
exceptions
from
the
exporter
and
by
design
the
sdk
is
not
catching
it.
A
So
it's
the
net
effect
is
the
app
would
just
crash,
and
that
is
like
really
against
the
entire
spec,
because
the
sdk
should
not
crash
once
it
started
successfully.
So
I
opened
this
issue.
I
basically
need
like
some
folks
to
help
validate
that
the
exporters
are
not
throwing
exceptions
from
their
export
method.
A
It
doesn't
look
like
that
right
now,
because
I
made
a
pr
just
to
fix
a
temporary
bug
fix,
but
we
should
do
like
some
try
catching
make
sure
that
none
of
the
built-in
exporters
do
throw.
A
So
if
there
are
like
any
volunteers
like
either,
you
can
speak
up
now
or
can
comment
here,
so
I
can
assign
it
just
to
load
balance,
because
I
I
have
to
actually
look
at
some
metric
stuff,
so
I
won't
be
able
to
do
this
thing.
I
think
it's
at
least
for
the
matrix
part,
the
exporter
and
otp,
which
deals
with
matrix
and
the
problem
is
that's
critical,
because
foreign,
if
it
was
broken,
it
was
broken
for
one
daughter
onwards.
A
So
it's
not
like
we
are
introducing
anything
new,
but
ideally
we
want
to
like
address
them
all
in
one
shot
so
that
we
don't
ever
crash
the
user
application.
A
As
soon
as
we
have
someone
volunteering,
we
can
start
looking
at
it.
I
don't
think
only
thing
which
would
block
the
1.2
releases
of
dlp
exporter,
one
because,
like
I
said,
eager
and
can
exist
even
before
that
prometheus,
I'm
not.
A
I
don't
think
we
will
be
releasing
the
stable
when
the
spec
becomes
stable,
because
prometheus
spec
itself
is
a
separate
thing,
independent
of
the
sdk
spec.
So
timeline
wise.
I
don't
really
have
a
specific
timeline,
but
if
you
can
do
this
for
otlp
really
soon,
that
would
be
great
and
bigger,
zipkin
and
prometheus
following
that,
so
I
would
say,
like
in
the
next
couple
of
weeks.
A
Okay,
so
I
just
like.
A
Yeah
she's,
like
relatively
new
she's,
one
of
the
new
engineers.
Probably
everyone
knows
her
by
now,
because
she's
now
joining
six
for
last,
maybe
a
couple
of
months
so
yeah,
if
ellen,
can
do
some
help,
he
could
at
least
do
the
otlp
part
and
if
there
is
anyone
else
who
can
do
the
like
other,
that
would
be
hope.
I
mean
if
he
can
like
respond
here.
That's
also
good
enough.
We
don't
need
to
like
us
right
now.
A
Right,
the
next
one,
so
we
don't
have
anyone
to
really
talk
about
this
issue,
so
I'll
share
something
in
here.
A
So
this
is
about
adding
even
counter
listener
as
a
package
in
the
controller-
and
it
looks
like
it
made
some
progress-
I
mean
I'm
the
only
one
reviewing,
so
I
think
they
are
like
little
bit
waiting
for
more
feedback,
but
I
don't
think
the
design
is
correct.
Yet
it
still
needs
some,
some
more
iteration
to
get
it
correct,
and
while
looking
at
that,
we
got
another
issue
which
finally
opened
he
did
mention
like
some
issues
here,
it's
basically
going
to
affect
this
pr.
A
The
gist
of
the
issue
is
like
this,
so
even
counter
only
has
like
a
polling
model
or
sorry,
not
a
product
model.
The
right
word
is
like
when
you
set
up
a
listener
for
even
counter
you
have
to
let
the
encounter
ap
know
what
is
the
frequency
at
which
I
want
to
be
notified
about
metrics
and
that's
something
which
you
cannot
change
afterwards,
but
the
open
elementary
matrix
model
is
not
well
aligned
with
that
strategy,
specifically
for
like,
if
you
were
to
use
prometheus
as
an
example.
A
The
only
time
we
are
supposed
to
collect
elementaries
for
amazing
instruments
is
when
this
actually
scrapes,
but
we
let's
say
we
get
a
script
request
from
chrome
excuse.
We
cannot
go
and
ask
encounters.
Hey.
Give
me
your
data
now,
because
there
is
no
such
ap
in
your
encounter.
So
what
we
are
all
we
can
do.
Is
we
like
set
up
some
time
like
let's
say
like
every
few
seconds,
even
though
prometheus
is
like
at
a
much
larger
interval
and
we
cache
that
data
and
return
it
to
prometheus.
A
If
you
are
exporting
every
10
seconds,
we'll
have
to
configure
even
counter
to
give
the
data
like
maybe
like
every
five
seconds
or
even
smaller.
A
A
So,
however,
the
reason
why
this
issue
was
brought
up
is
because
the
motivation
behind
this
pr
is
not
just
to
listen
to
any
random,
even
counters.
It's
mostly
people
are
interested
in
getting
the
runtime
information
like
there
are
some
well
known
counters,
published
by
the
dot
net
itself
about
emory
about
thread,
pool
all
those
things
the
thinking
here
is.
A
We
don't
really
need
a
even
counter
listener
to
expose
them,
because
those
this
is
the
class
which
exposes
those
are
already
available
as
a
static
callback,
and
you
can
really
call
these
things
like
tc
dot,
collection,
count.
A
Last
generation
say:
oh,
these
are
all
like
static
methods,
so
what
we
could
do
instead
is
we
can
ship
a
package
from
this
repo
which
will
set
up
a
synchronous
counter
or
a
synchronous
page,
and
that's
the
callback
we'll
just
call
the
static
method
to
obtain
the
value,
so
that
should
unblock
most
users
who
are
waiting
for
this
pr.
Primarily
because
I
mean
there
is
no
complexities
to
deal
with,
because
it's
a
straight
pulling.
A
I
mean
straight
away:
providing
a
callback
to
get
the
requested
information,
so
there
is
no
need
to
worry
about
the
even
counter
thumbing,
so
that
should
unblock
at
least
majority
of
the
customers,
because
even
in
this
pr,
the
main
motivation
was
to
get
the
specific
comments
from
runtime,
so
it
won't
solve
for
everything
at
least
for
the
runtime
counters.
It
will
so
if
you
can
just
do
a
like
another
instrumentation
library
which
can
just
provide
the
callback
which
I
mean
in
the
callback
provide
that
static
thing.
A
The
other
set
of
counters
which
people
are
mostly
asking
was
about
asp.net,
core
and
http
client
counters.
A
So
unfortunately,
that
requires
this
one
so
or
alternately
when
the
open
elementary
semantic
conventions
get
better
like
we
should
be
able
to
solve
that
in
a
different
way
like
without
worrying,
about
encounters
at
all.
So
I'll
just
share
these
comments.
Here
I
mean
I
was
hoping
to
see
like
an
alien
or
like
tony
to
join,
but
unfortunately
they
couldn't
make
it
so
just
an
update
here,
I'm
not
asking
for
all
india
to
do
this
one
yet
because
I
think
like
either
one
and
wheel
or
tony.
A
F
I'm
just
curious
those
static
methods.
I
know
some
of
them
have
been
around
for
a
while
now,
but
are
some
of
them
not
available
for
like
older.net
framework
apps.
A
D
A
Mean
if
it's
not
ported
all
the
way
back
to
like
all
dotted
questions,
then,
yes,
nothing
can
be
done.
But
how
do
we.
A
Methods
were
at
least
a
good
set
of
them
were
exposed
even
before,
like
like
much
before
even
counter
existed,
but
for
things
which
are
missing.
The
only
thing
which
we
can
do
is
ask
the
runtime
team
to
expose
it,
and
I
spoke
to
noah
about
like
from
the
front-time
team
about
this,
and
there
is
an
issue
tracking
it
in
front-time
repo.
Along
with
sorry,
let
me
find
that
issue.
First.
A
So
there
is
a
work
item
which
yeah
this
one
so
investigate
what
matrix
needs
to
be
added
to
the
runtime,
so,
basically,
like
nova,
is
figuring
out
whether
there
are
important
metrics
which
are
not
exposed.
We
are
the
static
methods,
because
if
they
are
exposed
to
static,
then
we
can
do
this
approach
and
obtain
them.
So
if
there
are
something
which
is
missing,
we
have
the
opportunity
to
add
them,
but
I
don't
think
it
will
ever
get
ported
to
the
dotnet
framework
one.
A
So
that
part,
I'm
not
very
sure,
so
we
need
to
either
leave
with
the
fact
that
it's
only
going
to
work
for
dotnet
7
or
maybe
it
will
get
back
quarter
to
at
least
the
dot
net.
Five
and
total
yeah,
I
think
dot.
Number
five
is
only
one
which
would
matter
because
total
core
3.1
will
be
end
of
life
by
end
of
this
year.
So
it
should
not
matter
yeah.
So,
like
alan,
is
there
anything
specific
which
you
are
after
or
you
are
just
curious
about
the
general
like
applicability
of
this
apis.
F
No
yeah,
I
just
was
curious
about
those
specific
api
but
yeah.
Certainly
if
there
are
new
ones
that
are
introduced,
then
yeah
they
won't
be
available
on
older
versions
yeah.
But
I
don't
know
how
much
that
matters.
G
F
A
Only
interacted
with
I
know
a
lot
of
people
are
using.
I
just
don't
know
that
breakdown
I
mean
I
don't
know
like
what
percentage
of
the
mrn.net
where's
the
dotnet
framework.
I
know
people
are
using
it's
unclear.
What
is
the
proportion,
but
I
think
one
alternate
option
which
is
probably
not
captured
here
is
if
they
are
on
like
dotnet
framework.
A
All
of
this
thing,
or
the
equivalent
of
these
are
published
as
performance
counters,
so
that
would
be
that
could
be
solved
with
yet
another
instrumentation
library
similar
to
even
counter
where
we
can
use
the
performance
counter
api
and
convert
that
into
the
new
matrix
api
yeah
right
so
but
again
like
if
there
is
enough
demand
for
I
don't
know
whether
there
is
going
to
be
enough
demand
or
not,
but
anyway
I
am
hoping
that,
like
there
could
be
like
someone
in
the
community
who
can
work
on
that
I
mean
that
performance
counter
aps,
I
think,
are
much
easier
to
just
use
compared
to
the
even
condor
one.
A
So
it
shouldn't
we
shouldn't
face
the
I
mean
sorry,
we
shouldn't
face
this
particular
issue.
We
should
be
able
to
just
add
hook.
Ask
of
counter
hey:
what
is
the
value
for
this
particular
puff
counter
right
now
and
then
just
type
it
to
the
actual
mate
matrix
api?
So,
but
I
haven't
done
the
investigation,
maybe
I
can
create
a
node
somewhere.
If
someone
has
interest
in
working
on
that
that
could
solve
the
problem
like
across
black.net
and
rotner
yeah.
I
think
the
good
start
would
be.
A
We
should
finish
this
one,
because
it
seems
like
the
most
important
one.
Most
likely
people
who
are
in
open
telemetry
are
majority
quite
likely
in
the
newer
versions,
so
at
least
they
should
benefit
and
can
use
that
feedback
and
figure
out.
What's
the
best
way
to
handle
the
dotnet
framework
thing
even
prometheus
had
like
some
support
for
maybe
like
they.
I
can
take
a
look
like
why
how
they
are
solving
it.
I
guess
they
are
using
like
something
like
this
prometheus
has
also
this
notion
of
guys.
A
So
they
are
like
coding
this
one
using
the
static
method
and
exporting
as
promoters
speeches
did
see
that
in
the
prometheus
represents,
you
might
be
able
to
liberate
something
from
there
yeah,
but
none
of
them
is
like
a
p1
like
or
any
important
issue.
It's
not
blocking
out
1.2
release,
but
these
are
like
really
nice
to
have
for
most
customers
to
like
immediately
see
some
value
from
the
metrics
supposed
to
writing
something
off
their
own
yeah.
So
that's
end
of
topic,
which
I
added
maybe
like.
A
Since
we
have
some
time
left,
we
can
look
at
some
of
the
pending
pr's
as
well.
Does
anyone
has
any
questions
to
be
discussed
now,
anything
which
you
need
help
with
or
okay?
There
is
nothing
yeah.
I
want
to
like
like
go
through
a
couple
of
vrs
and
ask
some
questions.
So
I'll
start
with
this
one
or
maybe
I'll
start
with
the
very
first
one.
A
Don't
have
the
context
on
this,
but
it
looks
like
we
are
sitting.
We
are
fixing
some
well-known
bug,
so
probably
it
should
be
like
straight
forward.
Like
michael,
do
you
know
like
anything
like
blocking
this,
or
is
it
just
waiting
for
reviews
from
us.
F
I
opened
the
issue
that
this
fixes
just.
A
F
Few
days
ago,
basically,
I
just
noticed
that
the
default
port
that
we
use
when
using
http
protobuf
was
not
right.
We
shouldn't
have
been
using
4317.
We
should
be
using
43.18,
so
it's
a
minor
thing
I
haven't.
I
just
saw
this
pr
right
before
this
meeting.
So
I
haven't
haven't
had
a
chance
to
look
over
myself,
but
okay,
it
should
be
straightforward.
A
A
A
Recently,
yeah,
I
think
I'll
just
put
it
as
a
minus
one,
because
I
want
to
let
make
sure
like
we
won't
merge
anything
like
which
can
affect
the
stability,
especially
the
matrix
one.
I
mean
if
it's
fixing
something,
then
it's
fine,
but
it's
a
major
feature.
I
would
just
wait
for
the
one
to
go
out
then
we'll
have
like
enough
time
to
get
feedback
and
yeah
for
this
one.
I
want
to
ask
this
person
is
not
in
the
call,
so
he
was
trying
to
add
a
new
example
for
asp.net
core.
A
I
think
I
I
left
some
comments.
I
don't
know
whether
anyone
else
understands
so.
Basically,
I'm
asking
like
what
should
be
our
policy
for
maintaining
examples.
A
So
right
now
we
have
quite
large
grpc
sps.net
code
and
microservice
even
uses
the
worker
service
one.
So
we
indirectly
cover
all
the
popular
templates.
A
So
now
the
next
question
is:
should
we
explore
this
by
adding
it
per
runtime
version?
This
is
mostly
significant
for
asp.net
core,
because
speed.net
like
it's
not
changing,
I
don't
think
it
will
ever
change,
so
we
should
be
like
relatively
safe
here,
but
it's
been
a
core
like
every
couple
of
years.
There
is
a
change
in
the
templates
and
the
way
host
is
set
up
the
way
dot.
A
Net
6
is
like
really
drastic
change,
so
I'm
asking
everyone's
opinion
like
do
you
think
we
should
maintain
like
examples
like
sp
net,
core
3.1
sp946
and
when
seven
daughter
comes
it's
me
at
core
7:
do
we
think
that's
needed
or
yes,.
G
I
would
say
for
supported
ones
if
you
want
to
want
to
cut
down
the
the
noise,
maybe,
but
I
I
run
into
this
problem,
a
lot
where
I
work
where
I
have
a
hybrid
enterprise.
I
got
three
one
six
and
then
we
had
to
take
the
two
ones
and
make
them
three
ones
and,
and
then
the
delta
between
the
two
wasn't
always
discernible
amongst
the
doves.
Until
we
just
slide
out
to
give
them
a
reference
implementation,
then
we
don't
have
to
like
explain
as
much.
G
There
doesn't
have
to
be
a
terribly.
We
don't
be
very
verbose
in
some
of
our
explanations.
We
can
just
say:
look
look
here.
A
I
mean
I
totally
get
that
part,
because
one
other
extreme
end,
I
was
like
don't
provide
any
like
workload.
Specific
example
like
we
only
provide
controller
example
and
we
have
users
to
figure
it
out,
but
that
has
been
a
big
pain
because
from
the
very
first
week
of
I
joined
this
guy
people
were
like
complaining
about
that.
A
So
I
think
alan
was
the
one
who
added
like
most
of
the
other
examples
where
we
show
like
how
to
do
the
complex
thing
I
mean
technically,
we
don't
need
to,
but
based
on
feedback
looks
like
there
is
a
good
demo
for
that.
So
I
have
a
slightly
tweaked
version
of
that
proposal,
which
is
we
will
maintain
only
the
most
recent
one.
A
So
as
of
today,
it's
not
six,
but
if
someone
is
interested
in
dotnet
3.1
they're
not
going
to,
I
mean
we
just
delete
this,
but
we'll
put
a
readme
saying
that
if
you
are
looking
for
sp.net
3.1
example,
look
here
and
like
pin
that
thing
like
this
is
a
there
is
no
way
this
link
would
ever
go
bad
because
it's
pointing
to
a
specific
tag,
and
when
next
year
comes
when
we
ship
or
when
dotnet
team
ships
dotnet
seven.
A
What
we'll
do
is
we'll
do
the
same
thing
to
the
asp.net
six
example:
we'll
update
it
to
be
dotnet
seven
and
put
a
comment
saying
that
hey
if
you're
looking
for
net
six,
it
is
now
residing
in
some
link
which
should
never
die.
A
So
if
people
are
okay
with
that
approach
or
like
any
conference
with
that
of
course,
because
my
main
goal
is
to
avoid
maintaining
so
much
code
because
we
would
reach
a
point
where,
like
this,
would
be
it's
already
showing
up
in
my
visual
studio
and
my
visual
studio
cannot
load
so
many
solutions
right,
super
slow,
but
more
than
that,
I'm
concerned
with
like,
if
you
have
more
code
to
maintain
like
it's
generally
a
bad
thing.
Something
is
changing.
A
We
have
to
go
and
update
so
many
places
and
these
libraries
do
have
like
external
dependencies.
We
have
to
worry
about
the
security
things,
so
whenever
it
happens,
we
have
to
make
sure
like
we
don't
do
it.
Otherwise,
github
starts
flagging
us
for
using
some.
A
Has
non-vulnerability
so
I
would
prefer
to
keep
it
the
smallest
any
thoughts
on
the
approach
which
I
just
described,
which
is
basically
like.
We
only.
A
The
most
recent
one
and
whenever
we
are
adding
a
newer
version
today,
we
are
adding.6.
We
just
note
the
older
one
but
forbidden
link,
so
people
are
not
completely
lost.
Maybe
you
repeat
this:
when
dotnet
7
comes,
we
dot
net
six
one
and
in
the
dot
net
seven
tree,
maybe
simply
say
that
hey.
If
you
are
in
document
six,
go
and
read
this
any
thoughts.
G
Just
just
to
clarify,
I
understand
in
your
examples
of
repo
or
samples
are
we
saying
you
only
keep
the
latest
version,
always
in
the
folders
yeah,
so.
A
Were
accepted,
what
you
would
see
here
is
always
the
latest
at
that
time.
So
right
it
will
be
dotnet
6,
but
there
will
be
a
readme
added
here.
I
mean
it's
not
there,
but
it
will
be
added
and
it
says
if
you
are
on
dotnet
code,
3.1
click
here
and
that
will
take
you
to
the
old
example
and
when
dot
net
seven
ships
end
of
this
year.
We'll
update
this
example
to
be
only.7,
but
we'll
modify
that
readme
to
0.2.
A
If
you're
in
dot
net
6
go
and
look
at
the
old
example
here,
and
it
should
work
because
of
the
commit
name,
we
don't
need
to
like
link
to
the
main
branch
already
we
can
do
a
specific
commit,
so
that
ensures
that
that
dope
will
always
be
accurate
forever.
G
I
mean
I
can
say
yes,
I
suppose
that
could
work.
I
think
yeah,
I
don't
depends
on
the
size
and
we're
growth
here.
I
just
see
like
someone
coming
back
and
saying,
at
least
for
the
supported
versions.
Maybe
that
would
make
more
sense
because
there's
a
time
gap
because,
like
we're
even
a
unique
well,
this
isn't
relevant
to
everybody
here
so
I'll
just
leave
it
leave
it.
There.
G
Move
forward
with
this
the
latest
implementation
we
could
and
then
have
a
link
there,
like
you,
said,
that's
a
secondary
place
winner.
I
guess
it's
just
sometimes
organizations
are
bound
by
security
like
like
we're,
we're
not
allowed
to
put
dot
net
six
in
prod,
because
our
security
vendor
that
this
source
code
scanning
isn't
up
to
date.
Yet,
okay,
so
we're
still
stuck
on
three
one
for
production
workloads
yeah.
I.
A
G
C
G
A
H
Oh
sorry,
go
ahead
mike
I'm
just
saying
I
like
the
idea
of
just
always
having
latest
and
then
just
adding
links
to
the
previous
one,
okay,
yeah
and
alain
you.
You
are
saying
something.
F
Yeah,
I
agree
with
that
as
well.
I
think
I
think
that
idea
with
the
links
to
the
old
ones
I
had.
F
That
it
may
be
in
addition
to
to
that
idea,
really
the
biggest
change,
I
think
from
you
know
three
one
to
five
to
six
is
all
within.
Like
you
know
the
startup.cs
class,
or
now
everything
in
dotnet6
is
all
done
in
program
cs
from
like
the
template.
F
This
is.
This
is
best
documented
for
that
package
like
if
we
in
that
read
me
of
that
package,
we
just
had
snippets
of
examples
for
the
various
runtime
versions.
A
Yeah,
in
a
way
like
I
agree
with
that
part,
but
this
is
related
to
what
I
started
with
it's
basically
like
we
could
use
that
approach
where
the
extensions.hosting
package
talks
about.
How
do
you
deal
within
like
how
do
you
attach
open
telemetry
into
da
in
the
web
host?
A
But
I
think
most
people
expect
like
runnable
examples,
so
they
just
they
get
a
example.
And
personally
I
also
like
it,
because
whenever
we
see
someone
like
reporting
bugs,
we
can
like
immediately
ask
some:
can
you
look
at
this
sample
and
make
the
necessary
change?
So
it's
like
relatively
easy.
If
you
have
like
runnable
examples,
so
that's
my
only
argument
for
keeping
it.
Otherwise,
we
don't
even
need
these
examples.
Then
we
can
like
completely
avoid
this.
A
This
is
like
very
specific
to
workload
like
this
is
how
you
do
things
in
asp.net
core,
but
you
don't
really
have
to
use
this.
You
can
always
use
the
you
know
mda
version,
and
we
can
just
document
it,
but
practically.
I
think
this
is
super
useful
for
customers,
a
lot
of
them
we're
asking
for
like
around
example,
so
yeah
another
option.
A
I
think,
like
alan
also
mentioned
that,
like
do
the
if
thing
like,
keep
the
same
file
but
do
an
if
and
conditionally
refer
to
target
framework
like
do
the
defaults
thing,
but
that
was
also
very
complex
thing.
A
I
have
one
specific
example
where
it's
hard
to
find
now,
but
maybe
I
can
see
so
there
is
an
example
which
we
had
for
law,
so
this
was
very
complex
when
he
had
that
like
if
he
felt
like
really
complex,
because
the
way
you
do
longing
change
between
dot
knight,
two
and
three,
so
it
was
kind
of
difficult
for
folks
to
really
follow
it
like.
What
do
we
mean
by
this?
Obviously
so
now
it's
clean
like
we
don't
have
that.
A
A
So
before
2.1
the
code
looked
like
really
ugly,
like
even
name
space,
everything
was
ugly.
So
now
we
get
rid
of
that
change.
So
it's
like
very
neat,
so
I
think
that
cleanliness,
cleanliness
is
like
very
easy,
because
these
are
meant
to
be
like
getting
started
right,
so
it
should
make
the
life
of
things
like
very
easy.
F
I
think
one
step
I
mean
again,
I'm
not
I'm
not
advocating
for
this,
but
like
one
thing
that
would
actually
have
simplified.
That
example
that
you
just
had
up
there,
the
old
one
from
the
logging
thing
is:
maybe
have
it
a
totally
separate
file
yeah
for
every
single
one.
That's
that
has
the.
If
def's
around
it.
A
Correct
yeah:
I
think
that
that
would
also
work
yeah
yeah,
okay,
at
least
we
have
some
feedback,
so
at
least
I
can
respond
to
this
here.
Okay,
let
this
be
a
thing.
One
of
the
biggest
change
in
the
last
release
was
we
had
a
fairly
big
purpose,
and
so
this
is
just
following
up
to
that.
So
I
don't
think
we
need
to
discuss
anything
unless,
of
course,
do
you
want
to
ask
anything
or
you
just
like
just
wait
for
someone
to
review
it.
A
Yeah,
I
think
it
will
be
discussed.
I
think
this
is
still
half
when
I
checked
last
time,
so
in
team
do
you
want
to?
I
mean
share
anything
with
about
this
api,
then
you're,
trying
to
add
log
record
as
setters.
So
currently
it's
like
readable
norwegian.
E
Yeah,
so
this
is
to
block
a
scenario
that
users
want
to
write
their
custom
exporter
and
then
so
the
use
case
you
can
scroll
down
to
the
test
case.
So
basically,
the
user
creates
their
custom
exporter
and,
in
the
lock
record,
there's
something.
For
example,
they
don't
wanted
to
like
export,
and
then
they
can
use
this
editor
to
like
update
the
state
state
values
and
the
formatted
message.
Okay,.
A
So
it's
making
us
consistent
with
activity
this
activity.
We
can
write
an
activity,
processor
and
call
like
activity,
dot,
set
tag
and
override
or
delete
anything
which
I
think
I
mean
is
the
user
thing
is
not
safe
to
be
exported.
So
this
is
basically
an
attempt
to
add
the
same
feature
to
log
record
as
well.
Okay
and
yes,
there
is
no
need
of
spec
or
anything,
because
this
is
purely
like.
I
logger
thing,
so
we
should
be
able
to
do.
I
I
had
a
question
about
this
vr
and,
like
I
think,
there's
another
pr
which
is
facing
the
same
issue
so
like
since
are
allowing
like
users
to
set
the
state
and
other
state
values
and
such
now
that
the
api
compat
com
failed,
saying
that
there
is
a
compiler
generated
attribute
that
is
present
in
the
contract,
but
missing
an
implementation,
and
I
think
that's
because
like
because
previously
before
making
it
a
privates
and
having
a
public
set
method,
this
was
so.
I
The
change
was
basically
from
making
an
auto
property
to
one
with
implementation
and
there's
another
one
another
pr
right
now,
which
I
think
is
facing
the
similar
issue.
So
yeah
I
spoke
to
unting
and
I
think
I
suggested
her
that
we
can
just
make
it
to
like
satisfy
api
combats
needs.
We
can
just.
Is
it
like
a
bug,
because
this
doesn't
seem.
I
You
know-
actually,
I
think,
maybe
some
just
the
very
first,
because
that
only
has
changes
to
the
public
api
docs.
So
I
guess
something
that
happens.
Let's.
A
Do
this
thing
I
think
we
can
like
walk
a
little
bit
offline
on
this
one
and
come
back
like
if
the
issue
is
with
like
tooling,
then
we
can
like
override
it.
It's
like
superseded,
but
if
it
is
like
an
actual
breaking
change,
then
we
need
to
like
make
it
in
such
a.
I
Right
now
I
see
this
pr
doesn't
look
yeah.
This
is
not.
This
is
not
a
breaking
change.
An
api
compliant
won't
complain
about
this,
but
if
we
actually
had
bodies
forget
and
said,
then
it
will
complain
because
then
it
then
it's
no
more
an
auto
implemented
property
and
it
becomes
a
like
manual
manually
generated
implementation.
I
So
it's
a
very
strict
check,
which
complains
about
compiler
generated
attribute
not
being
present
in
the
new
change.
Yeah.
H
A
Yeah
so
like
there
are
two
aspects
to
it
like
one
is:
we
were
using
this
ap
combat,
but
they
changed
the
way
you
are
supposed
to
use
the
api
compact
in
a
different
way.
We
haven't
like
really
adopted
that
method,
yet
so
the
best
thing
we
can
do
right
now
is
just
update
it
or
I
don't
know.
I
Yeah,
I
think
it
was.
I
did
start
on
that
and
then
bev
hess
also
like
was
the
one
who
like
set
up
all
the
build
tasks
and
stuff.
A
I
A
Compact
that
there
is
a
different
way
to
run
ap
compact,
so
dot
net
six
right,
so
is
that
still
considered
like
a
breaking
change
in
that
tool?.
H
A
A
A
Yeah
we
do
have
the
ability
to
override
things.
I
think
like
already
added
like
some
for
previous.
I
think
we
should
generally
on
go
to
like
this
new
mechanism,
because
this
is
going
to
be
like
little
more
tricky
because
it's
going
to
fly
a
lot
more
issues,
especially
since
we
have
different
public
apis
for
different
targets.
So
we
are
going
to
get
a
lot
more
flags
and
then
we
have
to
individually
to
solve
them
or
like
overwrite
it,
but
at
least
like
if
we
are
making
a
decision.
A
Like
you
mentioned
that
this
is
some
that
pr
is
something
which
we
expect
to
be
part
of
the
1.2.
Really
so,
let's
see
if
the
new
tooling
fixes
it
or
let's
decide
to
explicitly
overhead
it,
but
like
have
a
paper
trail
saying
like
why
we
are
doing
so,
because
if
someone
does
seem
affected,
we
can
like
at
least
there
is
an
issue
which
is
saying
why
we
decided
to
do
that.
I
Yeah
all
there
is
like
this
other
like
work
around
where
you
just
add
a
private
set,
and
then
you
have
another
public
method
that
will
basically
set
the
property.
A
That's
the
one
which
you
did
in
the
for
you
and
things.
We
are
yeah,
it's
right,
yeah,
the
logo
yeah.
Even
that
I
mean,
if
that
can
satisfy
the
tool
then
and
without
affecting
the
functionality.
Then,
let's
just
do
that
as
well,
so
we
don't
need
to
ever
worry
about
having
to
override
what
the
tool
did.
A
Yeah.
Okay,
so
can
you
like?
Because
can
you
add
that
comment
to
the
pr
where
this
one
this
is
where
it's
facing
and
see
if
it
helps,
if
not,
we
can
discuss
like
what's
the
best
way
to
unblock
so,
if
you
are
choosing
to
supersede,
then
let's
make
it
an
explicit
decision
and
like
backed
by
some
issue
or
some
eating
nuts,
I'm
not
yet
sure
whether
that
food
is
doing
the
right
thing,
at
least
that's
truly
our
gate
to
make
sure
we
are
not
breaking
it.
I
Yeah,
so
I
think
the
tool
is
like
doing
the
right
thing.
Like
I
mean
I
feel
it's
just
up
to
us.
If
we
don't
want
to
consider
it
a
break
and
change
because
functionally,
I
don't
think
anything
is
going
to
break
it's
just
that
it's
a
very
strict
check
to
like
even
match
the
like
compiler
generated
code
should
not
be
so
like.
A
I
I
A
I
think
there
was
one
issue:
maybe
I
can
chat
with
you
offline
and
figure
that
out
so
there
was
some
requirement
for
us
to
overwrite
something.
A
Okay,
let's
see
I
mean
how
to
override
it,
because
we
cannot
like
let
it
fail
in
every
because
if
it
fails
in
this
year-
and
if
you
don't
do
it
action,
it
will
keep
failing.
So
it
won't
catch
the
next
rear
issue.
So
we
want
it
to
be
green
before
we
merge.
A
So
we
need
to
like
figure
out
how
to
like
write
that
overriding
thing.
You
might
regret
if
we
go
back
in
history,
but
let's
do
that
offline.
B
Okay,
yeah,
okay,
let
me
see
if
I
can
open.
F
Yeah
sure
yeah
sure
yeah.
I
would
be
interested
in
talking
about
this,
so
I'm
proposing
that
we
add
an
open,
telemetry
proto
project
that
effectively
just
generates
the
code
it's
easily
consumed.
You
know
I've
mentioned.
I
think
I
mentioned
in
one
of
the
comments
like
I.
I
actually
have
done
some
internal
projects
where
I
just
need
to
interact
with
protos
and
I
feel.
G
F
That
may
be
a
use
case,
that's
valuable.
I
know
that
other
language
communities
have
this
or
are
doing
this
and
they
some
of
them,
have
separate
repositories.
Some
of
them
have
them
in
the
main
repository
like
I'm
doing
in
this
pr.
F
My
original
thought
was
that
you
know
like
the
open,
telemetry
protocol
exporter
package
would
reference
this,
but
I'm
not
doing
that
in
this
pr.
I
talked
with
mike
a
little
bit
offline
about
this
and
I
he
raises
a
pretty
valid
concern
and
that,
like,
if
somebody
were
to
reference
the
open,
telemetry
exporter
package,
then
you
know
they'd
get
this
downstream
dependency,
which
would.
G
A
Okay
and
like
would
we
be
publishing
this
as
a
nuget
right,
we
would
publish
this
as
saying
you
get
like
into
for
anyone
else
who
wants
to
consume
it.
F
Correct
yeah,
and
then
my
thought
was
that
if
people
are
interested,
I
don't
necessarily
have
a
burning
desire
to
do
it
retroactively,
but,
like
I,
it
also
doesn't
hurt.
I
was
thinking
about
just
doing
it
from
like
the
first
release,
which
happens
to
be
o30
like
that
was
the
first
release
of
the
open
telemetry
protocol.
A
But
this
won't
be
like
questioned,
does
a
stable
thing,
so
it
will
be
released.
As
a
point
to
your
question
is
that
the
intention
yeah
and
0.4.5,
like
whatever,
as
long
as
it's,
not
stable?
It's
fine,
because
we
don't
know
whether
it
was
came
back.
Okay,
yeah
I
mean
we
don't
need
to
do
it
right
away,
but
if
you
want,
we
can
do
it
as
long
as
it's
not
stable
yeah.
It
should
be
fine.
F
A
I
was
also
looking
at
like
how
do
we
handle
like
yet
another
question
to
maintaining
the
main
triple,
so
I
mean
it's
definitely
possible
it's
just
that.
We
need
to
be
aware
of
the
release
process.
Now
that
we
have
another
thing
I
mean
even
without
this
pr.
We
have
that
issue
because
prometheus
will
quite
likely
lag
the
sdk,
so
we'll
have
to
do
some
separate
versioning
for
prometheus
exporter
anyway,
but
anyway,
okay,
this
should
be
good,
I'll,
take
a
look
yeah
so
before
we
go
to
the
next
year.
A
Let's
see
if
we
can
quickly
reach
some
conclusion,
I
mean
once
again,
I
haven't
fully
finished
my
time
with
this
thing,
but
I
get
the
feeling
that
we
should
unblock
ourselves
first
by
taking
this
approach,
which
alan
has
done
basically
just
fix
the
issue
for
better
creator
in
the
sense
that
metric
leader
options
should
not
be,
I
mean
anything
which
controls
the
pipeline
in
this
case,
like
the
radar
should
be
like
a
separate
thing
from
the
exporters,
and
we
still
have
the
problem
of
existing
thing
like
tracing
exporters,
have
that
problem,
but
that
is
something
which
already
exists
in
1.0,
so
we
can
come
back
and
solve
it
in
the
future
after
1.2.
A
So
at
that
time,
I
guess,
if
you
want
to
choose
the
builder
approach,
we
could
just
taking
forever
to
go
yeah.
So
at
that
time
I
think
still
loading
yeah.
So
when
we
after
we
do
1.2,
and
if
we
choose
to
do
a
builder
approach,
we
can
do
it
consistently
across
all
raw
signals.
A
Like
logging
activity,
I
mean
span
and
metrics
like
mike.
Do
you
have
any
like
concerns
or
any
comments
on
that?
Basically,
I'm
just
saying:
let's
just
immediately
solve
the
immediate
problem
which
is
for
metrics,
we
haven't
been
stable,
so
we
can
afford
to
break
the
api
right
now.
Let's
just
solve
it
and
do
it
the
correct
way,
which
is
export,
relay
controls,
exporter
things
and
the
pipeline.
Things
should
be
a
separate
one,
so
there
is
no
need
of
marking
anything
else
replicated
or
anything
in
here.
A
A
We
could
be
duplicating
all
the
order
options
or
we
could
keep
it
until
we
do
two
dot
star,
primarily
because,
like
we
just
want
to
like
okay,
very
close
to
stable,
so
we
can
restrict
the
number
of
new
things
which
we
are
exposing.
So
we
can
just
tackle
the
immediate
problem,
not
exposing
anything.
H
A
Will
be
like
this,
so
you
need
a
api.
All
the
extension
method
on
meter
builder
would
take.
I
mean
if
the
providers
choose
to
maybe
if
the
exporters,
just
if
the
exporter
doesn't
allow
user
to
properly,
then
they
don't
need
to
they
can
like
choose.
Okay,
I
already
support
accumulated
and
I
only
support
full
model.
Then
there
is
no
need
of
even
exposing
this
one.
You
can
just
take
the
exporter
options
or
if
the
exporters
say
that
okay,
I
can
work
with
cumulative,
I
can
work
with
delta.
A
I
can
work
with
all
push
and
pull
mode.
Then
I'll
expose
a
new
thing
which
controls
the
pipeline.
I
will
be
attached
to
and
based
on
that
pipeline,
I
will
decide
whether
I
should
be
paired
with
like
cumulative
or
delta
or
what
is
supporting
mode.
So
it
will
be
basically
like
separating
this
thing
into
two
and
there
is
no
breaking
change
for
tracing.
We
are
not
touching
tracing,
it
would
remain
a
known
issue
for
tracing
for
now
and
we
can
solve
it
separately,
so
yeah.
I
think
this.
This
should.
A
If
they
leave
it
off,
will
we
just
assume
report
yeah?
If
the
user
doesn't
probably,
then
we
can
pick
the
default
because
for
otlp
I
think
there
is
a
default
specified
by
the
specification
I
mean
for
progress.
There
will
be
something
for
the
specification
for
console
like
we
have
to
make
a
decision
like
what
should
we
think
this
was
discussed
previously
also,
so
we
have
to
decide
what
should
be
the
default.
A
There
were
like
some
argument.
Like
should
be,
should
it
be
periodic,
or
should
it
be
full
based?
We
can
decide
that
separately.
There
were
like
some
previous
discussions
about
what
would
be.
The
default
can
probably
make
the
decision
independently,
but
yeah
I
mean
if
the
user
doesn't
care
anything
or
they
don't
want
to
really
know
about
this.
All
the
specifies
add
my
exporter,
and
these
are
the
settings
which
affect
this
exporter,
like
which
endpoint
I
should
export
to
things
like
that.
It
doesn't.
A
The
user
doesn't
need
to
know
how
the
pipelining
setup,
the
exporter
extension
method,
automatically
pick
the
right
default.
F
F
A
It's
really
up
to
the
exporter
to
decide
if
they
ever
want
to
expose
this
thing,
because,
for
example
like
if
I'm
writing
an
exporter,
I
know
that
I
can
only
take
delta
or
cumulative
and
I
can
only
be
periodic.
Then
there.
A
My
cut
says
there
is
nothing
which
can
be
because
prometheus
only
accepts
cumulative.
We
cannot
change
that
fact
and
from
this
only
works
in
periodic,
I'm
sorry
the
what
was
the
name
again,
if
not
periodic
forget
the
name.
I
forget
whatever
that
thing.
So
in
that
case
and.
A
To
expose
anything,
it
only
needs
to
know
like
which
sport
it's
supposed
to
listen.
That's
what
do
you
think
we
should
expose.
F
F
I
I
tooled
in
a
way
to
like
allow
for
the
otlp
exporter.
You
know
or
like
one
of
the
other
exporters,
to
have
a
different
default.
It's
a
little
goofy,
but
it
works.
I
used
another
pattern
right
in
this
file
like
this
unspecified
metric
reader
type
unspecified
up
above
there
that's
a
pattern
that
we
use
for
something
else.
I
forget
what.
A
We
use
it
like
somewhere
else
yeah.
I
remember
like
when
you
set
up
the
metric
radar.
You
can
only
specify
it
if
it's
unspecified
so
that
pattern
you
already
have
but,
like
I
I
mean,
let's
solve
those
small
things
within
the
pr,
but
I
just
want
to
get
like
some
comments
from
mike.
Also
like.
Is
it
acceptable
to
proceed
with
this
for
now
in
the
1.2
time
frame
and
revisit
this
pattern
when
we
turn
with
1.2?
A
So
I
also
want
to
like
mention
something
else
about
post
1.2,
because
we
have
this
extension
start
hosting
package,
which
at
least
I
had
like
two,
maybe
three
pr's
michael
had
so
we
never
finished
that
so
maybe
after
doing
1.2,
we
should
come
back
to
the
future
about
the
extension
spot
hosting
package,
and
we
should
solve
that,
and
it
looks
to
me
like
very
much
intertwined,
like
some
at
least
related,
not
if
not
really
determine
the
builder
pattern
because
most
of
the
examples,
everything
which
is
using
the
extension
throat
hosting
package
not
like
strictly
tied,
but
I
think
we
should
solve
that
problem
anyway,
because
most
most
people
I
know
are
using
that
back.
A
H
And
then
I
like
that
it
at
least
shares
the
metric
leader
options
from
sdk,
so
all
the
exporters
can
utilize
it
yeah.
That
was
that.
A
Original
way,
I
think
we
could
still
do
like
some
other
option
because
I
don't
know
like
the
http
client
part
is
going
to
be
how
we
are
going
to
share
that,
because
I
think
every
exporter
will
have
their
own
way
of
dealing
with
this
http,
but
probably
like
that's
a
relatively
less
concerning
issue,
we
should
be
able
to
solve
it.
A
With
this
thing
we
can
do
next
procedure.
What's
the
challenge
yeah
I
mean
so
in
this
approach,
every
exporter,
which
needs
to
be
with
http
client.
It
has
to
deal
with
that
in
their
extension
methods.
Thing,
like
you
mentioned
in
the
bit
builder
pattern
like
we
don't
really
need.
What
did
I
say
every
exporter
doesn't
need
to
do.
How
do
they?
How
how
did
they
get
the
http
line,
because
it's
handled
in
like
a
base
class
yeah?
A
So
there
is
some
niceness
which
we
lose
the
thing
we
can
leave
with
that
maybe
like
we
can
extract
some
like
helper
methods,
so
we
can
achieve
some
code
sharing.
But
I
let
like
alan
work
on
that.
So
then
you
mentioned
that
there
should
be
like
a
way
to
still
reuse
things,
but
it's
not
a
big
concern
if
you
are
like
having
not
reusing
the
code
for
now
it's
for
me,
it's
like
a
nice
to
have
so
you
should
be
able
to
tackle
that.
A
There
was
another
pr
which
I
discussed
like
a
couple
of
weeks
back
about
the
status.
I
don't
have
an
update
on
that,
because
I'm
still
mostly
spending
time
on
my
trick.
So,
given
that
we'll
have
time
I'll
come
back
and
post
my
proposals
in
the
activity,
dot
status-
migrations
there
is,
there
are
again
like
there.
There
is
some
approach
we
have
to
pick
like.
Should
we
do
it
in
the
stream
sdk,
or
should
we
let
individual
exporters
handle
it?
A
I
shared
my
preference
with
my
class
feed
like
I
prefer
it
make
that
a
problem
for
individual
exporters.
It's
not
very
neat,
but
at
least
the
user
doesn't
need
to
know
anything.
It
just
works.
They
just
update
they,
I
mean
all
the
exporters
which
we
ship
from
this
repo.
It
just
works
for
people
who
are
writing
their
own
exporters.
A
We'll
have
to
document
that
in
the
the
place
where
we
talk
about
writing
your
own
exporter,
so
I'll
send
like
some
peers
in
that
direction,
because
these
dogs
are
now
outdated
because
these
are
like
really
try
to
tracing.
There
are
like
some
dog
updates
which
I'll
be
sending
over
time
before
1.2.