►
From YouTube: 2022-11-09 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
So
nav
is
not
here,
he
made
a
PR,
but
is
not
here
to
discuss.
Maybe
oh
here
he
is
okay.
C
Yep
start
being
a
little
bit
late
yeah,
so
this
PR
is
really
about
defining
what
I'm
going
to
call
the
shape
of
an
event
as
part
of
the
rum
Sig
we've
been
looking
to
create
event.data
as
the
placeholder
for
all
of
the
event
or
domain
specific
Fields,
the
exception
potentially
being
exceptions
and
with
the
cloud
events
comment
last
week,
I
went
and
went
up
and
read
that
and
that
aligns
very
heavily
to
to
our
thinking.
C
So
I
created
this
PR,
which
borrows
heavily
from
said
Cloud
events
to
include
event
data
itself.
There
is
a
bunch
of
other
comment
content
in
the
cloud
events
which
I
was
going
to
include
in
this
specifically
the
data
schema,
but
I
thought
at
least
as
initial
one,
to
cut
it
down
into
smaller
chunks
and
and
go
from
there
rather
than
trying
to
bring
it
all
in.
At
the
same
time,
I
did
see
your
comment.
C
Tigrant
about
the
using
body,
that's
potentially
an
option
which
I've
already
added
a
comment,
for
it
was
really
a
case
of
one
of
the
reasons
for
saying
event:
data
is
we
have
this
ultimate
goal
of
aligning
our
event
schemas
or
our
event
definitions,
so
you
can
actually
send
it
as
a
log
event
or
potentially
as
a
span
event.
So
in
a
span
event,
there's,
obviously
no
body.
So
by
having
a
an
attribute
which
is
event
data,
it
could
be
included
in
that.
C
But
yeah,
it's
still
in
draft
I,
created
it
on
Monday,
really
just
looking
for
feedback
on
like
the
body's
a
good
example
of
having
event
data
or
body
and
whether
we
want
to
borrow
a
little
bit
more
from
cloud
events
as
the
initial
one
or
not.
B
C
For
most
of
the
events,
we
visit
the
three.
B
D
B
D
The
the
wording
is
a
little
tricky
right,
I
think
everything
about
the
data
I
think
only
the
payload,
but
think
about
any
metadata
that
could
be
common
across
all
events
like
event,
category
or
a
you
know
the
you
know
the
schema
URL
for
that
event
or
the
content
type
of
that
data.
D
You
know
those
are
those
are
not
even
specific,
so
those
are
applicable
to
all
the
events,
so
those
will
have
to
be
outside
and
event.data.
B
So
do
we
expect
that
somehow
the
the
decades,
for
example,
we
will
treat
this
field
differently?
This
particular
attribute,
like
I,
will
show
the
the
data
somewhere
separately
from
the
metadata
and
probably
won't
even
show
the
metadata
I
guess
they
would
use
the
metadata
to
somehow
interpret
the
data.
Is
that
the
intent
here?
Are
we
trying
to
to
split
it
in
the
attributes
into
parts
that
are
easier
for
the
backends
to
understand
and
and
use.
C
Yeah
sorry,
my
zoom
crashed
for
some
reason.
It
never
happened
there.
You
know
the
whole
point
of
having
the
event.
Data
is
yeah,
the
back
ends
or
Downstream
systems
can
look
at
this
and
say:
okay.
This
is
an
event.
If
I
know
about
the
the
schema
I.E
the
domain
name
combination,
then
it
can
pull
it
apart
and
do
whatever
it
needs
to,
and
if
it
doesn't,
it
knows
that
it's
an
event
and
it
can
just
send
it
Downstream
for
something
else
to
to
play
with.
C
C
C
As
part
of
the
page
view
event,
we
have
the
URL,
the
timing
associated
with
when
that
event
occurred
or
the
resource
timings
the
for
a
browser.
There's
like
things
like
you
know
when
the
DNS
entry
started
and
stopped
when
the
connect
for
the
SSL
started
and
stopped
the
fetch
started
and
stopped
like
there's
I,
think
about
in
the
w3c
standard,
there's
about
12
to
15
18.
C
D
Yeah,
so
he
I'm
sharing
one
event.
This
is
the
user
action,
so
on
the
on
in
an
app
where
the
user
clicked,
which
element
He
clicked
on,
is
it
a
button
or
a
link?
All
of
that
is,
is
you
know
you
could
consider
as
the
data
for
that
event,
yeah.
C
Yeah,
because
you
know
there
could
be
thousands
of
these
events-
and
you
know
having
to
go
through
the
process
of
of
defining
common
semantic
conventions
for
every
single
one,
for
every
single
field
is
just
problematic.
B
C
C
Wrong
thing:
yeah:
no,
it's
a
pickled
other
events
as
well.
So
if
you
look
at
the
cloud
events
and
and
there's
a
lot
of
good
stuff
in
the
cloud
events,
which
is
a
cncf
project,
they
actually
have
an
optional
data
schema
so
to
go
and
describe
exactly
what
the
data
might
be
for
an
event.
So
for
third-party
events,
this
would
be
the
potential
extension
or
also
the
content
type,
which
is
another
nice
one.
C
Where
you
know.
Third
parties
are
going
to
find
their
own
events.
They
can
pass
their
own
schema
down
they're
on
encoding.
So
in
this
particular
case,
my
response
to
your
thing
about
body.
This
is
this
is
where
that
comes
in.
C
So
because
body
only
takes
any
and
if
specifically
sort
of
says
it
should
be
stringified,
then,
if
because
we
want
to
have
it
as
as
a
map
for
most
of
our
events,
we
would
probably
either
want
to
have
a
the
a
data
content
type
which
says
it
is
a
map
or
say
by
default.
It
is
a
map
which
is
the
Assumption
I'm,
making
with
event
data,
and
then
later
we
can
say
it's
not
the
map.
It's
something
else.
B
B
C
It's
more
of
a
specification:
they
don't
Define
any
sort
of
Transport
they're,
just
saying
events
coming
from
clients.
Really,
you
know
they're
calling
it
Cloud.
Events
can
have
these
different
attributes
and
they
go
into
a
lot
of
different
areas
which
we're
not
defining
from
a
wrong
perspective
because
we
don't
need,
but
they
they
have
taken
them
all
into
account.
B
E
They
do
actually
have
some
transport
standards
as
well.
F
I
think
one
of
the
things
that
they
did
it
slightly
differently
is
that
the
type
seems
to
be
the
combination
of
domain
and
name
that
we
have
I
wonder
if
we
need
to
maintain
separate
fields
for
that,
especially
if
we're
moving
event
domain
out
of
scope,
attributes
and
into
that
attribute
to
log
attributes.
G
One
interesting
advantage
of
this
approach
of
putting
all
the
the
payload
pieces
of
data
inside
a
field
called
Data.
Is
you
avoid
collisions
with
other
attributes
that
you
might
attach
to
this
event?
So
if
you're
doing
something
like
you
know
extracting
baggage
and
attaching
those
to
to
events,
you
know
to
contextualize
the
environment
in
which
the
event
was
emitted.
You
don't
have
to
worry
about
those
baggage,
Keys
colliding
with
keys
from
your
your
events,
schema.
B
C
That
is
one
of
the
discussions
like
there
there's
been
a
lot
of
heavy
lifting
done
as
part
of
this
event.
The
cloud
events
spec
from
a
ROM
perspective
I
could
go
either
way
because
effectively
a
lot
of
My
Views
are
already
encapsulated
in
in
the
cloud
spec.
It's
just
how
we
go
about
representing
it,
whether
we
have
a
mapping
or
not
that's
so
that's
the
part
of
the
that's
one
of
the
reasons
for
putting
on
the
thing
this
morning
is
to
have
this
discussion.
B
C
Represent
them
that
way,
yeah,
because
you
know
most
of
it,
is
going
to
be
in
data,
so
that
was
already
the
point
of
alignment.
So
it
really
is
the
domain
name
versus
the
type
yeah
which,
when
we
first
started
talking
in
the
romsig
I,
was
actually
proposing
effectively
the
dotted
domain
name
combination,
I,
think
when
it
came
when
we
came
here,
it
was
separated
so.
G
Yeah
I
I
don't
see
a
serious
difference
between
the
you
know,
the
combined
domain
name
and
name
and
the
and
the
separate
ones
in
my
head.
You
know
the
combination
of
the
name
and
domain
just
form
a
composite
key
and
you
know
I
don't
really
care
if
that's
encoded
in
one
field
or
separate.
B
The
issue
is
that,
if,
if
you
want
to
to
define
a
mapping
from
cloud
events
to
to
open
Telemetry,
you
can't
do
that
right.
It's
unclear
how
you
split
the
type
field
into
two
parts
unless.
D
D
We
don't
know
whether
you
know
the
type
the
prefix
is
the
domain,
that's
what
they
intended.
Maybe
they
don't
have
the
concept
of
domain.
B
B
B
B
The
event
names
have
a
specific
structure,
for
example,
or
the
data
is
recorded
in
a
different
way.
That's
the
value
right.
The
ability
to
independently
come
up
with
your
own
semantic
conventions
for
your
domain,
your
own
schema
for
for
events,
your
own
rules,
decentralizing,
the
development
I-
think
that's
the
value.
F
B
Yeah
I
don't
disagree
with
it,
I
guess.
The
the
reason
they
were
separate
also
was
because
of
the
they
are
separate
is
because
they
are
in
different
places.
Really
one
is
in
the
scope,
the
other
is
in
the
log
record.
So,
first
of
all,
we
need
to
decide
that
they
belong
to
the
world
record
and
only
then
we
can
talk
about
combining
them
into
a
single
field.
I,
don't
think
we
made
that
decision
yet
right.
B
A
I
I
think
even
then
separate
also
helps
with
the
forking
events
in
the
back
end,
it's
easier
to
look
at
a
field
consistently,
as
opposed
to
stroke
splitting
and
then
making
a
decision.
B
C
And
that
will
be
like
I've
got
in
the
the
description
of
my
PR
of
a
potential
mapping
of
cloud
events
you
could.
We
could
just
then
say
the
domain
is
cloud
events
and
then,
from
that
point
outwards
it.
It
follows
the
cloud
Effect
definition,
mostly.
B
Okay,
I
think
it's
worth,
maybe
looking
good
A
bit
closer
to
the
cloud
events.
I
did
do
that
a
while
ago,
but
I.
Don't
really
remember
the
details
now,
so
maybe
at
least
for
myself,
it
could
be
useful
to
to
see
what
is
it
there.
Is
it
worth
aligning
more
with
them?
What
can
we
borrow?
What
ideas
can
we
borrow
from
them?
Yeah.
C
I
think
we're
mostly
aligned.
There
is
a
couple
of
additional
fields
which
are
optional,
which
would
be
really
nice
to
have,
but
in
terms
of
today,
an
event
really
is
just
event,
name
and
domain.
C
So
this
event
data
keeps
that
alignment
possibility,
as
well
as
defining
that
we've
got
optional
and
required
top
level
attributes.
One
of
the
big
differences
that
does
exist
is
for
a
couple
level
attribute
names.
They
have
a
to
z,
lowercase
zero
to
nine,
so
it
can't
have
dots
or
anything
else
where,
of
course,
we
can
have
an
extension
of
that
for
the
attribute
name
just
became
a
chemical
based.
B
C
C
Cool
that
was
it
for
me
and
the
only
reason
for
putting
event
on
the
front
was
to
keep
it
as
event.
So
again,
namespacing
all
is
semantic
conventions,
so
they're
all
prefects
with
event.
Dom.
B
C
B
That
makes
sense
yeah,
okay,
the
next
one
Santosh
is
your
PR
I
think
we
have
two
approvals
I'd
like
to
have
more
approvals
there,
but
I
think
it's
I
think
it's
non-controversial.
B
C
If
you
look
at
the
pr
there's
another
thing
that
came
up
with
my
PR
they've
changed
the
yaml
validation,
so
my
PR
is
failing
because
there
is
no
type
for
that
looks
like
there
is
no
way
for
me
to
represent
a
map
of
string
in
any,
which
is
why
my
piano
doesn't
have
a
data
element.
C
B
F
B
Not
in
the
events
yes
you're
right,
so
we
have
kind
of
conflicting
definitions
there,
but
in
the
in
the
in
the
API
we
say
that,
where
is
that
specifies
the
domain
for
the
events
immediate,
which
should
be
added
as
event
domain
attribute
of
the
instrumentation
scope?
It's
very
explicit
here.
It
says
in
the
scope,
so
anyway,
I
guess
it's
clear
that
we
we
have
conflicting
definitions
here.
Let's
make
up
our
minds
about.
Where
do
we
put
that
if
it
goes
into
the
log
record,
we'll
fix
it
everywhere?
B
B
B
B
Okay,
so
last
week,
when
we
talked
about
it,
I
I
couldn't
remember
really
what
was
the?
What
were
the
all
of
the
reasons
why
we
wanted
it
to
be
in
the
the
scope?
One
of
the
reasons,
I
remember,
is
the
the
possibility
of
more
efficient
processing
of
log
records
in
a
batch
right.
So
you
look
once
at
the
scope
attribute
and
you
can
make
a
decision
about
the
entire
batch
of
log
records
on
the
land
scope.
G
Should
we
so
this
is
related,
so
if
we,
if
we
move
it
down
into
the
log
record,
would
we
still
be
able
to
say
at
the
API
level
that
all
events
emitted
from
a
particular
logger
you
know
need
to
have
the
same
event
domain.
B
G
I
suspect
that
might
have
been
part
of
the
decision
right
so
yeah
you,
you
want
to
have
the
convenience
of
only
defining
the
domain
once
and
well.
If
you're
going
to
Define
it
up
at
the
logger
level,
then
maybe
we
were
just
gravitating
towards
attaching
it
to
the
instrumentation
scope,
because
you
know
it
kind
of
falls
out
from
there.
If
you,
if
you
that.
B
And
that
can
be
done
there
yeah,
especially
if
it's
a
separate,
different
API,
yes,
you're,
absolutely
right
so
I,
don't
think
that
should
be
influencing
our
decision
about
data
modeling
right,
the
API
can
actually
look
like
it
helps
it's
more
convenient
to
put
that
event
domain
where
it
belongs,
but
I
think
the
the
decision
about
where
to
place
it.
It's
it's
more
like
a
data
modeling
exercise,
so
we
should
probably
for
a
moment
I
think
it's.
B
We
should
forget
about
what
the
API
looks
like,
especially
since
we
don't
know
really
what
what
we
did
like
right.
So.
D
What
what
is
the
expectation
for
the
receivers
in
this
case?
Are
they
can,
should
they
be
expecting
mixed
domains
in
our
given
scope.
D
Even
though
the
API,
even
though
the
API
you
know.
B
B
Way,
let's
for
a
moment,
ignore
the
API,
maybe
that's
not
what
we
do
right,
maybe
in
the
API
we're
not
enforcing
in
any
way
that
a
single
domain
is
associated
with
a
particular
logger.
B
Let's
forget
that,
for
a
second
I
think
it's
natural
you
have
a
the
scope
is,
is
the
scope
represents
typically
an
instrumentation
library
right,
an
instrumentation
Library?
Is
there
a
reason?
We
think
that
an
instrumentation
Library
cannot
emit
events
that
belong
to
more
than
one
domain?
B
Yes,
I
understand
it's
typically
going
to
be
a
single
domain,
but
does
it
have
to
be
like
if
we
think
it's
some
different
areas
of
events
right,
a
single
complicated,
let's
say
library,
and
especially
if
it's
not
a
library,
because
the
scope
is
defined
as
a
unit
of
code,
it's
efficiently
large
and
complicated
unit
of
code
may
want
to
emit
events
that
really
belong
to
different
domains.
Why
not.
G
B
C
And
a
good
example
that
would
be,
you
could
have
an
instrumentation
library
that
effectively
generates
you
know
whatever
we
Define
as
common
events
from
an
open,
Telemetry,
perfect
perspective
as
well
as
its
own,
like
it
could
be
an
instrumentation
Library,
which
is
instrumenting
like
my
MySQL
or
something
so
they
want
to
have
the
standard
ones
that
we
that
that
we
might
Define
as
well
as
their
own
internal
ones,
for
Diagnostic
or
something.
D
I
think
the
domain-less
I
remember:
there
was
a
discussion
in
the
past
and
the
original
PR
made
that
domain
optional,
but
we
later
changed.
It
should
be
mandatory.
So
I
think
that
should
continue.
Yeah.
B
Okay,
think
of
it
from
the
data
perspective
you're
receiving
data
that
belongs
to
a
scope
that
comes
from
a
particular
scope.
The
data
is
a
bunch
of
log
records.
Some
of
those
may
be
just
just
regular
log
records
right.
They
are
not
events.
They're
raw
log
records,
structured
log
records,
they
don't
have
a
domain.
We
don't
have
a
domain
if
you're
using
an
appender,
no.
B
D
No
but
I
thought
I.
I
can
pull
that
comments
out,
but
I
I
remember
that
if
we
were
to
call
these
as
events,
then
events
must
have
a
domain
I'm.
B
D
But
a
receiver,
but
for
a
receiver,
if,
if
it's
processing
events,
should
it
also
prepare
for
the
absence
of
domain,
you
should
yes,
if.
G
B
D
B
Agree
I
agree,
but
they
can
easily
arrive
in
a
single
batch
of
Hotel
peer
requests
under
the
same
scope.
That's
what
I'm
saying
right
the
same
scope.
If
it's
a
large
enough
scope,
a
whole
application
may
be
a
scope
right,
a
data
that
application
emits
some
sort
of
events
by
our
definition
of
what
an
event
is
which
of
domain
and
the
and
a
name
and
in
addition
that
same
scope,
May
event,
May
May
emit
regular
log
records
by
using
a
logging
library
and.
D
D
Just
to
be
clear,
let's
say
this
events
API
layer
built
on
top
of
logs
API,
so
this
using
events
API
should
one
be
able
to
create
events
without
a
domain.
I.
B
B
Having
that
sort
of
restriction,
you
can
make
the
API
more
ergonomic
easier
to
use
more
difficult
to
make
mistakes.
A
mistake.
One
of
the
mistakes
is
forgetting
to
set
the
domain
or
the
name
right
so
by
by
kind
of
narrowing
your
API
in
a
way
that
it
restricted
pushes
it
forces
you
to
supply
the
domain
name,
you
make
it
easier
to
use
correctly.
That
is
the
reason
why
also
I
believe
we
should
not
allow
for
meeting
the
domain
or
domain
in
that
special
events.
Api.
G
Okay,
Peter
and
I
think
you've
actually
just
outlined
a
pretty
good
argument
for
why
event
domain
should
be
moved
down
to
the
log
record,
which
is
that
right
now,
there's
not
a
there's.
We
don't
constrain.
What
exactly
a
scope
should
be.
It
can
be
a
particular
class
or
it
can
be
a
library
or
it
can
be
an
entire
application,
and
so
by
keeping
the
event
domain
up
at
the
scope,
we're
we're
being
more
opinionated
about
what
a
scope.
G
B
B
Think
yeah
and
the
the
other
argument
being
the
performance
easier,
more
efficient
to
do
that
that
multiplexing,
if
you
will
I
I,
think
yeah,
it
is
true,
but
is
it
strong
enough
I,
don't
think
so?
To
be
honest,.
B
C
D
C
C
If
we're
saying
we're
going
to
have
it
here,
then
we
as
tigrid
mentioned
earlier.
We
can
then
now
discuss
whether
we
want
to
have
that
as
two
separate
fields
or
a
single
but
yeah
from
a
size
perspective.
It
is
going
to
be
like
domain
plus.
You
know
the
key
is
going
to
be
domain.
The
value
is
going
to
be
the
string
value
a
little
bit
messy
going
to
be
repeated
for
every
event.
That's
in
there.
B
Yeah
I
guess
right,
but
when
you
use
compression
you're,
probably
not
going
to
see
significant
difference,
we
can
try.
It
I
mean
it's
not
difficult
to
try
and
see
how
much
of
a
different
it
makes
on
some
sort
of
typical
data,
we're
assuming
it's
it
we're
using
the
save
them
hundreds
or
thousands.
Even
world
records
that
have
the
same
domain.
E
E
B
E
G
This
kind
of
helper
style
events
API
depends
on
how
we
structure
that
I
still
think
there's
an
advantage
to
not
making
callers
have
to
repeat
the
domain
in
every
single
call,
so
one
parameter
instead
of
two
is
still
helpful
and
I
do
think
that
it's
still
useful
to
have
some
sort
of
API,
because
the
you
know,
as
we've
been
talking,
we
started
out
with
just
events
are
defined
by
two
properties,
domain
and
name.
But
you
know,
nav
has
brought
up
some
compelling
cases
to
possibly
add
additional
characteristics
to
them.
G
Maybe
all
of
their
payload
is,
you
know,
encapsulated
into
a
data
field.
Maybe
they
have
a
like
a
content
type
associated
with
them,
and
so
you
know,
if
those
conversations
continue
to
push
forward,
then
you
know
that
solidifies
the
case
for
having
a
dedicated
API
for
these
things.
Yeah.
F
Yeah
and
I
think
it
it
should
be
fairly
straightforward
to
have
that
be
an
extension
of
the
logger.
Like
you
know,
we
have
a
logger
provider
that
gives
you
a
logger
and
the
logger
is
an
event
submitter
provider
right.
You
can
get
an
event
emitter
based
on
that
logger
and
and
then
provide
when
you're
constructing
that
event,
emitter,
the
domain
name,
and
it
will
ensure
that
that
domain
is
added
to
every
record
that
gets
submitted
as
attributes.
B
G
This
code,
snippet,
probably,
is
a
pretty
representative
of
what
the
ergonomics
are
going
to
be.
So
you
know
somewhere
you
initialize,
and
obtain
an
instance
of
your
logger
provider,
and
then
you
know
this
could
be
done
in
multiple
lines.
I've
done
it
in
a
single
log
here
so
a
line
here.
G
This
is
this
has
got
to
be
a
concrete
thing,
because
you
know
meaning
that
there's
no
opportunity
to
have
alternate
implementations
of
it.
G
So
you
know
you
know,
once
you
have
your
event
logger,
you
just
go
ahead
and
you
you
build
up
your
events
from
it,
so
you
pass
in
an
event
name,
you
associate
some
attributes
with
it
and
you
admit
that
and
behind
the
scenes,
all
that's
going
to
do
is
it's
going
to.
You
know,
use
the
the
logger,
the
API
from
the
logger
to
construct
a
log
record
with
this
domain
and
this
event
name
and
then
the
attributes
and
the
other
data
that
you
associated
with
it.
G
So
you
know
in
the
process
of
doing
this,
you
get
rid
of
the
the
API
to
you
know
on
logger
provider
to
get
a
logger
with
the
event
domain
that
goes
away
and
the
logger
itself,
the
API
to
emit
an
event
goes
away.
All
that's
left
is
just
a
an
API
to
emit
a
log
record
and
the
event
logger
is
going
to
delegate
to
that.
So
that's
kind
of
the
idea
in
its
simplest
form.
B
D
Because
the
receivers
they
don't
know
who
produced
it
and
if
each
language.
F
B
Yeah,
okay,
the
the
I
guess.
One
reason
why
we
would
want
this
to
be
part
of
the
specification
is
if
we
anticipate
that
a
lot
of
people
would
want
to
told
against
that
API
right,
so
that
it's
not
just
something
that
the
language
maintainers
decided
to
add
as
a
Helper,
but
it's
kind
of
part
of
the
entire
open
Telemetry.
It's
endorsed
by
open
Telemetry,
encouraged
throughout.
Let's
say
industry
to
use
this
as
as
a
means
to
produce
means
to
produce
Telemetry
I,
don't
think
we're
there.
E
I
do
kind
of
like
this,
though,
because
it
kind
of
ties
into
Alan's
thing,
where
we
could
ship
blogger
provider
and
the
the
method
to
get
a
logger.
We
could
kind
of
ship
that
independently-
and
this
is
sort
of
an
add-on
thing
that
we
could
roll
into
the
spec
for
have
it
as
an
add-on.
Totally
independent,
either
way
the
sort
of
fundamentals
that
are
kind
of
more
understood
and
known.
We
could
get
out
the
door
that
makes
sense.
G
Yeah
I
definitely
agree
with
that.
You
know
this
makes
it
clear
that
events
depend
on
logs.
You
know
not
the
other
way
around.
That's
part
of
there's
some
text
down
here
where
I
I
describe
that
with
that
said,
I
you
know
and
I
definitely
endorse
this.
This
proposal
I
think
this
is
a
good,
a
good
solution
and
it
it
clearly
splits
events
and
logs
in
a
way
where
you
could
proceed
with
maturing
logs
without
having
to
answer
all
the
event
questions.
G
So
it
does
that
in
a
very
clean,
clear
way.
I
still
do
think
that
you
could
do
even
if
you
weren't
a
do
a
change
like
this,
you
could
still,
you
know,
continue
to
mature
logs
in
with
like
a
with
partial
maturity.
G
So
you
know
some
parts
stable
or
what
do
we
call
it
like
mixed
maturity
where
some
parts
are
stable
and
what
some
parts
are
experimental
and
there's
some
there's
some
good
examples
of
that
in
metrics,
where,
like
key
parts
of
the
metrics
SDK,
you
know
there's
apis
that
are
expressed,
and
you
know
their
like
views
views
a
part
of
what
you
should
be
able
to
configure
with
a
view
is
the
Exemplar
filter
and
that's
still
experimental
and
yet
views
themselves
are
stable,
and
so
you
know,
even
even
you
know,
arguments
to
an
API
can
have
mixed
stability.
G
G
Well,
take
some
time
to
review
that
asynchronously
and
if,
if
I
get
a
couple
more
thumbs
up
on
it
I'll,
you
know
I'll
open
a
proper
PR
that
you
know
makes
the
the
the
changes
corresponding
to
that.
B
Okay,
another
thing
I
suggest
that
we
do
is
that
we
first
merge
the
clarification
that
Santosh
did,
because
it
clarifies
the
semantics
of
what
the
domain
is.
We
need
it
anyway
if
we
decide
to
keep
it
as
a
separate
thing
and
after
it's
merged,
we
file
another
PR
that
moves
the
domain
to
from
the
scope
to
the
world
record
and
if
that
gets
merged,
then
we
discuss
about
whether
we
want
to
combine
all
skills
into
a
single
one.
D
No
I
think
the
other.
My
concern
is
that
there
are
folks
looking
at
this
spec
from
our
back-end
teams,
and
we
want
to
give
them
updates.
On
the
you
know,
fewer
updates,
not
like
many.
B
I
I,
don't
think
that's
the
right
approach
Hunters
this
is
this
is
work
in
progress.
We're
not
even
making
releases
restricting
our
I
guess
size
of
iteration.
The
granularity
of
our
work
is
is
going
to
hurt
us,
make
it
larger,
and
it's
going
to
be
very
difficult
to
to
agree
on
what?
What
exactly
is
in
the
pr.
D
G
F
Could
be
done
in
terms
of
sequencing
is
to
remove
the
discussion
in
santosh's
clarification
PR
regarding
location
of
these
attributes,
but
keep
the
discussion
regarding
what
they
mean
so
that
the
semantic
conventions
currently
don't
say
that
event
domain
lives
in
instrumentation,
scope,
attributes
and
if
we
remove
that
from
this
PR
it
won't
and
then
we
can
just
go
back
and
remove
from
the
logger
API
that
discussion
and
I
think
we've
accomplished.
That's.
B
That's
fine!
That's
fine!
That's
fine!
I'm
I'm,
only
saying
that's
not
combined
in
a
single
PR,
the
movement
of
the
event
domain
from
the
scope
to
the
log
record
and
introduction
of
a
new
events.
Api
helped
API,
because
the
events
API
likely
will
need
a
lot
of
discussions.
There
will
be
small
details
that
we
would
want
to
refine
and
I.
Don't
want
that
to
block
the
decision
to
move
the
domain
from
the
scope
to
log
record.
D
Okay,
okay,
yeah,
then
I
I
can
submit
a
PR
for
that
separate
PR.
G
I
had
a
PR
merged
that
added
contacts
to
log
record
processor
and
it
was
only
open
for
like
24
hours
because
it
did
a
very
narrow
small.
C
D
But
we
are
not
doing
that
in
one
in
one:
go
I.