►
From YouTube: 2021-12-07 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).
B
C
Okay,
sorry,
sorry,
you
guys
I'm
for
a
delay.
A
C
Okay,
I
mean
just
just
like
when
you're
free
to
even
join
the
meeting
as
per
you,
because
we
have
a
meeting
which
I
think
the
alternate
meeting
is
which
more
suits
you.
So
I
mean
you
can
always
go
through
the
comments
on
the
agenda
document.
I
mean
on
the
updates
so
good.
C
C
Okay
feel
free
to
probably
add
the
agenda
items.
I
think
we
can
discuss
that,
I'm
just
going
to
add
one
of
the
items
which
was
probably
planned.
We
wanted
to
discuss
it
last
week.
I
think
with
tom
tom
just
wanted
to
talk
more
about
this
with
you
also
so
this
this
is
basically
the
windows
dln
support
for
rotating
c
displays,
so
we
we
don't
support.
So
we
do
support
shared
libraries
which
works
fine
for
linux,
like
environment,
but
I
think
for
windows
dll.
It
does
not
work.
C
C
C
Oh
and
he
had
some
idea
how
to
do
it
and
he
had
some
suggestions,
so
I
just
tagged
him
just
in
case
they
want
to
add
more
details,
but
I
think
finally,
it's
us
to
decide
whether
we
didn't
want
to
do
it
and
if,
yes,
how
and
when
we
should
be
doing
it,
so
I
mean
either.
We
should
not.
If
we
don't
we're
not
going
to
support
it
and
let
let
let
for
windows,
let
users
statically
link
the
library.
A
A
C
And
all
the
global
global
data
and
global
class
methods,
probably
which
we
want
to
export
from
dll,
we
have
to
provide
the
specific
tags
for
that
in
the
source
code.
So
it's
a
source
code
change,
we're
not
going
to
we're
not
going
to
provide
anything
for
windows
or
linux.
We
will
provide
the
source,
but
but
to
support
to
support
building
dll.
C
So
so
dll
can
be
just
built
by
specifying
the
cmake
option
like
build
shade
library
is
equal
to
one
will
build
the
dll,
but
that
dll
does
not
work,
because
we
have
to
express
explicitly
export
those
method
or
class
methods
and
the
global
metadata
to
make
it
work.
Without
that
it
does
not
work
as
of
now
it
will
not
work.
C
A
C
So
it
works
fine,
so
that
I
mentioned
that
this
works
fine
for
building
shared
library
on
unix,
like
system,
because
there
is
no.
There
is
no
share
constraints
on
the
way
global
global
data
should
be
shared
from
a
shared
library,
so
library,
in
linux,
to
the
application.
But
there
is
a
constraint
the
way
dll
allows
you
to
share
the
its
own
heap
or
memory
usage
to
the
application,
so
it
has
own
constraints
on
sharing
that
for
dll,
okay,
so
for
dll
it
will
not
work,
and
so
my
thoughts
were
that
we
can
just
document
it.
C
C
C
Yeah,
so
we
have
to
add
so
the
global
data
is
basically,
I
think
one
of
them
is
thread.
Local
storage,
which
I
know
the
the
tracer
provider,
my
media
provider,
locker
providers,
which
all
are
the
global
data,
and
apart
from
that,
all
the
functions
we
have
to
do
it
again,
I'm
not
a
windows
expert
till
now.
It's
probably
I
may
be
missing
something,
but
I
think
it
needs
lots
of
changes
based
on
what
owen
has
been
saying
on
this
live
channel,
that
it
needs
lots
of
changes
to
support
it.
C
So
yeah
I
mean
I
thought,
probably
we
can
add
some
documentation
here,
building
as
a
standalone
project
somewhere
where
we
are
setting.
Probably
we
can
mention
the
shade
library
I
think
we
haven't
mentioned
that.
C
C
So
yeah,
that's
that's
something
I
think
probably.
A
Yeah,
I
think,
like
this
kind
of
changes
should
not
be
blocking
yeah,
but
it
yeah.
It
must
sounds
like
a
nice
to
have
feature
you
know
like
if
there
is
a
single
deal
of
open
telemetry
and
if
there
are
multiple
components
which
you
use
open
telemetry.
Maybe
they
can
share
one
component
and
maybe
save
some
memory.
C
C
A
Do
we
have
an
idea
of
how
how
big
is
our
library
like
even
for
we
compiled
into
static
library?
I
think
our
open
telemetry
library
should
not
be
maybe
just
a
few
mag
at
most.
C
Yes,
it
will
depend
on
what
all
level
two
libraries
we
are,
what
our
targets
we
are
compiling,
probably
api,
is
just
the
header
only
so
there
is
nothing.
Much
sdk
also
would
be
small.
I
don't
think
it
depends
on
the
other
component,
the
exporters.
I
think
that
may
have
depend
on
the
what.
B
C
C
A
C
Okay,
so
apart
from
that,
I
think
for
matrix,
I
have
raised
I'm
going
to
raise
the
pr
for
matrix,
sdk
view
aggregation,
I
think
I'll
be
adding
it
subsequently.
This
week.
C
I
just
wanted
to
to
pull
in
somebody
for
reviewing
it.
Apart
from
somebody
from
the
secret
space
community,
somebody
who
had
worked
on
the
matrix
specification,
I
was
relying
on
really.
He
was
really
when
he
was
part
of
the
metric
specification
team.
I
think
he
has
moved
out
so
I'll
try
to
pull
in
josh
or
cejo
for
reviewing
the
matrix
semantics
I
mean
or
not
the
source.
C
Matrix
specs
part,
but
I
really
like
your-
I
mean
it's
still
still
working
progress,
but
I
think
once
I
raise
raise
up
here,
I
think
I'll
need
help
from
you
guys
to
review
it
from
more
from
the
language
perspective.
C
C
Yeah,
so
probably,
I
think
I'm
planning
to
reform
the
view
I
think,
probably
by
today
or
maybe
tomorrow
I
should
be,
it
should
be
ready
for
review.
Aggregation
part
is
still
being
done
planning
to
do
it
in
couple
of
days,
don't
want
to
it's
already
delayed
for
by
one
week.
I
want
to
finish
it
up
in
a
couple
of
days.
Hopefully,
okay
I'll
raise
it.
A
Is
it
the
pr
which
is
marked
as
improved
rest?
Yes,.
C
C
Yeah,
it
is
stable.
I
don't
see
any
major
changes
happening
in
this,
so
I
just
need
to
see
some
of
the
stuff
which
is
breaking
air
up
now,
like
I'm,
not
sure
which
ones-
okay,
so
probably
some
some
things
are
still
missing.
The
test
test
case
tests
are
missing
and
some
things
are
breaking
somewhere.
So
I
just
need
to
see
those
things
so
hopefully,
but
today
or
maybe
it
was
by
tomorrow-
I'll
be
using
it
like
aggregated
part
times,
not
I'll,
be
raising
it.
C
So
yes,
most
of
the
things
are
complete.
So
I
think
once
I
add
the
test
cases
and
fix
the
issues
for
which
the
build
is
trading.
I
think
we
should
be
good
to
review
it
and
just
this.
This
was
one
of
them,
and
you
know,
after
that
I
need
to
raise
the
pr
for
this
aggregation
which,
right
now
I
put
as
a
placeholder,
so
I'll
be
doing
that.
C
So
yeah
december
at
least,
I
think
this
we
can
go
for
the
second
tom.
This
is
your
question
right.
C
I
am
not
sure
if
we
there
is
any
timeline,
do
we
want
to
do
it?
Probably
we
can
do
it
end
of
I'm
not
sure.
Should
we
do
it
in
december
or
if,
unless
anything,
substantial
coming
up
in
this,
because
I
I
think
this
number
is
going
to
be
a
bit
slow
in
terms
of
the
changes
happening,
but
I
think
we
can.
We
can
probably
we
can
by
mid
of
december.
I
think
we
can
review
it
and
probably
we
can
just
we
can
decide
if
we
really
want
to
do
a
release
or
not.
A
C
C
A
Yes,
the
outer
skin
yeah.
C
Yes,
so
should
we
add
the
tags
which
it
should
skip.
C
And
good
first
issue
with
all
some
of
the
tags,
which
I
feel
I
think,
if
we
are
adding
it
probably
it
would
be.
That
means
that,
even
though
these
issues
are
open
for
a
long
time,
we
definitely
want
somebody
to
fix
it
up.
We
need
a
help
and
or
something
just
wanted
to
check.
I
think
you
added
some
tag.
Also,
right
I
mean
we
are
going
to
skip
it
for
that.
A
Okay,
I
think
that
makes
sense.
We
can
add
more
tags
to
the
exclusion
list.
C
C
D
A
C
A
C
At
least
we
are
getting
a
reminder
and
I
think
we
were
able
to
close
some
of
the
old
issues
which
were
no
more
valid
so
which
was
good
good
to
have
this
so
yeah.
Okay,
so
probably,
let's
rely
on
do
not
stay
and,
as
we
see
any
issue
getting
marked
at
stale,
probably
we
can
decide
whether
we
should
add
this
label
do
not
scale.
C
Okay,
anything
else
we
want
to
add.
Otherwise
we
can
just
go
through
the
box.
C
C
C
Yeah
thanks,
there
was
one
pr
add
the
json
support
to
o
streams
fire
exporter.
I
did
had
few
comments
on
this.
C
C
So
my
comment
was
basically
if
we
can
enable
this,
if
you
can
have
a
macro
to
enable
all
this
features
just
on
exporter
support
and
by
default
it
is
not
enabled
that
should
be
fine.
C
Apart
from
that,
the
way
we
are
adding
the
recordable
the
way
we
are
providing
the
support
for
json,
I
think
I
felt
the
right
way
would
be
using
the
recordables
to
support
it
in
current
implementation.
It
is
just
using
spam
data
and
it
is
trying
it
it
uses.
The
expand
data
is
a
recordable
implementation
and
it's
trying
to
further
format
the
span
data
data
into
the
zone,
which
probably
I
think
the
recordable
could
be
the
better
of
doing
it.
C
I
mean
I
mean
so
the
content
repo
I
mean
the
so.
The
main
report
should
definitely
have
any
changes
going
to
hosting
hispanics
memory
exporter,
so
api
sdk.
These
are
part
of
main
repo.
So
any
change
happening
in
this
and
they
spec
specs
does
not
talk
how
we
should
be
formatting
this
or
stream
spam
data.
We
can.
We
can
format,
format
it
in
a
normal
std.
You
can
use
our
std
or
we
can
use
any
json
formatter.
So
it's
okay
to
go
it
in
main
repo.
C
But
if
even
if
we
want
to
put
it
in
main
repo,
at
least
we
should
know,
we
should
remove
the
dependencies
on
from
from
any
external
libraries.
C
Okay,
probably
I
agree
with
you
like.
If
you
want
to
create
a
separate
hosting
span
exporter
for
json,
we
can
add
it
in
the
content
repo
also
or
if
we
can
add.
I
think
both
either
way,
both
both
are
fine.
It's
just
that
the
o
stream
span
exporter
is
part
of
is
defined
by
the
specs.
That
means
it
can
be
part
of
main
repo
just
because
it
is
part
of
the
specs,
so
that
that's
the
only
reason
why
it
can
be
in
the
main,
repo.
C
C
C
C
C
I
think
tom
will
have
a
better
idea
of
the
other
expo.
He
was.
A
C
A
A
The
open,
telemetry
spec
requires
elaborate
exporter.
C
C
C
C
It's
just
that
only
three
were
only
one
of
these
three
protocols
was
supposed
to
be
supported
as
per
the
specs,
and
so
we,
I
think
we
only
we
started
with
udp
and
the
http
was
added
afterwards
and
probably
if
there
is
the
interest
for
grpc,
I
think
it
can
be
added
in
case
there
are,
if
somebody
really
wants
to
add
it
for
grpc.
C
A
C
A
A
D
C
C
D
D
Sorry,
it's
okay,
I'm
just
I
will
probably
fix
some
http
like
in
the
cpp
contrib
repo.
I
I
I
will
just
do
this.
Thank
you.
C
B
C
C
B
A
C
A
C
C
C
I
think
it's
great.
This
is
created
in
all
the
six,
probably
and
I'm
not
sure
if
it's
the
right
time
to
just
do
it,
but
let's
see
definitely
it's
a
breaking
change
so
possible
to
do
it.
But
it's
something
with
breaks.
Yeah.
C
Yeah,
it
would
be
sorry
for
the
api,
also
I'm
sorry
not
for
the
av,
because
we
don't
use
instrumentation
libraries
directly
in
the
api
right.
C
C
C
Support
building
reality
is
something
we
already
discussed.
This
is
work
in
progress
unable
to
export
the
library
with
the
existing
cmx
project.
This
is
with
me.
I
have
to
see
actually
once
I
have
gone
through
this,
so
what
is
it
yeah?
I
haven't
gone
through
this.
I'm
sorry.
I
think
it's
on
me
and
I'll
go
through
this.
C
C
C
C
So
this
is,
and
apart
from
that
yeah,
if
you
list
this.
C
C
C
C
C
Yeah,
I
think
I
tested
this
and
I
could
not
reproduce
the
issue,
probably
it's
with
bazel,
but
I
think
it's
for
civic.
I
don't
see
this
issue
is
coming
if
we
are
going
to
use
if
you
try
using
external
epsilon
c,
plus
plus
library,
since
the
issue
is
normal
coming,
no,
it
does
not
come
and
if
we
sub,
if
we
use
f
cell
as
the
stn
and
something
which
is
installed
externally,
so
I
couldn't
reproduce
it
with
this.
C
C
Yeah,
I
mean
probably,
I
think
we
can
close
these,
something
which
is
like.
Let
our
scan
scanners
close
it,
something
which
is
where
we
don't
think
it's
not
a
body,
it's
not
a
good
result
and
there
is
not,
and
and
even
the
the
the
issue
owner
is
not
replying
to
this
also,
so
I
think
we
can
probably
let
it
get
close.