►
From YouTube: 2021-07-20 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
B
B
B
Okay,
I
think
we
can
start
now.
So
if
you
are
in
the
call,
please
make
sure
you
write
your
name
in
the
in
this
list.
I
have
added
like
three
topics
for
the
agenda.
So,
let's
see,
if
anyone
else
have
any
questions
before
we
go
into
these
items,
if
not,
I
can
start
with
the
items
in
the
agenda
all
right.
So
let
me
open
these
two
issue.
B
I
probably
ping,
like
some
of
you
offline,
to
get
some
feedback
on
this,
so
basically
the
diagnostic
source,
6.0
version,
like
preview
6
onwards,
the
library
did
support
it-
did
support
like
anything
including.net
452
before,
but
starting
with
preview
6.
They
are
cutting
support
for
net
452
and
post
6,
even
though
these
frameworks
are
still
officially
supported
like
for
another
few
more
months.
B
So
the
team
made
a
conscious
decision
that,
like
it's
hardly
four
months
before
these
are
going
after
support,
so
they
decided
they
are
dropping
support
for
anything
older
than
at
four
six,
one
which
kind
of
puts
us
in
a
sport,
because
we
have
a
hard
dependency
on
diagnostic
source
6.0.
So
now
we
are
equally
forced
to
cut
support.
There
is
no
way
around
it,
but
one
of
the
reason
why
I
want
like
to
discuss
this
thing
is
technically.
B
If
you
are
cutting
support
for
a
framework
without
bumping
the
major
version,
it's
a
breaking
change
so,
ideally
like
in
the
strict
sense
of
somewhere.
We
should
be
like
releasing
2.0
in
number
when
we
take
the
new
version
of
diagnostic
source,
however,
like
that
may
have
its
own
issues,
because
we
just
released
that
1.0
and
if
we
release
2.0
people
might
get
scary
like.
B
Why
are
we
like
already
having
2.0,
and
there
is
like
explicit,
ask
from
the
spec
also
like
we
do
not
have
any
plan
to
release
2.0,
it's
very
clear
in
the
spec
and
spec
also
expects
each
language
libraries
to
bump
their
major
version.
If
there
is
any
breaking
change.
So,
however,
we'll
need
to
get
an
exception,
probably
like
an
informal
thing,
but
I
will
just
make
sure
like
this
is
something
which
we
want
to
get
sign
off
from
all
the
maintainers
and
approvers
before
we
release
this.
B
B
So
my
ask
is
like
go
to
this
issue
and
actually
make
a
slight
modification
to
the
text
here
to
say
that
if
you
are
a
maintainer
or
approver,
please
thumbs
up
to
this
issue
or
plus
one
to
this
issue,
or
if
you
have
any
concern.
Please
leave
a
comment
so
that
this
will
become
a
documented
decision
that
we
are
like
not
like
accidentally
cutting
support.
We
are
cutting
support
intentionally,
and
this
is
what
I
wrote
as
a
reason.
B
So
I
let
everyone
just
read
through
it,
so
basically
cutting
only
net
four
five,
two
and
four
six,
and
also
like
the
second
issue,
is
about
cutting
support
for
net
core
2.1.
All
these
frameworks
are
unsupported
from
the
dot
net
itself.
So
only
customers
who
will
be
impacted
are
those
who
are
still
using
the
unsupported
one
or
they
are
using
a
version
which
is
going
to
be
unsupported
in
like
three
or
four
months
since
our
release
date.
So
so
it
probably
doesn't
make
sense
for
us
to
keep
supporting
them.
B
So
this
is
what
I
have
put
here.
So
please
look
at
it.
I'll,
probably
copy
this
thing
into
this
issue
and
ask,
and
maybe
like
ping,
each
and
every
maintainer
and
approver
to
get
a
like
consensus
on
that,
because
if
there
are
concerns
we
need
to
like
decide.
Okay,
should
we
do
like
2.0,
because
if
we
do
2.0,
then
there
is
no
issue,
because
we
are
still
complaining
with
somewhere.
But
then
we
have
to
explain
like
why
are
we
doing
2.0
within
few
months
of
one
or
two?
B
B
B
Okay
and
the
actual
work
is
still
progressing
and
with
the
assumptions
that
we
will
be
proceeding,
I
already
started
doing
the
prs.
It
was
a
bit
tricky
to
get
it
done
in
one
shot,
so
I
did
it
from
the
leaf
and
then
I
just
finished
the
ap
and
sdk
today,
so
it
should
be
like
done
like
by
end
of
day
or
by
tomorrow.
B
Okay,
so
that's
just
the
thing
and
I
have
an
action
item
to
follow
up
with
each
internal
and
approver
to
make
sure
there
are
no
strong
objections
to
this.
Professor
second
is
just
following
up
on
what
we
discussed
as
the
first
alpha
release
for
metric,
so
we
decided
and
defined
what
is
a
minimum
bar
and
we
created
a
milestone
here,
based
on
what
we
discussed
and
most
of
the
things
or
maybe
like
all
of
the
things
which
we
discussed
are
already
met.
B
So
we
decided
we
will
only
support
a
single
instrument,
counter
the
synchronous
version
and
we
have
the
ability
to
do
it.
A
some
aggregation
like
some,
like
not
anything
else,
and
we
did
not
explicitly
mention
about
the
proline
push,
but
we
do
have
it
now
and
we
have
the
console
exporter.
B
We
have
the
otlp
exporter
and
in
fact
we
have
a
prometheus
outside
in
explicitly
listed
because
it's
like
really
really
basic.
It
supports
a
single
pipeline
and
allen
added
one
instrumentation
for
spin
at
code.
So
I
think
this
is
good
enough
for
our
first
release.
It's
not
packing
in
features,
so
it's
called
alpha
one
and
it
can
be
used
for
end-to-end
validation,
because
we
have
instrumentation
from
sp
net
core
and
we
have
otlp
which
can
be
used
by
a
customer.
They
just
enable
this
instrumentation
without
emitting
any
custom
metrics.
B
They
should
be
able
to
see
the
matrix
automatically
showing
it.
So
unless
there
are
objections,
I
will
proceed
to
do
the
first
release
and
you
have
to
figure
out
the
version
x,
one
dot.
You
cannot
do
the
same
name
as
alpha
one.
I
think,
because
we
were
already
releasing
that
into
our
magic
field,
because
the
mag
it
is
like
automatically
generated
on
a
daily
basis,
yeah,
I
think
alpha
one
would
be
already
okay,
it's
alpha
dot,
one
yeah,
okay,
I'll
find
a
different
name
which
doesn't
conflict
and
do
the
relay.
B
So
if
there
are
any
objections,
please
let
me
know
right
now.
Otherwise,
I'll
proceed
to
the
next
topic.
B
B
So
the
prometheus
one
like
this
is
like
all
these
examples
are
like
working,
so
you
can
set
up
the
prometheus
to
listen
to
it
and
just
run
this
example
and
it
would
be
opening
a
port.
I
see
okay
cool,
so
it
only
collects.
I
don't
know
that
right
there,
because
spec
hasn't
defined
what
that
thing
is
called,
but
I
think
victor
and
I've
been
we've
been
using
the
term
collect
collection.
Some
people
call
it
like
harvest
some
people
call.
B
It
accumulate
like
what
the
thing
which
takes
the
current
memory
state
and
gives
it.
I.
B
Of
the
spec
that
I
saw
calls
a
collect
so
so
the
collection
is
triggered
when
someone
makes
a
request
to
this
okay
and
for
the
push
exporter.
The
console
exporter
is
an
example
of
that.
It's
basically
yeah
every
configured
seconds
it
pushes
I
mean
it.
It
would
be
like
revisited.
C
B
C
So
so
yeah
we,
those
are,
these
are
details
that
doesn't
hold
off
the
release
per
se,
but
I'd
like
to
when
we
get
a
chance,
discuss
the
exporter
getting
past
the
delta,
but
we
could
discuss
that
some
other
time
it
doesn't
hold
up
anything
at
the
moment.
Yeah.
B
So
as
we
agreed
like,
we
can
release
alpha
one
and
what
what
we
need
define
is
like
we
briefly
discussed.
What
do
we
do
in
like
alpha
2b?
So
I
want
to
like
revisit
that,
because
originally
we
were
planning
to
do
like
alpha
one
like
end
of
this
month.
It
looks
like
we'll
be
able
to
do
it
like
tomorrow,
so
which
means
we
should
be
able
to
do
the
like.
B
Let
me
call
it
alpha
2
in
july
30,
so
I
would
like
to
ask
like
what's
the
next
immediate
thing
which
we
should
tackle,
we
discussed
like
bunch
of
things
last
week,
but
I
want
to
like
revisit
and
see
if
there
are
any
other
opinions
or
thoughts.
So
my
personal
thinking
is
we
should
solve
the
async
counter
first
in
the
alpha
one.
B
Nothing
more
like
just
everything
same
as
alpha
one,
but
now
we
would
support
an
additional
instrument
from
dot
and
dotnet
has
six
instruments
or
five.
So
we
support
the
first
one
in
the
alpha
one
and
in
the
alpha
two,
which
is
coming
like
very
short
like
one
week
after
the
one
alpha
one.
We
need
to
support
alpha,
sorry,
a
synchronous
version
of
the
counter
I
mean
maybe
like.
While
doing
this,
we
need
to
solve
something
else,
but
at
least
my
like
cube
takeaways.
B
We
should
solve
this
because
once
we
are
done
with
supporting
one
instrument,
each
of
synchronous
and
asynchronous
version
supporting
the
rest
of
the
instruments
like
wage
or
histogram
should
be
relatively
easy,
as
opposed
to
like
defining,
I
mean
if
we
go
and
like
do
another.
B
C
C
B
C
C
So
at
least
the
api
could
be
there
and
then
what
was
the
other
scaling
down
the
dimension
to
only
select
dimension?
We
could
do
that
too,
but
that
those
two
things
is
should
already
be
part
of
the
view
api.
We
just
remove
some
enums
to
for
the
aggregators.
If
that's
what
we
want
yeah
so.
B
I
also
want
to
like,
even
though
the
viewspec
says
we
want
to
allow
per
instrument
selection
of
cumulative
versus
delta.
The
current
code,
which,
like
access
today,
is
tied
to
the
like
whole
pipeline.
So
if
the
pipeline
is
set
up
with,
for
example,
if
you
have
a
console
exporter,
then
all
the
metrics
are
either
delta
or
cumulative.
You
cannot
change
it
based
on
a
single
instrument,
but
we
definitely
need
that
capability.
B
So
I
would
say
that
in
the
next
alpha
we
would
still
not
allow.
We
should
not
allow
that
instrument
capability,
because
you
saw
very
less.
C
Number
of
days
to
get
this
student,
so
so
I
I
think
my
goal
is
basically
I
want
the
internal
infrastructure
to
be
there.
What
we
decide
to
expose,
we
could
limit
that
down
or
not
expose
it
whatever.
It
is,
and
we
could
just
limit
that
what
we
expose,
but
I
like
to
see
the
internals
of
that
mechanism.
Ideally,
you
know
in
the
code
base.
B
B
B
And
in
fact,
I
think
I'm
trying
to
recline,
I
think
by
the
current
pr,
allows
you
to
pick
aggregator
and
the
temporality
as
well
right,
like.
C
B
Okay,
so
just
so
we
can,
we
will
not
be
able
to
select
or
change
the
temporality
per
instrument
in
alpha
two.
It
would
still
be
like
if
you
don't
want
to
that's
fine,
yeah
and
yeah
one
once
we
release
alfred,
I
think
like
we
will
do
this
exercise
next
week,
just
to
do
like
what
we
do
in
alpha,
3.
yeah
sure.
I
think
we
should
be
able
to
support
the
instrument
thing,
because
it's.
C
Well,
so
if
you,
if
you're
going
to
support
async,
because
we
already
have
sync,
if
you're
going
to
support
async
well
by
default
synchronous,
you
know
and
async
uses
different
temporality,
but
we
could
just
say
we
just
limit
it
all
to
one.
That's
okay,
too,
but
I'm
just
saying
by
the
thief
the
spec
says
by
default
synchronous
counter
and
asynchronous
can't
they
both
use
slightly
different
aggregators
from
the
temporality
perspective,
yeah
yeah.
So
that's.
B
The
way
I
need
to
solve
this
first,
because
I
know
that
there
are
a
lot
of
open
issues
there.
That's
why
I
want
to
like
try
and
tackle
it
first,
because,
even
though
the
async
counter
produces
the
cumulative
instrument,
if
the
exporter
wants
like
delta,
we
need
to
do
like
some
improv
conversion
from
delta
pin
cumulative
delta.
C
B
So
I
have
like,
like
I
tried,
like
some
examples,
and
I
agree,
like
I
probably
mentioned
to
you
like
in
offline
messages,
it
was
a
bit
difficult
for
me
to
see
the
same
thing
flowing
into
one
into
inch.
So
I
think
this
is
good
enough
for,
like
one
and
a
half
weeks
of
like
mostly
two
people
working
yeah.
C
Yeah
so
yeah,
so
I
think
the
yeah
so
the
my
part
for
getting
the
view.
I
think
you
know
you
know
in
a
week
or
so
I
I
don't
know,
people
have
enough
time
in
a
week
to
review
the
pr
so
that
you
know,
but
the
pr
has
been
out
for
a
couple
of
weeks,
but
you
know
people
may
probably
haven't
looked
at
started
looking
at
it
yet
so.
C
C
B
All
of
them
like
until
we
done,
and
so
like
alan
already
wrote
the
first
instrumentation
for
xp
net
core
and
see
if
we
can
get
one
more,
maybe
like
http
client
or
something
it's
not
a
big
value
right
now,
because
we
are
just
doing
the
count
like
the
number
of
records.
B
That's
the
only
thing
which
we
count,
but
we
should
be
like
having
we
need
to
like
do
something
which
can
do
like
response
time
something,
but
we
don't
have
the
instrument
for
that
yet
so
we
can
probably
just
do
like
http.
Also
we
can
just
do
the
counting
thing
which
just
counts.
The
number
of
requests
or
number
of
dependency
calls.
C
Yeah,
so
on
a
side
note
on
that,
I
know:
josh
mcdonnell
has
been,
has
a
call
out
for
anyone
to
try
and
do
some
kind
of
a
histogram
implementation
prototype.
C
We
should
discuss
whether
or
not
net
has
a
histogram
ready
to
go
or
can
be
used,
or
do
we
have
to
port
something
from
go
or
from
java,
but
you
know
eventually
we're
going
to
have
to
have
some
prototype
of
a
histogram,
and
you
know
I
don't
know
who's
interested
and
if
anybody
wants
to
you
know
do
that
and
if
not,
I
was
gonna
talk
to
riley
and
to
talk
to
josh
to
see
if
we
should
do
that
for
net
as
well,
because
I
know
the.
B
B
B
So
if
you
want
to
like
create
an
issue
just
for
that
and
see
if
there
are
anyone
interested
in
picking
that
up,
we.
B
Not
like,
we
will
come
back
to
it
once
we
have
like
we
said
like
we
once
we
do
the
initial
like
framing
a
couple
of
releases.
We
let
people
use
it
right,
then
we
can
come
back
and
solve
the
histogram
part.
B
I
think
it
should
be
like
we
can
still
write
the
most
dumbest
efficient
histogram
very
easily,
but
to
get
it
like
right
and
to
get
it
like
performing
well
would
be
the
challenge
so
right,
yeah,
so
probably
something
which,
if
no
one
picks
it
up,
I
would
come
to
it
towards
the
end.
B
Okay,
any
other
questions
to
be
discussed,
I'll,
create
like
the
second
milestone,
based
on
what
they
discussed
and
leave
everything
else
unknown,
and
we
just
have
1.2
still
the
same
date.
I
mean
it
could
be
number
30
like
somewhere
in
number,
I'm
not
touching
anything.
Okay,
any
questions
to
be
discussed.
C
Yeah
so,
along
with,
if
we're
going
to
do
the
view,
I'm
asking
people
to
review
the
view
pr
in
the
spec,
you
know,
if
possible,
there's
a
few
questions.
Specifically,
you
know
with
the
view
pr.
The
two
questions
I'm
trying
to
get
answered
is
the
first
one
which
a
bigger
one
is:
where
do
people
see?
The
scope
of
an
aggregator,
you
know
is
an
aggregator,
a
distinct
function
like
a
min
only
and
a
max
only
or
is
an
aggregator
something
tied
to
a
metric
data.
C
Point
like
this
is
the
sum
otlp
protocol
aggregator,
and
this
is
the
you
know
the
histogram
otlp
protocol
aggregator.
So
that's
first
question:
that's
a
harder
question.
B
C
C
B
B
C
Scroll
down
a
bit
there's
in
the
conversation
there's
a
section
for
pros
and
cons
that
people
can
look
at
if
they
want
yeah.
I
I
I
mean
I
did
see
that
that
was
something
like
you.
B
C
B
B
B
And,
in
fact,
that's
a
validation,
I
think,
because
there
are
like
aggregations
which
are
not
covered
by
the
otlp,
but
yeah
I'll
share
my
comment
in
the
actual
peer:
let's
see,
if
there
is
anyone
else
who
wants
to
comment
on
it,
otherwise
yeah
we'll
see
how
it
goes
and
based
on
that
we'll
react
in
the
dot
net
repo
yeah.
Anything
more
like
victor,
like
like
probably
like
alain,
is
also
here
so
alan.
B
Like
do
you
have
any
questions
or
anything
which
you
want
to
work
on
yeah
by
the
way,
thanks
for,
like
finishing
the
otlp
and
the
sp
net
core,
I
think
we
briefly
discussed.
We
want
to
write
unit
tests
because
we
were
like
trying
to
get
alpha
one
out
so
we'll
be
soon
typing
some
tests
for
it,
but
I
didn't
like
do
you
have
like
any
anything
which
you
want
to
work
on.
A
Yeah
so
yeah
I
was
gonna
prioritize.
Getting
some
tests
landed,
though
I'd
be
happy
to
do
some
simple
instrumentation
for
http
client,
as
you
suggested
as
well,
just
so
that
we
have
a
little
bit
more
I'll,
definitely
review,
because
I
haven't
spent
much
time
with
it
at
all,
but
I'll
review
your
vue
pr
victor.
Thank
you
and
yeah.
Those.
Those
are
the
things
that
that
I
think
I
can
lend
a
hand
in
in
the
coming
days.
Okay,.
B
Yeah,
I
think,
having
one
more
instrumentation.
It
should
be
like
very
like
straightforward
to
do
the
second
one.
Now
that
one
is
done
yeah
for
sure
and
like
I
really
like
the
simplicity,
because
in
the
tracing
world
we
were
like
going
back
and
forth
with
like
at
least
five
approaches
because
of
the
legacy
activity
creation.
But
fortunately
here
we
don't
have
to
deal
with
that.
So
it's
very
neat,
so
I'm
hoping
that
like
http
client,
would
be
like
equally
smooth
yeah
and
just
sharing
like
something
like.
B
There
is
a
strong
interest
in
the
net
side,
especially
in
the
asp.net
core
and
eventually
in
grpc
and
http
client,
to
emit
matrix
using
the
new
api.
But
it's
almost
guaranteed
that
it
will
not
happen.
The
dotnet
six
timeline
because
we
are
very
close
to
feature
complete
in
dot
net
world.
So
it's
unlikely
that
sp
net
core
would
have
any
built-in
instrumentation.
But
the
plan
is
asp.net.
B
If
they
do
that,
that
will
be
the
best
outcome,
because
then
there
is
no
need
of
writing
instrumentation
ourselves,
because
sp
net
core
itself
is
producing
matrix
following
all
the
semantic
conventions.
B
However,
since
the
semantic
conventions
are
like
not
logged
and
dotnet
theme
is
not
convinced
that
they
would
be
doing
it
so,
at
least
in
the
foreseeable
short
term,
we
would
still
be
leveraging
the
diagnostic
source
callbacks
and
like
emitting
metrics
on
its
behalf
by
using
instrumentation
library,
so
the
dotnet
folks
would
be
creating
an
issue
in
their
repo
attacking
tackling
it.
B
Sorry
tagging
it
as
dotnet
seven
time
frame,
so
they
are
hoping
that
the
feedback
which
we
have
from
the
open
telemetry
community
about
instrumentation
would
be
instrumental
in
their
decision.
So,
but
we
don't
have
that
except
like
a
very
basic
one.
So
once
we
have
it,
it
will
eventually
be
either
recommended
by
espana
core
team
or
be
absorbed
by
the
sp
net
core
into
the
platform
itself.
B
I
believe
I
mentioned
it
somewhere
here
yeah,
so
I
spoke
to
the
dotnet
team
about
what
do
they
do
with
the
new
metric
api
and
even
counter?
So
as
of
now
the
plan
in
action
is,
there
will
be
no
pipe
from
you
encounter
to
the
new
apa?
They
would
remain
two
independent
things
and
the
dotnet
has
like
some
built-in
tools,
like
dotnet
counters
and
visual
studio,
which
has
the
ability
to
which
already
has
the
ability
to
display
event
counters.
B
Those
tools
will
be
updated
in
the
next
few
weeks
to
support
the
new
metric
api.
So,
basically,
what
it
means
is,
if
you
instrument
using
metric
api
or
if
you
are
already
instrumented,
with
even
counters
the
built-in
tools
from
dot
net,
the
net
counters
and
the
visual
studio,
they
would
support
displaying
metrics
from
both
this
mechanism.
B
But
that's
the
end
of
that's
most
likely
the
end
of
what
would
happen
in
the
dot
next.
B
Six
time
frame,
which
basically
means
if
you
were
using
even
counters,
for
whatever
reasons
like
either
for
observing
the
building
metrics
from
dotnet
like
system.one
time
or
if
you
are
using
it
for
like
your
own
custom
thing,
there
is
no
way
like
it's
going
to
magically
appear
in
open
telemetry,
so
most
likely
we'll
have
to
write
some
translator
like
something
like
a
open,
elementary
dot,
instrumentation
dot,
even
counter
which
can
read
the
data
from
even
counter
and
translate
that
into
a
wage
or
whatever
is
cycle
and
think
so
we
would
need
it.
B
B
All
right.
I
think
I
don't
have
any
other
topics,
so
we
would
proceed
with
the
first
release
of
metrics
and
we
have
a
good
plan
for
what
we
want
to
do
in
alpha
2.
So
thank
you.
Everyone!
Okay!
There
is
a
message:
okay,
yeah!
So
that's
just
victor
saying
goodbye.
Okay.
So
if
there
are
no
questions,
we
can
end
early
and
thank
you.
Everyone
see
you
next
week,
bye.