►
From YouTube: 2021-06-29 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
glad
to
see
alan
is
also
back
from
vacation.
So
I'll
just
share
like
two
very
quick
updates,
basically
about
the
release
we
did
last
week,
so
we
released
the
last
beta
for
the
1.1
milestone.
B
It
was
renamed
from
beta
to
rc1
because
it
is
expected
to
be
the
last
one,
so
it
will
be
followed
by
the
actual
1.1.0
release
in
the
next
week,
so
it
should
be
like
reflected
in
the
milestones
now
and
thanks
to
michael
now,
we
solved
the
configuration
issue,
mostly
without
even
taking
a
dependency
on
dependency
injection
dot
abstractions
package.
So
that
was
a
thing
which
we
discussed
last
week
so
but
it's
sold,
but
we
have
a
follow-up
here.
I
submitted
it
after
the
original
pr
was
march.
B
I'll
spend
some
time
discussing
it,
but
just
the
next
update
on
the
release.
So
as
soon
as
1.1
is
done,
we'll
start
the
1.2
series
and
still
to
figure
out
the
exact
logistics,
because
we
want
to
start
releasing
packages
which
has
matrix.
B
It
was
originally
planned
to
start
at
end
of
june,
so
I
would
expect
it
to
be
delayed
by
a
week
or
two
quite
likely
two
weeks,
I'm
on
vacation
like
rest
of
this
week,
so
I
would
count
that
one
week
is
already
gone,
so
we'll
be
expecting
the
first
preview
release
which
contains
some
matrix
by
around
july
14th
or
15th.
So
I
did
not
create
like
specific
milestones,
targeting
the
like
beta
or
thread
releases.
We
only
have
a
major
one
like
which
tracks
1.2,
which
is
in
alignment
with
what
we
originally
discussed.
B
It
should
be
net
6
is
releasing
number
9,
so
we'll
be
doing
it
around
the
same
time,
but
definitely
not
before
that.
So
that's
just
update
on
timing.
I
want
to
like
spend
like
a
couple
of
minutes
on
this
proposal
which
I
sent
last
week,
but
before
that
is
there
any
questions
or
anything
it
looks
like
we
have
a
new
member.
So,
let's
see
if
they
want
to
introduce.
So
I
see
austin
like
like
it's
a
different
austrian
than
I
see.
Is
it
the
same
one,
hello
austin?
C
B
Not
new
here
yeah,
I
can
see
like
kidneys
here
team
was
here
like
few
more
few
weeks
back,
not
sure
if
you
had
a
chance
to
introduce
so
tim.
If
you
want,
you
can
say
hello
to
everyone.
If
you
want
to.
D
Hi,
my
name
is
tim
hess.
I
work
for
vmware
on
the
steeltoe
project.
B
Okay,
like
are
you
trying
to
like
looking
for
some
contributions
or
you're,
just
like
curious,
what's
going
on
here,.
D
Well,
steel
toe
has
a
dependency
on
open,
telemetry
right
now,
so
right
now,
I'm
I'm
currently
in
the
middle
of
trying
to
upgrade
to
the
the
latest
version
spoken
telemetry.
So
I'm
very
closely
following
along
with
the
the
ga
release
of
110.
B
Okay,
did
you
I
mean
last
time
when
I
worked
with
someone
from
steel
toe,
they
were
like
very
much
interested
in
the
metrics
space.
Do
you
know
like
if
there
is
any
interest
in
matrix
space
at
all.
D
Yeah
there
there
is
we've
definitely
got
some
vmware
has
some
major
initiatives
around
metrics
and
observability
in
general.
It's
not
my
personal
forte,
but
I'm
doing
what
I
can
at
the
moment.
Okay,.
B
Yeah
welcome
yeah
nah,
since
there
are
no
other
topics
in
the
agenda.
I'll
just
use
this
to
take
review
this
year.
So
let
me
open
it.
B
So
this
is
like
basically
stealing
ideas
from
several
other
peers,
some
of
the
mind,
some
of
them
michaels
and
probably
from
someone
else
as
well.
So
it's
trying
to
address
like
bunch
of
issues
in
one
shot
by
making
like
two
explicit
decisions.
So
that's
why
we
want
to
like
discuss
it
in
the
community.
So
the
first
thing
is
we,
as
of
today,
like
the
we
have
like
certain
bugs
where
like.
B
If
you
call
like
multiple
ad
open
elementary
tracing
in
the
extensions
package
package,
each
of
them
will
result
in
adding
a
new
instance
of
the
provider,
and
we
have
a
bug
where,
like
the
old
one
is
not
disposed
so
one
way
of
solving
this
is
simply
don't
allow
it
to
be
called
more
than
once
just
call
it.
I
mean
just
throw
it
if
someone
attempts
to
call
it
one
more
than
once
so
it
basically
means
if
you
are
using
the
extension
start
hosting
package.
B
If
there
is
a
need
for
you
to
create
like
multiple
tracer
providers,
you
can
always
do
it
by
using
the
regular
sdk.createbuilder
dot,
build
pattern
and
add
it
to
the
da
and
then
your
response
for
its
lifecycle.
B
But
I
think
this
mostly
solves
most
of
the
use
cases
where
people
would
typically
only
have
a
single
instance.
So
that's
the
first
part
of
this,
dr
and
second
part
is
we
did
modify.
B
I
mean
to
make
it
slightly
easier,
because
previously,
if
we
wanted
to
like
pick
something
from
di
like,
for
example,
a
processor
or
sampler,
you
have
to
like
explicitly
announce
that
hey
I'm
expecting
this
sampler
or
processor
from
di
when
you
call
the
ad
open
elementary
tracing
method,
but
now
that
we
have
decided-
or
at
least
if
one
is
agreed
upon,
since
there
is
only
one
da
sorry
one
instance,
we
don't
need
that
explicit
announcement.
B
So
whatever
is
added
to
the
di
would
be
part
of
the
single
instance
of
tracer
provider
constructed
by
this
code.
So
the
code
would
look.
I
mean
there
are
some
comments
from
michael
about
like
improving
this,
but
in
general
you
can
add
samplers
thing.
We
would
in
future,
add
instrumentation
library
and
maybe
resource
as
well.
All
the
things
which
are
configurable
on
a
tracer
provider
will
be
automatically
picked
up
from
the
di,
so
I
mean
with
some
extension
method.
B
We
can
make
this
even
neater,
but
the
idea
is
you:
if
you
want
to
use
assembler,
you
just
add
it
to
the
di
and
it's
like
it's
a
set
call
it's
equivalent
of
set
call.
So
if
you
do
it
like
10
times,
the
last
one
will
be
replacing
everything
else
for
processors.
B
It's
just
changed,
so
you
can
add,
like
any
number
of
processors,
it'll
all
be
chained
together
and
it
could
be
part
of
the
provider
which
we
construct
as
part
of
this,
like
any
questions
right
now
before
I
even
open
the
pr
or
if
there
are
any
strong
objections
to
this
one.
Let's
take
it
now
and
see
whether
we
want
to
proceed
any
further
or
not.
B
Okay,
that
means
no
one
is
objecting,
so
I
think
I
can
leave
the
rest
of
the
part
to
the
actual
peers,
because
tr
is
like
very
straightforward.
Mike
left
some
comments,
but
that
I
said
it's
very
straightforward:
we
maybe
why
not
just
open
it.
B
It's
going
to
like
trim
down
some
of
the
public
apa,
because
we
don't
need
to
like
explicitly
announce
that
there
would
be
like
these
are
the
things
which
we
are
removing
like.
This
is
where,
like
user
explicitly
said,
hey
like
set
the
sampler
and
then
get
it
from
di,
but
we
don't
do
it
now
because
with
even
without
this
call,
we'll
just
pick
it
up
from
da,
so
just
ask
for
sampler,
and
we
just
have
four
processors.
This
is
to
be
extended
for
instrumentation
library
and
resource
so
like.
B
If
you
have
any
comments,
please
share
it.
I
leave
it
like
for
end
of
this
week
to
see
if
there
are
any
objections,
otherwise
I'll
address
the
comments
which
michael
left
and
try
to
merge
it
in
the
next
week.
The
goal
is
like
we
want
to
make
sure
like
we
shoot
the
stable
version
of
extension
start
hosting.
It
does
not
have
any
dependency
on
specification.
It's
just
that
we
just
have
to
find
time
to
like
wrap
it
up.
B
Okay,
I
think,
like
alain
had
some
comments
a
few
months
back
when
I
tried
to
address
it
in
like
a
different
way.
So
please
take
a
look
and
see
whether
your
use
case
of
adding
a
new
relics
exporter
at
the
same
time
accessing
the
logo.
So
all
those
scenarios
should
still
be
supported.
So
please
take
a
look,
and
let
us
know
if
something
is
not
good.
A
Yeah
for
sure
I
can
take
a
look,
I'm
also
curious,
but
I
can
catch
up
with
the
conversations,
but
I
remember
there
being
some-
maybe
some
compelling
arguments
for
allowing
ad
open
telemetry
tracing
to
create
multiple
providers,
but
it
sounds
like
y'all
have
decided
to
to
go
this
route
which,
in
my
opinion,
does
seem
simpler,
but
I'm
I'm
kind
of
curious
like
how
that
discussion
kind
of
resolved
itself.
But
again,
I'm
happy
to
just
kind
of
like
review
these.
These
newer
videos.
B
Like
once,
we
settle
on
the
fact
that
we
only
allow
single
call
to
the
add
up
until
elementary
tracing,
and
we
assume
that
only
single
provider
a
provider
is
to
be
registered.
Then
it's
like
everything
is
similar
to
reasonable.
Once
we
have
multiple,
then
always
the
question
is,
like
you
say
I
think,
do
like
da.
B
Should
it
be
picked
up
by
both
or
should
it
be
picked
up
by
one
of
them,
then
that
means
like
someone,
like
user,
has
to
write
little
bit
more
code
to
say
like
which
one
should
pick
up
the
specific
sampler,
but
once
we
make
it
like
singleton,
like
a
truly
single
instance
of
tracer
provider,
managed
by
the
extensions
package,
you
can
always
create
like
any
number
yourself
and
add
it
to
di
yourself.
B
So
we're
not
like
blocking
anyone
from
using
that
scenario,
but
we
are
just
targeting
the
typical
use
case,
which
is
tracer
provider,
is
a
like
single
instance.
B
So
that
lot
I
mean
that
simplified
rest
of
the
discussion
say
a
lot.
So
I'm
a
big
fan
of
like
keeping
it
simple
and
the
yet
yet
like.
If
someone
is
like
really
advanced,
they
want.
They
can
always
use
the
sdk.great
builder
pattern
as
well
yeah,
so
leave
any
other
comments
on
the
pr
we'll.
I
won't
be
like
working
next
three
days,
so
we'll
still
leave
it
open
for
another
week
and
try
to
merge
like
early
next
week
and
see
if
there
are.
B
There
are
like
plenty
of
issues
open
like
some
of
them,
like
as
old
as
this
repo
about
configuring,
we'll
see
if
all
of
them
can
be
solved
once
this
is
closed
and
if
that's
the
case,
we'll
try
to
release
a
new
release
candidate
of
the
extension
start
hosting
package
and
eventually
call
it
like
a
stable
one,
because
there
is
no
need
for
delaying
it
indefinitely.
B
Okay,
thanks!
I
yes
victor,
I
think
victor
is
back
communication.
B
Yes,
we
have
the
prs
to
be
reviewed
yeah.
I
pretty
much
said
the
same
thing
last
week
and
nothing
has
happened.
At
least
it
did
seem
like
some
review
on
the
data
value
pr,
but
the
views
no
one
has
had
the
time
to
look
at
it.
Yet
it
looks
like
the
spec
is
also
kind
of
stuck.
I
didn't
have
done
this
that
meeting
today.
I
don't
know
whether
it
made
any
progress
today,
but
last
week
there
were
like
almost
like
50
minute
discussion
on
like
the
viewpierre.
B
It
did
not
get
resolved.
I
think
it
still.
Let
me
see
if
it
got
like
victor.
Do
you
know
if
the
like
views?
Pr
got
progress,
today's
matrix
meeting
or
it's
still
so
I
think
the.
E
Upr
is
still
kind
of
being
deleted
per
se,
so
today
there
was
some
debate
over
how
to
resolve
conflicting.
E
You
know
when
you
create
a
view
whether
what
happens
when
you
have
multiple
matching
instruments
and
so
forth,
so
I
think
that
got
resolved
today
a
little
bit,
so
I
didn't
fully
catch
up
with
last
week's
comments
per
se,
but
I
did
read
through
some
of
the
comments
from
last
week's
view.
I
don't
think
it
materially
impact,
at
least
the
pr
at
this
moment.
E
E
B
E
It's
expected
that
the
sdk
would
log
something
or
have
a
mechanism
to
report
errors
or
log
errors
or
or
callback
for
getting
errors,
something
along
the
basically
the
whole
error
handling
mechanism,
and
so
I
did
not
look
into
that.
I
assume
tracing
has
very
similar
mechanisms,
so
whatever
tracing
is
using
for
logging
out
errors,
probably
the
same
that
we
would
do
here.
Yeah.
B
So
dotnet
case
we
we
were
using
even
source
from
the
beginning,
so
anything
which
we
think
like
should
be
reported
to
the
user.
But
we
cannot
just
throw
an
exception
right
exactly
you
just
log
into
even
source
right
exactly,
and
I
think
we
did.
I
don't
think
we
decided
to
change
anything,
but
there
was
a
proposal
to
replace
because
right
now
like,
if
there
are
like
15
projects,
we
have
15
even
sources
and
some
boilerplate
code.
B
There
was
a
proposal
to
add
a
like
this
kind
of
troubleshooting
api
in
the
open,
elementary
api
itself
like
in.net
and
have
everyone
else
just
use
that,
but
that
never
got
approved
or
merged
so
like
by
default.
The
current
answer
is
still
even
source
right
yeah,
I
don't
know
like
whether
spec
is
explicitly
asking
for
that
like
because
it
should
be
like
the
standard
thing
based
on
their
handling
principles
already
in
the
specification
somewhere
yeah.
E
E
A
E
Other
than
that
I
have
two
pr's,
one
is
simple
data
value,
so
that's
a
very
quick,
simple
one,
then
the
bigger
one,
which
is
the
view
api,
which
I
think
will
still
continue
to
need
work
in
terms
of
keeping
up
with
the
spec
as
the
spec
is
continually
changing,
but
does
what
I
would
probably
do
with
the
view
api
is.
I
think
the
structure
is
still
sound
and
good.
E
Now
we're
just
working
through
the
specifics
following
the
view
in
terms
of
the
constraints
and
rules
that
they
want
or
not
want
to
support,
for
example,
whether
or
not
they
want
to
support
you
know
view
matching.
You
know.
Multiple
views
matching
an
instrument,
for
example,
is
one
one
area,
there's
also
some
discussion
about
what
the
defaults
are
for,
histograms
and
stuff.
We
still
don't
have
we
don't
have
an
implementation
of
a
histogram
of
aggregators,
so
anybody
that
wants
to
tackle
that
are
is
more
than
welcome,
even
though
the
spec
is
still
continually.
E
You
know
being
developed
on
that
as
well,
so
so
that's
kind
of
where
we
are,
but
I
do
have
a
general
question
for
I
think
allen
actually
and
you
see
joe,
how
goes
it
with
trying
to
implement
an
exporter?
B
Okay,
yeah,
I
did
the
basic
dumb
one,
the
console
one.
I
looks
fine,
I
I
think
like
utkar,
she
is
also
trying
to
do
a
microsoft,
specific
exporter
which
should
be
like
internal,
so
we
won't
share
the
code,
but
he
he
would
also
be
sharing
some
feedback
based
on
what
we
see
are
we,
I
think
in
this
like
once
this
pr
is
done
like
where
we
refactor
the
attacks.
From
I
mean
the
value
into
a
separate
thing.
Do
you
think,
like
we
are
close
to
defining
what
the
metric
would
look?
E
I
believe
so
I
I
did
speak
to
riley
yesterday
about
you
know
how
we're
doing
our
stuff
and
he
did
not
seem
to
have
any
major
concern
or
whatever
now.
Please
note
that,
however,
that
I
think
the
next
step
on
the
spec
perspective,
I
think
riley
was
mentioning
that
they
in
the
spec.
E
You
know
into
you
know
the
default
configuration
for
aggregator,
so
I
think
that's
still
yeah.
I
don't
know
where
that's
going
to
go,
so
I
think
they'll
continue
to
discuss
that
portion
as
well
so,
but
but
as
far
as
your
question
is
concerned,
c
joe,
I
I
currently
don't
see
any
you
know
significant
change
to
how
we
pass
the
metric
information
to
the
exporter.
If
that
that
was
your
question
yeah
exactly.
That
was
exactly
my
question.
Yeah
yeah,
so.
B
A
B
A
C
A
Time
it
does
a
thing
I
I've
only
just
kind
of
briefly
manually
tested
it
running
my
own,
like
local
collector
instance,
but
I'll
add
some
tests
and
so
on.
I
haven't
put
a
ton
of
thought
yet
into
that
interface
and
and
developed.
You
know
opinions
of
whether
it
feels
right
or
whether
I
have
feedback
yet,
but
I
will
think
about
that
more
this
week.
A
I
think
maybe
maybe
like
the
the
high
level
question
I
I
have.
But
again
I
don't
haven't
developed
any
opinions.
Yet
it's
just
that
we're
basing
the
processors
and
the
exporter
on
and
so
on
are
different
than
the
and
the
base
classes
that
we
created
for
tracing,
which
is
probably
necessary
just
because
of
the
the
difference,
but
I
I
will
be
curious
to
kind
of
like
look
at
it
through
that
lens
to
see
if
there's
a
way
to
evolve
things
so
that
there's
some
commonality.
B
Okay,
like
I
think
we
will
get
like
some
more
clarity
from
this
background,
like
what
is
the
expected
thing
which
a
exporter
can
get
it's
mostly
based
on
the
data
model.
It
looks
like
very
close
here.
I
think
whether
we
should
use
the
existing
base
processor
or
create
a
brand
new
one,
those
things
we
can
always
change,
based
on
more
feedback.
B
Okay,
this
okay,
we
don't
have
the
dedicators
for
histograms,
but
yeah.
You
still
have
the
tests
which
you
would
be
using.
I
assume
you
would
be
using
like
the
basic
counters
that,
like
you,
said
that
you
were
able
to
see
that
in
your
console
right
so
like
we're
just
using
the
some
counters
or.
A
Test
metrics
there
I
forget
what
I'm
creating
there,
but
it's
it's
whatever.
B
B
Okay,
okay,
it
does
create
everything
like
it
yeah
founder,
the
passing
version
of
it
and
quiz,
and
I
think
it
also
creates
a
histogram
of
did
see
like
histogram
yeah.
It
does
do
everything,
but
yeah
histograms
are
probably
dropped
on
the
floor,
but
yeah
you
should
be
able
to
see
this
thing.
Okay,
so
where
okay,
okay,
this
is
where
we
are
adding
otp
metric
exporter
without
okay,
yeah
so
like
when
we
do
the
like
first
release.
B
I
think
we
can
do
the
otlp
also
along
with
that,
as
I
mentioned
in
the
beginning,
it
would
be
like
approximately
two
weeks
from
now
when
we
release
the
first
preview
or
beta
version,
so
we
can
release
the
sdk
and
dotnet
has
already
done
their
part.
The
api
is
already
out
there,
so
we'll
release
the
sdk
and
the
otlp
part
not
sure
we'll
have
time
for
prometheus.
But
if
there
are
anyone
who
has
like
prometheus
experience
and
wants
to
contribute,
please
let
us
know
we
can
dig
up
the
old
existing.
B
Oh
sorry,
the
old
prometheus
one
which
we
like
know
sometime
back,
but
we
can
look
at
the
code
and
probably
we
use
a
lot
of
them
because
it
was
a
working
code.
We
were
able
to
successfully
export
both
gui's
thing.
We
were
able
to
do
summary,
don't
recollect
but
at
least
the
basic
framing
is
there
and
we
can
take
it
and
polish
it.
If
anyone
has
time
to
do
that,
otherwise,
we'll
just
keep
the
sdk
and
otlp
as
the
first
release
and
then
get
back
to
primitives.
Little
later,.
B
All
right,
any
other
questions
to
be
discussed.
Yeah
I
mean
someone
asked
about
instrumentation.
Let
me
see
if
it's
sorry,
I
think
I
accidentally
clicked
and
shared.
So
let
me
do
that
again.
So
just
asking
for
ideas.
So
what
I'm
trying
to
do
here
is
the
it's
not
clear
that
why
the
at
least
for
some
folks
why
the
instrumentations
are
like
still
stuck
without
a
stable.
So
I
try
to
create
a
milestone
here.
B
It
says
eta
is
not
available
because
we
are
waiting
on
this
thing.
So
if
anyone
has
any
better
way
of
like
communicating
this,
please
let
me
know,
because
I
got
thing
by
a
lot
of
people
asking:
why
is
the
instrumentation's
not
stable
so
and
this
along
with
the
main
readme
file,
which
says
released,
only
the
core
components
have
released
and
the
milestones
are
linked
from
here.