►
From YouTube: 2021-07-06 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
Yes,
yeah
victor
bring
me
early
about
some
scheduling
issues,
but
he
said
it
was
his
calendar,
but
now
I
need
to
check
like
whether
the
calendar
got
screwed
up
in.
A
B
Hey
good
small
group,
just
yeah,
we
were
just
discussing
whether
like
something
happened
with
our
there
is
a
open,
elementary
calendar
which
was
updated
last
week
to
reflect
some
changes
in
the
dot
net
instrumentation
site.
So
I
I
was
just
wondering
whether
someone
accidentally
updated
this
meeting.
Oh.
C
B
Yeah,
I'm
just
trying
to
see
like
where
do
I
see
this?
So
no,
I'm
probably
looking
at
the
wrong
calendar.
B
B
C
I
don't
personally
have
a
whole
lot
last
week,
yet
the
week
before
last
I
was
on
vacation
as
well,
and
so
last
week
was
kind
of
a
catch-up
week.
I
I
didn't
quite
get
a
chance
to
wrap
up
my
otlp
metric
exporter
pr,
but
I
this
week
I'm
gonna,
be
I'm
gonna
have
a
bunch
of
time
to
focus
on
it,
so
I'm
gonna
get
that
landed
and
I'll
pull
it
out
of
draft
and
ask
people
to.
B
Yeah,
I
think
that
people
were
asking
for
it,
but
they
were
also
asking
for
the
log
one
like
we
can
simply
state
the
matrix.
One
takes
priority.
Logan
can
rate
little
bit
more,
so
we
should
be
fine
there
yeah,
it
was
also.
I
don't
know
whether
you
were
here
last
week,
so
I
mentioned
that
we
will
need
a
delay.
I
don't
know
exactly
like
one
to
two.
B
This
is
sufficient,
but
most
likely
we
should
be
able
to
do
a
like
very
basic
preview
version
of
metrics
in
the
next
two
weeks,
hopefully
by
next
week
itself,
and
this
week
by
friday,
I
will
mark
the
1.1
release.
Candidates
are
stable,
there
is
no
changes,
no
active
bugs
reported,
so
we
should
be
able
to
release
like
1.1.0
like
this
friday.
C
Cool
you
had
said
at
one
point
that
you
wanted.
D
C
Spin,
some
more
people
up
on
the
whole
release
process.
I
think.
C
Okay,
yeah
yeah,
I
can.
I
can
be
available
if
you
said
you
want
to
do
that
on
friday.
B
Yeah,
let's
target
this
friday,
because
that's
what
we
mark
here
so
unless
we
find
any
bug
which
require
media
fix,
we
shouldn't
delay
it.
We
should
do
it
on
july
9th.
So
it's
this
friday,
so
I'll
find
you
and
let's
do
the
release
together.
B
For
the
one
one
quick
thing
which
I
briefly
mentioned
was
about
like
transitioning
to
the
next
release,
like
let's
say
we
did
the
1.1
this
friday.
After
that,
the
next
only
planned
release
is
1.2,
which
would
align
with
the
dot
net
six
release
as
well.
So
we
should
have
matrix
support
and
whatever
other
changes
we
need
for
document
six.
B
So
maybe
like
we'll
make
the
we'll
update
the
main
branch
to
depend
on
the
dot
net
6
preview
after
we
are
done
with
this
and
then
like
even
migrate
or
move
some
of
the
metric
changes
directly
into
the
main
branch
things
we
have
high
confidence
and
for
things
which
we
are
working
along
with
the
spec,
we'll
keep
it
in
the
metrics
branch,
because
it's
going
to
be
like
lot
of
significant
changes,
assignment,
spec
changes
and
as
and
when
we
do
more
and
more
experiments.
B
So,
but
that's
something
which
we
can
do
like
discuss
in
the
next
meeting,
because
we
will
probably
be
like
done
with
1.1
this
friday.
B
Okay,
oh
something
came
now.
Okay,
victor
is
here
hello,
victor
hi,
hello,
hey!
I
had
a
very
small
working
window
today,
so
I
was
able
to
look
at
the
refactoring
of
data
value
into
its
own
thing.
That
part
is
good,
so
I
haven't
reached
the
matrix
view
yet
so
yeah.
I
can
take
a
look
at
it
later
today.
In
fact,
right
after
this,
I
think
it
would
be
on
youtube.
B
B
Yeah
yeah
anything
else,
you
want
to
ask
hope
if
not,
we
can
end
early
and
meet
again
later.
D
Yeah,
hey
alan
any
any
learnings
from
your
otlp
implementation
or
exporter.
C
Cjo
here
that
last
week
I
did
not
get
the
time
that
I
wanted
to
polish
that
up,
but
this
week
I
will
have
the
time.
So
I
I'm
going
to
get
that
pr
of
mine,
cleaned
up
and
move
it
out
of
draft
state
and
I'll
absolutely
be
in
communication
with
you
about
many
feedback.
I
have
in
the
coming.
B
D
B
Yeah
I
I
was
just
like
being
very
specific
like
so.
The
current
api
stand,
the
one
which
alain
was
working
on.
It
takes
metric
item
as
the
input
to
the
exporter.
B
C
C
C
The
metric
pipeline
has
this
notion
of
just
like
the
metric
item
and
in
my
mind
I
think
that
that's
okay,
but
has
there
been
any
discussion
about
any
further
discussion
about
like
making
the
the
notions
similar?
Maybe
inheriting
from
some
of
the
same
classes
or
designing
things?
Does
that
even
make
sense?
I
don't
know.
D
So
so,
having
said
that,
I
I
don't
know
that
the
batching
concept
is
necessarily
a
concern
of
the
exporter
and
it
may
be
more
of
a
concern
of
a
batching
metric
processor,
but
but
that
portion
of
coming
up
with
a
metric
processor,
batching
is,
is
still
tbd
or
left
to
be
done.
So
so
that's
the
question
then,
aside
from
that,
it's
not
very
clear,
at
least
to
me
what
batching
means
for
a
processor
unless
we're
somehow
you
know
making
that
part
of
an
aggregator
which
doesn't
really
quite
make
sense
to
me.
D
So
in
general
I
don't
fully
understand
just
me.
I
don't
fully
understand
what
the
concept
of
batching
is
in
terms
of
metric.
If
we
are
talking
about
aggregation
and
numbers,
or
are
we
talking
about
just
network
so
depending
on
what
the
answer
to
that
is,
the
the
the
meaning
of
batching
could
be
different.
B
Sense
right
so
at
least
I
understood
the
questions.
I
don't
really
have
a
strong
opinion
on
either,
maybe
like
we'll
have
like
a
separate
classes
stands
today,
but
definitely
one
thing
which
we
want
to
address
in
the
next
few
questions
is:
we
want
to
define
a
thing
called
like
metric
exporter
base
class,
from
which
all
the
exporters
should
derive,
because
that's
because
one
thing
is
in
sync
with
the
tracing
world
like
the
processor
is
one
thing:
exporter
is
another
thing,
and
also
the
current
spec
also
explicitly
calls
out.
B
There
is
a
thing
called
measurement
processor
and
there
is
a
thing
called
metric
processor
and
there
is
a
third
thing
called
metric
exporter.
We
could
define
a
base
class
for
exporter
right
now.
We
are
like
piggybacking
on
the
metric
processor
to
write
an
exporter.
B
There
might
be
some
changes
there,
like
once
we
like
do
another
round
of
refactoring,
but
I
don't
think
it
should
be
like
very
disruptive
to
the
actual
exporter
logic,
because
majority
of
the
logic
is
in
translating
that
metric
item
into
export
format.
So
all
those
things
should
not
like
significantly
affect
the
pr
like.
Even
if
we
do
change
something,
it
should
be
like
relatively
straightforward
to
adapt
to
yeah.
D
So
yeah,
I
agree
with
you
see
joe
my
concern.
Alan
is
more
of
if
we
somehow
figure
out
that
we
are
forced
to
having
to
do
aggregation
in
the
exporter
or
we
need
to
do
some
kind
of
a
delta
to
cumulative
conversion
or
cumulative
delta
conversion
and
exporter.
D
The
other
aspect
is
that
if
we
ran
into
any
trouble
with
potentially
exporting
due
to
different
exporter
rates,
you
know
config
different
configured
exports.
So
those
are
the
things
I'm
primarily
worried
or
concerned
about.
C
B
My
current
answer,
or
my
current
understanding
is
exporter,
is
not
expected
to
do
that.
It
should
be
handled
by
the
exactly
from
someone
else,
whether
we
call
it
measurement
or
metric
processor
or
like
something
else
in
the
sdk.
I
just
don't
know
like
exporter.
It
should
only
do
like
translation
from
like
the
metric
item
into
whatever
format
the
backend
understands.
D
C
Yeah
and
you
do
bring
up
an
interesting-
I
mean
the
the
the
delta
cumulative
thing,
I
think,
is
an
interesting
topic.
I
I
I'm
of
the
same
mind
as
you
and
that
I
would
hope
that
that
wouldn't
necessarily
be
a
concern
of
the
exporter,
though
I
can
see
how
maybe
those
two
things
that
that
would
be
tacked
on
in
some
people's
mind.
In
the
sense.
Like
you
know,
I
work
a
new
relic
and
right
now,
like
for
years,
new
relic,
has
operated
basically
on
on
delta
metrics
right.
C
C
D
So
thus,
but
but
my
statement
still
goes
and
cjo,
we
kind
of
had
a
conversation
on
this
a
little
bit,
but
my
current
thinking
is
that
the
exporter
is
dumb
and
thus
all
it
can
do
is
if
it
has
data
that
it
doesn't
support
like
if
I'm
a
delta
exporter,
but
I
get
cumulative
or
vice
versa.
The
best
I
could
probably
do
at
that
point
is
just
to
throw
an
error
and
that's
up
for
debate,
but
that's
my
current
thinking.
B
Yeah
I
mean
that
definitely
aligns
with
my
understanding
as
well.
Like
exporter
should
be
like
really
dumb.
It
should
not
try
to
do
any
aggregation
or
merging
or
anything
of
that
stuff
right
right.
The
previous
version
of
the
spec,
which
existed
like
two
years
back
had
this
I
mean
there
was
aggregator
which
does
not
know
whether
it
is
aggregating
for
a
cumulative
exporter
or
a
delta
exporter.
B
In
fact,
that
was
given
to
a
thing
called
batcher
and
the
batcher
is
someone
which
is
a
stateful
batcher
or
stateless
batcher,
which
would
produce
either
deltas
or
cumulative,
but
the
current
spec
test
node
have
that
explicitly
called
out,
so
I'm
hoping
that,
like
that,
would
be
coming
soon
in
the
spec,
maybe
riley
or
you
or
someone
else
would
be.
Writing
that
part.
D
B
Okay,
yeah,
while
like
we
I
mean
we
were
in
the
topic
of
like
exporters.
I
want
to
bring
another
thing
to
like
just
for
review
with
other.
I
think
I
briefly
discussed
this
with
victor,
so,
given
that
there
is
a
lot
of
complexities
which,
on
spec,
is
not
like
final
about
any
of
these
things,
would
we
be
like
better
off
releasing
a
minimal
version
of
the
matrix
sdk
from
the
main
branch,
which
would
let's
say,
support
just
like
one
type
of
instrument?
B
Let's
say
synchronous
counter
and
have
a
habit
exporter
to
console
in
a
delta
way?
Would
it
make
sense
to
do
like
a
very
simple
thing
from
the
main
branch
by
copying
the
relevant
questions
from
matrix
finance,
or
should
we
just
like
release
everything
from
matrix
branch,
which
kind
of
supports
all
the
instruments
now?
But
there
are
a
lot.
D
B
Unanswered
questions
I
I
mean
I
was
favoring
to
release
something
from
the
main
branch
which,
just
like
absolute
minimal.
There
is
no
ability
to
configure
anything
other
than
maybe
like
what
what
exporter
you
want
again.
We
already
shipped
the
console
in
the
beginning
just
to
give
like
people
a
feel
of
like
how
the
matrix
world
would
look
like
and
start
playing
with
it.
Anyone
who
who
wants
to
like
really
know
more,
they
can
always
get
the
daily
build
from
the
matrix
branch
which
would
contain,
like
all
support
for
all
the
instruments.
B
D
Yeah,
so
my
stance
on
it
is
pretty
much.
That's
not
my
concern.
That's
for
the
maintainers
to
decide
how
best
to
package
and
make
their
code
available
per
se.
You
know
so
so
I
leave
that
up
to
you
see
joe.
My
concern
is
just
to
have
enough
spec
and
have
enough
prototype
code
that
can
move
forward
when
time
and
spec
catch
up
with
the
right
version.
B
Point
like
alain
like
do
you
see
any
opportunities
for
us
to
like
ship,
something
like
a
slim
down
version
of
what
we
have
in
the
matrix
branch?
I
mean
there
is
always
the
alternatives
to
do
nothing
special.
We
just
release
from
matrix
branch.
We
should
contain
everything
and
it
will
be
like
heavily
undergoing
changes.
B
C
I
am
yeah,
no,
I
would
find
it
very
compelling
to
ship
something
on
the
main
branch
as
soon
as
we
can.
The
only
thing
that
I
want
to
be,
I
guess
careful
of
is
any
you
know
we
just
talked
a
minute
ago
about
like
interfaces
changing
or
like,
like
you
said
like
right
now,
the
exporter,
the
metric
exporter
is
based
off
of
just
the
metric
processor
class
and
that
might
change,
and
so
what
would
be
our
plan
for
if
we
needed
to
if
we
wanted.
D
B
B
D
For
that
right,
so
the
only
I
would
think
the
only
help
is
that
certain
languages
may
provide
a
preview
package
that
I'm
still
talking
about
preview.
B
D
Okay,
yeah,
so
okay,
so
my
comment,
then,
is
if
you're
shipping
a
preview,
it's
known
as
a
preview.
If
we
limit
the
public
interface,
then
what
difference
does
it
make
if
they
happen
to
have
other
code?
That's
not
public,
because
it's
already
a
preview.
So
anyway,
so
that's
just
a
feedback.
That's
all
yeah!.
B
B
I
I
was
trying
to
see
like
whether,
like
we
want
to
ship
something
really
small
to
a
set
of
customers
who
can
like,
try
it
and
give
some
feedback.
I
just
don't
know
like
whether
we
should
ship
the
whole
thing.
I
say
from
the
matrix
branch,
because
we
that's.
D
B
D
B
Yeah,
like
only
thing
is
like
we
cannot
like
the
part
which
I
was
trying
to
clarify.
There
is
no
way
we
can
ship
a
stable
version
before
number
10,
because
we
have
a
dependency
on
2nd
6
anyway
yeah.
So
we
cannot,
even
if
we
want,
unless
we
take
like
some
special
exceptions-
yeah,
yes,
okay,
yeah,
but
anyway.
This
is
something
which
is
like
a
like
a
minor
concern.
B
I
think
I'll
come
back
to
it
next
week,
when
we
get
ready
to
do
our
first
release,
whether
it
comes
from
matrix
branch
asses
or
whether
we
piggy
I
mean
take
something
from
that
and
put
it
into
main
branch
and
release
from
there
is
like
pure
implementation
detail.
We
can
come
back
to
it
next
week.
Meanwhile
I'll
try
to
validate
that
the
current
sdk,
the
current
space.
I
would
I'm
mostly
focusing
on
whether
the
exporter
input.
B
The
patrick
item
is
good
enough,
so
people
can
write
exporters
because
I
have
someone
in
inside
microsoft,
working
a
microsoft,
specific
exporter,
so,
apart
from
more
dlp,
will
get
a
feedback
from
like
a
separate
use
case
about
the
exporter
interface.
So
that
would
be
good,
but
everything
else
like
how
the
measurements
from
the
dot
net
api
became
that
export
metric
item.
Everything
all
of
those
things
are
like
internal
implementation
details.
We
can
like
iron
it
out
anytime
as
long
as
it's
like
internal.
B
B
Even
the
spec
would
think.
Like
victor,
you
mentioned
that
you
would
be
working
on
the
aggregator
spec
and,
as
of
today,
like
aggregator,
is
not
a
like
specified
thing
in
the
spec.
So
it's
fine
for
us
to
not
expose
anything
related
to
aggregation
at
all,
so
we
would
just
be
exporting
exposing
the
meter
provider
and.
D
That's
not
entirely
true
correct
the
the
spec
as
it
stands
today
does
specifically
mention
that
you
know
in
the
view,
I
I
guess
that's
more
of
the
views
back
does
mention
aggregator,
but
the
view
spec
isn't
quite
complete.
So
from
that
perspective,
yeah,
it's
it's
not
there,
but
if
you
just
took
the
view
spec
as
it
is
today,
it
does
mention
aggregator,
but
definitely
without
much
detail
except
just
a
blind
mansion.
Okay,
so
yeah.
B
D
Yeah,
that's
correct.
That's
riley
asked
me
to
you,
know:
work
on
the
aggregator
portion,
so
yeah
yeah,
you're
correct.
It
is
unclear
at
the
moment.
C
So
yeah,
if
we
didn't,
if
we
were
able
to
ship
something
without
exposing
any
api
or
sdk
around
aggregators
at
this
point
in
time,
then
what
would
that
look
like?
It
would
be
like
some
somebody
would
create
an
instrument,
and
it
would
I
mean
there
has
to
be
a
way
to
aggregate
it,
but
it
would
just
be
like
kind
of
the
default
like
yeah.
B
Yeah
and
they'll
get
the
default
aggregation.
They
just
won't
be
able
to
change
to
their
own.
Like
let's
say
we
ship
a
very
stupid
aggregator,
not
performing
very
well.
They
won't
be
able
to
swap
it
by
defending
a
new.
But,
however,
there
is
a
hook
called
measurement
processor
which
gives
access
to
the
raw
ins
raw
metric
data
coming
from
the
api,
so
they
can
write
their
own
aggregator.
B
On
top
of
that,
it's
just
that
we
don't
call
it
as
a
aggregator
per
se,
but
if
someone
doesn't
like
the
performance
of
the
sdk,
they
can
always
like
implement
an
aggregator
and
the
whole
pipeline
themselves
by
using
a
measurement
processor
yeah.
I
think
even
today,
like
what
victor
has
is.
The
aggregator
is
a
written
as
a
measurement
processor.
B
So,
like
the
current
spec
allows
these
hooks
like
access
to
raw
measurements,
which
is
a
measurement
processor,
and
then
there
is
metric
processor
which
gets
the
pre-aggregated
matrix.
So
you
can't
like
build
anything
off
of
that,
but
it
fails
to
define
what
is
an
aggregation
or
aggregating
processor.
Hopefully
that's
what
victor
is
going
to
work
on
in
the
spec
space
yeah?
Okay,
I
got
it
yeah,
don't
think
like
even
in
the
original
version
of
the
spec
which
george
walked
on,
I
don't
recollect
like
whether
aggregator
was
defined
or
maybe
it
was
different.
B
I
don't
you
recollect
yeah,
I
mean
if
the
spec
says
I
mean
defines
the
aggregator
interface,
then
yes,
we
can
edit,
but
until
then
like
we'll
try
to
expose
like
the
most.
D
So
minimal
thing
so
so
I
think
so
I
I
don't
think
in
general,
there
is
an
aggregator
interface.
I
think
really
all
it
is
is
that
if
we
have
a
view
api,
then
aggregator
can
be
configured
by
the
user,
but
outside
of
having
a
view
api,
I
don't
believe
there's
anywhere
in
the
spec
that
says
a
customer
can
change
at
that.
So
really
we're
talking
about
the
view.
Api,
yeah,
yeah,
okay,.
B
It
defines
like,
what's
the
input
to
a
sampler
and
what's
output
from
a
sampler,
and
that
basically
means
like
anyone
can
write
their
own
sampler,
they
know
what
to
expect
as
the
input
and
they
know
what
they
should
emit
as
output,
but
for
aggregator
it's
not
yet
not
yet
defined
anywhere
in
the
spec.
That
aggregator
gets
like
these
as
the
input
and
it
is
supposed
to
produce
these
as
output,
so
that
part
is
not
defined
in
the
spec.
B
D
Yes,
yes,
that
is
what
I'm
currently
working
on
so
yeah
yeah.
So
right
now
the
spec
just
has
some
in-memory
state.
D
B
So
you'll
like
break
it
down
that
in
memory
state
would
be
like
aggregators,
followed
by
like
some
state
which
it
maintains
right.
That's
the
current
thought.
Yes,
okay,
yeah,
okay!
I
would
look
forward
to
it
and
meanwhile
try
to
unblock
existing
prs
and
see
if
we
can
ship
the
like
fast
beta
in
the
next
few
days.