►
From YouTube: 2023-03-22 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
Yeah
sure
and
I
can
share
my
screen,
foreign.
B
So
if
we
go
to
the
specification
today,
you
know
this
is
just
in
the
context
of
the
conversation
about
stabilizing
the
logs,
Bridge,
API
and
SDK.
B
You
know
if
we
go
to
the
logs
directory,
we
have
a
number
of
documents.
We
have
the
bridge
API
the
SDK
document.
We
also
have
this
readme
in
the
root,
and
this
readme
has
a
lot
of
useful
contexts
about
how
logging
Works
in
open
Telemetry
and
why
decisions
were
made.
It's
it's.
It
doesn't
contain
normative
language,
so
it's
kind
of
like
a
bit
of
a
strange
thing
to
have
specified
or
to
Mark
as
stable,
but
it
is
useful
context,
and
so
there's
kind
of
this
question
of
you
know.
B
What
do
we
do
with
this
document?
Do
we
do
we
somehow
change
it,
and
do
we
not
Market
as
stable?
Do
we
do
we
adjust
it
in
some
form,
such
that
you
know,
we
feel
comfortable
marketing.
It
is
stable,
despite
the
lack
of
you
know,
normative
language
in
here
and
to
give
a
little
context
about,
like
other
readme's,
for
the
other
signal.
So
if
we
go
to
metrics
the
metrics
read
me,
there
is
no.
B
There
is
no
status
to
this,
so
you
know
it
does
a
similar
thing
where
it
gives
I
I'll,
be
it
at
a
higher
level
than
what
logs
does
so.
It
gives
like
high
level
design
goals
and
Concepts
and
and
that
it
provides
links
out
to
the
other
relevant
sections
of
the
specification,
but
again
there's
no
status.
So
it
doesn't.
You
know
none
of
this
is
marked
as
stable
and
then
a
little
bit
more
context,
just
for
completeness
so
over
in
traces,
the
readme
is
empty.
B
You
know,
I
I,
think
the
trace
signal
could
use
with
some
of
the
additional
things
that
we've
done
in
metrics
and
and
logs
like
the
addition
of
a
readme
and
the
addition
of
a
data
model
document.
But
you
know
that's
kind
of
besides
the
point
I
guess
we
should
try
to
mirror
metrics
more
than
tracing.
A
Yeah
yeah
I,
agree,
I
think
what
we
need
to
do.
Probably
there
is
probably
some
language
that
needs
to
be
normative
here.
We
should
move
that
to
where
it
belongs,
I,
guess
or
if
the
appropriate
document
doesn't
exist,
maybe
create
that
right
and
the
rest
is
just
yeah.
Is
these
helpful
context
but
doesn't
need
to
have
a
stability
definition
right?
It's
it's
a
it's
just
context,
setting
right
so
I
I
agree
with
that.
B
A
B
A
normative
language
goes,
the
majority
of
the
you
know
the
languages
down
in
this
Trace
context
and
Legacy
formats.
This
this
is
normative.
I
have
a
PR
open
right
now
that
suggests
breaking
this
out
to
this
compatibility
folder.
So
you
know
it's
having
a
new
document
under
compatibility
that
you
know
essentially
just
lifts
and
shifts.
A
B
Okay,
so
I'll
open
if
others
agree,
if
there's
no
kind
of
you
know,
General
disagreement
with
that,
I'll
open
a
PR
to
remove
the
label
and
I
guess.
Another
thing
that
I
I
think
would
be
useful
to
do
is
to
provide
links
from
this
document
to
the
other
sections.
Just
as
like
a
helpful
navigational
thing.
B
There's
no
other
items
on
the
agenda.
We
should
I
suppose
briefly
talk
about
anything
that
we
view
in
the
way
of
marking
the
the
bridge.
Api
and
SDK
is
stable.
Any
remaining
items
there's
been
an
open
issue.
You
know
I
guess
backing
up.
Let's
just
go
to
the
issue
tracker.
B
Right
so
30.
A
The
one
that
says,
mature
logs,
Bridge
API,
doesn't
contain
implementation
details,
yep,
yeah
I
think
we
need
to
complete
that
to
finalize
that
one
as
well.
B
Right-
and
so
you
know
kind
of
my
attempt
with
this
PR
just
for
contacts
of
others
on
the
phone
was
was
you
know,
one
of
the
remaining
issues
is
to
proofread
the
logs
Bridge,
API
and
SDK
documents,
and
so
like
this,
this
PR
is
just
to
when
we
Mark
the
documents
as
stable
to
put
ourselves
in
a
good
footing.
B
You
know
traces
and
the
met
and
metrics
the
language
kind
of
diverges
a
bit
in
some
key
ways
and
I
think
metrics
is
a
little
bit
more
up
to
date,
and
so
you
know
I
try
to
align
Logs
with
some
of
the
the
new
language.
That's
been
included
in
the
metrics
specification.
B
A
B
I,
don't
believe
so
give
me
one
second
and
I'll:
pull
up
the
maintainers
notes.
I
think
there
was.
There
was
some
conversation
about
it.
I,
don't
think
that
there
is
any
feedback.
There's
just
like
folks
asking
questions.
B
Oh
so
Daniel
asks
about
the
term
appender
versus
Bridge.
B
You
know,
should
we
should
we
standardize
on
on
one
of
those,
because
you
know
in
the
in
the
API
document
we
use
the
term
appender.
Should
we
just
update
the
the
places
in
that
document
that
use
the
word
appender
to
to
refer
to
those
things
as
a
bridge
or
should
we
just
kind
of
you
know
Define
our
vocabulary
as
appenders
and
bridges
are
terms
that
are
used
interchangeably.
B
A
Is
there
anything
else
actionable
here,
I
see
Morgan
to
emphasize
I
think
we
do
emphasize
that
multiple
times
in
the
spec,
so
yeah.
C
C
A
B
Yeah,
so
that's
that's
the
current
state
of
things
with
respect
to
stabilizing
log,
bridging
at
API
and
SDK,
so
a
number
of
small
PR's,
but
nothing
that
should
be
too
controversial.
Hopefully.
A
B
Yeah
integer
just
for
some
contacts,
so
I
don't
feel
strongly
about
this
stuff.
So
you
know
I'm,
I'm,
guess:
I
I
I
want
to
reach
a
conclusion
quickly,
yeah
more
than
anything.
Okay.
A
D
D
Like
stable,
right
and
and
moving
it
Forward
after,
that
is
your
expectation
that
that
some
of
the
you
know
the
upender
providers,
like
let's
say
log4j,
may
decide
to
write
in
a
Pender.
That
makes
it
really
easy
for
people
that
are
using
log4j,
for
example,
to
emit
something
that
makes
it
easy
to
go
Downstream
through
all
of
the
other
pieces
that
need
to
that
that
it
needs
to
go
through
in
order
to
make
this
all
work.
A
I
guess,
for
me,
the
next
step
after
the
spec
is
declared
stable
is
to
make
sure
that
the
prototypes
that
we
have
are
turned
into
production
quality,
implementations
right,
that's.
That
would
be
the
number
one
priority
for
me
and
those
include
the
penders
there
right.
We
have
a
number
of
offender
implementations
in
Java
I
believe
at
least
it
would
be
good
also
to
have
one
in
in
go.
Also,
we
we've
been
working
with
go
folks
recently
discussing
how
we
can
enable
the
inclusion
of
the
context
in
the
logs
we.
A
So
we
ended
up
with
a
pretty
nice
solution
there
we
thought
that
we
won't
be
able,
but
apparently
we
will
likely.
The
context
is
going
to
be
also
possible
to
nicely
include
all
in
all
the
logs
immediate
through
the
law
goes
new
new
s-log
library.
So
to
me
it's
the
next
step
is
actually
that
right.
Just
have
production
quality,
implementations.
B
Think
the
order
of
operations
for
me
would
be
Mark
the
mark,
the
specification
as
stable
and
then
Mark
the
SDK
and
API
components
from
java
as
stable,
and
then
you
know,
work
with
the
instrumentation
folks
to
Mark
the
open
Telemetry
log
for
J
and
log
back
appenders
is
stable
as
well
just
kind
of
okay,
that's
kind
of
the
natural
order
that
things
would
need
to
happen.
I.
B
It
exists,
you
can
use
it
today.
Yeah,
okay,
oh.
A
I
guess
what
we
could
talk
about
is
about
the
client
instrumentation
seek,
so
we
we
had
a
discussion,
I
think
Martin.
You
asked
me
about
what
do
we
do
right?
So
we
had
a
discussion
in
the
technical
committee
today
and
I
guess.
The
outcome
of
that
discussion
is
that
we
think
that
the
scope
of
the
problem
that
you
you
guys
were
trying
to
solve
is
probably
too
large.
A
So
we're
thinking
that
probably
the
way
forward
is
to
try
to
limit
the
scope
of
what
do
you
guys
try
to
achieve,
at
least
in
the
near
future,
right
to
solve
the
what
is
absolutely
necessary
to
be
solved
right
now.
The
minimum
kind
of
to
minimize
the
score,
essentially
right
and
I
believe
Jack.
You
and
Josh
are
probably
going
to
attend
the
next
meeting.
The
next
fine
seek
meeting
and
then
you'll
pick
it
from
there
right.
You
try
to
figure
out
what
that
scope.
Exactly
is
that's.
B
Correct-
and
so
you
know,
I
think
we
talked
about
this
yesterday-
Martin
in
the
you
know
the
Tuesday
version
of
the
client
instrumentation
seg,
but
you
know
today's
meeting
the
one
that
was
just
a
couple
of
hours
ago
that
conflicts
with
the
TC,
and
so
if
we
could
try
to
find
a
new
time
that
accommodates
everybody.
B
That
would
be.
That
would
be
helpful.
C
Okay,
yeah.
That
sounds
good.
We
have
that
Tuesday
meeting,
but
if
that
doesn't
work
we
can
find
another
meeting
to
another
awesome.
B
I'll
just
talk
with
Josh
and
ask
him
if
that
time
works
for
him
on
Tuesdays,
and
you
know
if
everybody
else
from
the
group
you
know
is
already
allocating
time
on
Tuesdays
and
that
time
works
for
them.
And
then
maybe
we
can
just
kind
of
switch
so
that,
like
Wednesdays,
the
more
implementation
focused
one
and
Tuesday's,
like
kind
of
the
broader
meeting,
as
we
were
discussing,
okay.
C
Yeah
so
I
guess
for
the
next
meeting.
We
should
come
up
with
the
list
of
things
that
we
think
our
wish
list
and
like
the
minimum
requirements
that
we
that
we
want
yeah.
B
Yeah,
let's
just
I
I
guess
it
would
be
useful
to
have
a
Consolidated
list
of
all
the
of
all
the
the
the
requirements
that
are
in
progress
like
there's
a
number
of
PRS
that
are
in
various
forms.
So,
like
there's
specification,
PR's
related
to
the
semantic
conventions,
there's
a
specification,
PR's
related
to
kind
of
you
know,
structural
things
like
complex,
attribute
types,
I
think
there's
an
O
Tap
Out
two
at
least
two
oteps
out
that
relate
to
you
in
some
way.
There's
ephemeral,
resources
and
maybe
related
to
that
is
context.
B
Yeah
and
so
like,
if
we
could
just
pull
together
all
the
links
to
say,
like
you
know,
what's
what's
currently
all
the
work,
that's
in
flight
and
then
kind
of,
maybe
we
can
have
a
more
structured
conversation
about
what
is
absolutely
necessary
versus,
like
you
know
what
is
you
know,
what's
maybe
necessary
in
the
medium
and
long
term,
but,
like
you
know,
in
in
an
effort
to
get
something
done
like
what
what
can
be
pushed
for
at
least
some
period
of
time?
Well,
we
focus
on
on
delivering
the
the
more
critical
pieces.
C
Okay,
okay,
yeah,
so
let
me
know
if
the
Tuesday
works
for
free
with
you
and
Josh,
and
if
not
we'll,
try
to
find
a
different
time
and
have
this.
Have
this
ready
for
that
meeting?
Sounds.