►
From YouTube: 2022-03-28 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
A
I
think
we
discussed
this
a
fair
amount
last
week.
If
you
didn't
join
us
last
week,
whether
we've
set
the
status
we
call
mixed,
meaning
most
of
the
metrics
sdk
is
confirmed
to
be
stable.
It
is
ga
there
are
a
few
exceptions
like
exemplars
that
will
be
coming
later,
but
for
all
practical
purposes
it
is
stable
and
we
should
begin
with
our
release
candidate
and
ga
implementations,
which
is
something
we're
checking
in
on
today.
So
that's
the
big
update
for
the
spec
and
for
metrics
for
logs
for
log
collection,
we
reached
version
.28
today.
A
The
log
data
model
update
breaking
changes
that
we
discussed
last
week
are
tigran
curriculum
from
wrong,
but
I
assume
that
those
are
merged
in
at
this
point
and
there's
a
proposed
merge
to
collect
your
contrib
here.
This.
B
Is
specifically
about
the
log
collection
library
bingo
in
general,
which
we
talked
about
before
yeah,
then
then,
maybe
he's
in
the
call
then
do
you
want
to
add
anything.
C
Yeah,
basically,
the
release
today
will
just
align
the
log
collection
library
with
the
final
data
model
for
logs,
and
so
it
does
include
a
few
breaking
changes
in
the
collector
and
then
basically.
The
other
point,
though,
is
that
I
proposed
to
merge
the
log
collection
library
into
the
collector
contrib
repository,
and
it
was
basically
the
sole
user
on
it,
and
this
will
streamline
a
lot
of
workflows.
C
Yeah
basically
collector
and
logs
related
if
you're
interested.
But
you
know,
if
anyone
has
an
opinion,
please
feel
free
to.
A
D
Timelines
that
they're
looking
at
yeah,
so
we
don't
have
a
plan
for
a
release
candidate,
but
we
have
plans
to
release
the
the
ga
version
on
april,
8th,
oh
okay,
you're
just
going
to
skip
an
r
see.
I
guess,
then:
that's
that's
the
planet.
Right
now,.
A
It
might
be
okay,
okay,
cool
interesting,
any
feedback
from
other
stick
maintainers.
Typically,
we
go
through
an
rc
than
a
ga,
but
I
I
don't
really
know
if
I
have
thoughts
about
this.
E
D
So
why
why
why
are
we
not
doing
a
release
candidate?
I
would
sum
it
up
as
as
we
don't
know
so
so
I
would
be
open
to
doing
a
release
candidate
personally,
but
we
view
it
as
extra
overhead
right
now
or
I
guess
that's
that's
the
opinion
right
now.
We
could
go
back
and
change
that
and
do
a
release
candidate.
There
have
been
changes
since
our
prior
release
to
the
what
will
be
the
ga
release,
but
it's
narrowing
the
api,
our
public
api,
surface
area,
there's
no
widening
so.
A
Okay,
so
I
guess
in
some
sense,
because
you've
had
releases
that
included
metrics
in
the
past
you're
fairly
comfortable
with
it.
Is
that
accurate,
yes,
okay,
okay,
moving
on
for
javascript
for
expected,
metrics
beta
hope
for
this
week
next
week
is
more
likely
expected.
Metrics
actual
release
candidate
tbd
and
of
april
is
the
target
date
to
give
a
buffer
before
kubecon
hope
for
ga
before
kubecon
fantastic,
currently
working
on
updating
exporters
to
work
with
the
new
sdk
prometheus
is
done.
A
Otlp
is
in
progress,
also
implementing
clarifications
from
the
spec
around
shared
meter,
state
and
meter
identity.
Remaining
issues
are
small
and
not
holding
up
the
release.
Great
great
update
python
expected
metrics
release
candidate.
We
have
an
experimental
release
already.
Ga
is
pencilling
for
end
of
april.
Okay,.
F
Yeah
I
have,
I
haven't,
discussed
that
with
the
receiving
maintainers.
Yet
we
do
have
an
a
release
that
includes
metrics
that
has
been
announced
that
they
can
use,
and
we
are
now
pretty
much
going
through
the
depending
issues.
Hopefully
we
can
look
at
that.
A
Okay,
that's
the
update
for
net
expected
metrics
rc,
we're
in
rc3
doing
rc4
this
week.
Push
from
last
week
expected
expected
metrics.
Ga
that's
been
helpful,
is
in
one
to
two
weeks,
looks
like
we
don't
have
anyone
from.net
present
to
talk
about
it,
but
cjo
provided
these
updates
offline?
Thank
you.
Cjo
for
go
released
version
1.6
and
corresponding
version.
A
0.28
last
week
contains
a
revised
metrics
api
that
implements
the
stable
spec,
supports
more
configuration
via
environment
variables,
already
working
on
a
revised
metrics
sdk
that
implements
the
new
spec
rc
could
be
anywhere
between
a
few
weeks
to
a
few
months.
Yep
I
heard
it
was
a
little
behind
the
other
ones.
Ga
would
also
be
a
few
months
few
weeks
to
few
months
after
rc
obviously
depends
on
feedback
to
the
rc
c,
plus
expected
metrics
release
candidate
target
for
end
of
april.
A
Ga
no
dates
finalized
yet
could
come
once
one
month
after
rc
obviously
be
dependent
on
that.
Looking
for
more
contributors
for
the
metrics
sdk
work,
ruby
work
on
the
metrics
rc
is
in
progress.
No
eta,
no
updates
for
swift,
collector
next
release
is
scheduled
for
this
week.
This
will
include
otlp
version
.15,
that's
it
for
updates.
A
B
Yeah,
this
is
about
defining
what
currently
is
undefined
in
our
versioning
and
stability
document,
particularly
what
guarantees
we
provide
about
the
stability
of
the
semantic
conventions
and
what
guarantees
the
instrumentations
provide
about
the
telemetry
that
they
emit.
This
pr
is
an
attempt
to
define
both
right
through
the
the
concept
of
telemetry
schemas.
B
It
impacts
all
of
the
instrumentation
implementations
and
impacts
how
we
work
with
semantic
conventions
in
the
specification
and
for
I
think,
it's
worth
for
every
maintainer
of
for
all
four
of
our
languages,
to
have
a
look
at
the
proposal
and
and
give
some
feedback
and
say
whether
it
works
or
doesn't
work
for
for
that
language.