►
From YouTube: 2020-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
B
F
D
F
When
my
brother
was
driving
back
from
san
diego
and
stopped
in
san
fernando
this
weekend
for
lunch,
and
it
was
120
degrees
in
san
fernando,
which
is,
if
you
do
celsius,
that's
almost
49
degrees.
F
F
It
is
actually
a
hiker
died
that
weekend,
who
was
out
hiking
near
l.a
at
all
that
town.
F
Mean
it
gets
hot
right
like
that's,
like
kind
of
the
great
vine
going,
if
you're
going
from
los
angeles
north,
it
does
get
hot
there,
but
that's
that's
a
record.
It
was
120
in
san
luis
obismo
that
was
recorded
10
miles
from
the
coast,
and
that
is
the
hottest
temperature
ever
recorded
that
close
to
a
coastline
in
north
america.
H
E
Scary:
okay,
okay,
let's
wait
one
minute
in
case
somebody
wants
to
add.
I
think
I
see
enough
items
in
our
agenda
today,
but
let's
wait
one
more
minute.
Actually
we
have
12
people.
That's
probably
that's
probably.
E
Okay,
let's
start
yes
agenda.
First,
ga
process
discussion.
C
C
E
E
Party,
so
I
would
say
it's
not
so
important,
but
this
could
be
breaking
or
yeah.
I
would
be
breaking
the
tracing
api
because
it
wouldn't
be
changing
stuff,
but
removing
stuff.
E
E
I
E
If
you
can
go
andre,
you
do
the
do
the
bottom
there's,
because
you
should
already
mention
that
link
it's
up
up.
Please
there.
You
are
remove
context,
interaction
from
tracer
correlation
context,
manager,
that's
one
so
yeah
bogdan
started
doing
something
about
this
issue.
So.
E
E
C
Okay,
I'll
set
it
at
that
for
now,
then
that's
one,
the
other
clarify
values.
For
there
we
go.
J
K
J
I
Yeah,
I
agree
they
already
linked
the
log
data
model
which,
which
lists
some
some
values
and
I'm
quite
sure
we
should
be
able
to
find
a
mapping
for
each
language
framework.
For
that
one.
I
Sdk
logging
usage
errors
and
such
because
there
is
an
environment
variable
that
is
consumed
by
potentially
all
sdks
and
therefore
it
has
to
be
aligned
somehow
or
it
wouldn't
make
sense.
Actually.
J
J
C
So
this
one
suitable,
let's.
I
C
E
L
Right
now
deciding
this
kind
of
thing
in
the
metric
stick
right
now,
so
I
mean.
K
L
Definitely
d1,
it's
gonna
be
a
breaking
change.
It
needs
to
get
decided
so.
C
L
Not
100
familiar
with
area
but
metrics.
J
I
I
personally
agree
that
the
renaming
should
be
done,
because
I
see
that
this
is
conflicting
somehow,
but
I
could
imagine
that
just
changing
the
the
marketing
term
used
in
markdown
would
be
sufficient
and
we
don't
have
to
touch
all
the
code
and
and
change
this
everywhere
to
to
deter
people
from
mixing
these
things
up.
If,
if
this
is
too
much
of.
C
C
Yeah,
okay,
so
I'm
not
sure
if
that
was
in,
if
it's
helpful
to
believe
this
note.
I
D
M
A
good
point
on
the
on
the
on
the
receivers
and
exporter.
J
K
C
C
We
have
from
last
week
still
83
to
do's
net
zero
change
again
this
could
have
been
like
somewhere
addressed
or
some
were
resolved,
and
then
new
ones
are
added
net
zero.
In
other
words,
from
last
week
when
I
took
the
measurement
gas
and
items
in
progress,
we
have
seven
down
from
one
down
one
from
last
week
and
we
have
58
done
one
up
from
last
week.
C
The
p1
issues
overall,
barring
the
ones
we
just
triaged,
is
15
out
of
31
completed
to
about
the
halfway
mark,
and
this
is
the
most
immediate
concern,
one
which
I
think
we
really
need
to
talk
about.
Is
we
have
three
open
out
of
15
that
are
labeled
p1
and
spec
trace?
C
So
these
need
to
arrive
at
some
conclusion
in
order
for
us
to
move
on
to
the
next
step
previously.
I
Because
I
noticed
that
that
some
prs
are
labeled
just
like
issues
usually
are
not
that
one.
Oh
yeah.
E
Sorry,
yeah
sorry
yeah.
I
I
changed
that
one,
because,
even
though
this
is
not
originally
like
an
issue,
I
think.
F
E
M
E
E
H
And
just
a
reminder
like
we
wanted
to
trace
spec
issues
closed
last
week,
so
this
is
the
first
week
where
the
tc
has
the
permission
to
rapidly
make
rulings
on
things.
H
Obviously
that
doesn't
help
us
if
we're
just
waiting
on
prs
to
get
finished.
But
if
we
have
any
discussions
that
are
still
swirling,
the
the
tc
is
off
the
leash.
So
to
speak,.
E
E
C
So
do
you
guys
want
to,
should
I
realize
for
my
time
so
that
way
the
discussion
can
continue
on
that
topic.
E
Yes,
I
would
propose
that.
Okay,
thank
you
thanks.
So
much
okay,
so
in
that
case,
let's
get
into
the
discussion.
E
Well,
actually,
there's
one
related
to
the
to
what
you
were
talking
about
andrew
is
about
the
ga
process,
discussion
about
whether
we
should
do
a
spec
freeze
and
stop
adding
new
changes
unless
they
are
identified
as
critical.
J
G
J
Mean
guys
do
we
prohibit
any
changes
to
the
specification
repo
at
all.
Is
that
what
we
intend
to
do,
and
the
reason
I'm
asking
is
there
is
the
logging
part
that
is
not
related
in
any
way
to
what
we
want
to
ga
and
it
is
more
or
less
independently
being
worked
on
by
a
few
people.
So
if
we
outright
make
it
illegal
to
make
any
changes
to
the
repository,
then
these
people
will
have
to
stop
working.
E
H
H
J
I
H
Yeah,
of
course,
when
like
for
reference,
when
we
went
through
like
locking
down
the
w3c,
trace
contact
spec,
it
was
the
same
sort
of
thing
like
the
core
areas
were
frozen,
but
what
we
call
the
non-substantive
change,
so
just
a
pure
editorial
change.
Those
were
still
fine.
E
J
We
either
make
them
part
of
the
g
1.0
ga
or
we
don't
right.
If
we
make
them,
then
they
have
to
be
done
before
we
freeze
the
spec.
That's
the
decision
we
need
to
make.
Are
they
part
of
it,
then?
Are
they
still
required
for
ga?
Then,
regardless
of
the
of
the
priority
they
have
to
be
done
before
they
decrease
the
spectrum,
provided
that
they
are
a
substantial
change
to
the
specification
if
we
believe
they
are
not
necessary
for
that,
then
remove
the
label
right,
move
it
to
the
after
the
g8.
J
If
anything
is
remaining
there
in
the
list
required
for
ga,
then
I
don't
think
we
can
freeze
the
spec
unless
it's
some
editorial
change.
A
I
mean
we
have
88
issues
marked
as
required
for
ga
right
now.
J
E
Andrew
oh,
never
mind.
No,
I
just
stopped
sharing.
I
just
wanted
to
go
because
I
was
thinking
that
some
changes
are
additive,
so
maybe
they
can
just
be
postponed,
but
there
are
things
that
will
be
breaking
the
api.
So
it's
yeah.
I
don't
know
I
mean
that's
what
the
that's.
That's
exactly
my
question.
A
A
J
I
think
we
need
to
make
an
important
call
here.
Do
we
want
to
freeze
the
spec?
Do
we
do?
We
agree
that
freezing
the
spec
is
necessary
for
for
the
ga
now,
maybe
in
a
couple
weeks,
we
have
to
freeze
it
so
that
the
implementation
can
implementations
can
catch
up
and
to
satisfy
that
spec
or
we
don't
right.
If
we
in
my
opinion,
if
we
make
a
decision
to
freeze
the
spec,
then
that's
the
the
natural
outcome
of
that
decision.
The
issues
either
make
into
the
spec
or
they
don't.
There's.
J
C
I'm
not
sure
whether
we're
talking
about
a
bigger
picture
or
whether
we're
talking
about
the
more
immediate
goal
for
this
week,
which
is
making
sure
the
trace
part
of
the
api,
is
locked
down.
First,
like
metrics,
can
come
second
to
be
locked
down,
so
that
was
the
strategy
before
trying
to
lock
down
by
signal
right,
trace.
C
C
So
I
like
I'd
like
to
hopefully
address
the
first
focus
of
this
week.
What
do
we
need
to
do
in
order
to
lock
down
the
trace
api.
J
J
That's
one
purpose,
the
other
is
we
will
want
to
have
a
complete
spec
so
that
the
sdk
authors
can
go
ahead
and
implement
that
that's
separate
right,
which
one
is
that
we're
trying
to
solve
for-
and
I
guess
both
are
important,
but
the
one
that
requires
freezing
for
implementation
does
not
work
with
a
soft
approach.
In
my
opinion,
right,
if
you
keep
adding
stuff
to
the
spec,
then
you're
just
moving
the
goalpost
right
that
the
implementation
has
to
catch
up
on
that.
J
Okay,
so,
yes,
I
think
that's
reasonable
and
we
probably
have
to
do
that
early,
but
at
some
point
we
have
to
also
do
the
harder
threes,
so
that
implementations
know
that
it's
complete.
I
can
now
go
ahead
and
fulfill
it
with
the
implementation,
so
that's
probably
two
two-step
sort
of
free
software's
and
then
a
half
is
at
some
point,
yeah
yeah
exactly.
E
E
E
Yeah,
for
that
probably
we
need
to
plan
some
calls
so
either
the
tc
or
our
approvers.
I
don't
know
who,
but
we
need
to
go
and
probably
have
to
decide
what
items
need
to
be
left
out.
J
We
have
that
hard
loop
to
see.
Are
they
actually
required
or
we
can
just
yeah.
A
M
Yeah,
I'm
just
looking
over
the
p2
issues.
It
seems
there
are
a
few
issues
that
can
easily
be
moved
after
ga
because
they
are
additive
like
the
prepared
span.
I
don't
think
this
needs
to.
It
would
be
a
breaking
change,
but
I
guess
even
after
removing
things
that
can
be
added
later,
we
will
have
to
make
some
harder
chords.
Of
course,
I.
J
Suggest
we
do
this,
what
what
just
christian
did
right
if
anybody
can
have
a
look
at
the
open
issues,
p2
and
p3
issues,
and
they
think
that
this
can
be
moved
out
of
the
ga
then
comment
on
the
issue:
make
that
proposal
open
the
discussion
around
removing
that,
if
each
of
us
does
a
couple,
then
what
we
will
be
left,
we
can
do
another
meeting
live
meeting
and
make
the
final
call
on
the
remaining
stuff.
J
C
There's
14
p3s
and
24
p2s,
so
the
the
theory
of
the
prioritization
was
we
could
easily
cut
any
of
the
p3s.
The
harder
decision
starts
coming
on
the
p2s,
whether
any
of
those
need
to
be
pushed
off
to
later,
but
that's
where
we
could
work
towards
carlos.
Did
you
want
a
dedicated
meeting
time
for
that.
E
C
E
Can
do
that
yeah
yeah?
I
suggest
yes,
of
course,
if
somebody
wants
to
work,
asynchronously
like
tikran
suggested
feel
free
to
do
that
and
if
there
are
still
pending
items,
let's
do
a
call.
So
let's
skip
that
call
this
week
tomorrow
or
thursday
or
friday.
C
Okay,
so
after
this
meeting
I'll
post
in
the
getter
the
list
of
the
these
issues,
that
would
help
if
they
had
a
comment
as
yeah
and
then
find
out
when
we
have
the
meeting
which
ones
to
change
up
on
the
priority
with
you
and
wherever
else
I
can
have
on
the
call
as
well.
M
E
M
Okay,
if
that's,
if
the
package
is
not
associated
with
the
context,
then
we
can
probably
solve
this
issue
easily
by
just
saying
there
should
be
a
set
baggage
on
the
span.
F
Yeah
baggage
is
its
own
separate
system.
Now,
that's
part
of
context,
and
so
if
you,
if
this
is
like,
gets
back
to
that
issue
of
like
it's
ideal,
if
methods
have
access
to
the
context
when
possible,
not
just
the
span,
because
it'll
that'll
give
you
the
ability
to
deal
with
this.
That.
M
But
there
is
one
api
where
this
breaks-
and
this
is,
if
you
set
an
explicit
parent
with
with
a
spank
context
or
a
span,
then
you
lose
the
context.
And
I
have
a
pr.
G
M
M
So
if
you
get
disbanded
the
exporter
which
context
should
be
associated
with
it,
it
could
not
an
explicit
parent,
I
would
just
add
the
context
of
the
parent
so
to
speak,
and
then,
when
we
use
a
root
span,
when
we
have
a
root
span
that
is
associated
with
when
we
start
a
root
span,
I
think
the
current
context
is
implicitly
the
parents,
but
I'm
not
sure
of
that
either.
N
G
Are
you
more
saying
that
we
need
the
ability
to
include
the
context
when
creating
a
span,
who
has
a
different
who
has
a
different
parent,
so
it
can
have
the
correlation
context
from
there
and
not
that
it
needs
to
like
hold
on
to
it.
That
was
my
concern
with
it.
Like
the
former,
I
I
understand
and
would
agree
with
the
latter,
where
it
needs
to
have
a
reference
to
the
parent
context.
I
don't,
I
didn't
understand.
M
F
Issue
like
we
don't
want
to
keep
having
to
pile
everything
on
top
of
spans
and
tracing.
We
want
metrics
and
various
other
things
to
be
able
to
pass
context
around.
So
I
think
it's
about
if
you're
saying
you're
in
some
situation,
where
you're
building
up
spans
that
are
not
active.
F
It
means
like
those
situations,
need
to
be
like
context,
merging
or
context,
switching,
not
just
not
just
something
that
happens
on
the
span,
because
presumably
metrics
and
all
kinds
of
other
things
may
want
to
start
putting
stuff
into
that
context
or
into
baggage.
So
I.
K
M
G
M
G
M
G
So
if
you
want
the
baggage-
and
you
want
this
parent-
like
you-
maybe
you
just
extracted
it
to
the
you
should
set
that
as
the
current
context.
That
gets
you
the
baggage
and
the
parent
and
then
start
a
spam.
F
Yeah,
I
think
this
just
points
to
a
couple
of
areas
where
we're
maybe
saying
like
set
span
is
active
or
we're.
You
know
manipulating
spans
in
a
way
that's
separate
from
whatever
is
active,
and
I
think
maybe
some
of
those
methods
to
be
need
to
be
lifted
to
being
saying
a
set,
active
context
and
a
way
of
like
manipulating
multiple
contexts.
At
the
same
time,
if
you're
not
using
some
kind
of
active
context,.
G
I
mean,
I
think,
it's
in
large
part,
just
how
do
you
keep
baggage
like
when
the
example
I
gave
in
the
thread
is
if
I
one
of
the
ways
to
move
a
span
or
create
a
child
span,
create
it
that
it's
inactive
and
pass
it
off
to
like
the
async
callback
or
a
new
process.
You
then
set
span
as
the
current
one
and
then
set
the
child.
G
That's
new,
but
then
the
baggage
is
gone,
so
you
have
no
baggage
in
that
new
processor
async
callback,
whatever
so,
really
I
guess
what
you
need
to
do
is
create
an
inactive
span
in
a
new
context
that
carries
the
baggage
with
it
then
pass
that
and
set
that
as
the
current
cont
attach
that
so,
instead
of
doing
spam
stuff
like
set
spam
in
the
in
the
new
callback,
we
need
to
get
kind
of
get
rid
of
that
stuff
and
just
say,
use
context
itself.
F
G
M
I
think
the
current
situation
is
even
kind
of
funny,
because,
if
you
propagate
across
different
processes,
you
have
to
use
propagators
and
those
already
operate
only
on
context.
So
if
you
operate
cross
process,
you
will
get
the
baggage,
but
if
you
operate
cross
thread
in
one
process,
the
simplest
api
loses
the
baggage.
That's
the
current
situation,
at
least
in
java.
G
Well,
yeah,
I
mean
those
methods
are
in
the
tracer
or
span
instead
of
the
content,
like
people
should
be
using
the
context
functions
to
do
this
kind
of
stuff,
I
think,
is
what
should
change
so
it
shouldn't
change
those
methods.
Instead,
where
we
document
stuff,
like
passing
a
thread
to
a
new
passing
a
span
child
span
to
a
new
processed
thread,
whatever
you
want
to
call
it
use
context,
don't
use
span,
set
child,
don't
use
tracer,
who
said
spain.
M
Yes,
as
far
as
I,
no
the
only
things
you
would
need
to
change.
This
change
is
removing
the
set
parents
that
take
a
span
context
in
a
span.
Everything
else
should
be
fine.
M
I
mean
you,
you
need
to
have
some
way
to
create
a
you
may
might
need
a
way
to
create
a
spam,
con
full
context
of
just
a
span
to
work
around
some
old
apis,
but
maybe
you
don't
even
need
that,
and
I.
G
E
By
the
way,
I
got
impression
that
the
original
discussion
was
about
whether
there's
any
logical
operation
defined
or
should
be
between
correlation
context
or
backups
now
and
span,
which
is
something
we
don't
have.
I
think,
and
for
this
I
could,
I
could
really
suggest
we
asked
spock.
Then
he
was
the
original
leader.
I
remember
back
at
the
time
he
explained
us
what
you
know
why
they
separated
that
and
for
the
sake
of
time
I
suggest
we
continue
that
offline.
E
Nice,
thank
you.
I
think
yeah
hasn't
commented
on
that
one.
But
let's
let
me
poke
him,
because
this
is
something
that
I
think
that
especially
needs
his
his
feedback.
F
Yeah,
so
I
just
wanted
to
put
this
on
people's
calendars.
We
are
trying
to
get
this
resolved
this
week.
We
had
a
good
discussion
on
thursday.
I
have
a
proposal
based
on
that.
I'm
going
to
finish
it
up
today
and
so
I'll
either
be
releasing
it
tonight
or
early
tomorrow
morning
so
and
then
we'll
be
having
a
meeting
thursday.
Let
me
double
check
the
time
thursday.
It's
8
a.m,
pacific.
F
So
it
would
be
really
great
if
people
could
review
that
just
put
market
on
your
calendar
right
now
to
review
that
otep
tomorrow,
so
that
we
can
pass
it
on
thursday.
I
think
it.
It
resolves
all
the
various
threads
on
this
issue
in
a
way,
that's
actually
pretty
clean
and
is
like
a
fairly
minor
change
to
status
codes,
so
I'll
get
that
o-tip
up
soon,
but
I
just
wanted
to
flag
it
at
this
meeting
today
so
that
we
don't
spend
thursday
just
reading
it
for
the
first
time.
F
F
Yeah
no,
no
problem,
it
was
a
little
tricky
wicket,
but
I
think
I
got
something
clean,
but
we
do
want
to
get
it
resolved,
quick,
so
awesome
posting
it
in
sl
gitter
as
well.
If
you
want
me
to
ping,
you
directly,
just
put
your
name
down
there
and
I'll
ping.
You
directly.
E
Yeah,
I
remember
that
this
is
very
important,
because
if,
if
it's
not
resolved
by
thursday,
then
the
tc
will
have
to
make
a
heart
call
so
yeah,
please
try
as
much
as
you
can
to
to
make
it
to
this
call
right:
okay,
okay,
next
one
armin
and
giovanni
about
adding
a
couple
of
pr's.
I
Yeah,
so
we
have
this
actually
closed,
but
not
really
resolved
issue
with
required,
sga
that
we
wanted
to
add
the
semantic
conventions
as
yaml
files,
so
that
people
can
work
with
it
and
chovani
added
some
prs
that
edit.
I
just
wanted
to
make
sure
people
are
not
confused
or
even
frightened,
because
while
the
change
set
looks
huge,
it
only
changes
the
syntax,
because
the
handcrafted
markdown
tables
are
now
generated
and
therefore
aligned
in
the
same
format
and
so
on.
So
there
is
no
no
content
that
has
changed
no
semantics,
it's
just
syntax.
E
Okay,
moving
on
otlp
to
hotel,
that's
one
of
the
things,
but
we
already
briefly
talked
about
it
yeah.
We
also
talked
about
hotel,
lock,
level
yeah.
We
only
have
12
minutes,
but
maybe
we
can,
but
for
the
otlp
to
hotel.
Probably
we
should
discuss
offline
because
I
feel
that
tigran
since
he's
he's
gone,
you
know
like
we
really.
E
Interested
okay,
so
I
guess
that
ma
the
obvious
question
for
this
one
is
whether
we
should
use
a
log
data
model
or
something
like
that,
and
the
idea
is,
is
a
a
stigma
was
saying
like
java
or
python:
they
have
different
login
levels
or
they
may
so.
You
need
to
unify
them
and
probably
to
find
some,
you
know
table
that
maps
to
each
one
of
them
does
does
this
idea
make
sense,
or
you
guys
think
that
we
should
allow
this
to
be
language
specific.
I
So
I
think
that
it
can
be
language
if
you
use
one
one
variable
one
environment
variable
that
is
consumed
by
r
unless
it
has
the
value
python
equals
warning
java
equals
something,
but
that
would
just
make
things
complicated,
yeah.
I
think
we
we
should
be
able
to
agree
that
we
can
use
the
security
number
from
the
block
data
model
which
we
already
have
and
which
and
where
people
thought
that
all
use
cases
are
can
be
mapped
to
these.
E
K
I
have
a
general
concern
with
this
whole
environment.
Environment
variable,
it's
kind
of
I
mean
for
normal
java
logging.
K
Every
logging
framework
has
its
own
way
of
specifying
the
log
level
and
now
we're
introducing
it
another
one,
and
it
feels
like
for
like
java
users
who
are
used
to
doing
java
logging,
adding
yet
another
inconsistent
incompatible
environment
variable
for
this.
I
feel
like
it's
going
to
be
confusing
for
java
users
for
people
who
are
actually
trying
to
set
up
the
sdk
to
not
just
use
whatever
logging
framework
they're
using
that
they're
used
to
and
that
the
application
has
already
set
up
that
they
have
this
other
thing
they
have
to
do
also.
K
So
I
think
that's
my
main
concern
just
in
general
with
this,
with
this
being
specified
at
this
level.
F
K
I'm
not
exactly
even
sure
how
that
would
work,
because
it
would
depend
on
the
what
logging
implementation,
the
heat
that
was
actually
being
used
like
how
to
actually
do
that.
Mapping
doesn't
feel
like
there's
a
clean
way
to
do
that
at
the
sd.
From
the
sdk's
perspective,
like
sdk,
doesn't
know
whether
someone
is
wired
up
blog
for
j,
pointing
like
with
a
re
with
an
appender
that
it
pulls
in
the
java
util
logging
framework.
Like
I
don't
know,
sdk
doesn't
know
what
that
setup
is
like.
How
is
it?
How
can
it
do
that
mapping?
F
K
Well-
and
I
don't
know
how
the
sdk
could
do
this
mapping
from
an
arbitrary
environment
variable
into
whatever
arbitrary
logging
framework
logging
implementation,
the
user
happens
to
be
using.
E
K
E
Yeah
and,
for
example,
yeah
okay,
trying
to
just
go
into
details
about
this
like
the
agent,
I
know
that
they
do
bytecode
manipulation,
so
they
are
redirecting
the
calls
from
java
multi
logging
into.
I
forgot,
which
level
is
this.
K
E
F
I
just
had
an
epiphany.
I
realized
this.
This
is
about
internal
logging
out
of
the
sdk
right,
but
we
are
going
to
be
adding
like
something
that's
more
like
hotel
logging
from
the
logging,
sig
post,
ga
right,
like
all
the
logging
people,
have
been
meeting
regularly,
they're
very
excited
about
that.
F
So,
in
that
case,
hotel
log
level
in
a
world
where
that's
existing,
you
would
imagine
hotel
log
level
would
be
an
environment
variable
associated
with
whatever
that
logging
feature
is,
and
if
we
camp
on
it
now
to
indicate
just
the
log
level
like
diagnostic
log
level,
for
the
tracer
or
the
sdk,
we
might
camp
on
an
environment
variable
that
could
even
confuse
future
open
telemetry
users.
Good
point.
I
It
should
rather
be
something
like
hotel,
sdk,
diagnostic
clock
level,
or
something
like
that,
but
if
we
can
agree
that
there
is
no
reasonable
mapping
or
that
it
is
not
even
possible
from
a
technical
perspective,
we
might
as
well
just
drop
that
hotel
lock
level
for
now
and
introduce
something
better
if
possible.
Later
on.
I
just
checked
the
compliance
matrix
and
only
js
has
implemented
it
so
far
from
the
ones
that
that
populated
the
metrics
yeah.
F
We
we
may
want,
I
don't
think
we
have
a
hotel
debug
flag.
Do
we
not
a
universal
one.
F
Right
right,
but
I'm
saying
rather
than
well,
this
is
like,
if
you
want
to
have
fine-grained
control
of
your
logging,
but
I
think
the
most
common
use
cases
and
users
being
like
I'm
trying
to
set
this
up
and
it's
not
working.
So
I
just
want
to
turn
debug
on
and
have
open,
telemetry
explain
all
the
things
to
me.
So
we
could
just
have
a
simpler
flag
for
end
users
called.
F
You
know:
hotel
debug.
If
you
set
that
true,
then
under
the
hood,
it
will
do
whatever
it
needs
to
do
to
to
map
that,
to
what
debugging
would
look
like
in
that
language
and
if
you
want
to
get
into
the
weeds
about
like
no,
I
want
production
logging
from
inside
of
the
sdk,
but
only
at
this
level
or
whatever.
That's
we're
just
like
not
going
to
deal
with
that
right
now.
That
can
be
a
language
specific
thing
that
you
do
since
it
sounds
like
it's
not
at
least
in
java
and
maybe
other
languages.
F
Yeah,
maybe
this
is
like
a
poor
practice,
but
it
seems
to
me
we
it
would
be
great
to
supply
our
end
users
with
a
very
simple
way
for
them
to
just
turn
on
debug
mode
and
understand
what
the
heck
is
going
on.
So
ideally
it
would
be
nice
if
we
didn't
over
complicate
that
unnecessarily.
B
Good
question
it
seems
to
me
like
currently
we
don't
have
a
clear
understanding.
What's
the
internal
like
troubleshooting
log
experience
for
the
for
the
open,
telemetry
overall,
like
api
sdk,
should
we
have
that
interface
also
for
like
plugins,
like
exporters
and
propagators,
and
do
we
try
to
clarify
that
or
we
think
it's
okay
for
now
I
ask
this
because
it
seems
like,
for
example,
if
we
have
environment
variable
that
gives
a
clear
indication.
F
So
I
guess
what
I'm
proposing
is
like:
let's
not
get
into
anything
like
that
right
now
and
just
assume
some
simple
case
where
a
user
is
not
trying
to
do
anything
in
production,
they
just
want
to
turn
the
system
into
debug
mode
so
that
they
can
understand,
what's
going
wrong
with
it,
and
we
could
deprecate
this
environment
variable
later.
If
we
come
up
with
a
fancier
way
of
doing
it,
I'm
just
trying
to
think
of
the
the
simplest
thing
that
would
solve
the
primary
use
case
for
this.
F
It
also
makes
it
kind
of
obvious
that
you
shouldn't
do
this
in
production
right
like
having
debug
equals.
True,
that's
clearly
an
environment
variable
you
wouldn't
want
to
have
set
in
production,
and
so
we
say
we're
we're
just
going
to
try
to
handle
this
just
for
the
use
case
of
either
a
debug
mode
or
in
production
mode,
and
we
can
come
up
with
something
fancier
later,
but
something
simple
like
that
might
allow
each
language
to
translate
that
to
whatever
it
might
mean
in
that
language.