►
From YouTube: 2022-07-11 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
C
C
All
right,
happy
monday,
everybody
so
we'll
get
started
with
the
usual
sick
check-in
and
then
we'll
move
on
to
special
topics.
Starting
with
the
specification
sig
looks
like
for
metrics.
We
are
currently
adopting
the
otlp
partial
success
extension
from
from
the
proto,
which
will
be
relevant
for
sdk
exporters
once
merged.
We
have
anyone
from
the
spec
group
who
wants
to
speak
to
what
this
means
in
practical
terms,
for
maintainers.
B
For
maintainers,
it
means
that
they
can
in
the
exporters
they
can
check
for
the
partial
success
in
the
response,
and
if
it's
a
partial
success
means
partial
non-success
right
so
that
maybe
you
want
to
log
that,
or
or
or
maybe
maintain
a
metric
for
for
failed
for
failed
responses.
B
It's
still
in
progress.
There
is
an
open
pr,
so
it's
not
done
yet.
B
D
Can
you
add
a
pr
that
pr
just
a
link
beating
us,
please
yeah
yeah?
Thank
you.
C
B
Yeah
this
is
this-
has
been
open
for
quite
some
time
now.
This
is
primarily
in
an
alignment
document
right.
This
is
a
more
of
a
declaration
of
an
intent
to
have
an
events
and
logs
api.
B
It
describes
the
in
high
level
terms
what
we
want
to
do
and
the
we
this
will
be
followed
by
specific
prs
against
the
specification
repository
which
which
defines
the
the
actual
api
the
author
doesn't,
but
we
we
have
the
alignment
now
we
didn't
have
any
objections
and
we
had
a
number
of
people
who
did
agree
to
move
forward
with
this
approach.
So
this
is,
I
think,
it's
it's
a
good
thing
that
we
have
this
agreement
now
this
there
will
be
more.
B
There
will
be
prs
directly
against
the
specification
repository
which
say
which
describe
the
actual
events
and
logs
api,
so
keep
an
eye
on
it.
Excellent.
C
D
B
The
first
one
is
about
what
what
needs
to
be
done,
so
we
did.
What
are
the
conditions
before
we
decide
that
one
1.0
should
be
declared
for
otlp?
I
think
mostly
we're
in
alignment.
There
are,
so
there
are
a
couple
that
I
think
we
need
to
resolve
them
all
right,
they're,
just
I
think
at
least
one
that
is
unclear
which
way
we
go,
but
we
still
need
to
to
decide
one
way
or
another
about
what
we
do,
which
is
about
the
the
json
encoding.
B
So
it's
the
short
keys
proposal,
and
there
are,
I
guess,
strong
opinions
both
ways
against
that
as
well.
So
maybe
we
don't
do
that
actually,
but
if
this
is
something
that
you
you're
interested
in,
I
would
like
to
see
more
more
eyes
on
this,
particularly
on
the
short
keys
and
also
on
the
the
generally
on
the
conditions
or
what
remains
before.
We
actually
go
ahead
and
declare
t
of
this
table.
C
B
C
C
Okay,
moving
on
to
the
implementation
so
for
php,
0.0.13
released
for
both
trip
and
core
we've
got
five
issues
remaining
before
the
beta
release.
That's
fantastic!
No!
Updates
for
java
java,
instrumentation
javascript
still
burning
down
metrics.
Ga
we've
got
six
items
to
do
three
in
progress;
switch
from
a
yaml
template
syntax
for
bug,
reports,
which
is
drastically
increase
the
quality
of
bugs
nice
daniel
for
js
like
this
is
not
just.
This
is
not
like
a
pressure
thing,
I'm
just
curious
like
like.
A
I
mean
I
would
have
thought
we'd
be
done
by
now
so
making
time
estimates
is
always
difficult,
maybe
a
month
or
less
okay.
C
Yeah,
I
I
really
don't
that's
fine
cool,
just
curious
python.
Metrics
rc2
has
been
released,
working
on
the
stable,
metrics
release,
cool
no
updates4.net,
but
for
go.
We've
got
the
metrics
sdk
alpha
70,
complete
22,
open
issues,
52
closed,
it's
great
progress,
released
version
1.8
last
week,
c,
plus
symmetrics
rc
is
45.
Complete,
we've
got
five
open
issues
and
one
issue
in
review:
we've
merged
the
otlp
grpc
exporter,
http,
is
in
review
and
memory
memory.
Metric
exporter
is
in
review
traces.
C
We
have
an
improvement
on
abi
compliance
and
async
http
support
for
zipkin
and
otlp
is
in
next
for
the
collector
no
noticeable
update
added
tooling
for
our
change
logs.
This
might
be
useful
for
other
cigs.
C
Just
whoever
wrote
this
for
the
collector
want
to
expand
on
how
this
could
be
useful
or
I
mean
actually,
I
think
people
probably
understand
the
usefulness.
Do
you
want
to
expand
on
what
the
tooling
was.
E
Yeah
I
can,
I
can
describe
the
tooling,
so
basically
the
you
know,
the
problem
was,
of
course,
collisions
in
the
changelog
happening
frequently
and
causing
us
to
have
to
rerun
ci,
so
we
basically
have
a
process
now
where
we
have
an
unreleased
directory
and
basically
each
pr
is
expected
to
add
a
very
simple
yaml
file
to
that
directory.
E
There
is
a
tool
written
in
go
and
hooked
into
our
make
file
that
will
basically
auto
generate
that
file.
It
will
validate
all
the
files
in
that
directory
and
it
will
consume
all
the
files
in
that
directory
and
insert
them
into
the
change
log
at
the
release.
Time.
Basically,
and
then
there
are
checks
in
the
ci
in
the
github
actions
as
well.
E
C
A
A
So
if
you
touch
a
package,
it
automatically
updates
the
change
log
when
a
release
is
made
based
on
the
pr
title
from
it,
uses
the
the
semantic
or
not
conventional
commits
specification
to
determine
whether
it's
like
a
feature
or
a
bug
or
a
breaking
change
or
whatever.
It
also
increases
our
version
numbers
for
our
sub
packages.
C
C
All
right
moving
on
we'll
finish
with
the
community
demos,
so
there's
an
announcement
blog
post
that
was
published,
but
not
yet
mentioned
here.
So
you
can
go
on
this
link
to
read
it
currently
discussing
testing
documentation
and
our
release.
Cadence.
C
In
that
case,
then
we're
done.
Thank
you
very
much.
Everybody
welcome
back.
If
you
were
on
vacation
last
week.
Obviously
lots
lots
still
to
do
for
metrics
to
wrap
up
a
few
language
releases,
but
there's
lots
of
great
stuff
happening
here.