►
From YouTube: 2022-09-20 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
C
B
C
I
have
not
done
that
yet
I
was
still
collecting
my
thoughts.
B
B
It
seems
there
is
not
much
on
the
agenda
like
anything
which
we
want
to
to
the
thing
like.
We
should
be
able
to
do.
The
release
now
like
we
are
unblocked
from
over
over.
We
haven't
merged
them
in
Max
for
histograms,
okay
yeah,
that
is
still
yeah,
but
that
I
said
we
should
be
like
unblocked.
We
should
be
able
to
do
the
release,
including
the
log,
emitter,
Event,
Source
and
sorry
log
stuff,
as
well.
B
Try
to
do
that
like
I,
do
not
know
whether
the
person
who
is
working
on
me
Max
for
histogram
is
going
to
be
available
today.
In
case
we
share
some
feedback.
So
if
that
happens,
we
can
have
the
first
Beta
release
this
week.
If
not
I
think
we
can
still
do
the
release,
because
there
are
other
components
like
the
loading
collided
stuff,
which
has
changed
significantly
now
without
any
release,
or
so
let's
try
to
do
the
first
beta
this
week.
A
B
I
haven't
gotten
around
it
yet,
but
like
I
think
like
this
week
or
whenever
we
get
close
to
delays,
I
would
probably
I'll
definitely
check
that
yeah.
C
Yeah
and
I
mean
I'm
happy
to
if
it
helps
at
all
I
don't
know
if
it
helps
I
can
walk
you
through
what
it
looks
like
I,
like
I,
said
last
week,
I
think
I
at
least
I.
Think
I
said
this:
I
went
through
it
on
my
own
Fork,
just
to
see
that
all
it
all
worked
and
you
can
kind
of
get
a
sense
of
the
two
different
flows
that
I
tried
out.
C
You
know
we
recently
removed
it.
Michael
removed
it
from
the
HTTP
client,
instrumentation
I'm.
B
A
A
B
A
B
B
When
we
used
to
create
Force
creation
of
certain
payloads,
which
we
are
not
even
interested
in
so
now,
this
would
be
like
much
better.
So
yeah
I
had
one
like
small,
very
minor
thing
to
ask
here
for
this
PR
like
now
that
we
are
guaranteed
to
only
listen
to
a
certain
set
of
events.
B
Maybe
we
can
get
rid
of
this
check
because
I
don't
think
any
of
the
other
events
are
going
to
fall
into
the
custom
path
right
now.
So
that
would
be
a
very
good
optimization
like
1.3
like
I,
know
the
whole
thing
we
can
be
very
like
much
more
faster
yeah
I'm,
already
working
on
that
so
I'm
I'm
planning
to
just
get
rid
of
all
of
these
onstart
stop
on
exception
events.
Everything
will
just
be
inside
on
custom,
okay
or
just
call
it
a
phone
event.
B
It
is.
There
is
no
start,
stop
custom.
It's
all
like
one
event:
yes,
okay,
yep
yep,
yeah,
yeah
I've
already
started
working
on
that
I'm
just
hoping
to
get
this
much,
and
then
we
can
like,
because
that
involves
the
SDK
change
as
well.
B
So
yeah
yeah
as
part
of
this
I,
think
like
I,
don't
know
whether
it's
already
in
your
mind
like
there
is
a
there
was
a
proposal
for
a
long
time
that
we
want
to
use
the
actual
type
bridge
and
filter,
which
should
also
be
like
possible,
because
we
know
those
there
is
no
need
of
any
extra
thing
we
already
know.
These
are
the
public.
B
So
just
wanted
to
make
sure
if
you
guys
are
okay,
then
we
can
merge
this
and
I'll
just
like
continue
working
on
the
other
stuff
and
okay
thanks
plans,
you
can
try
talking
again
best
test,
it
did
sound
louder,
I.
A
B
A
A
B
A
Moved
some
of
what
was
in
SDK
and
the
API,
so
it
needs
the
log
record
data
struct,
which
represents
basically
the
data
elements
for
the
log
model.
So
there's
like
severity,
timestamp
the
trace
fields
and
then
I
move
the
attribute
list,
which
is
how
you
can
pass
attributes
or
tags
on
events
or
logs
without
allocation
up
to
eight
that
that
thing,
it's
all
internal
right
now
in
apis.
A
So
then
what
I
did
in
SDK
is
I
implemented
those
providers
just
like
we
do
for
traces
and
metrics.
So
for
all
three
signals.
It's
the
same
across
the
board,
there's
the
Builder,
the
SDK
Builder,
there's
the
provider
and
then
the
provider
SDK.
All
the
extensions
find
the
same
exact
mix
so
I,
just
basically
unified
Logs,
with
traces
and
metrics.
A
Why
it
got
big,
is
I
had
to
refactor
I
just
did
a
big
PR
where
I
was
adding
all
of
that
stuff
onto
the
open,
Telemetry
logger
provider,
which
is
like
our
bylogger
implementation.
I,
basically
split
it
so
that
we
have
a
logger
provider
just
like
the
other
signals
and
then
our
eye
logger,
logger
provider.
A
The
names
are
terrible
because
they're
all
the
same,
our
ilogger
implementation
just
consumes
the
spec
provider.
So
our
eye
logger
integration,
is
more
like
what
we
have
for
Siri
log
and
Event
Source
after
this
PR,
all
three
of
them
just
consume
the
spec
logger
provider,
and
then
they
call
the
emit
methods
to
actually
write
the
data,
so
I
basically
refactored
a
lot
of
what
was
really
deeply
integrated
into
ilogger
into
its
own
spec
thing,
and
then
it
just
is
consumed.
Does
that
kind
of
make
sense.
B
A
A
A
Are
our
final
thing
that
we
give?
The
exporter
hasn't
changed,
so
the
log
record
class
that
we
pull
is
still
very
eye.
Logger
I
didn't
want
to
break
the
exporters,
but
everything
in
front
of
that.
So
how
you
code
against
the
API,
how
you
use
the
SDK.
It
is
much
more
spec
compliant,
there's
no
I
logger
polluting
anything
in
the
API
layer,
it's
just
whatever
the
spec
says
so
that
ended
up
I
kind
of
like,
but
you
guys
have
to
look
at
it
and
see
what
you
think.
One.
B
Other
person
is
like
the
the
general
client
has
to
do.
The
next
stable
to
release
is
matching
the
number
time
frame
and
Dot
Net
7
comes,
but
if
you
expose
anything
related
to
logging
from
the
loading
spec,
which
is
going
to
be
like
really
tricky,
because
they
are
definitely
going
to
be
remaining
experimental
for
next
couple
of
months
for
sure.
So,
we'll
have
like
to
do
like
something
to
remove
it
or
keep
it
internal.
So
yeah
I.
A
A
B
So
the
the
logo
provider
and
the
logo
provider
Builder,
which
we
have
in
the
public
in
the
API,
do
they
bring
like
additional
dependencies
or
is
it
just
pure
Hotel
thing?
So
maybe
because
you
are
sharing
it,
so
can
you
go
to
the
Cs
approach
for
API
project
from
this
here
like?
Is
there
any
change
there
or
is
it
still
the
same
okay?
A
If
you
look
expand
the
logs
folder
one
up
from
where
you
are
highlighted
in
the
tree.
A
A
Has
this
nice
representation
now
of
instrumentation
skill,
metrics
and
traces?
Don't
use
this?
They
could.
But
so,
if
you
look
at
52
line,
52
57,
some
of
the
properties
I
use
the
init
keyword.
So
you
can
only
set
these
properties
when
you
create
this
class,
when
you
define
your
logger
or
your
Tracer
or
your
meter
or
whatever
the
init
keywords,
kind
of
special,
it
needs
some
compiler
Magic.
So
if
you
look
there's
that
shims
folder
one
down
in
the
tree,
so
that
is
external
init.
B
A
B
A
What
would
happen
is
both
of
those
would
get
that
internal
compiler
hack.
Basically,
but
then,
if
you
consumed
into
net60,
we
had
a
problem,
because
now
it
exists
in
the
runtime
and
in
the
net
2-0
build
so
I
had
to
add
the
targets
here
so
that
the
binaries
have
the
correct
internals
when
they're
consumed
Downstream.
A
So
that's
the
first
level
of
nastiness.
We
had
to
do
the
same
thing
in
the
SDK,
so
Now,
API
and
SDK
have
the
same
targets
that
rippled
into
Siri
log
and
Event
Source,
which
now
use
that
instrumentation
scope
because
they're
using
the
internal
logger
Tracer
to
emit
logs
and
events.
So
what
was
going
on
there
is
they
had
the
same
problem.
It
just
pushed
it
to
them.
When
they
had
net
standard
2-0,
they
were
consuming
the
net
standard
2-0
from
an
Epi.
A
That
has
that
internal
thing,
and
then
they
would
blow
up
when
consumed
into
like
net
6
or
something
more
formal.
So
it's
sort
of
we
were
building
toxic
libraries
that
can't
be
consumed
in
newer
run
times,
so
I
had
to
kind
of
take
all
these
targets
and
push
them
all
the
way.
Through.
Does
that
kind
of
make
sense,
yeah.
B
But
the
thing
like
they
go
into
the
original
question
which
island
was
asking
like?
Can
we
get
rid
of
the
next
standard
Alan.
C
Can
we
get
away
with
so
I
I
think
I'm
tracking
here
at
least
90
percent?
Can
we
get
away
with
just
adding
net
60
up
here
and
then
dropping
the
net
standard
Targets
on
the
serialog
Event
Source
things,
or
is
there
more
Ripple
effects
that
maybe
I'm
not
getting
quite
yet.
A
A
A
C
So,
like
I'm
I
think
adding
a
net
6-0
to
our
API
and
SDK
is
probably
a
good
thing
regard
like,
regardless
of
whether
we
drop
net
standard
targets
for
say.net
like
a
net
five
app
consuming
the
API
or
the
SDK
they'd
grab
the
net
standard
2o
Target.
Would
they
run
into
this
conflict,
Net
5?
Does
it
have
the
the
runtime?
Does
it
have
this
thing?
C
A
A
A
C
B
A
B
Yeah
but
I
think
like
we
don't
need
to
like
worry
too
much
about
that
part,
because
the
said
Logan,
even
log
adapters
and
all
the
extra
things
can
be
a
remaining
like
experimental
for
like
near
future,
because
it's
going
to
take
more
time
for
respect
to
declare
itself
as
stable.
So
to
be,
we
we
just
need
to
gather
some
feedback
from
the
user,
so
we
don't
really
expect
people
to
run
it
in
production,
with
the
assumption
that
it's
not
quite
compatible
or
anything.
We
know
that
it's
not
going
to
be.
B
B
B
I,
don't
have
any
shy.
I
was
just
saying
like
like
what
Alan
was
trying
to
go
after
was
like
removing
extended.
This
doesn't
like
really
remote
standard
is
like
Netflix
only
so
that's
that
issue
is
still
to
be
discussed
separately
from
this
one.
C
Yeah
my
question
originally
stem
I
was
playing
yes
just
yesterday,
I
was
just
playing
around
with
for
all
of
our
packages
that
have
not
ever
had
a
stable
release,
yeah,
mainly
our
instrumentation
packages
and,
of
course,
the
serial
login
Event
Source
packages.
I
was
just
kind
of
oh
and
Prometheus
as
well.
I
was
going
across
the
board
and
just
removing
the
net
standard
targets
just
to
see
what
that
looked
like,
and
so
that's
what
originally
raised
my
question.
B
B
So
that's
a
like
something
which
we'll
come
back
next
week,
but
so
specifically
about
this
beer.
Like
do
you
see
like
any
scope
of
like
bringing
down
the
number
of
changes,
because
you
mentioned
like
it's
all
like
you're
playing
from
one
place
to
another,
so
any
because
it's
going
to
be
like
very
tricky
to
review
it
or
we'll
have
to
like
review
it.
But
we
know
that
there'll
be
like
more
follow-ups
with
the
hope
that
we
can
merge
things
and
block
progress
and
then
like
before
the
actual
stable
time.
B
You
need
to
carefully
review
all
the
public
APA
and
try
to
trim
down
as
many
things
as
possible
from
the
public
API
for
the
stable,
because
we
don't
have
like
a
ton
of
time.
It's
like
two
months
at
Max,
because
we
wanted
to
push
around
0.7.
So
so
my
question
is
like:
do
we
want
to
do
it
right
now
for
Indian
strip
of
the
public
APA
changes
by
number?
Or
do
we
just
keep
it
like
separately?
B
Don't
download
it
until
we
stamp
the
stable
version,
and
then
we
have
plenty
of
opportunity
to
experiment
like
anything
which
affects
public
API.
Now
we
need
to
be
very
careful
because
we
have
like
six
to
eight
weeks
to
release
this
table,
or
should
we
even
try
the
same
approach?
We
did
for
the
Matrix
that
can
be
move.
The
logging,
like
basically
this
PR
completely
into
the
separate
branch
code
logs
and
have
it
stay
there
until
we
ship
the
1.4
stable
in
November
and
then
bring
it
back
to
me.
A
A
A
A
Now
we
have
an
actual
Builder,
so
I
I
split
the
Two
Worlds,
so
that
class,
open
Telemetry
logger
options
has
become
essentially
just
a
Poco
of
the
options
for
our
I
logger
integration.
Okay,
just
doing
that,
it
simplifies
that
whole
mess
this
PR
was
trying
to
solve,
which
is
options
when
you
register
to
configure
calls
they
come
after
the
service
provider.
So
if
you
look
at
this
code,
it's
doing
this
whole
two
phase
thing:
it's
like
applying
options
to
different
instances.
A
B
B
Yeah
maybe
like
we
should
like
pursue
that
as
well,
because
then
we'll
have
or
like,
let's,
let's
go,
delaying
or
shipping
anything
we
don't
want
in
1.4
I
mean
I
I
want
to
hear
from
others
as
well,
because
if
we
ship
something
in
1.4,
which
we
are
not
like,
100
sure,
and
then
we
have
a
even
bigger
trouble
next
year.
So
I
would
rather
like
revert
anything
which
you
are
not
confident
and
keep
it
all
like
piled
up
in
a
separate
branch
and
like
get
the
ship
sale
for
1.4
State.
B
So
if,
if
anything
else
is
going
to
stand
in
the
Vietnam,
I
would
prefer
to
like
move
it
out
and
delay
the
loading
stuff
so
that
the
actual
metrics
changes
can
go
uninterrupted
for
the
one
1.4
time
so
I'm
generally
seeing
like
there
is
more
more
risk
because,
after
like
maybe
like
in
next
two
or
three
weeks,
we
want
to
do
like
release
candidate
kind
of
things
similar
to
what
we
did
for
like
previous
two
stable
releases
for
traces.
Like
the
closer
to
the
release.
We
want
to
have
like
less
disruptive
changes.
B
That's
why
I
don't
have
that
problem?
I'll,
see
that
as
an
issue
or
not.
That's
I
want
to
hear
from
my
calendar
also
like
what
do
you
think
of
I
mean
just
to
summarize
like
what
I
see
here
is
there's
a
fairly
big
amount
of
change,
specifically
targeted
to
logging,
and
it
has
ripple
effect,
and
it
also
tries
to
undo
some
of
the
things
which
are
already
in
the
main
branch.
B
So
my
suggestion
is,
let's
undo
it
in
the
main
branch
anyway,
because
those
are
things
we
introduced
only
since
the
last
table,
so
we
have
the
dictionary
to
remove
it
and
then
let
1.4
have
only
the
changes
related
to
The,
Matrix,
API
and
anything
which
we
are
like
super
confident
anything
else,
we'll
queued
up
in
the
separate
Branch
until
November
when
104
ships,
and
then
we
need
to
absorb
that.
That
way
like
we
can
easily
approve
PRS
to
logs
Branch.
B
We
don't
need
to
be
like
like
taking
like
very
close
attention
like
we
were
doing
it
for
this
table.
So
that
way
we
can
unblock
plants
because
otherwise
we'll
be
blocked
on
people
approving
and
people
who
definitely
need
more
time
to
approve
bigger
PRS.
B
Just
like
we
did
four
metrics,
so
if
there
are
people
we
want
to
get
feedback
feedback
from
about
the
new
logging
configuration
and
the
logging
adapter
thing,
the
cell
log
stuff.
We
should
be
able
to
like
get
still
feedback
from
them
without
affecting
control
for
and
without,
like
blocking
plans
from
getting
reviews.
C
So
yeah
I'll
just
share
my
thoughts.
Yes,
I
I
think
I'm,
understanding
all
them
options
here
and
I
think
that
that
may
be
a
legit
option
to
like
undo
some
of
the
work
that
we're
looking
at
on
the
screen
right
now,
though,
I'd
also
be
open
to
spending.
You
know
a
day
this
week
to
just
kind
of
look
at
that
PR
because
ultimately,
I
think
you
know
Michael
seems
pretty
confident
in
it
and
it
seems
like
it.
It
will
likely
be
the
direction
that
we
do
go
long
term.
C
So
I
have
no
problem
spending
some
time
this
week,
just
better
grounding
myself
in
that
PR
before
we,
you
know,
make
a
final
decision
of
whether
to
roll
back.
B
C
Or
do
something
else?
Does
that
seem
fair
to
folks
yeah.
B
B
Because
I
mean
I
I
want
to
make
sure
like
I'm,
not
looking.
Plants
from
making
progress
and
I
will
only
block
if
it
affects
the
stable
release,
so
that
that's
why
I
was
thinking
if
you
have
opportunity
to
unblock
him
without
delaying
or
affecting
1.4
in
any
way.
We
should
pursue
that.
But
let's
give
it
at
least
an
attempt
this
week
see
if
you
think
it's
safe
to
do
the
change.
But
next
week
we'll
come
back
and
yes
like,
if
you
think
it's
going
to
take
more
time,
prefer
to
Decor
back
in
logging.
B
Specific
APA
changes
like
leave
with
the
existing
login,
as
if
until
1.4
has
saved.
C
B
Another
question
so,
like
all
of
these
changes
that,
like
the
one
that
we
are
looking
at
right
now,
they
were
also
like
meant
to
bring
the
extensions
hosting
packets
so
like.
If
we
undo
these
like,
then
we
are
also
going
to
be
delaying
the
extensions
hosting
package.
B
Okay,
so
the
changes
related
to
metrics
and
tracing
which
would
enable
us
to
ship
the
stable
version
of
Hosting
can
stay
However
specifically
for
improving
login
related
one,
because
that's
the
one
which
are
likely
to
be
undone
because
of
the
bigger
PR
on
the
left
of
your
time,
the
tracing
and
Matrix
one
they
are
like
fairly
stable
compared
and
there
is
no
future
PR
which
is
coming
to
replace
them.
So
we
should
be
like
moving
forward
with
that
with
the
intention
of
shipping
it
as
stable
in
1.4.
B
A
I
agree
that
sounds
that
sounds
good
like
I
could
I
could
revert
the
logging
stuff?
That's
that's
fine,
so
I'll
wait
I'll,
wait
to
hear
from
Alan
yeah
Alan.
Do
your
thing:
I'll
I'll
continue
on
that
PR
I
have
to
build
out
the
the
description
a
little
bit
and
show
the
public
API
and
stuff
so
I'll
ping.
You
when
I'm
done,
give
me
a
couple
hours
today
and
then
you
can
look
at
it
and
then,
based
on
that
I'll
we
can
either
get
it
in
or
I'll
basically
revert
this
yep.
B
Sounds
good
yeah
and
the
topic
of
like
removing
net
standard
I
think
like
bro,
we
we
should
come
back
to
Tech
next
week
because
we
have
to
meet
I.
Think
plan
wanted
to
talk
to
Nova
and
Terex
from
the.net
runtime,
but
due
to
internal
Microsoft,
even
like
no
no
meeting
is
happening
this
week.
So
it
will
be
only
next
week
when
we
can
revisit
that
topic.
C
Sounds
good
on
just
on
that
topic,
one
thought
that
I
was
that
I
had
on
my
mind
was
you
know,
we've
been
making
changes
that
I
I
think
you
know,
may
not
people
may
not
have
totally
digested
yet
you
know,
like
we've
removed
the
net
standard
targets
from
the
ASP
net
core
instrumentation
we've
just
removed
it
from
the
HTTP
instrumentation.
C
You
know,
I
made
an
attempt
to
kind
of
clarify
the
change
log
notes
just
to
kind
of
emphasize
to
folks
hey.
You
know
if
you're
on
net31
or
net
five.
C
This
is
this
isn't
going
to
work
for
you
anymore,
you're,
going
to
have
to
stay
on
the
old
instrumentation,
but
I
was
thinking
like
as
we're
developing.
What
our
final
strategy
is.
C
Be
if
I
mean
we
have
the
one
issue
that
Michael
made
that
kind
of
goes
it's
our.
The
conversation
is
already
long
and
it
kind
of
goes
into
the
Weeds
about,
like
you,
know,
people's
opinions
or
thoughts
about
how
to
proceed.
But
I
was
wondering
if
we
could
just
have
like
kind
of
an
announcement
issue
where
we
maybe
draft
up
at
least
our
current
stance
and
then
evolve
it
between
now
and
when
we
do
the
one
for
stable
release.
C
B
We
should
try
to
do
it
here
and
probably
in
the
announcements
in
the
open,
telemetry.io
has
a
section
4,
we
can
do
announcements,
but
if
it's
just
for
the
like
non-stable
packages,
I
think
we
can
create
an
issue
and
pin
it.
That
would
be
like
making
it
like
catching
more
attention.
So
people
know
okay,
we
are
doing
some
things.
We
are
getting
support
for
some
framework
for
X
and
Y
package.
Design.
Here
goes
the
reasoning
and
they
can
comment
whether
it
makes
sense
or
not.
C
B
C
I
and
yes,
I
I,
think
right
now,
we've
only
touched
unstable
packages,
but
if
we
do
ultimately
start
entertaining
doing
the
you
know
the
stable
packages
I
would
just
evolve
that
that
pinned
issue
to
just
be
current
up-to-date
kind
of
announcement
of
what
we're.
B
Like
does
this
announcement?
Does
this
get
a
lot
of?
Is
that
like
a
this
is
one
option
and
because
we
did
this
and
then
we
have
in
issues
there
is
a
pinned
issue
thing.
Okay,
it's
been,
we
originally
did
the
field
issue.
The
report
did
not
have
discussions
enabled
so,
let's
see
so
right
now,
if
you
go
to
issues
you
can
see,
pin
dishes
that's
what
we
were
using
to
do
the
Matrix
announcement
and
all
those
things,
because
we
basically
removed
metrics
from
the
core
plans.
So
we.
C
B
Thing
so
we
can
actually
move
things
into
announcements,
so
the
issue
which
we
have
been
we
can,
if
you
log
in
as
an
admin,
you
have
the
ability
to
change
that
issue
into
the
announcement.
I
think
this
was
done.
That
way.
This
can
you
click
on
the
Matrix
support
plan
and
release
date
from
an
expand.
You
click
it.
It
was
not
a
discussion
or
announcement.
It
was
originally
just
a
any
other
GitHub
issue.
Then
I.
B
There
was
an
option.
Yeah
create
issue
from
discussion,
or
there
is
vice
versa.
A
B
So
that
way,
I
was
able
to
convert
that
into
a
discussion
and
tag
it
as
announcement.
So
does
this
notify
people
better.
B
But
at
least
this
looks
like
a
very
like
official
place
to
put
announcements.
Maybe
we
should
get
a
lot
of
like
news.
That's.
B
Yeah,
so
can
you
go
to
the
issues
the
one
we
have
for
the
latest
four
pics
release:
yeah
click
on
that.
Maybe,
since
you
are
logged
in
as
yourself,
you
should
be
able
to
see
an
option
to
change
it
too.
Yeah
convert
to
discussion.
Okay,
let's
do
it
right
now,
if
no
one
is
opposing,
let's
make
it
an
announcement.
B
You
click
on
it
yeah
it's
already
going.
C
B
B
B
C
B
B
A
C
B
B
B
A
B
This
I
was
just
saying,
like
you,
can
write
one
more
sentence
saying
this
is
done
just
to
unblock
1.4
stable,
which
is
expected
to
happen
number
this
year
and
we
don't
want
any
known
any
risky
thing
or
any
non-stable
thing
to
be
part
of
that
release.
B
Any
what's
the
adjective
non-stable,
because
the
logs
logs
thing
might
have
dependency
on
a
experimental,
spec,
okay,
yeah
yeah.
This
is
good
and
I'd
like
to
show
like.
If
someone
reads
the
meeting
notes,
they
have
some
opinion.
They
can
come
back
at
least
after
seeing
what
we
discussed.
Yeah.
B
Okay,
I,
have
to
believe
now,
but
I
don't
see
any
opening
topics.