►
From YouTube: 2021-09-08 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
A
A
A
We
just
wanted
to
discuss
basically
the
the
issues
which
are
created
by
josh,
so
he
has
created
last
week
so
there
at
least
two
issues
which
I
have
noted
down
here.
So
one
is
the.
A
B
A
B
A
Yeah,
so
basically
we
exclude
everything
from
this
I
mean
anything
which
should
not
be
there.
I
mean
you
can
see
my
screen,
anything
which
is
internal
to
our
implementation
and
it
should
not
be
used
by
the
external
customers.
We
exclude
that
from
the
documentation.
B
A
Because,
ideally
developers,
anybody
should
not
just
start
looking
into
the
code.
Try
to
see
that
this
something
looks
good
and
let
me
start
trying
to
use
it,
and
if
they
do
it,
I
think
they
have
they.
It's
that
the
risk
they
have
that
we
can
change
those
things
internally,
but
I
mean
they
should
go
through
the
to
our
documentation
and
try
to
see
whatever
we
are
whatever
we
are,
exposing
in
our
documentation
or
whatever
api
we
are
exposing
in
the
documentation.
They
should
be
using.
B
That,
okay,
so
now
we
explicitly
removed
all
the,
inter
all
the
header
files
with
details
included
right.
That's
that
yeah.
A
We
already
knew
it.
There
was
one
there
was
one
header
which
we
were
not
doing
it,
so
I
just
created
a
pr
for
that.
So
there
was
one
header
which
was
the
propagation.
There
was
some
propagation
detail.
Namespace
has
some
some
internal
functionality
which
we
were
still
exposing
in
our
documentation,
so
I
just
removed
that.
A
We
can
add,
we
can
document
those
internally
in
the
header
files
also,
but
I
mean
I
mean
I'm
not
sure
whether
we
should
really
do
it.
I
mean
we
should
not
encourage
developers
or
developers
to
start
looking
into
the
header
wheel.
Try
to
see
if
it
is
not
documented.
If,
if
you're
not
giving
any
warning,
then
they
should
not
be
using
it
and
all
these
things
it
should
be
whatever
we
are
exposing
in
our
documentation.
They
should
just
use
that
so
so,
like
I
mean
the
example
I
mean,
one
of
the
example
would
be.
A
Basically,
the
semantic
convention
does
make
sense
that
we
should
add
the
the
note
in
the
header
file
and
we
also
document
it,
because
we
expose
that
semantic
namespace
implementation
in
our
public
api.
A
B
Yeah,
I
think
I
haven't
seen
our
document
says
the
details.
Namespace
is
not
intended
for
the
developer
use.
So
do
you
think
we
can
add
that
statement
to
to
our
document
to
see
that
details
is
only
for
sdk
developer,
not
for
our
sdk
user.
A
We
can
do
that,
but
where
should
you
think
we
should
add
it?
I'm
just
thinking.
I
if
you
just
want
to
add
it
that
this
namespace
is
internal.
We
should
not
be
used.
We
can
do
that,
but
where
do
we
do
it?
Should
we
add
in
the
public
api?
We
should
not
do
it
there,
because,
anyway,
we
are
not
exposing
them
and
we
can
add
it
as
a
comment
in
the
header
file.
If
that
makes
sense,.
A
Yes,
so
wherever
it
is,
I
don't
see
there
are
lots
of
files.
I
think
they're,
just
three
or
four
files
which
are
internal,
so
we
can
do
that.
So,
let's,
let's
see
what
josh
is
saying
so
josh
is
saying
that
all
such
detailed
names
should
have
documentation
denoting
these
are
electronic
packages.
So
he's
saying
that
it
should
be
documented
in
the
header
file
and
also
we
should
document
it
somewhere
in
the
versioning
document.
B
B
A
B
A
C
D
Sig
is
a
special
interest
group.
I've
been
following
it
very
interested
in
using
it
and
contributing
so.
A
A
D
Yeah
I
saw
the
I
saw
a
vc
package
for
an
rc4
put
in
and.
D
Okay,
I
didn't
know
if
you
guys
were
aware
of
that.
The
port
got
accepted
yeah
in
the
vc
package,
but
they
pulled
out
open
telemetry
at
the
last
minute.
So
I
thought
I'd
okay,.
D
That's
that's:
that's
good!
Yeah
yeah!
I
know
this.
This
committee
talked
about
or
this
group
had
talked
about
doing
it
after
the
1-0
release,
but
so
somebody
jumped
the
gun
on
it.
B
D
I
saw
that
you're
talking
about
this
context
span
or
or
something
else.
D
A
Thanks
so
so,
just
going
through
the
next
issue,
which
we
have,
let
me
open
that
so
yeah.
So
this
this
is
one
which
is
open,
so
we
so
there
are
standard
set
of
environment,
variable
names
which
we
should
be
using
for
otlp
exporter.
A
A
A
A
B
Your
comment
besides
comment,
I
mean
put
all
the
environment.
Variable
parsing
code
under
like
feature
underscore
experiment
right.
So
when
user
compiles
on
our
code
by
default,
it
is
not
included.
So
there's
no
environment
variable
support.
A
C
B
C
B
A
A
C
A
B
Yeah
no
from
the
code
side,
I
mean
that's
the
case,
but
for
the
user
side,
when
the
user
want
to
use
that,
but
we
we
currently,
we
have
some
environment
where
both
the
user
may
be
confused
right.
We
have
the
the
skk
has
some
variables,
but
it
is
not
compliant
with
the
spec
so
whether
to
use
it
or
not
or
maybe
may
cause
confusion.
B
A
A
Somewhere
here
we
can
definitely
add
that
we
have
already
not
added
the
environment
variables,
so
we
can
add
the
list
of
all.
I
mean
all
the
current
set
of
non-compliant
environment
variables,
which
we
support.
We
know
that
these
are
not
something
which
is
as
good
as
x
and
this
we
are
going
to
remove
them,
but
I
think
once
we
are
compliant,
we
are
going
to
add
the
new
environment
variables
and
support
both
of
them.
A
Okay,
so
we
are
going
to
keep
it
we're
not
going
to
do
any
change
in
the
environment
variables
we're
not
going
to
make
them
behind
the
feature
flag,
but
we
are
just
going
to
add
the
documentation
that
these
are
the
environment.
We
support-
and
this
is
not
something
same
same
as
the
specs
and
but
we
are
not
going
to
remove
them.
Also
in
the
future.
C
A
And
let's
go
through
probably
let's
go
through.
These
were
the
main
issues
I
wanted
to
talk.
Schematic
convention
are
not
considered
stable
and
need
to
be
clearly
marked
already.
We
have
it
pr
for
that.
A
So
I
think
george
had
some
comment.
We
can
add
and
release
this
1.2
and
he
had
a
comment
on.
Let
me
go
through
that.
Okay,
he
did
have
a
comment
that
if
we
can
add
in
the
versioning
document,
which
is
already
done
now,
so
we
do
have
a
note
here
in
the
versioning
document,
and
we
do
have
a
note
for
the
in
the
actual
header
for
x.
A
A
Yeah-
and
apart
from
that,
this
we
discussed
this
is
fine
this
we
should
be
good
to
close
it
now
from
context
and
it
sticks
as
a
parameter.
We
have
already
closed
the
public
mystery.
A
A
A
See
if
you
want
to
discuss
something
apart
from
this,
and
I
think
we
are
good
discussing
for
what
we
had
in
the
agenda.