►
From YouTube: 2022-12-05 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
B
B
Good
morning,
everyone
welcome
back
to
the
maintainers
meeting.
Apologies
I
haven't
been
here
for
a
few
weeks.
I
was
traveling
and
then
I
was
sick,
but
it's
good
to
see
everybody
again.
So
we'll
start
with
a
Sig
check-in
and
then
I
know.
We
have
a
few
special
topics
for
discussion
today,
but
saw
some
Community
PR's
there
and
probably
some
other
topics
too
so
starting
from
the
Sig
check-in
for
the
spec.
We've
got
a
release.
B
Pr
later
today,
I
wasn't
here
last
few
weeks,
so
I'm
guessing
that
the
the
contents
of
that
were
probably
discussed
in
the
last
few
weeks.
So
unless
Carlos.
B
Okay,
no
major
updates
for
logs
and
for
the
Proto
for
PHP,
no
major
updates,
Java
the
SDK
monthly
release
will
be
the
end
of
this
week.
Instrumentation
and
contribute
monthly
releases
will
be
next
week
for
python,
no
new
updates
same
for
JavaScript
and
then
for
go.
We
have
release
a
0.34.0
which
is
100
complete
and
we
will
release
that
later
this
week,
quick
question
for
the
go
people
and
apologies.
This
was
discussed
the
last
two
weeks.
A
Yeah
so
I'm
hopeful
that
the
next
release
following
this
one
will
be
a
Beta
release.
I
think
we're
about
80
through
our
beta
backlog
and
unless
anything
significant
comes
in
there.
It's
my
hope
at
least
that
we'll
be
able
to
get
the
next
release
out
as
a
beta.
B
That's
awesome
exactly
C,
plus
plus
we've
released
version
1.8.1,
which
contains
several
bug,
fixes
and
then
moving
down
to
erlang
we've
released
an
alpha
of
metrics
this
week
and
then
no
major
updates
for
the
community
demo
or
the
consig
L
looks
like
we're
getting
an
update
here
for
the
collector.
B
Release
is
coming
this
week,
cool
so
the
first
of
our
special
topics.
We
have
a
community
PR
here
allowing
maintainers
to
have
admin
rights
if
they
request
I,
don't
know
who
added
the
agenda.
So
if
you
added
it,
please
speak
up.
D
And
I
can
figure
out
how
there
we
go
all
right,
so
this
was
discussed
last
week
by
the
GC
and
because
it's
come
up
a
few
times
in
the
past
and
so
trying
to
so.
The
proposal
is
to
allow
maintainers
to
have
admin
rights
if
they
request
and
to
revisit
this
in
a
year
in
case
we're
at
a
different
place.
You
know
maturity
wise,
maybe
tooling,
wise,
that
we
can
lock
those
rights
down
more.
D
But
at
this
point
it
doesn't
feel
like
we
are
without
causing
burden
on
the
maintainers,
which
is
not
something
that
is
we
want,
so
what
it
the.
So
what
I'd
like
kind
of
the
call
for
folks
on
here.
D
So
the
main
thing
here
is:
if
we
as
maintainers,
do
have
admin
permissions,
then
we
need
to
document
changes
that
we
make
to
the
repository
settings
in
a
file
in
the
repo,
and
so
we've
been
doing
this
in
the
Java
in
the
Java
repo
for
a
while,
which
I
found
helpful
anyway.
Just
to
sort
of
so
that
everybody
is
aware
of
what
settings
we've
enabled,
especially
around
the
branch
protection
rules
which
can
be
tricky,
and
so
that's
sort
of
the
trade-off
there.
D
But
I
think
it's
a
good
thing,
and
so
what
kind
of
just
checking
from
everybody
here
to
take
a
look
and
see,
if
that's
clear
what
you
would
need
to
do
then
to
have
or
maintain
admin
privileges.
C
One
one
thing
to
ask:
there
are
some
things
that
we
don't
want
to
touch
like.
It's
still
a
permission,
lcla
checks,
so
is
that
somewhere
documented?
Where
things
that
add
me
I
mean
one
of
the
reasons
why
it.
D
So
Branch
protection
rules,
so
this
is
the
defaults,
but
then
it
says
the
only
ones
of
the
these
are.
As
Bogdan
said,
these
are
really
important
and
shouldn't
be
changed.
So
in
general
the
only
one
of
these
rules
that
can
be
changed
are
number
of
approvals
required
can
be
more
than
one.
D
D
C
Yeah,
go
ahead
should
so
we
are
waiting
for
the
pr
to
be
merging.
Then
we
enable
this
or
what's
the
roadmap
for
this
yeah.
D
C
E
B
The
next
is
another
Community
PR
this
one's.
For
me,
this
is
an
official
project
roadmap,
so
we
discussed
this
in
cubecon
Valencia.
We've
discussed
this
on
this
call
after
that,
and
we
also
had
a
big
group
meeting
in
Detroit
to
discuss
all
of
the
different
things
that
we
want
to
and
that
we
can
work
on
as
a
community
within
open.
Telemetry
logging,
obviously
is
is
a
big
thrust.
B
Metrics
was
a
big
thrust
and
continues
to
be
and
there's
various
other
things
that
have
been
bubbling
up
like
client,
instrumentation
and
profiling,
and
digging
into
our
semantic
conventions
and
various
others,
and
so
what
I've
done
here
is
an
attempt
to
take
all
of
those
discussions
put
together
a
list
of
the
current
set
of
sort
of
objectives
and
priorities
that
are
within
the
community
and
I've
put
down
priorities
against
those
just
to
be
clear
for
everyone
like
this
is
mostly
me
cataloging
the
work
that's
going
on
this
isn't
like
me
or
the
GC
coming
in
and
saying
like.
B
You
must
work
on
this
open.
Telemetry
is
not
a
company,
we
don't
work
for
each
other,
there's
some
sort
of
a
huge
hierarchy
here.
People
work
on
what
they
want
to
work
on
or
what
their
employers
want
them
to
work
on,
and
so
this
has
started
really
as
an
effort
as
catalying.
What
people
are
already
doing.
B
That
being
said,
I
think
there's
value
in
this
in
allowing
people
who
maybe
have
options
of
what
they
can
work
on
or
looking
for
for
projects
within
the
community
to
assist
with
for
them
to
find
out
what
our
big
priorities
and
their
objectives
are.
So
this
can
help
us
focus
our
efforts
within
open
Telemetry.
So
I've
created
this
as
a
PR.
Again,
it's
just
based
on
those
conversations.
B
There
shouldn't
be
any
surprises
here
for
people,
but
please
please,
please
come
in
and
comment
propose
suggestions
if
you
think
things
are
misordered
here
like
please
go
and
edit
that
if
you
think
the
the
writing
could
use
some
some
help,
please
go
go,
make
some
edits
with
that
as
well,
and
then
we'll
get
this
merged
in
within
a
week
or
two
I'm
not
going
to
go
over
it
sort
of
line
by
line
here.
B
B
That
being
said,
any
discussion
now
and
I'll
also
bring
this
up
in
in
future
weeks,
so
we
can
discuss
in
the
future,
but
are
there
any
comments?
Questions
about
this
right
now.
B
Okay,
so
give
people
a
week
to
go
over
this,
we'll
discuss
it
again
in
one
week
in
the
maintainers
meeting
and
then
we'll
discuss
it
the
following
week
and
if
there
are
no
pending
items,
then
we'll
merge
it
in,
and
this
will
be
on
the
community.
Repo
and
I'll
also
try
and
get
it
pulled
into
the
website,
because
I
know
people
who
are
a
little
less
involved.
B
E
Yeah
I,
don't
think
this
is
exactly
covered
by
the
the
spec,
so
I
thought
I'd
raise
it
because
I'm
as
metrics
as
we're
getting
closer
with
the
metrics
release
in
erling
and
wanting
to
get
people
to
use
it.
E
One
of
the
barriers
I
find
often
is
being
in
an
experimental
package
and
I
mean
it's
going
to
be
a
barrier
even
if
it's
in
a
the
stable,
stable
with
a
Beta
release
but
I'm
wondering
if
people
have
used
in
other
cigs
when
they
take
something
like
metrics
and
it's
an
experimental
package.
Do
they
then
put
it
into
a
into
the
main
SDK
and
API
and
Mark
those
releases
as
beta
or
do
they
not
move
it
until
things
are
stable
and
out
of
experimental
I'm,
just
wondering
what
people
have
been
doing.
C
Is
is,
is
possible
in
in
Ireland
to
have
so
so
majority
of
the
languages
that
I
know
personal,
they
have
packages
and
they
have
artifacts
or
modules.
So
essentially,
there
is
a
package
for
import
package
and
there
is
the
the
artifact
that
you
produce
a
new
release
as,
for
example,
in
Java,
a
jar
or
in
Mojo
or
or
things
like.
That,
is
this
something
that
you
have
in
erlang
or
or
yeah.
So.
E
A
C
So
what
I've
seen
so
far
was
that
people
were
putting
them
the
the
this
experimental
in
the
final
import
package,
but
they
were
releasing
them
in
a
module
or
a
jar
marked
as
experimental
so
essentially
because
I
have,
because
in
Java
we
have
these
two
Notions,
for
example,
or
in
go.
There
are
these
two
Notions
you
could
put
them
into
the
import.
The
final
import
package,
but
you
you,
the
artifact
that
you
release
you
mark
them
as
experimental
beta,
stable
or
whatever
you.
E
C
Essentially,
there
will
be
and
I
don't
think
there
is
that's
something
that
God
can
answer
or
or
Java,
but
I
don't
think
there
is
necessarily
a
desire
to
end
up
with
them
in
the
same
artifact
in
the
same
genre,
for
example,
as
long
as
both
jars
are
marked
stable,.
E
Okay,
so
are
you
saying
that
the
experimental
artifact
contains
everything
like
the
experimental
SDK
contains
the
stable
parts
and
the
metrics
part
no.
C
E
C
Is
that
does
that?
Does
that
break
user
so,
for
example,
if
I'm
using
right
now
after
your
move,
do
I
need
to
break
so?
Is
that
just
the
the
just
the
encapsulation
of
things
or
is
the
that
gonna
cause
me
and
a
breaking
code
change
that
I
have
to
teach
Imports
and
stuff
like.
E
That,
if
you
were
well,
you
don't
have
to
change
Imports
or
anything,
but
you
would
have
to
it.
There
might
be
breakage
between
Alpha
Beta
and
then
the
stable,
but
the
idea
would
be
people
wouldn't.
If
they
chose
to
switch
to
the
Alpha
version,
they
would
be
accepting
breakage,
but
it
would
be
in
the
technically
stable
API
SDK
packages
artifacts
that
we
use.
F
Yeah,
at
least
in
JS,
that's
what
we've
done.
We
keep
an
experimental
package
and
once
we're
ready
for
it
to
be
stable,
we
move
it
into
the
regular
package.
Okay,
but
our
SDK
packages
are
separate
anyways.
So
we
we
have
one
API
package,
but
that
we
have
a
metrics
SDK
package
and
a
trace
SDK
package
and
a
logs.
F
So
we
just
rename
the
package
to
remove
the
experimental
from
the
name.
Gotcha
division,
no
1.0
got
you
yeah,
it's
different
experimental
is
never
in
the
name.
I'm,
sorry
I
I
just
like,
but
the
the
version
number
we
just
bumped.
The
version
number
to
1.0.
F
Okay
and
we,
we
essentially
have
two
and
JS
because
of
the
deployment
size
issue
on
browsers.
People
complain
a
few
put
too
much
extra
stuff
in
any
one
package.
E
B
Okay,
thanks
Tristan
the
next
topic.
It's
the
final
on
the
list
is
for
keep
kind
of
you.
There
was
an
email
that
went
out
tall,
maintainers,
asking
them
to
submit
Talk
ideas.
We
submitted
one
on
behalf
of
the
GC.
Just
to
lock
up
the
spot,
Ted
had
suggested
doing
a
deep
dive
on
open,
Telemetry
semantics,
which
I
think
is
actually
a
really
interesting
idea
for
for
a
talk
to
a
couple
hundred
people
at
a
conference.
B
C
Oh,
this
is.
A
B
April
or
or
may
I'd
have
to
double
check
the
date
and
that's
it
for
topics.
So
thank
you
very
much.
Everybody
see
you
on
the
various
other
Sig
calls
and
if
not,
then
we'll
see
you
next
week.
Thank
you
very
much.