►
From YouTube: 2021-07-13 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).
C
C
C
C
Okay,
so
I,
like
I
mentioned
like
two
weeks
back.
We
wanted
to
make
sure,
like
more
than
one
person
know
how
to
do
the
release,
so
I
have
done
it
like,
probably
for
five
times
and
utkash
has
done
it
once
now.
Alan
has
also
done
one.
So
at
least
we
have
like
some
backup
in
case
I'm
not
available
to
do
any
releases
even
for
like
how
big
so
we
are
covered
like
michael.
C
If
you
want
to
do
like
next
release,
I'm
happy
to
help
with
like
just
walking
through
the
steps
it's
mostly
done
down.
I
see
I
mean
just
need
to
follow
the
dog
asses.
C
We
like
discovered
yesterday
that
there
are
several
things
which
can
be
automated,
but
none
of
them
are
like
passing
enough,
because
we'd
only
do
the
release
like
once
in
a
month
or
once
in
two
once
in
two
months,
and
also
some
of
that
manual
steps
has
will
potentially
go
away
once
you
remove
the
instrumentations
from
this
repo,
because
the
key
challenge
right
now
is
we
release
instrumentations
in
a
different
version
than
the
core
packages,
so
once
they
align
on
the
versions,
some
of
those
things
would
become
like
no,
so
we
can
still
leave
with
the
manual
operation
and
one
I
mean
maybe
like
I'll
just
ask
that
so
there
is
something
called
like
github
releases,
which
we
do
whenever
we
do
a
nuget
release.
C
This
is
like
manually,
you
create
a
draft
and
you
pick
the
tag
which
was
released
and
you
just
copy
paste
the
change
log
from
all
the
components
which
are
released
and
put
it
here.
So
I'm
just
like
thinking
something
back
like.
Is
it
something
which
people
use
like
the
github
releases?
I
was
wondering
like.
Can
we
like
stop
doing
this
because
I
don't
know
what
value
does
it
add?
C
Because
you
can
always
look
at
the
change
log
in
the
repositories,
change
log
and
look
at
the
new
get
and
we
always
do
the
tagging
anyway,
so
we
can
always
map
the
nougat
version
to
the
tag
name.
So
I
wonder
like
whether
do
we
need
this
step,
because
this
is
like
one
additional
manual
step
which
we
can
avoid.
If
you
can,
so
you
don't
know
whether
it
makes
sense
to
keep
doing
it
or
are
there
some
issues?
If
you
don't
do
this,
does
anyone
know
like
the
significance
of
github
releases.
C
A
C
Yeah
I
mean
I
mean
what,
if
we
don't
do
this
releases
like
we
have
the
tax
anyway,
which
tells
us
which
are
the
versions
which
we
have
released
and
that
tag
would
correspond
to
the
nougat
version
as
well.
So
you
should
find
it
in
nougat
and
if
you
want
to
know
what
changed
between
one
version
to
another,
always
like
you
can
come
and
look
at
the
change
log.
So
my
thinking
is
like
whatever
we
are
doing
is
like
just
redundant
yeah
yeah.
D
I
think
I've
seen
in
some
projects
that
when
they
they
they
use
the
the
the
release
from
from
github.
They
also
put
the
the
nougat
package
there.
I
don't
know
if
we
want
to
do
that
as
well.
Yeah
java,
also,
they
put
the
jar
files
in
the
release,
yeah
yeah,
so
I
a
few
dotnet
projects
that
I
follow.
They
they
do
the
releases
and
they
put
the
nougat
packages
there
together.
I
don't
know
if
there's
any
value
but.
C
A
C
Yeah
we
didn't
even
fold
yeah.
We
did
it
this
even
for
the
counter
grip
yeah,
it's
kind
of
like
a
manual
thing.
That's
why
I'm
like,
if
it's
not
adding
any
value,
you'll
just
stop
doing
this.
It's.
C
Yeah,
you
can
definitely
do
like,
like
github
actions
and
like
automate.
It
of
course,
like
you,
have
to
like
invest
some
time
to
make
it
happen.
C
If,
if
it's
not
adding
any
value
like
it's
best
to
like
not
do
it
at
all,
irrespective
of
whether
we
are
doing
it
manually
or
automatically,
but
anyway
like
this
is
something
which
allen
and
I
was
discussing
yesterday.
While
we
were
doing
the
release
like,
is
it
of
any
use
or
are
we
just
doing
it?
For
the
sake
of
doing
it,.
C
Yeah
I'll
check
like
if
what
is
that.net
cleaning
just
like
do
they
do
like
github
release
on
top
of
the
new
gate
and
like
it's
a
good
reference
to
follow,
because
we
already
have
so
much
dependency
on
the
runtime,
they
don't
have
runtime
and
we
may
try
to
follow
what
they're
doing
as
well.
C
Okay,
yeah!
So,
along
with
one
dot's
one
of
the
core
packages,
we
did
release
a
rc
update
for
the
instrumentations.
As
noted
like
earlier,
it's
not
going
to
be
stable
for
a
long
time.
I
just
don't
know
like
how
long
is
that
long
time,
so
the
milestones
we
still
have
instrumentation
1.0.
C
It's
not
happened
and
no
due
date,
no
eta,
so
it
it
will
be
like
released
as
rc
until
the
semantic
conventions
are
mark
stable.
We
probably
have
like,
like
one
or
two
issues
in
the
instrumentation
to
solve
ourselves,
which
is
about
like
having
different
public
api
based
on
different
targets.
I
don't
have
time
to
get
to
it.
C
We
have
open
full
request
to
that,
but
we'll
get
to
it
once
the
key
things
are
like
done,
because
the
next,
the
next
key
milestone,
is
1.2
release
which
we
are
trying
to
align
with
dot
net
release
date,
which
is
number
nine,
so
I'll,
be
creating
like
more
milestones
to
do
a
monthly
kind
of
update.
We
were
expected
to
do
the
first
version
of
like
alpha
or
beta
of
the
matrix
end
of
june.
C
That
was
what
we
promised
earlier,
but
that
hasn't
happened
so
I'll
create
milestone
to
reflect
the
new
like
new
timeline,
because
june
2021
did
not
happen
so
I'll
have
to
update
it
to
like
july
and
would
be
when
I
expect
the
very
first
version
of
the
open,
elementary.net
sdk,
which
has
the
metric
support
so
I'll,
create
like
milestones
for
monthly
and
share
it
before
the
next
meeting.
C
Yes,
now
we
can
talk
about
matrix.
Victor
is
here.
We
haven't
made
much
progress.
At
least
I
haven't
had
any
progress
with
the
prs.
I
did
peek
at
it
like
while
doing
something
else,
but
that
I
said
I
haven't
done
it,
but
I
would
be
expending
100
of
the
time
today,
just
to
make
sure
we
can
close
on
the
spears
and
get
the
first
alpha
version.
As
I
mentioned
earlier.
So
viktor,
do
you
have
like
specific
asks,
or
you
are
requesting
people
to
review
prs.
E
Yeah,
so
just
in
general,
I
think
the
you
know,
metric
spec
team
is
asking
for
anybody
who's
interested
in
metric
and
view
the
sdk
to
you
know.
Please
take
a
look,
and
you
know
help
out
with
the
view
spec
or
yeah.
So
that's
out
there
that
riley
is
trying
to
close
down.
It's
been
stalled
for
a
couple
of
weeks,
but
hopefully
we
could
get
enough
people
to
start
making
progress
on
finishing
up
the
views
back,
yeah.
E
Oh
sorry,
okay,
I
yeah
I'll
fix
that
in
a
I'll
fix
that
in
a
second
and
then
and
then
after
the
view,
spec
is
more
concrete
per
se.
Then
I
do
have
the
an
aggregator
spec.
That
is
also
people.
Please
take
a
look
and
see
you
know
if
you
guys
have
comments
on
how
to
do
the
aggregator
spec
and
then
I
do
have
a
prototype
view.
Pr,
that's
currently
out
there
for
c-sharp
as
well.
So
again,
also
why?
If
you
guys
are
interested,
please
help
and
take
a
look.
E
I
do
know
that,
for
example,
all
of
these
are
somewhat
tied
and
related
together.
So
in
the
you
know,
going
from
the
very
high
end,
spec
the
views
back
then
somewhere
in
between
the
aggregator
spec
and
then
finally,
to
the
view
pr.
I
know
that
they're,
not
all
a
hundred
percent
in
sync
and
matching,
so
I
I'm
we're
all
aware
of
that,
because
the
specs
are
all
still
not
finalized,
so
it's
still
kind
of
floating
a
little
bit.
E
But
having
said
that,
I
think
the
vue
pr
that
I
have
out
there
does
cover
probably
80
to
90
percent
of
what
will
be
required
by
the
spec
and
some
things
we
probably
want
to
limit
access
to
per
se.
So
I
think
the
infrastructure
or
the
structure
and
framework
is
in
place.
However,
the
details
of
the
what
we're
actually
exposing,
which
aggregators
available
those
are
still
up
in
the
air
based
on
how
the
specs
are
going.
C
Okay,
yeah.
I
I
have
some
general
comments
about
this,
so
let
me
see
if
there
are
any
other
questions
from
folks
in
the
phone
other
ways
the
discussion
so
like
does
anyone
helps
have
any
questions
before
we
go
slightly
deeper
into
victor's
prs
for
metrics,
okay,
I
don't
see
anything
yeah.
So
victor
like
what
my
first
thinking
like
first
question
was
when
I
saw
the
let
me
find
that
exact
place
come
on
yeah.
C
So
I
put
it
as
a
comment
here
like
when
a
user
is
expected
to
like,
let's
say
the
user
has
already
decided
to
use
the
right
instrument,
which
itself
is
a
bit
of
a
learning
curve
for
anyone
coming
from
like
any
metric
system,
because,
like
the
spec
says
we
have
around,
I
think
eight
instruments,
so
they
have
already
done
a
bit
of
mental
exercise
to
figure
out
and
pick
the
right
instrument.
C
Dotnet,
we
limited
the
number
of
instruments
to
like
too
short
of
what
is
different.
We
don't
have
the
synchronous
and
asynchronous
version
of
it
now
like
after
going
through
that
accessories.
Now,
when
they're
trying
to
configure
a
view,
we
are
kind
of
asking
them
to
like
have
a
steep
learning
world
because
we
need
to
understand
or
the
person
who
is
configuring.
That
view
should
have
a
good
understanding
of
what
this
means
it
kind
of
feels
like
we
are
asking
too
much
from
the
user.
So
is
it
something
which
you
expect
the
like?
E
So
yeah,
so
so
I
am
following
the
view
spec
for
the
most
part.
So
I'm
not
necessarily
you
know
completely
going.
You
know
off
rail
on
it,
but
if,
having
said
that,
if
you
want
to
look
at
the
view,
spec
riley
recently
added
some
examples
of
what
he
might
mean
for
how
to
specify
aggregators
and
from
the
current
view,
spec.
It
looks
more
like
that.
E
It
is
more
of
a
new
class
with
parameters
rather
than
enums
and
then
the
question
then
you
asked
about
well,
does
the
people
you
know
have
to
know
about
how
to
configure
each
of
the
aggregators
for
all
of
the
instruments?
E
My
interpretation,
based
on
what
you
know
my
my
understanding
of
the
spec
of
the
view
spec,
is
that
likely
the
user
will
have
to
have
some
level
of
understanding
of
the
defaults
that
are
required,
although
we
would
prefer
to
have
you
know
the
default
configuration
per
se.
So
I
think
what
will
wind
up
is
that
there'll
be
a
default
configuration
that
people
will
use,
but
then
the
details
of
all
of
those
defaults
or
all
of
those
parameters
will
still
be
likely
still
available
for
the
users
to
specify,
for
example,
with
a
histogram
right.
E
So
they
might
pick
a
default
set
of
boundary
for
histogram,
which
we
preferably
won't
have
the
user
provide.
But
the
user
have
the
ability
to
change
all
of
the
boundaries
for
the
histogram
and
that
so
I'm
picking
that
histogram,
so
in
that
representation
of
the
histogram
as
an
enum
in
this
particular
case
is
probably
not
ideal.
Rather
it
probably
should
be
based
on.
E
You
know
a
class,
a
new
something,
so
you
could
see
that,
in
the
view
ap,
you
could
see
that,
in
the
view
spec
as
well
as
I
put
out
some
pros
and
cons
in
the
aggregations
spec
as
well.
If
you
want
to
look
at
that.
C
Yeah,
so
my
concern
is
not
specifically
with
like
histogram
buckets
being
like
a
liquid.
E
C
I
correct
I,
I
was
just
writing
the
getting
started
for
matrix
yesterday
and
I
realized
okay.
This
is
this
is
very
complex,
like
how
do
I
ask
user
to
like
because
they
already
did
the
exercise
of
picking
the
instrument.
C
Now
I
should
be
like
just
doing
it
myself
or
like
the
sdk
should
be
doing
it
automatically
without
asking
the
user,
because
in
this
case
the
user
is,
let's
say
he
picks
the
like
some
delta
and
what,
if
it
gets
paired
with
a
exporter
which
is
not
capable
of
supporting
delta,
so
then
like
even
if
he
picked
the
like
some
delta,
after
some
research
or
whatever
yeah.
E
C
I
think
it's
going
to
be
dropped
by
the
exporter
anyway.
So,
yes,
that's
my
main
concern.
It's
like
it
should
be
like
the
user
should
not
be
forced
to
maybe,
like
you
said,
it's
a
thing
in
the
spec,
but
based
on
what
I
see
here,
the
user
is
explicitly
picking
this
for
each
and
every
instrument.
C
So
if
they
pick
the
wrong
one
like
it's
quite
likely,
because
you
can't
see
like
it's
fairly
involved
and
you
can
see,
the
combinations
are
too
much
like
you
can
have
some
with
delta
and
some
with,
I
think,
by
default,
it's
the
cumulative,
and
then
you
have
these
combinations
and
if
you
pair
it
with
the
wrong
exporter
like
do
you
like
or
like
maybe
like
yeah,
does
anyone
else
see
this
as
a
like
concern?
Or
is
it
just
me
being
like
too
much
concerned
about
these
options.
E
Okay,
so
I
think
I
I
hear
you
loud
and
clear,
see
joe,
and
I
think
that
conversation
that
question
is
best
answer
when
we
talk
about
it
in
the
views
back
or
in
the
aggregators
spec
conversation,
so
so
from
at
the
net
sig
level.
E
We
probably
should
talk
about
whether
or
not
we're
adhering
to
the
spec
or
not
adhering
to
the
spec,
but
if
we
were
talking
about
spec
specific
issues,
I
think
it's
a
wider
conversation
and
I
think,
just
today
we
had
a
somewhat
similar
debate
in
terms
of
you
know
two
different
factions
of
people
saying
we
should.
What
do
we
do
if
the
defaults
aren't
correct
and
there's
some
faction
of
people?
E
That
says
well
it's
incorrect
and
we
just
do
nothing
and
others
think
we
should
just
provide
proper
default
and
I'm
not
making
a
judgment
on
one
or
the
other,
I'm
just
letting
the
spec
people
kind
of
work
it
out
and
figure
out
what
that
is.
I
think
the
default
is,
I
think
the
generally
people
want
to
have.
E
You
know
good
defaults
to
start
off
with
to
help
the
user
so
that
they
don't
have
to
do
stuff.
So
so
I
do
agree
with
that
stance
as
well,
but,
like
I
said,
I
think
this
conversation
is
best
addressed
at
the
view
spec
level
rather
than
the
c-sharp
sig
level.
C
E
I
think
there
are
the
from
the
two
other
prototypes
that
I
have
heard
the
the
go
and
the
java,
I
think
the
how
they
do.
Aggregators
and
vue
are
still,
I
think,
they're
still
divergent
for
the
most
part,
even
in
terms
of
how
they
arrange
for
the
aggregators
and
the
pipeline
to
be
put
together.
I
think
there's
some
difference
like,
for
example,
the
go
implementation.
They
talk
about
an
accumulator
and
they
talk
about
a
processor
and
they're
talking
about
the
accumulator,
storing,
just
deltas
and
the
processor
converting
deltas
to
cumulative.
E
So
that's
one
implementation
in
gold.
I
heard
that
the
java
implementation
is
even
more
complicated
in
that.
Well,
there's
the
in-memory
stuff,
that's
more
complicated,
but
the
java
implementation,
I
think,
has
you
know
notions
of
the
the
measurement
process.
They
have
these
processors
and
the
measurement
processors
that
store
some
data
in
some
in-memory
thing
that
they
then
have
processors
that
pick
up
the
memory.
So
there's
slightly
different
implementation.
E
E
C
But
I'm
just
hoping
that,
like
the
at
best
the
we
should
ask
the
user,
do
you
want
to
have
a
histogram
or
do
you
want
like
summit,
and
if
it
is
histogram
you
ask
for
the
buckets
but
whether
it
is
delta
or
cumulative
or
monotony?
C
That
should
be
best
left
for
the
sdk
to
automatically
figure
out
based
on
the
exporter.
It
is
paired
with,
but
yeah
that.
E
C
Okay,
yeah,
so
that
I
put
like
other
comments,
mostly
about
like
exposing
things
as
public
this
one.
Yes,
we
definitely
need
this
public
if
we
want
user
to
specify.
E
There's
a
in
the
aggregator
spec
there's
a
pros
and
cons
list
of
this
conversation.
If
you
want
to
take
a
quick
look
and
comment
on
there,
that
would
be
awesome.
C
Okay,
I
think
I
have
it
opened
as
well,
so
I
would
look
at
it,
but
mostly
about
like,
let's
just
pick
like
this
one,
for
example,
like
you
intend
like
these
to
be
public
like
the
way
the
current
pr
stands
out
like
these
are
public.
C
Like
the
I
view,
role
along
with
include
tag,
rule
and
other
things,
but
like
from
what
I
see
like
the
even
example,
you
think
you
have
the
example,
because
the
way
you
like
the
way,
an
inducer
specifies
view
is
by
just
calling
the
add
view
api
in
the
builder,
so
they
which
takes
like
bunch
of
parameters.
There
is
no
need
for,
like
anything
else,
to
be
public
except.
E
C
You
would
get
it
back
to
internal
okay
yeah,
so
I'm
really
concerned
like
if
we
expose
any
anything
which
we
are
not
required
at
all,
because
since
user
the
spec
is
still
like
moving
from
one
place
to
another
and
not
stable
at
all.
We
don't
want
to
like
expose
too
many
things
so
sure
yeah
great
addressing
it.
I
mean
adding
more
comments,
but
I
would
like
to
see
if
he
can
agree
on
what
we
get
in
the
first.
Let's
call
it
alpha
version,
let's
take,
what
is
we
should
have?
C
We
do
have
might
get
even
from
the
matrix
branch,
but
we
haven't
had
any.
Oh
sorry.
Can
people
still
hear
me.
C
Morning
it
says
your
internal
connection
is
unstable,
but
that
message
has
disappeared,
so
I
hope
I'm
affordable
now
yeah.
So
let
me
like
write
it
down
just
to
see
if
it
makes
sense
so
right
we
want
to
like
defend
the
minimum
bar
for
first
metric
review
release.
It
could
be
called
like
alpha
one
or
maybe
like
beta1
whatever
it
is.
I
want
to
see
whether
the
following
makes
sense
as
the
minimum
power.
C
I
can
take
comments
right
now,
so
victor
I'm
proposing
that
like
the
first
release,
which
which
was
supposed
to
be
like
two
weeks
ago,
but
now
I'm
trying
to
do
it
like
by
at
least
the
end
of
this
month.
So
I
was
like
no.
C
No,
no,
let
me
be
very
specific.
Let
me
just
be
putting
like
this:
would
it
eric?
Are
you,
okay,
with
just
supporting
the
synchronous
version
of
the
counter,
because
I
think
I
mentioned
to
you
like
in
on
offline
conversation?
I
just
don't
know
whether
the
asynchronous
counterpart
we
are
doing
the
aggregation,
correct
or
not.
So
I
I
was
hoping
like.
We
need
to
release
something,
but
we
cannot
solve
all
the
problems
in
one
shot.
So
what
if
we
just
support,
like
I
mean,
keep
writing
but
from
an
instrument
standpoint.
C
We
would
only
support
the
synchronous
counter
in
the
first
release,
which
I
hope
to
release
at
the
earliest.
So
any
objections.
If
this
basically
means
no
passing
counter,
no
glitch,
no
histogram,
I'm
I'm
not
saying
we
will
not
release
it
in
the
stable,
but
just
trying
to
defend.
E
So
so
hold
on
hold
on
a
sec.
I
think
maybe,
let's
clarify
the
language
a
little
bit?
Okay,
so
I
I
don't
think
you
mean
just
support
the
sync
counter,
because
I
think
there's
two
portions
to
it,
the
first
of
which
is
the
instruments
that
we
want
to
support.
Well,
the
the
api
is
already
public,
so
the
customer
currently
today
already
have
full
access
to
all
the
range
of
instruments
that
they
can
already
use.
Okay,
so
that's
number
one
number
two
for
the
sdk.
E
I
think
per
the
spirit
that
you're
talking
about
perhaps
for
the
sdk.
We
will
only
support,
maybe
only
a
very
simple
kind
of
aggregator,
and
maybe
we
will
support.
Then
we
from
that
simple
aggregator
to
the
otlp,
maybe
just
in
memory
or
console-
and
I
agree
with
you
that
we
want
to
minimize
it,
but
I
I'm
just
trying
to
clear
up
the
language
a
little
bit
here,
yeah.
So
that's
awesome,
open
elementary
sdk.
C
E
Well,
so
so
again
I
I.
I
don't
know
that
it's
particular
the
counter.
I
think
it's
more
about,
given
all
the
instruments
are
just
giving
values
and
given
that
we
may
or
may
not
have
the
view
api
really.
The
the
crux
of
the
issue
is:
how
do
we
add
or
or
accumulate
those
numbers?
So
all
I'm
saying
is
that
perhaps
in
the
first
release
we
only
support
one
very
simple
aggregator
which
will
in
this
case,
probably
directly.
E
E
C
Let's
pick
one,
that's
why
I
want
to
write
the
minimum
part,
because
we
don't
want
to
support
two,
because
I
just
want
to
make
sure
like
what
is
the
minimum
bar.
We
can
ship
a
very
first
version,
so
at
least
people
can
start
using
it
just
to
get
a
feel
of
what
it
what
it
would
look
like,
and
we
can
add
everything.
So
we
either
pick
some
or
either
either
pick
some
organization.
E
Right,
I
didn't
say
we're
gonna
pick
both
I'm
just
saying
that
if
you
were
to
pick
an
aggregator,
the
gauge
aggregator
only
keeps
the
last
value
without
having
to
keep
any
accumulation,
so
it
is
probably
the
most
simplest
aggregator
that
we
could
do
now.
If
we
don't
want
to
do
that,
we
could
pick
some.
We
could
do
that.
I'm
not
saying
we
pick
both.
I'm
saying
you
know
that
yeah,
I'm
saying
one
aggregator
is
simpler
than
the
other.
Is
all
I'm
saying.
C
Because
I
expect
that
the
synchronous
version
of
the
counter
should
be
paired
with
the
aggregator,
which
does
the
sum.
So
that's
my
reason
why
I
put
like
the
support.
The
aggregator
should
be
doing
the
sum
and
not
keeping
the
last
value,
because
the
counter
should
be
paired
with
something
which
does
the
sum.
E
E
With
the
counter,
because,
well
how
why
do
we
have
to
account,
we
could
just
have
a
gauge.
C
E
C
So
I'm
thinking
like
because
alan
would
be
working
on
the
sp
net
core
counter
sorry
asp.net
core
metrics,
which,
like
instrumentation
for
asp.net
core,
which
can
count
the
number
of
requests
it
has
received.
I
would
assume
that
that
count
would
be
best
used
with
counter
because,
like
along
with
the
sdk,
we
want
to
ship
like
one
instrumentation.
C
So
we'll
have
like
a
more
end
to
end
story
like
we
have
like,
even
with
user,
doing
nothing.
They
just
enable
this
instrumentation
for
sp
net
core,
which
gives
the
count
of
requests,
and
we
do
the
sum
in
terms
of
aggregator
and
support.
Did
you
say
like
we
will
support
console
exporter
plus,
let's
create
it
exclusively
support,
otlp
exporter
and
support
only
this
exporter
and
support
a
single.
E
C
I
don't
know
whether
which
pairs
best
with
otlp
exporter.
Do
you
know
the
answer
because
console
doesn't
care
like
it
can
just
display
to
the
console,
but
for
otlp.
E
Does
it
actually,
when
you
output,
so
again
also
I
mean
that
if
you're
supporting
an
otlp
exporter,
it
depends
on
what
data
you
give
it
and
you
could
choose
the
data
you
give
it
whether
you
want
to
give
it
cumulative
or
delta,
so
the
otlp
exporter
has
really
little
influence
on
what
we
want
to
do.
Oh
so,
you're
saying
that
hotel
exporter
can
accept
both
that's
correct.
Okay,.
C
C
C
Which
does
some
in
a
cumulative
way,
and
does
this
look
good?
I
mean
this
is
good
enough,
because
I'm
going
to
write
that
like
getting
started
doc,
which
would
say
that
the
user
would
take
an
instrument
from
the
dotnet
api
like
meter,
dot,
create
counter,
and
they
just
call
like
counter
load.
Add
that's
what
the
spinner
core
instrumentation
is
going
to
do
and
they
just
set
up
the
meter
provider,
which
will
have
like
a
very
minimal
interface,
which
I
mean.
I
don't
think
we
even
ask
the
user
for
aggregator.
C
No,
I
mean
at
least
in
first
person,
let's
skip
view,
because
it's
much
more
involved
than
the
like
the
scope
of
the
first
release
thing,
I'm
I'm
basically
trying
to
get
like
one
release
out
and
at
least
by
end
of
this
release
we
will
know
a
little
bit
more
about
what
is.
E
C
It's
better
than
no
progress
right
I
mean.
I
don't
think
that
we
can
just
release
assays,
because
we
need
to
write
some
talk
like
which
shows
like
how
to
use
it,
and
views
are
still
like
work
in
progress.
I
don't
think
like
the
spec
pr
would
be
merged
like
today,
which
means
like
we'll
have
we
still
need
like
more
time
to
like
flush
it
out?
So
that's
why
I'm
trying
to
target
like
release
like
something.
E
C
Experimentation,
so
this
will
give
you
something
which
walks
into
it,
because
this
is
like
starting
with
like
you,
can
either
do
the
counter
yourself
or
you
can
use
the
instrumentation
which
will
produce.
So
this
will
be
like
something
which
you
can
see
into
it
but,
like
I
said,
if
you
try
to
solve
into
and
for
everything
like
whether
the
user
picks
aggregation,
whether
they
pick
cumulative
versus
delta,
those
are
not
yet
closed
by
the
spec
as
well
like
because
you
said
the
aggregator
pr
itself
is
in
the
spec
state.
C
So
we
don't
want
to
like
wait
for
that.
We
can
at
least
release
this
here
and
there
is
no
pressure,
but
I
want
to
get
the
at
least
from
microsoft
standpoint.
We
want
to
start
writing
exporters
for
microsoft,
custom
back-ends.
We
have
to
know
like
the
structure.
What
is
the
thing
it
expects
so
just
to
unblock
that.
We
need
like
something
released
to
look
at
I'm
fine,
even
if,
even
if
we
like
support
this
thing
from
an
instrument
standpoint.
C
Even
if
the
exporter
has,
I
think,
the
metric
item
which
you
have
defined
in
the
as
the
input
given
to
the
exporter.
So
we
need
to
like
solve
that
as
well
before
I
can
write
a
full-fledged
exporter,
but
to
begin
with
at
least
something
which
works
end
to
end.
C
C
I
think,
if,
if
we
agree
that
this
can
be
shipped
as
the
first
one,
I'd
call
it
alpha,
because
this
is
not
worthy
of
calling
beta
because
it
like
it
doesn't
even
support
all
the
counters
or
all
the
features
which
the
spec
is
clear
about,
because
the
spec
already
supports
all
the
other
instruments.
C
So
we
can
like
release
this
like
at
the
earliest
and
then
like
add
like
other
instruments
and
call
it
beta
and
then
work
on
like
push
base,
pull
based
and
multiple
pipelines.
I
think
we
like
most
of
the
code
is
already
there
like.
We
just
don't
expose
it
to
public
so
like
we
are
not
like
going
to
delete
all
the
code.
We
just
keep
it
like
internal,
so
the
user
will
have
the
ability
to
simply
add
a
single
pipeline,
and
once
we
are
out
releasing
that,
then
we
can
add.
C
Mean
I
want
to
hear
like
if
anyone
else
have
like
like
alternate
proposals
or
questions
or
objections
to
this
idea,
because
we-
I
don't
have
because,
like
couple
of
days
back,
the
totality
must
like
what
is
the
feedback
for
the
matrix
api.
C
Unfortunately,
since
we
haven't
shipped
an
sdk
which
can
even
do
like
even
a
basic
counter,
we
cannot
give
them
any
feedback
from
the
open
elementary
community
and
the
window
for
any
change
in
dotnet
is
like
almost
closed
like
so
I
want
to
like
make
sure
like
we
have
like
something
from
open
telemetry,
because
without
open
elementary,
it's
very
unlikely
that
someone
would
be
using
the
open
element,
the
dot
next
api.
So
we
want
to
like
do
something
which,
rather
sooner
so
any
objections
or
any
comments
on
this
blind.
C
I
would
put
this
would
be
released.
Like
probably
like
next
friday.
I
mean
we
can
even
do
it
this
friday,
but
I'm
just
being
like
a
bit
more
liberal
and
then
create
milestones
like
every
two
weeks
from
that
which
would
be
calling
it
beta
one
beta,
two
and
so
on,
which
incrementally
adds
more
features.
C
C
Okay,
I
hear
no
objection,
so
I
mark
it
as
the
decision
which
we
are
taking
I'll,
just
call
it
alpha
one
because,
like
I
scope
the
features
to
be
the
most
minimal,
so
it
better
fits
the
alpha
name.
So
I'll
create
a
milestone
with
alpha
one
and
copy
this
thing,
and
then
I
can
work
with
victor
to
decide
like
what
is
the
thing
which
we
include
in
the
next
release
like?
C
Should
we
add
more
instruments,
or
should
we
add
view,
or
should
we
support
like
multiple
pipelines,
depending
on
which
one
is
easier
to
tackle
and
depending
on
the
actual
need?
I
think
ellen
is
not
here,
but
what
he
said
is
he
will
be
working
on
like
cleaning
up
the
remaining
of
otlp
exporter
this
week
and
see
if
we
can
do
the
asp.net
core
instrumentation
part.
C
C
So
we
have
an
opportunity
to
like
compare
them
to
see
like
whether
we
are
giving
the
same
count
as
as
what
spinner
core
already
produces.
It
uses
event
counter
for
request
count.
I
think
it's
just
a
basic
count
like
successful
request
count
and
failed
request
account.
So
if
we
export
this
counter
through
open
telemetry
and
we
split
by
success
as
a
dimension,
we
should
see
the
same
thing
like
violation
that
this
is
like
truly
counting
the
actual
number
and
not
having
any
like
buds
or
anything.
E
C
Work
with
all
right,
I
will
mark
this,
as
the
I
mean
put
it
into
a
milestone.
So,
like
victor
like
would
you
want
to
like
discuss?
What
do
we
do
for
the
next?
Like
I
mean
as
soon
as
we
release
this
thing,
we
can
do
the
next
one.
Let's
call
it
beta1,
would
you
recommend
adding
all
the
other
instruments,
or
would
you
recommend
like
tackling
the
push
based
versus
full,
based
or
supporting
multiple
pipelines
or
like
like
views?
What's
your
take
on
it.
E
Yeah,
so
so,
okay,
so
if
I
understand
you
correctly,
you
you're
just
interested
in
having
a
minimum
something
end
to
end
to
help
out
you
know
more
adoption
or
or
getting
feedback
right
right.
Okay,
I
get
that
okay
cool,
so
I
think
for
that,
for
your
minimum
bar,
I
think
if
we
polish
up
the
otlp
exporter,
I
think
we're
probably
pretty
set
on
that.
E
Then,
once
you
finish
this,
then
I
would
think
the
next
set
of
goals
you
know
for
the
next
release
or
whatever
it
is,
would
be
probably
to
work
through
and
get
the
view
api
available
and
because
the
view
api
will
will
hopefully
resolve
any
issues.
With
your
single
pipeline.
Multi
pipeline,
you
know
push
base
versus.
You
know,
pull
base
export
that
kind
of
stuff.
So
I
think
the
view
api
would
probably
be
the
next
big
thing
we
want
to
incorporate
in.
C
Okay,
so
basically,
what
you're
saying
is,
like
view,
would
help
us,
like
with
other
parts
as
well.
E
Right
and
then
to
do
the
view,
api,
there's
gonna,
be
people
gonna,
be
able
to
select
aggregators
as
well.
So
so
that
will
force
us
to
have
you
know
some
aggregators.
You
know
the
default
aggregators
or
what
have
you?
So
I
think
the
view
api
would
be
next
and
all
the
things
that
the
view
api
attempts
to
address.
E
C
I'm
just
trying
to
see
whether
can
we
do
like
a
like
scaled-down
version
of
the
view
where
we
don't
allow
the
aggregator
to
be
changed,
but
we
can
allow
extra
dimensions
and
like
selecting
dimensions,
is
that
something
which
we
should
try,
because
if
we
say
that
view
is
to
be
tackled
in
the
next
milestone,
we
cannot
solve
the
view
until
and
unless
we
close
on
the
aggregator
part,
we
should
also
entail
us
solving
the
somewhat
stimulative
part.
So
it's
basically
like
a
huge
milestone.
C
We
we,
I
was
trying
to
ask:
is
it
possible
to
do
like
a
view
which
only
allows
the
user
to
pick
which
dimensions
they
want
and
which
extra
dimensions
they
want?
It's
still
view,
but
it's
like
a
scaled
down
version
of
the
view
which
doesn't
force
us
to
solve
the
aggregator
part.
C
Would
it
make
sense
to
tackle
it
as
the
first
release
after
alpha?
Let's
maybe
let
me
just
call
it
like
alpha
two.
C
C
Just
writing
it
down
like,
let's
see
if
everyone
agrees
to
this
speaking.
C
E
Like
bunch
of
other
people,
so
so
so
I
I
think
I
think,
there's
two
two
things
to
be
concerned
about
and
I
think
the
things
that
you're
addressing
is
what
portion
of
the
code
base.
We
have
you
want
to
expose
for
the
public
okay,
so
so
that's,
fine
and
and-
and
you
know
I'll
defer
to
you
on
that
since
you're
running
the
the
release
cycle.
So
if
we
don't
feel
comfortable
with
exposing
everything,
that's
fine,
we
could
lock
it
down.
E
E
Aggregator,
like
we'll,
have
to
like
pick
you
down.
You
just
support
only
one
aggregator
or
two
aggregator,
and
they
only
have
a
choice
of
that
same
aggregator,
I
mean
so
you
can
limit
it
that
way.
If
you
want.
C
Try
this
one
basically
means
like
we'll
defer
solving
the
sun
versus
stimulating
and
the
monotonic
versus.
E
Right
right
right,
so
so
let
me
repeat
again:
you
can
support
one
aggregator,
whether
you
pick
delta
or
cumulative.
It
doesn't
really
matter
just
pick
one
aggregator,
and
if
you
pick
that
one
singular
aggregator
and
you
only
make
that
one
singular
aggregator,
you
know
public,
then
you
your
view,
api
isn't
crippled
or
anything.
It
just
happens
that
when
the
user
use
the
view
and
they
pick
aggregator,
they
only
have
that
one
aggregator.
E
So
we
don't
have
to
solve
any
some
cumulative
issue.
We
don't
even
have
to
address
the
some
cumulative
or
whatever
issue
we
could
still
support
view
and
the
whole
pattern
of
how
you
could
use
a
view
to
change
your
aggregator.
It
just
so
happened.
There's
only
one
simple
aggregator,
it's
I
mean.
Does.
C
Yeah,
probably
in
this
milestone,
is
where,
like
one
it
in
this
milestone,
we
need
to
like,
basically
when
we
say
views
as
perspective,
which
means
more
aggregators
should
be
exposed
which
automatically
means
support
the
remaining
instruments.
C
Sure
yeah,
maybe
like
I'll,
probably
like
split
this
even
further,
because
the
I
intentionally
picked.
The
synchronous
version,
maybe
like
I'll,
create
something
in
the
middle
to
support
the
async
counter
as
well,
because
that
would
be
a
different
thing.
Based
on
what
I
see
it's
a
different
challenge
and
from
what?
Whatever
I
tried
with
the
current
implementation,
it's
not
trivial.
How
do
we
deal
with
the
like
singleness
counter
versus
asynchronous
counter?
C
Even
the
fact
that
the
asynchronous
already
gives
us
cumulative
and
unless
I
mean-
and
we
already
agreed,
our
aggregator
is
already
like
the
cumulative
one.
So
what
do
we
do
with
a
data
which
is
already
accumulated
like
we
don't
need
to
do
anymore?
Some,
we
kind
of
like
act
as
a
pass-through
kind
of
thing,
but
I
just
don't
know
like
whether
it
is
like
significantly
different
or
not
so
maybe
like.
I
introduced
something
in
the
middle
like
as
the
next
instrument.
C
We
would
support
the
asynchronous
version
of
counter,
if
that's
the
case
in
the
later
alpha,
4
I'll,
add
remaining
instruments,
because
once
we
have
at
least
a
synchronous
version
of
counter
and
an
asynchronous
version
of
the
counter,
it
should
be
relatively
easy
to
tackle.
Histogram,
also
because
histogram
would
just
pick
a
different
aggregator
with
a
different
thing,
but
it
should.
The
overall
flow
should
not
be
like
significantly
different
from.
G
E
It
looked
good
sure.
C
Okay,
yeah,
I
mean
I
I
did
share
with
you
like
some
example
like
maybe
like
two
weeks
back
about
a
sim
counter.
I
I
mean
that's
some
problem
which
we
haven't.
At
least
I
haven't
seen
solved.
So,
let's
sync
on
it
and
see
whether
like
this
encounter
is
like
really
important.
Maybe
we
can
like
move
it
to
an
earlier
milestone
or
we
can
keep
it
like
as
alpha
3
or
later
and
timeline
wise.
Let
me
see
this
one.
C
We
will
do
the
release
and
like
for
the
remaining
one,
let's
discuss
it
in
the
next
segmenting
like
what
is
the
timing
like
whether
it's
two
week
or
like
three
week,
depending
on
how
how
much
progress
we
make
in
the
first
release,
we
can
decide
the
timelines
for
the
next
releases,
okay,
and
if
we
go
backwards.
Let's
say
that
number
is
when
we
are
going
the
actual,
stable
one.
We
need
to
release
like
a
release
candidate
by
number.
C
So
probably
we
need
like
betas
before
october,
yeah
september
october,
okay,
so
we
should
be
able
to
do
like,
like
some
alphas
in
like
till
august
10th.
If
we
do
like
two
thing,
we
should
be
able
to
do
till
like
august
and
and
then
start
rolling
it
better.
The
only
reason
why
I'm
calling
it
our
face
because
it
does
not
have
all
the
features
and
then
beta
means
like
the
features
are
there.
C
It
may
not
be
like
like
high
performance
or
anything
and
when
we
reach
rc,
we
try
to
lock
down
the
public
ap,
not
locked,
like
we
put
a
heavier
bar
to
change
the
public
api.
So
at
least
let's
walk
on
the
first
release
and
then
take
it
from
there.
C
E
E
No,
those
were
the
main.
Those
are
just
main
concerns,
just
making
sure
those
things
are
available
for
the
exporter.
C
So
we
would
have
the
public
interface
called
metric
item
it
can
contain,
like
all
the
like,
even
though
we
are
only
supporting
the
synchronous
version
that
the
data
structure
which
is
given
to
the
exporter,
it
may
contain,
like
more
than
the
sum
like
it
can
contain,
histogram
whatever
it
has.
Is
it's
just
that
there
is
no
way
the
sdk
can
produce
it
in
the
alpha
one.
So
that
should
be
fine.
I
think.
E
C
I
think
we
can
keep
the
same
branch
I
think
like
if
you
just
cut
down
like
anything
which
is
exposed
as
public
we'll
just
revisit
and
make
it
internal
to
unblock
that.
For
me,
I
mean,
if
you're
asking
like,
do
I
create
a
separate
branch
to
do
the
alpha
one
or
probably
not
I'll,
just
stick
with
the
current
matrix
branch?
C
Okay,
sure!
Okay,
do
you
see
any
problems
with
that
I
mean
I
do
see
one
problem
because
we
have
like
like
big
changes
like
incoming,
and
so
it
might
be
little
tricky,
but
I
think,
like
we'll,
have
to
just
coordinate
among
ourselves
rather
than
creating
another
branch,
because
we
are
already
in
the.
C
Yeah
thing
I
briefly
asked
last
week
like:
should
we
like
promote
like
a
little
bit
of
like
whatever
I
called
it
alpha
one
into
the
main
branch
and
released
from
there?
C
That's
still
possible,
but
it
may
be
like
more
same
like
logistically.
It
may
be
like
more
work
just
to
copy
over
manually
copy,
all
things,
because
eventually
we
want
the
matrix
branches,
the
one
which
we
are
shipping,
so
it
may
be
more
trickier,
so
it's
probably
best
if
we
just
stick
with
matrix,
but
once
I
actually
start
doing
the
work,
I
know
like
whether
it's
feasible
or
we
need
to
create
separate
branch
or
anything
of
that
sort.
C
C
B
C
Yeah,
so
I
think
these
once
again
between
the.
C
Matrix
trying
to
record
which
one
is
this:
is
this
one?
So
there
is
a
class
called
metric
item
which
yeah
here.
So
this
is
what
thing
that
public
interface
would
look
like.
The
exporter
gets
metric
items,
so
what
you
need
to
make
sure
is
validate
that
you
can,
like
you,
have
all
the
data
you
need
for
your
exporter.
C
So
that's
if
it
does
not
contain
anything
which
you
are
expecting
it
to
contain,
then
trace
it
or
if
it
is
containing
things
which
is
not
in
the
expected
format
or
anything
that
something
which
we
can
solve
and
as
I
mentioned
like,
we,
we
don't
need
to
like
restrict
what
this
public
api
would
look
like.
It
may
change
as
we
learn
more
but
yeah.
It
can
even
support
all
the
things,
including
histograms,
even
in
alpha
1.
C
C
Yeah,
okay,
okay,
we'll
create
the
milestones
and
do
the
like
clinical
work
of
like
copy
pasting.
These
things
into
the
milestones,
maybe
like
we'll
still
refrain
it
further.
Maybe
I'll
just
do
the
alpha
one
now
and
leave
this
thing
for
the
next
meeting,
because
when
we
actually
hit
alpha
one,
we
may
need
to
adjust
it
so
I'll.
Just
do
this
match
for
today
and
come
back
to
this
in
our
next
meeting.
C
Yeah,
because
I
mean
I'm
suspecting
that,
like
maybe
like,
we
might
need
to
adjust
these
things
once
we
like
go
deeper,
so
we
I
don't
want
to
like
promise
something
and
then
scale
it
down
again,
so,
okay,
yeah
and
like
this
is
something
which
requires
some
more
so
either
align
or
I
will
try
to
add
this
instrumentation.
So
it
requires
some
work
in
the
meter
provider
itself
to
attach
an
instrumentation
to
it.
So
I'll
work
on
that,
so
that
we'll
have
the
folder
into
nb
all
right,
any
other
questions.
C
Okay,
I
think
there
is
someone
who
joined
for
the
first
time.
Could
you
say
hi,
I'm
having
a
hard
time
pronouncing
your
name
so
I'll?
Let.
D
D
Yeah,
thank
you.
My
background
is
I've
been
writing.net,
let's
say
server
applications
for
a
while
now
for
some
years
and
then
I
guess
in
a
few
weeks
I'll
be
taking
a
new
role
which
will
lead
me
out
of
let's
say,
writing
applications
and
going
to
this
sort
of
work.
Yeah.
So
mostly,
I
think
open
telemetry
I'll
be
joining
one
of
the
let's
say:
vendors
of
yeah
apms.
D
It's
not
I'd
enjoy
it.
So
that's
why
I
I
didn't
put
there
so,
but
that
will
will
probably
lead
me
to
get
involved
into
this
area
so
yeah,
it's
all
new
to
me
and
I'm
very
I'm
trying
to
read
as
much
as
I
can,
and
you
know
like
getting
information,
it's
a
lot
of
stuff.
So,
but
I
hopefully
hopefully
I
can
contribute
soon
with
some
interesting
stuff.
I
actually
have
a
pr
open
for
a
while
about
the
semantic
conventions.
C
Power,
okay,
yeah
I'll,
try
to
get
to
it
like
sooner
but,
like
I
said,
like
my
first
project.
E
C
D
Yeah
I'll
definitely
bother
some
of
you,
probably
at
some
point.
Okay,.
C
Thanks
everyone,
if
there
are
no
questions,
we
will
meet
again
next
week.
Hopefully,
at
that
time
we
would
have
either
released
the
first
alpha
or
we
would
be
like
the
first
matrix
alpha
by
then.
So
thank
you
for
joining.
See
you
all
next
week.