►
From YouTube: 2023-02-08 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
B
So
I
I
prepared
the
pr
there
to
see
what
it
would
look
like,
I
wonder:
what
do
you
guys
think
I
am
I
am
not
sure
myself.
B
That's
probably
the
minority
of
the
languages,
so
I
guess
the
only
language
that
so
far
said
that
this
would
be
necessary,
is
C,
plus
plus,
and
maybe
that's
okay,
I,
don't
know.
A
I
think
this
is
okay,
but
I
guess
my
question
was:
is
it
any
more
than
just
a
like
a
cosmetic
thing
in
the
spec?
Just
to
you
know,
make
sure
that
we
reduce
confusion
or
is
it?
Is
there
going
to
be
more
to
it
like.
B
B
If
we
decide
to
have
an
actual
log
API,
it
will
need
to
be
different
from
this
all
right,
we'll
say
any
more
that,
let's
add
a
couple
more
methods
to
the
to
the
existing
blogger
and
that
will
become
the
log
API
that
the
application
developers
can
can
call
right
we're
we're
essentially
drawing
that
that
line
the
kind
of
thicker
right
the
separation
between
what
what
what
we
have
today
and
what
in
the
future,
we
may
want
to
propose
for
the
end
users
to
to
use
for
application
developers
to
use
as
the
as
a
general
purpose
logging
API.
B
What
kind
of
drawing
that
line
more
more
strictly
right,
it's
no
longer
going
to
be
possible
to
just
say:
okay,
let's
in
backwards
compatible
manner,
add
some
some
additional
methods
to
the
logger
and
that
becomes
the
logging
API
that
that
that's
that's
the
probable
long-term
concealer
named.
If
we
ignore
that
part,
then
sure
that's
purely
cosmetic
right
now,
I
did
it's
just
a
name
change!
Nothing,
changes
functionally.
A
B
A
I
think
it's
more
like
a
psychological
thing
like
seeing
SPI
makes
people
pause,
wait.
What
is
this
thing?
Trask?
Also,
you
know,
one
of
one
of
the
suggestions
was
to
put
a
Pender
in
the
in
the
title
of
the
thing
as
well.
I,
don't
know
if
that's
too,
constraining
or
folks
think
that
would
be
too
constraining
like
use.
Case-Wise
like
log
appender,
SPI
or
something
I.
D
A
question
I
have
about
SPI
is
so
we
use
the
term
API
all
over
the
place
in
the
specification.
It
means
a
certain
thing.
It
has
implications
about
how
we
package
up
artifacts
and
how
we
version
them
and
backwards
compatibility
guarantees.
This
is
the
first
time
we'll
use
the
term
SPI.
What
you
know.
It's
I
think
we
need.
We
need
to
come
to
an
understanding
about
what
implications
Exist
by
calling
such
a
thing,
an
SPI
like.
Why
call
it
an
SPI
versus
an
API?
What
guarantees
are
available?
How
does
it
differ
from
an
API.
A
A
A
Think
it's
like
the
propagators
I
think
is
an
example
like
you
know,
there's
the
Jagger
and
the
and
the
Zipkin
propagators
and
I
think
that
there's
something
in
the
spec
that
says
these
must
be
shipped
to
separate
packages
or
something
so
are
we
going
to
get?
Is
there
going
to
be
like
a
technical
specification
to
what
this
SPI
or
how
it
must
be
organized
by
it.
B
E
Yeah,
like
the
thing
that
gets
me,
is
calling
it
a
service
provider
interface
like
if
it
was
just
the
log
provider
interface
or
taking
that
to
the
extreme
based
on
trusting,
keep
calling
it
an
API.
But
it's
called
a
preventer
provider
interface,
but
yeah
the
having
service
there
I
think
confuses
it
a
little
bit
because
really
it's
it's.
B
I
think
the
SPI
is
is
used
by
log4j
if
I'm
not
wrong,
to
describe
the
same
concept.
Essentially
it's
a
it's
a
it's
an
interface
of
the
backend
portion
of
the
login
library
right
and
that's
exactly
what
we
do
here.
I,
don't
know
if
any
any
other
language
or
any
other
Library
uses
the
term
SPI
for
this
purpose.
B
But
there
is
a
precedent
like
that
right,
I,
think
log
4G
does
the
same
thing
there
in
the
in
the
new
air
flock
packaging
goal.
They
call
it
a
backhand.
They
they
use
that
term.
A
backhand
that
the
Handler
is
part
of
the
back
end
I,
believe
that's
what
they
call
it.
So
essentially,
the
library
is
composed
of
two
parts,
the
front
end
and
the
back
end
and
the
back
end
is
pluggable
and
the
front
end
is
what
what
the
application
sees
right.
B
E
Yeah
exactly
like,
because
we
had
just
talking
Cosmetics,
so
it
was
a
name
thing
like
even
just
service
Si.
Would
that
still
feels
wrong?
So
yeah
I
don't
know
names
are
not
my
equity.
F
B
F
A
B
The
main
change
is
that
the
beat,
but
this
comes
as
a
proposal
from
people
who
are
confused,
so
they
are
thinking
that
a
different
name
would
help
prevent
the
confusion,
a
kind
of
tend
to
agree
but
I'm
not
sure
how
much
it
helps.
Confusion.
C
A
I,
don't
know
that
a
change
to
just
the
wording
in
the
spec
is
going
to
benefit
or
help
clarify
things
for
end
users.
Different
packaging
might
but
I'm
a
little
skeptical
like
I'm
thinking
like.
If,
if
we
declare
that
this
must
be
shipped
as
like
a
separate
package,
then
I
can
see
how
instrumentation
authors,
who
are
writing
a
log.
A
A
B
Packaging
is
also
very
language
dependent
actually
so
this
this
is
a
lie
right
this
this
box,
that
I'm
showing
here
in
reality
in
go
I,
think
we
have
separate
separate
modules
for
metrics,
API
or
Trace
API
for
for
the
SDK,
I,
think
and
I
think
it's
the
same
is
in
Java
right.
We
have
separate
jars
for
metric
traces
if
I'm
not
wrong.
We.
D
Just
a
quick
comment
on
something
that
was
said
earlier
about
log4j
using
the
term
SPI.
So
SPI
is
a
it.
It's
a
term
that
exists
in
the
Java
ecosystem.
It's
service
provider
interface.
It
provides
like
a
mechanism
for
you
to
provide.
You
know
your
own
implementations
of
various
interfaces
that
are
used
throughout
some
sort
of
library
or
framework
and
log4j
does
have
some
spis
that
you
can
implement,
but
the
appenders
are
not
spis.
The
appenders
do
not
fall
under
that
category.
D
B
Okay,
can
you
guys
post
comment
on
on
the
pr
that
I
created
with
your
opinions,
because
it
has
like
already
three
approvals
and
we
need
opposing
opinions?
If
we
don't
want
this
to
be
to
be
merged
right,
I
am
I
am
personally
on
the
fence
on
this.
One
I
could
go
either
way,
so
I
guess
this
is
gonna,
go
the
way
of
what
the
majority
people
of
people
think.
D
I
could
probably
go
either
way
as
well.
I
will
I
will
go
and
comment
on
that.
I
think
where
I
stand
right
now,
is
that
you
know
as
long
as
we
Define
SPI
like
what
we
mean
when
we
say
SPI
and
the
specification
and
in
a
way
that's
that's,
that's
clear.
D
I,
probably
don't
mind
it.
I
think
I
have
a
slight
preference
for
calling
it
The
Log
appender
API,
but
if
SPI
allows
us
to
move
forward,
I,
don't
think
it's
the
worst
thing,
but
I'll
I'll
go
and
comment
on
that.
Pierre.
A
Yeah
I'll
just
say,
I
think
I
I
would
have
I
would
approve
this
PR
again.
Naming
is
maybe
the
thing
up
in
the
air,
but
I
would
approve
this
PR
simply
I.
Think
because
you
know
the
the
question
that
was
brought
forward
about
the
C
plus
plus
Community.
It
was
just
a
indicator
to
me
that
you
know
people.
B
Yeah
that,
and
also
there
are
people
who
intend
in
the
future
to
have
an
actual
API,
a
log
API
right,
and
they
are
confused
by
this,
because
it
doesn't
look
like
anything
remotely
what
they
expect.
The
log
API
to
look
like
all
right
so
and
also
when
they,
when
they
decide
to
to
design
that
API,
that
log
API
in
the
future.
They
are
going
to
have
a
bit
of
a
problem
here
right.
They
they
will
need
to
try
to
somehow.
B
Accept
the
existing
log
API
instead
of
introducing
a
completely
new
one
as
an
additional
layer
which
I
think
what
technically
is
the
right
approach
in
the
future
right.
So
if
this,
if
we
call
this
a
log,
Pender,
API
and
SPI
or
whatever
it
is,
the
future
log
API
user
facing
log
API
will
need
to
sit
on
top
of
this.
One.
A
Does
that
make
sense,
given
that
I
don't
I,
don't
think
we
are
in
the
near
future,
going
to
design
an
actual
end
user-facing
log
API?
Does
it
make
sense
in
this
to
have
some
words
in
the
specification
that
explicitly
kind
of
talks
or
speaks
to
what
it
would
look
like
if
you
were
designing
your
own
log,
API
and
and
maybe
explicitly
saying,
maybe
through
a
diagram
saying
this
box
and
the
diagram
this
log
API
is
not
governed
by
the
open,
Telemetry
spec.
A
You
can
write
one
if
you
want,
but
this
diagram
simply
helps
illustrate
that
you've
designed
this
part
and
then
the
the
Vlog
backend
API,
is
something
that's
been
designed
by
the
open,
Telemetry
community,
and
it
rests
on
top
of
this
as
a
as
a
way
to
integrate
and
hook
into
open
telemetry,
but
a
diagram
like
that
help.
D
What
about
what
about
what
about
just
like,
framing
it
as
a
in
May
so
like
languages,
may
you
know,
extend
the
the
log
API
to
be
user
facing
is.
Is
there
just
like?
Is
there
too
much
baggage
in
that?
Where
you
know
the
design
requirements
of
that
would
start
to
impact
the
Pender
API
in
in
ways
that
would
be
concerning.
E
D
E
I
think
there
is
actually
Martin
correct
before
wrong.
It
was
already
an
open
PR
that
does
exactly
that.
G
G
That
yeah
I
mean
there
are
some
there's
some
libraries
for
logging
in
JavaScript
or
node,
but
I'm
not
sure
that
it's
like
standard.
D
I'm
just
trying
to
gauge
how
frequently
this
question
of
building
a
user
facing
log
API
is
going
to
come
up
with
C
plus
plus
kind
of
the
only
one
or
are
there
others,
and
it
sounds
like
there's
at
least
two.
So.
B
B
D
B
B
B
We
have
other
topics,
so
maybe
for
the
sake
of
time,
let's
move
to
the
next
item
and
you
guys
please
please
comment
on
the
pr
right
with
what
thoughts
you
have
okay.
So
the
next
item
is
from
Braden,
follow
up
on
December
7,
meaning
removing
vendor
examples.
B
J
Was
the
decision
I
I
was
I
just
today
was
finally
catching
catching
up
on
all
that
stuff,
because
we
all
left
for
vacation
after
that
meeting.
So
yeah
I
saw
that
the
first
thing
we
talked
about
at
that
meeting,
which
was
about
like
clarifying
structured
body
intentions
like
that,
has
been
remediated,
but
we
just
haven't
gotten
to
the
the
the
second
thing
we
talked
about,
which
was
taking
those
examples
out
of
the
data
model
and
I
wanted
to
offer
that
I
could
do
it
or
if
someone
else
has
a
specific
way.
J
Sure
so
the
reason
we
brought
it
up
at
the
time
was
we
were
noticing
a
potential
concern
with
how
we
originally
were
mapping
between
the
Google
Cloud
logging
format
or
map
between
a
hotel
logging
format
to
Google
Cloud
logging
format,
and
we
were
thinking
about
like
if
we
needed
to
make
a
change
technically
our
example
for
how
that
mapping
happens
is
in
the
data
model.
Spec
document
which
is
marked
stable,
so
is
us
making
a
change
to
that.
J
Like
is
that
example,
now
suddenly
intertangled
with
the
stability
of
that
document,
which
we
didn't
think
seemed
like
the
right
idea
and
I
think
it
was
just
sort
of
like
an
unfortunate
consequence
of
what
was
supposed
to
be
a
helpful
example
in
that
document
now,
suddenly
being
intertwined
with
that.
B
B
Example-
and
we
should
be
able
to
fix
those
inaccuracies
without
thinking
twice,
because
this
document
is
not
stable,
right
right,
yeah
yeah.
So
let's
do
that.
I
think
that
it's
completely
fine
to
move
this
into
a
separate
document,
separate
file.
J
Okay,
so
I'll
add
that
to
my
to-do
list
this
week,
this
will
be
my
first
PR
of
the
spec
repo,
so
be
as
as
eyes
on
it
as
possible.
I
guess
to
make
sure
I'm
doing
everything
right,
but
I
guess
one
one
follow-up
question
is:
if
we're
going
to
move
step
out
to
examples,
would
one
document
with
a
bunch
of
examples
be
a
good
idea,
or
should
we
like
parcel
out
all
the
examples
of
different
documents.
D
Yeah
there's
one
thing:
that's
coming
to
mind
is
that
in
the
metrics
specification
there
is
there's
a
document
called
supplementary
guidelines,
and
it
just
gives
it's
a
list
of
a
bunch
of
advice
that
might
be
useful
in
implementing
the
metrics
SDK
and
it
might
be
good
to
add
a
similar
document
for
logs,
where
these
examples
is
just
one
of
the
sections
under
there.
B
J
Can't
make
any
promises
about
being
able
to
put
a
lot
of
good
advice
in
there,
but
I
can
at
least
set
it
up
to
look
similar
to
this
so
that
it
can
be
added
to
that
would
probably
be
the
direction
I
would
take.
Yeah
I
see
that
so
this
is
this
document's,
not
a
spec,
I'd,
probably
I'd,
probably
put
something
very
similar
to
the
top
of
the
new
document.
I
Right:
okay,
hey
guys,
just
a
really
quick
comment:
I
know
that
I
I
really
can't
offer
things
at
the
level
that
you
guys
are
offering.
But
one
thing
I
can
offer
in
terms
of
that
section
in
the
spec
that
tries
to
I
guess
the
the
net
net
of
what
I'm
trying
to
say
is
I
found
that
section
extremely
helpful,
particularly
when
we
started
down
the
path
of
elastic
common
schema
and
trying
to
figure
out.
I
Does
it
make
sense
for
us
to
Pivot
and
go
towards
open
Telemetry
and
I
found
all
of
those
examples
extremely
helpful,
because
if
you
go
and
you
take
a
look
at
some
of
the
other
documentation
you'll,
you
know
for
other
things
like
openshift,
for
example,
you'll
find
all
kinds
of
documentation
with
regard
to
logging.
That
seems
to
fly
in
the
face
of
many
other
things
that
you
read
and
I
found
that
section
to
be
very
helpful
and
clarifying
lying
I'm,
not
suggesting
that
we
keep
it.
I
You
know
in
the
actual
spec
itself,
because
I
I
totally
understand
those
comments.
Just
I
just
a
comment
that
I
found
it
very
helpful
and
I.
Think
people
like
me
who
are
walking
up
to
this
new
right
and
don't
have
the
level
of
experience
that
all
of
you
have
I
think
it
would
be
helpful
for
those
types
of
people
so
just
offering
that
thanks
yeah.
Thank
you.
Thank
you.
B
I
J
Think
that
makes
a
lot
of
sense
and
I
guess
one
other
question
I
have
then
is
like
if
I
were
to
link
to
that
document
from
the
data
model
specification
that
would
that
also
tangle
the
stability
of
those
two
documents
with
each
other.
B
J
J
Great
I
will
open
a
PR
for
that.
It's
on
it's
on
my
to-do
list
now.
B
Okay,
thank
you,
Santosh
review
of
the
whatever
is
this
PR
three.
H
H
So
disappear
you
just
commented
on
before.
H
So
so
yeah
we
could
add
the
you
know,
text
that
this
is
not
mandatory
is.
Is
that
all
or
any
other
comments.
B
So
what
what
so
you
see
guys
right,
we're
seeing
some
some
I
guess:
reluctance
from
people
who
were
not
part
of
the
discussions
about
introducing
the
event
API
right,
so
we
probably
need
to,
and
even
if
there
is
an
open
right,
I
I
know
I,
understand
that
and
we
discussed
it
all.
We
decided
as
a
Sig
that
that's
the
right
thing
to
do,
but
we
need
to
make
an
effort
to
convince
not
just
this
sick
but
others
who
are
interested
in
logging
and
events
being
all
complementary
to
to
have
this
as
a
separate
API
right.
B
H
No,
but
this
PR
is,
is
just
reorganizing.
Existing
content.
B
B
D
Well,
you
know
if
there's,
if
there's
good,
if
there's
good
conversations
in
the
Otep
or
in
other
issues,
where
we've
already
gone
over
this,
we
can
link
out
to
those
so
that
we
can
remember
the
the
arguments
we've
made
in
the
past.
H
E
I
guess
like
I
I
responded
to
the
was
that
3167
and
one
of
the
descriptions
of
how
I
described
it
in
there,
which
probably
makes
sense
to
maybe
reinforce,
is
the
events.
Api
is
really
user
and
application.
Level
usage,
Telemetry
versus
the
logging
API
is
really
you
know
more,
you
know
sending
out
unstructured
log
data
or
you
know,
or
what
I
call
the
server
or
system
style
logging.
F
F
D
There
is
an
issue
where
that
was
discussed
so
trying
to
find
it,
but
we,
the
resolution,
was
that
there
was
a
stronger
decoupling
from
the
event
API
and
the
log
API
versus
based
on
a
long
conversation.
D
The
original
well
I,
don't
want
to
say
the
original,
but
one
of
the
versions
of
the
event
API
was
what
you
described
in
like
where
there
the
event
API
was.
Basically
you
know
you
instantiated
it
by
passing
it
an
instance
of
the
the
log
API
and
it
would.
It
would
delegate
to
that
in
a
very
obvious
and
direct
way.
F
B
B
F
H
B
B
B
F
Got
a
little
confused
there,
so
our
goal
was
for
sure
to
get
logs
out
the
door
and
then
add-on
events,
but
I,
don't
think
a
decision
was
made
that
events
should
be
independent.
I
think
they
could
still
be
part
of
logging
Ergo
like
what
what
Jack
was
proposing
before
I.
Just
don't
think,
we've
vetted
if
there's
a
strong
enough
case
for
it
to
be
completely
independent,
I'm
saying
it
should
just
be
part
of
logging.
C
D
Having
it
separate,
doesn't
preclude
us
from
making
it
part
of
the
log
API
in
the
future.
E
Yeah
and
I
think
there
is
argument,
one
of
which
I
put
in
in
the
thing
that
if
we
Define
an
event
API
one
of
the
implementations
of
that
event,
API,
so
the
the
event
SDK
could
be
that
it
actually
doesn't
use
hotel
at
all.
It
actually
uses
the.net.
You
know
logging
framework
to
create
those
structured
log
events.
E
Likewise,
in
the
romsig,
we've
talked
about
as
a
potential
stop
Gap.
In
that
we
could
have
a
span
version
which
effectively
creates
span
level
events
rather
than
MOG
level
events,
but
yeah
I,
don't
think
we
want
to
go
down
the
path
of
having
you
know,
interfaces
for
being
able
to
muck
with
them.
In
this
case
of
note,
it's
effectively
a
standard
set
of
mechanisms,
a
convenience
methods
for
creating
the
structured
events.
B
B
B
Yeah,
but
we
we
discussed
and
decided
that
the
decisions
about
event
API
will
be
done
later,
right
that
that
will
be
a
separate
discussion
about
that,
but
it
seems
like
we
are
making
this
decision
just
by
saying:
okay,
let's
decouple
the
events,
API,
so
I
kind
of
understand
what
Mike
is
saying
here.
So
maybe
we
shouldn't
be
doing
that
instead.
E
E
F
D
So
I
mean
I'm
going
to
post
a
link
to
the
issue
where
this
is
being
discussed,
but
there's
been
some
pretty
significant
pushback
on
that
Mike
on
the
idea
that,
in
order
to
use
an
events
API,
you
need
to
be
aware
of
this
log
API,
which
we
say
is
not
supposed
to
be
user-facing,
and
so
we
contradict
ourselves
by
having
the
API
aligned
how
it
is
in
the
spec.
Today.
D
D
I
guess
I'll
say
that
I
don't
have
terribly
strong
opinions
about
this
event.
Api
piece
I'm
more
interested
in
trying
to
make
progress
on
the
log,
API
and
log
SDK
piece
without
getting
bogged
down
by
the
event
stuff
I
think
decoupling
events
in
in
a
in
a
very
real
way
where
they
they
have
no
dependency
on
the
log
API
to
me,
it
provided
a
pretty
clear
way
to
achieve
that,
because
there's
no
question
that
events
and
logs
are
not.
B
So
I
I
have
a
question
about
that.
Is
it
necessary,
though,
how
does
the
existence
of
experimental
events
API,
which
wants
to
consume
the
log
API
prevent
us
from
declaring
the
log
apis
stable?
Why
is
it
a
problem.
B
I
I
was
thinking
myself
that
we
need
to
make
this
part
the
coupling
part
clearer
before
we
declare
the
log
API
stable,
but
I'm
no
longer
sure
that
that
really
is
necessary.
Why?
Why
is
it
a
problem
like
events?
Api
is
an
experimental
design
if
it
chooses
to
say
that
it
wants
to
depend
on
log
API,
fine,
that's
not
a
problem
from
the
perspective
of
declaring
the
log
apis,
stable.
E
D
In
Java,
the
way
that
we
Implement
stuff-
that's,
not
that's,
not
a
a
problem
for
us.
E
So
you
release
version
1.1
stable.
We
changed
the
event,
API
someone's
taking
the
dependency
on
1.1
stable.
That
then
breaks
what
you
know.
How
do
you
resolve
that.
F
B
E
B
B
B
D
And
and
I
guess
further
now,
I
think
what
Mike
is
advocating
for
is
to
keep
the
the
event
API,
how
it's
structured
today,
where
the
event
API
you
create,
or
maybe
we
did
revert
this
so
I-
think
what
he's
advocating
for
is
where
the
event
API
you
you
it
delegates
directly
to
the
log
API.
F
Yeah
so
in
my
mind,
the
log
apis,
let's
call
it
log
appender
API
for
a
second.
So
my
event,
API,
would
just
be
kind
of
a
first
party
log
upender.
So
I
would
have
a
nice
happy
API
for
events,
but
under
the
hoods
it's
just
using
the
log
appender
API.
So
it's
just
sort
of
an
add-on
thing
to
what's
in
the
spec.
B
Okay,
can
you
Mike?
Can
you
take
a
look
at
the
the
issue,
the
the
link
that
Jack
posted
yep
I?
Will
you
missed
this
discussion?
I
believe
this
was
discussed
both
on
the
issue
and
in
the
sign
meeting,
and
we
made
a
decision
on
this
one.
So
you're
now
asking
us
to
rethink
about
that
decision
and
fair
I
think
we
can
rethink.
But
please
do
take
a
look
at
at
the
issue
and
all
the
comments
and
arguments
before
before
we
we
we
we
start
discussing
it
again
right.
Maybe
you
can.
H
B
Okay,
so
I
would
suggest
to
do
this
since
Mike
has
a
strong
opinion
about
this.
It
would
be
great
if,
if
you
could
read
the
the
discussion
that
I
pointed
to,
if
if
he
still
disagrees
with
what
we
decided
and
then
then
maybe
he
also
disagrees
with
the
pr
that
you
posted
in
and
can
post
arguments
right
comment
on
the
pr
to
explain
why
the
objections,
what
the
objections
are
and
why
we
shouldn't
be
merging
the
spr
I.
H
H
That
yeah
I'm
actually
worried
about
a
different
thing.
I
think
what's
difficult
here
is
I
think
there
seem
to
be
multiple
stakeholders
with
you
know
differing
opinions
I
think
like
how
do
we
get
them
in
one
room
to
divide
this
out,
like
I,
think
John.
I
H
Is
is
one
who
you
know
suggested
that
you
know?
Let's
not,
you
know
like
the
event.
Api
users
should
not
be
knowing
anything
about
logs
and
that's
why
we,
you
know
this.
H
But
I
think
the
problem
is
like
Riley,
you
know
came
in
now
right.
So
how
do
we
handle
that.
B
D
Yeah
San
Antonio:
it's
it's
a
bit
hard
right,
so
you
know
we
have
synchronous
discussions
and
then
there's
people
that
object
asynchronously.
So
it
seems
like
we
were
repeating
the
same
conversations
and
I
think
you
know
some
of
that
is
inevitable,
because
John
Watson
doesn't
do
this
full-time.
So
he's
not
going
to
be
able
to
make
this
meeting.
D
Maybe
we
can
get
Riley
to
come,
but
we're
gonna
face
more
of
that
when
we
try
to
stabilize
the
log,
API
and
SDK,
because
there's
going
to
be
a
lot
of
people
in
the
open,
Telemetry
community
that
haven't
been
privy
to
the
conversations
we've
had
here.
So
just
kind
of
the
nature
of
how
this
works.
I
think.
B
Okay,
so
I
think
what
would
help
is
that
we
are
clearer
in
the
in
the
offline
communication
right
when,
when
we
make
a
decision
here
after
a
live
discussion,
we
need
to
capture
the
outcomes
better
in
more
detail
on
the
PRS
on
the
on
the
on
the
issues
that
are
open
there,
so
that,
where
whoever
is
was
not
in
this
room
still
can
have
a
good
understanding
of
what
with
why.
We
decided
what
we
said.
Foreign
probably
I
think
we're
not
maybe
doing
a
very
good
job
with
that.
Probably
that's
why
this
is
settlement.
B
C
F
So
it's
going
to
be
hard
to
get
the
log
API
stable
and
then
trying
to
get
a
dedicated
events.
Api
stable.
Those
are
just
two
big
uphill
battles,
so
it's
probably
an
easier,
less
friction
design.
If
we
get
logs
stable
and
then
events
are
just
a
subset
or
an
add-on
or
something
you
can
do
with
the
log,
API
I
think
that's
really
what
we're
running
into
with
Riley.
Is
he
and
a
lot
of
other
people
are
not
that
closely
tied
to
the
Sig
they're.
F
H
Well,
how
about
the
individual
language
maintenance,
like
our
are?
Are
they
actually
following
the
outcome
of
this
six
specification
like
I
was
hoping
the
issue
that
Riley
pointed
out
on
on
C
plus
plus
needing
log
API.
You
know
it
could
have
come
from
the
C,
plus
plus
maintenance,
too.
B
So
I
I
posted
numerous
times
on
slack
of
our
intent
about
our
intent
to
to
stabilize
the
logs
API,
and
we
we
said
that
we
will
go
to
the
specs
again
to
the
maintainers
meeting,
to
also
explain
what
we're
planning
to
do.
That
has
not
happened
yet,
but
this
is
essentially
what
we're
seeing
a
result
of
what
those
announcements,
but
right
people
started
paying
more
attention
and
they
were
not
so
for
like
outside
of
this
sick
likely,
people
were
not
very
much
aware
of
what
is
happening.
B
A
As
a
general
anymore,
as
a
general
note,
I
I
think
they're
trying
a
different
thing
in
the
maintainers
meeting
on
Mondays
yeah,
where
yeah
keeping
saving
a
space
where
people
can
kind
of
go
into
a
technical
topic
or
do
a
demo
or
something
I.
I
think
that
is
something
that
our
community
has
been
in
need
of,
because
the
maintainers
meeting,
and
also
the
specification
meeting,
are
both
places
where
you're
going
to
get
a
broader
audience
and
and
I
think
that
could
help
our
work
go
faster.
B
E
Yeah
and
I
I
think
that
this
week
in
the
maintainers
meeting,
when
Ted
went
through
his
list
so
Elle
and
I
were
there.
The
stability
announcement
of
logging,
API
logging
SDK
was
brought
up,
which
is
I,
think
why
we've
got
a
lot
of
visibility
because
people
are
now
saying:
oh,
let's,
oh
my
stable.
Let's
the
maintainers
then
start
to
take
a
look
at
it.
So.
B
Yeah
I
think
this
was
kind
of
expected
right.
So,
let's
we
should
be
okay
with
this
and
we
should
be
okay
with
maybe
rethinking
some
of
the
decisions
that
we
made.
That's
it's
okay,
all
right,
more,
some
people
who
have
strong
opinions
and
expertise
as
well
in
the
area.
They
were
not
aware
of
these
things.
They
are
now
that's
good.
Let's,
let's
hear
those
opinions.
B
B
Okay,
the
next
one
is
yours
as
well:
yeah.
H
H
Yeah
I
mean
basically
that's
Europe
I,
just
I'm
wondering
what
are
the
next
steps
on
on
that
PR.
So.
B
We
need
more
approvals.
We
only
have
one
approval
that
counts
it's
from
Yuri
and
there
are
no
others
if
this
sick
supports
this
I
wonder
why
you
guys
are
not
approving
it
if
you're.
If
you
agree
with
this,
that
would
help.